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, and their impact in solution development
“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”
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)
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:
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”.
Some of the typical non-functional requirements considered during system development are:
|1||Defines ‘What’ of the customer requirements||Defines ‘How’ of the customer requirements|
|2||Elicited by business analysts, specified by the customer||Defined by technical team like architects, developers etc|
|3||Documented as the requirements document by the business analyst||Documented as the technical document by the team|
|4||Defines the functionality in the system||Defines quality attribute in the system|
|5||Captured as a user story in agile||Captured either as a story or part of acceptance criteria of a user story|
|6||Customer tests and validates the functionality as specified by them||Customers cannot test these quality attributes, however, can experience while using the system|
|7||Customers find it easy to define these||It is hard to define by the customer|
|8||Defines the product features||Defines the product properties|
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.
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.
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.
Your email address will not be published. Required fields are marked *
85 percent of respondents say Scrum continues to... Read More