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).

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.

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.

The following examples of NFRs are for the subway example.

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.

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

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.