What are two effective ways for the scrum team to make a non-functional requirements visible?

In this article, we will see what non-functional requirements are, and how they are elicited and captured in agile projects. You will understand the concepts through a few examples, and get to know the difference between functional & non-functional requirements. The impact of non-functional requirements in solution development is discussed, together with the implementation approach.  

Understand the concepts of non-functional requirements through a few examples, acceptance criteria, their impact in solution development and user stories examples, and more.

What is Non-Functional Requirement? 

“In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behaviour or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements” 

Source.

While functional requirements define “what” the system should do, non-functional requirements define operational capabilities and constraints that enhances the functionality and “how” the system should do it. They specify quality attributes of a system. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide v3) describes non-functional requirements as requirements that “do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have” (p. 16)  

How to Elicit Non-Functional Requirements? 

When the business analysts elicit requirements from the stakeholders on the functional aspects of the system, they also should understand from the stakeholder what attributes the system should provide in order to meet their business goals. For example, the website must be able to load within 0.5 seconds. 

Eliciting a non-functional requirement is more challenging than the functional requirement, as the stakeholders/users are good at articulating the functional requirements well; while they may not be aware of, or good at explicitly stating non-functional requirements. Business analysts will have to get these requirements from stakeholders by asking the right questions. 

NFRs are implicit by nature, meaning that people assume them to exist without being asked. 

Some of the questions to be prompted that may help the business analyst to ask stakeholders how they want their system to function include the following aspects: 

• Performance – speed of the system e.g., response time, throughput etc 
• Availability – what is the impact if the system is not available for the customer? 
• Security – ensuring unauthorized access to the system 
• Data Retention - how long should the data be retained in the system for reference? This could be a regulation from the government/country. 
• Usability – easy access for the customer/user while using the system 
• Stability – code/system stability when dynamic changes apply due to business needs 
• Compliance – understanding compliance needs by local laws/regulations 
• Reliability – probability of system performing without failure 
• Recoverability – ability of the system to recover from failure 
• Serviceability – ease of system service when necessary 
• Data integrity – accuracy and correctness of data maintained in the system 
• Scalability – ability of the system to scale when more resources are added 
• Capacity – how much the system can store information 
• Accessibility - how easily people with the widest range of capabilities can use the system. 

Non-Functional Requirements in Agile 

A common challenge for an Agile team is dealing with capturing non-functional requirements in a user story. The non-functional requirements can be written as a user story and made available in the product backlog or sprint backlog.  

For example, “As an ecommerce website user, I want the website to be available for 99.99999%, so that I purchase products whenever I feel like” 

NFR can also be included as Acceptance Criteria in a user story. 

For example, for the following user story, “As an ecommerce website user, I want to search for products, so that I can purchase them”. NFR as acceptance criteria would be “application responds to search request within 5 seconds from the time request is received”. 

Examples of Non-functional requirements 

Some of the typical non-functional requirements considered during system development are: 

• Performance – funds transfer transaction should not take more than 0.5 seconds 
• Availability – the system should be available for the users to use the system anytime of the week they need 
• Security – payroll data is not visible to all the employees in the organization. Only the authorized personnel should have access to the data 
• Data Retention – all healthcare data should reside in the system for 7 years. Older data can be archived and should be accessible when required 
• Usability – the system navigation is easy for the end user and provides a seamless journey while accessing the system 
• Stability – the code/system is stable when new changes are applied due to dynamic business needs 
• Compliance – HIPAA compliance should be adhered when dealing with patients’ data in USA 
• Reliability – website users should be able to access the system 99% of the time without any failure 
• Recoverability – In case of any major failures, the system should be restored within 48 hours 
• Serviceability – the system should be serviceable immediately when there is a failure 
• Data integrity – the system should not allow phone number to be entered in the data field 
• Capacity – the system should be able to store 1 million records of basic customer information 
• Scalability – the system should be scalable to support unlimited growth of the employees 
• Accessibility - The system shall be accessible to people with disabilities in accordance with the Americans with Disabilities Act  
• Confidentiality – The system shall not display the bank account number in full. It should display only the last 4 digits of the account number while others can be masked 
• Efficiency – The interface between the system and user should not take more than 2 seconds 
• Portability – The system shall be developed for both windows and Mac operating systems platforms 

 Functional vs Non-Functional Requirements

The Impact of NFRs on Solution Development  

The business analyst and the project development team understand the customer requirements and expectations well and they are comfortable in converting the requirements into a finished product. Customer also validates the functional part of the requirements and signs off on successful implementation. However, the project success is dependent on the non-functional requirements as they define the quality attributes of a system.  

Some or all of the types of non-functional requirement that is described above contributes towards the successful implementation of the system. For example the system should be available all the time with minimal or negligible downtime, security is not compromised, maintaining confidential data/information, not allowing unauthorized users, scalable while the customer business is growing, having enough capacity to maintain product data considering future growth etc. Failure of any of these quality attributes will leave the customer unsatisfied.  

Implementation Approaches  

In general, the focus of the project team is to provide the functionality that the user has given. The non-functional requirements are looked into towards the end of the project after the customer UAT is complete. The team then focusses on the non-functional quality attributes, and sometimes may not be able to fulfil them as the design of the system may not accommodate the respective implementation. 

It is good to see the trade-off between the quality attributes during the requirements and early in the design stage of the project. Defining the non-functional requirements needs thorough analysis and creativity in the early stages. It is recommended to consider this during the development life cycle of the software development, rather than leaving this to be discussed at the later stage of the project.  

As seen earlier, the elicitation of the non-functional requirements can be carried out by the business analyst by using the prompt list and added as part of the requirements document in the traditional project management. These requirements can be specified either as a user story or part of the acceptance criteria of a user story, which enables the team not to miss any of these during the development stage, without leaving it to the end of the project life cycle. 

Conclusion

Successful implementation of a system depends on the non-functional attributes and their behaviour during the lifecycle. It is important to elicit or identify these quality attributes at the beginning of the system development cycle.