Non-Functional Requirements (NFR) in Agile Practices

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

Methods to create Targets or constraints

Common Methods for establishing Targets and Constraints include:

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.