Introduction to NFR

NFR as Constraints

Two Types of Constraint

Internal Quality

External Quality

Identifying the Non Functional Requirements

NFR Analysis approach

How to Define a Quality

Step 1

Step 2

Methods to create a BASELINE

Methods to create Targets or constraints

Common Methods for establishing Targets and Constraints include

Estimating NFRs in Scrum

Cost of Initial compliance

Cost of Ongoing compliance


Estimating NFR as a User Story

NFR can be included as a part of FR story card




Introduction to NFR

  • NFR is qualified to specify “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 need hall and double bed room, not care how structured ,sized and strong. To provide a valuable user experience, we should provide structured and the strongest build with the 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, 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 as constraints on the system,NFR imposes constraints on the system, if we want security/reliability on our project
  • All Functional requirements to meet with non functional requirements
  • “Say House with 3 bedrooms having one bedroom size is 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
  • Constraint to be obeyed either during the implementation by the builders (internal quality) or at run time by the software (external quality).


  • Constraint has two parts :a narrative and a list of acceptance criteria
  • Narrative describes the non functional requirement, where as the criteria clarify the interaction and describe the environment
  • BOTH are required to validate the constraint



Two Types of Constraint

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, which is 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, which carry out the software’s functions at run time, and as such, are not only visible by stakeholders but also highly desirable

Ex: User requires 2 BHK but it requires the rooms in good shapes 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 under stated 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 conform 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 in the 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 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 needs to be considered to meet all stakeholder expectations Here we will talk about one of the method for elicitation and analysis of NFR is 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 four steps as follows

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 achieved under constraints?

As a brief the team has to identify the stake holders then by discussing the goals of the system, the non functional requirements for the system should come up. 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 the above picture, the NFR analysis has been done on the product video management system which is specifically for recording the cameras motions through recorder and playing back it. Also it provides 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 it. Here I have taken ‘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 above picture 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 Ex: Clip result should come in 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

NFR Type Goal 1
Goal 2
Video Clip
Goal 2 Exporting Video Clip Goal 3
Goal 3
Searching Cameras
Goal 4
Assign Camera
Goal 5
Performance 2 2   1 2 1  
Usability     1       1
Reliability       1   2  

Based on the analysis using four layered, we shall conclude which NFR is a critical one.  If you see the above table, we can easily conclude that performance NFR’s are the most critical NFR, because all the goals requires this.The critical NFR’s which are identified must be implemented in the system.Quantifying the Non Functional RequirementsOnce 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


NAME: In then form of 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 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 above format


TARGET: Success level to achieve

CONSTRAINT: Failure Level to avoid

BASELINE: Current Level

Methods to create a BASELINE

 Method of creating Baseline
Method Description
Use Existing Meter Use Existing method of measuring such as Report. Ex: Usability tests to measure, Using tools to measure
Create a New Meter Create a new method of measuring 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 above format/methodology we shall define a quality with the baselines and targets  

Estimating NFRs in Scrum

Challenges with estimating NFRs involves two costs

  • Initial compliance
  • Ongoing compliance 

     Cost of Initial compliance

  • The amount of time the team spends on initial NFR development and the performance testingInitially zero code, over the period of sprints the code base is ready for the NFR development 

    Cost of Ongoing compliance

  • Consider the NFR development and testing has done on Sprint 5, In sprint 6 the team is adding some more features relating to that. Here is where the second cost – Ongoing compliance comes
  • The moment NFR has 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 has added into the sprint 6, the Team should conform the NFR till the end of project”       


  • 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
  • Team can then estimate how much work will be involved over the planned number of sprints and allocate that amount of work to 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 take 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 theproduct backlog for the NFR, why not       user story itself having NFR parameters?Assume your large product like Building security system have multiple major modules like Access Control, Video.etc.. In a particular release/version there might be  a functional requirements  alone from 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


Refer the below mentioned diagram

NFR Userstory

“As a user , I want the access credentials should download in 10 seconds to the controllers”Assume this nfr takes 6 story points to complete it.  Since the NFR is less priority one and also we need this to be parallely developed one,  so we are planning to take 2 story points of NFR in each sprint.

So the above is going to split in sprints as like below


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

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 above, the performance testing will be done


NFR can be included as a part of FR story card

This time NFR parameters come up along with the functional requirements story cards. The background of this type of estimation is along with the functional story development, NFR parameters also should also be considered.Consider an example that we got 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 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

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




 Let’s talk about the above NFR representation, During the grooming meeting the user stories will be identified with the NFR parameters, As you see in the above picture, scalable/reliable/performance parameters also be identified at the beginning.Once the sprint starts the development of functional stories with the NFR parameters are started developing and completed with the functionally tested including NFR at the end of sprint.During the sprint or in the beginning of the sprint, if any constraints have identified [i.e. if any NFR implementation affects one or more user stories]It should be added into the product backlog.Once a new constraint is added to the system, any stories in the product backlog that will have to comply with this constraint may need re-sizing if there is material time required to comply with the constraint. Said another way, 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 make sure it lists within 10 seconds.



  • Explore nonfunctional requirements that apply to the entire product or to important features early on – It makes you create a greater user experieance and make the right architecture and technology decisions
  • Capture the requirements precisely to ensure testability