Non-Functional Requirements (NFR) in Agile Practices

Introduction to NFR

Non-Functional Requirements (NFR) specifies "how well" the "what must behave".

"Say you are building a 2BHK house for your customer with a hall and a beautiful lawn, the user needs a hall and double bedroom, does not care about the structure, size and strengrh. To provide a valuable user experience, we should provide structure and the strongest build with perfect maintainability".

"Another example is the training part of our website. If its performance is poor, and if it takes too long to receive a confirmation once a participant has been registered then users are unlikely to have an enjoyable experience. Other common nonfunctional requirements include robustness, interoperability, usability, and compliance with a regulation or a standard"

• It can be called constraints on the system; NFR imposes constraints on the system, if we want security/reliability in our project.
• All functional requirements to meet with non-functional requirements.
  
  "Say a house has 3 bedrooms with one bedroom's size completely different."

NFR as Constraints

• A constraint is a condition to make the requirements in line with quality expectations
• It helps determine whether you have satisfied the non-functional requirements
• NFR is always a constraint for other user stories
• Any backlog item may be constrained by NFR
• A constraint to be obeyed either during the implementation by the builders (internal quality) or at run time by the software (external quality)

Example 1

• A constraint has two parts: a narrative and a list of acceptance criteria
• The narrative describes the non-functional requirement, whereas the criteria clarifies the interaction and describes the environment
• BOTH are required to validate the constraint

Example 2



Two Types of Constraints

Internal Quality

• Rule is a "constraint" that sets a limit to comply during software construction
• Impose constraints using "Rules"
• Internal qualities such as maintainability and testability, that are barely visible by the stakeholders but simplify how to build the software.
• Each user story is not « Done » until each rule is confirmed
• It can be confirmed by doing peer reviews / inspection
   

  Non-Functional Requirement	Rule
  Simplicity	Naming convention: Practices that ensure code is its own best documentation by allowing useful information, such as programming constructs, to be deduced from the names.

   

  Non-Functional Requirement	Definition
  Simplicity	Ease to understand or explain
  Maintainability	Ease to change and evolve with minimal effort
  Testability	Ease to confirm conformance by observing a reproducible behavior
  Portability	Ease to reuse for multiple platforms
  Extensibility	Ease to takes into consideration future growth

External Quality

• Restriction is a "constraint" that sets a limit to comply during software execution.
• External qualities such as performance, correctness, security and usability, that carry out the software's functions at run time, and as such, are not only visible by stakeholders but also highly desirable.
  For example: the user requires 2 BHK but it requires the rooms to be in good shape as well
• It can be confirmed by test(s), automation or performance testing
• Restriction is specific for one scenario
• Restriction has a measurable quality objective
• Restriction is confirmed by test(s)

Non-Functional Requirement	Definition
Correctness	Ability with which the software respects the specification.
Performance	Ease with which the software is doing the work it is supposed to do.
Usually	It is measured as a response time or a throughput.
Reliability	Ability with which the software performs its required functions in understated conditions for a specified period of time.
Robustness	Ability with which the software copes with errors during execution.
Scalability	Ability with which the software handles growing amounts of work in a graceful manner.
Security	Degree to which the software protects against threats.
Usability	Ease with which the software can be used by specified users to achieve specified goals.

Restriction (External Quality Constraint)

• Restriction is specific for one scenario
• Restriction has a measurable quality objective
• Restriction is confirmed by test(s)

Restrictions should be SMART

Characteristic	Description
Specific	It should target a piece of functionality that is small, consistent and simple
Measurable	It imposes a limit that is measurable, otherwise how would you know when you've addressed it
Attainable	It is recognized as achievable by the team
Relevant	It is directly related, connected, and pertinent to the non-functional requirement
Traceable	It is linked with a requirement and a target that justifies why it exists

How do you confirm an External Restriction with Tests?

• Correctness: Acceptance testing
• Performance: Response time or throughput testing
• Reliability: Testing over a period of time (memory leaks???)
• Scalability: Load testing (with growing amounts of work)
• Security: Intrusion testing
• Usability: Testing with real users

Identifying the Non Functional Requirements

Non Functional Requirement analysis is the most important activity for requirement engineering. In the requirements engineering we need to elicit both functional and Non Functional Requirements. Though we satisfy the functional requirements if we cannot satisfy the Non Functional Requirements people may not accept the product.

Here we see some methods and approaches to elicit and analyze the Non Functional Requirements in the product.

NFR Analysis approach

Non Functional Requirements elicitation and analysis involves a variety of people in an organization. In order to elicit and analyze requirements completely multiple views need to be considered to meet all stakeholder expectations.

Here we will talk about one of the methods for elicitation and analysis of NFR, called Four Layered Approach. This approach is used to identify all Non Functional Requirements from multiple views of different stakeholders.

Non Functional Requirements analysis process



The Non Functional Requirements identification process can be divided into the following four steps:

Step 1: Identify the key stake holders of the system [or] <Who> are the stakeholders?

Step 2: Generate the goals from stakeholders based on developer's knowledge and experience [or] <What> are the services<goals>?

Step 3: Decompose goal into sub goals [or] <What> are the sub goals of each service?

Step 4: Identify non functional requirement for each sub goal [or] How the goals are reached under constraints?

As a brief the team must identify the stake holders then by discussing the goals of the system, the Non Functional Requirements for the system should develop. You can see the following explanation to get the detailed explanation of four layered analysis for Non Functional Requirements.

Four layered analysis of Non Functional Requirements identification





As you see in the picture above, the NFR analysis has been done on the product video management system that is specifically for recording the cameras motions through recorder and playback. Also it provides the facility for rendering live videos on screens.

Usually the NFR requirements identification and analysis should start with identifying the stake holders of the product by arranging a meeting, in which the goals of the system should be identified and discussed. Here I have taken the "Video Management System" product as an example for explaining this analysis process.

The Stake Holders shall be a product owner, system administrator, user, Architect of the system, and Quality manager. So with the stake holders the team will identify the goals, sub goals of the system with the Non Functional Requirements, as you see in the picture above searching the video clip could be a one goal for the system, in which sub goals here are Search the clip by name, Search the clip by length.

These sub goals Non Functional Requirements will be identified during the meeting.

For example: the clip result should arrive within 5 seconds.

As like that, the goals with the sub goals of the system will be identified with the Non Functional Requirements. Using this approach the complete set of Non Functional Requirements will be identified.

How to find the CRITICAL Non Functional Requirements?

The following traceability matrix is used for finding critical Non Functional Requirements.



Based on the analysis using four layers, we shall conclude which NFR is a critical one.

From the table above, we can easily conclude that the performance NFR's are the most critical NFR, because all the goals requires this.

The critical NFR's that are identified must be implemented in the system.

Quantifying the Non Functional Requirements

Once we have identified the Non Functional Requirements, we need to quantify it to ensure stakeholder's desires are clearly understood by everyone.

How to Define a Quality

There 2 steps to define the quality.

STEP 1:

NAME: In the format "quality.subquality"
SCALE: What to measure (units)
METER: How to measure (method)

Real Time Example: STEP 1

NAME: Usability. Efficiency
SCALE: Number of Actions to complete a Transaction from a Location
METER: Average observed results from testingsite.com usability tests
Actions: One of {Data entry, Click, Scroll}
Transactions: One of {eCommerce [Shop, Purchase], Self Service [Activate, Change Plan]}
Location: One of {Home Page, My Account}



As a first step we should identify the name, appropriate scale of measure and method of measuring as like in the format above.

STEP 2:

TARGET: Success level to achieve
CONSTRAINT: Failure Level to avoid
BASELINE: Current Level

Method of creating a Baseline

Method	Description
Use Existing Meter	Use Existing method of measuring such as Report. Example: Usability tests to measure, using tools to measure
Create a New Meter	Create a new method of measurement whichever is easy to measure

Methods to create Targets or constraints

Common Methods for establishing Targets and Constraints include:

Method	Description
Improvement from Baseline	Plan a 20%-40% improvement over current levels by next year
Comparison with other competitors	Benchmarking yourself against leading competitors and setting levels based on their capabilities

Using the format/methodology above we shall define a quality with the baselines and targets.

Estimating NFRs in Scrum

Challenges with estimating NFRs involves two costs

1. Initial compliance
2. Ongoing compliance

Cost of Initial compliance

• The amount of time the team spends on initial NFR development and the performance testing.
• Initially zero code, over the period of sprints the codebase is ready for the NFR development

Cost of Ongoing compliance

• Consider the NFR development and testing was done on Sprint 5, in Sprint 6 the team adds some more features relating to that. Here is where the second cost, Ongoing compliance, comes.
• The moment NFR is accepted by the team, they need to remain in compliance with the NFR for the remainder of the project.
  
  In other words "If the NFR has been developed and tested by the team in sprint 5 [For Ex], also if new features related to the NFR have been added into Sprint 6 then the Team should confirm the NFR until the end of project".

Estimation

• Estimate the cost of initial compliance and ongoing compliance separately
• Estimate the initial compliance as like any other user story or product backlog
• The Team and PO will need to incorporate an estimate when they will do this? Every sprint or every n sprints?
• The Team can then estimate how much work will be involved over the planned number of sprints and allocate that amount of work for each
  
  "Suppose the team and product owner agree that they will do performance testing in every fourth two-week sprint. The team then estimates that it will require six points of work every fourth sprint. That's about 1.5 points per sprint"

Estimating NFR as a User Story

Can you imagine and tell why separate userstories will be created in the product backlog for the NFR, why not use the user story itself with NFR parameters?

Assume your large product, such as a Building security system, has multiple major modules like Access Control, Video and so on. In a particular release/version there might be a functional requirements alone from a video module, and a few Non Functional Requirements from the Access control.

In this case the highest priority would be for the functional requirements in the sprints.

And a very less value for the non functional parameters.

Example:

Refer to the following diagram.

NFR Userstory

"As a user, I want the access credentials to download in 10 seconds to the controllers"

Assume this NFR takes 6 story points to complete. Since the NFR is less than a priority one and also we need this to be developed in paralell, so we are planning to take 2 story points of the NFR in each sprint.

So the preceding will be split into the following sprints:



Sprint 1: Internal quality rules should be applied throughout the code portions of the NFR above

Sprint 2: Towards external quality acheviement, performance tuning should be done in the communication layer

Sprint 3: Towards external quality acheviement, performance tuning should be done in the user layer

Sprint 5: As a whole of the above, the performance testing will be done



NFR can be included as a part of FR story card

This time NFR parameters come along with the functional requirements story cards. The background of this type of estimation is along with the functional story development, NFR parameters should also be considered.

Consider the example that we have a functional requirement user story called "Searching and retrieving of video clips from network video recorder" in which the NFR parameters will also be included as a part of the user story.

Example: Retrieval of video clips in 10 seconds

• Scalability View: As a user I need a scalable clip search module in video to search and list the clips when the system is configured in more than 20000 Cameras.
   
• Determines if the application is stable under varying load
   
• Reliability View: As a user I need a clip search or clip download operation in 10 seconds when the system is running for more than 10 days
   
• Determines if the application is reliable for a period of time
   
• Performance View: As a user I need a clip search or clip download operation responds in 10 seconds when the system is configured in more than 20000 cameras

Determines whether the application responds quickly.





Explanation

Let's talk about the preceding NFR representation. During the grooming meeting the user stories will be identified with the NFR parameters. As you see in the picture above, scalable/reliable/performance parameters will also be identified at the
beginning.

Once the sprint starts the development of functional stories with the NFR parameters begin developing and completed with the functionally tested, including the NFR at the end of the sprint.

During the sprint or in the beginning of the sprint, if any constraints have been identified (in other words if any NFR implementation affects one or more user stories) then

it should be added into the product backlog.

Once a new constraint is added to the system, any stories in the product backlog that needs to comply with this constraint may need re-sizing if there is material time required to comply with the constraint. In other words, all estimates for future stories will need to take into account the fact that the constraint must be complied with in order to call the story "done".

Constraint Example:

Recorded clips of various cameras need to search and ensure it lists within 10 seconds.

Workflow




Summary

• Explore Non Functional Requirements that apply to the entire product or to important features early on. It makes you create a greater user experience and make the right architecture and technology decisions.
• Capture the requirements precisely to ensure testability.