NFR – Cannot be forgotten technique often forgotten


City A launched its first subway system, after a nearly one-year delay. After 12 days intensive testing by the city and the contractor, the city announced the subway system was ready to go.

However, since day one of launching the new subway system, issues have been popping up one after another. Delays in commuting happen on a daily basis and customer complaints are flooding social media.

Beside the subway system not moving as it is supposed to, it is very interested to find the most complaints are related to:

  • Lack of washrooms
  • Safety concerns
  • Lack of communication
  • Slippery floors
  • Overcrowded platforms
  • Lack of connecting buses

All those complaints are not directly related to the subway itself. They are “non-functional requirements” (NFRs).

Definition of NFRs

As per IIBA BABOK V3 definition, non-functional requirement: A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.

The keywords from this definition are:

  • Must meet
  • Constraints

From our subway station story, it seems those performance and quality attributes of the subway solution have not met customer expectations and they have become major constraints for proper system operation, which leads to terrible customer experience.

Why NFR are important

First of all, any operating system or solution contains two types of requirements: functional and non-functional. The solution works as a clock, which requires each gear within the solution to be properly functioning. Based on the theory of constraints, any process throughput can only be improved when the constraint or bottleneck is resolved.

Therefore, no matter how fast the train can run and how many passengers it can carry in one trip (the functional requirements), as long as the NFRs are not met, the performance of the solution (subway system) can only be as good as the non-functional requirements.

Second, if NFRs are not considered during the business analysis process, it is very likely they were not part of the criteria for solution evaluation. Without consideration of NFRs, the proposed solution may not be evaluated accurately. What was thought to be the best solution may not be a suitable solution at all.

Third, failure to consider NFRs increases the risk of solution failure and liability for the organization. For example, a slippery floor leading to a rider falling off the platform could lead to a lawsuit against the city.

Last, but not the least, the cost to fix an existing solution (a running subway system) will be more expensive than fixing the problem at the design stage. For example, purchasing additional buses and hire additional bus drivers hurts the city’s budget.

What are NFRs

The following examples of NFRs are for the subway example.

Riders require parking spaces, connecting buses
Operating hours and frequency, parking space near stations, availability of connecting buses
Fault tolerance
Can customers holding doors cause the system to shut down?
How do buses work with train schedule?
Will customers catch connecting buses within x minutes after the train arrives or will they always miss the bus?
Can user safely enter and exit the station without slipping and falling in any weather conditions?
Can the train and station handle rush hours or delayed situation?
How reliable is the service?
How fast can the system respond and recover from interruption?
How well can the system to protect the stakeholders in the subway systems?

When to consider or take action on the NFR in business analysis process

The majority of the legwork for NFRs occurs during the requirement analysis and design definition stage. But any business analyst should keep NFRs in mind during other stages of business analysis process.

During the planning and monitoring stage, the business analyst needs to clearly identify all the stakeholders to ensure their NFRs will be captured and considered during further stage. The lesson learned session can be used to address any NFR from the previous projects were overlooked, so the similar NFR can be considered during current project

During the elicitation and collaboration stage, the business analyst needs to ensure the stakeholders are encouraged to consider NFRs. All the stakeholders have their opportunity to express their NFRs.

During requirement life-cycle management stage, all NFRs are properly traced, maintained, prioritized and approved

During the requirements analysis and design definition stage, the business analyst needs to ensure NFRs are clearly specified and modelled, if applicable. The elicited and recorded NFRs are verified and validated from stakeholders. The potential value of the NFRs are properly evaluated and considered, when defining the design solution and a recommended solution is provided.

During the solution evaluation stage, NFRs are properly measured and analyzed.

In summary, NFRs should be kept in mind during the entire life cycle of business analysis process.

Techniques for NFR

Some techniques to use at different business analysis life-cycle stages are provided below.

To record, track and prioritize remaining NFRs
Backlog management, item tracking
To elicit NFRs from stakeholders
Group methods: brainstorming, focus group, mind mapping, observation, survey/questionnaire, user case, user stories
Individual methods: interview, research, documentation review
To analyze and model NFRs
Concept modelling, data mining, decision analysis, decision modelling, document analysis, estimation, financial analysis, interface analysis, metrics and KPI, process analysis, process modelling, risk analysis and management, root cause analysis
Lessons learned, stakeholder list, personas


The subway is still running daily and issues pop up as days go by. People are more and more concerned, as the temperature is dropping. Will the system survive the harsh winter weather (another NFR)? City is picking up those issues one at a time to address them, which probably will add more burden to the taxpayers on top of billions of dollars already spent.

The business analysts working for city should have a good lesson-learned session and put more focus on NFRs for the future projects.

Same advice to all our fellow business analysts: Let us keep alert on NFRs. If we do not, they will cost us.

Author: Wenwei Yao, CBAP,CSCP

Business professional with over 10 years’ experience in supply chain management and business Analysis, lean manufacturing/Business Process Improvement. I have been working with supply chain and ERP system for the majority of my career.

Contact Information
[email protected]

Like this article:
  29 members liked this article


Charlene H. posted on Wednesday, March 11, 2020 1:41 PM
One of the things I did was create a NFR template with checkboxes, as I work for NYS government and the NFRs are very similar across projects. I shared it with my teams and it helped standard everyone's approach, and makes sure nothing gets overlooked!
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC