Beyond Functionality: The Critical Role of Non-Functional Requirements

The Consequences of Ignoring NFRs

Not taking NFRs into account can have serious repercussions. For example, city A launched its first subway system, after a nearly one-year delay. After 12 days of intensive testing by the city and the contractor, the city announced the subway system was ready.

However, once the new subway system was launched, issues started appearing. The subway system was not moving as it was designed to. Delays in commuting were daily occurrences and customer complaints flooded social media.

The complaints were not directly related to the subway. They were related to NFRs and included:

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

The Definition

First, 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 function properly.

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), the solution’s performance (the subway system) is only as good as the NFRs if these are not met.

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 that leads to a passenger falling off
the platform could lead to a lawsuit against the city.

Finally, fixing an existing solution (a running subway system) will be more expensive than fixing a problem at the design stage. For example, purchasing additional buses and hiring additional bus drivers will hurt the city’s budget.

What Are NFRs?

The following examples of NFRs relate to the subway example: 

NFR	Example
Dependency	Riders require parking spaces and connecting buses
Availability	Operating hours and frequency, parking space near stations, availability of connecting buses
Fault tolerance	Can customers holding doors cause the system to shut down?
Interoperation/integration	How do buses work with train schedules? Will customers catch connecting buses within X minutes after the train arrives or will they always miss the bus?
Operability	Can users safely enter and exit the station without slipping and falling, in various weather conditions?
Scalability	Can the train and station handle rush hours or delays?
Reliability	How reliable is the service?
Resilience	How fast can the system respond to and recover from interruption?
Safety/security	How well can the system protect the stakeholders in the subway system?

When to Address an NFR

Most of the legwork for NFRs occurs during the requirement analysis and design definition stage. However, any business analysis professional should keep NFRs in mind during other stages of the business analysis process.

During the planning and monitoring stage, the business analysis professional must identify all the stakeholders to ensure their NFRs will be captured and considered during further stages. The lesson-learned session should address any overlooked NFR from the previous projects so that a similar NFR can be considered during the current project.

During the elicitation and collaboration stage, the business analysis professionals must ensure that stakeholders consider NFRs. All the stakeholders should have the opportunity to express their NFRs.

During the requirement lifecycle management stage, all NFRs must be properly traced, maintained, prioritized, and approved. During the requirements analysis and design definition stage, the business analysis professional must ensure that NFRs are specified and modelled, if applicable. The elicited and recorded NFRs are verified and validated by stakeholders. The potential value of the NFRs is 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 lifecycle of the business analysis process.

Techniques

Some techniques to use at different business analysis lifecycle stages are provided below.

Purpose	Technique
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 KPIs, process analysis, process modelling, risk analysis and management, root cause analysis
To plan	Lessons learned, stakeholder list, personas

Summary

Non-functional requirements are crucial in designing and delivering successful solutions to meet end-user needs. As seen in the example of city A’s subway system, neglecting NFRs can result in poor performance, customer dissatisfaction, and even legal liabilities. Therefore, business analysis professionals must consider NFRs throughout the solution lifecycle, from planning and monitoring to solution evaluation.

Techniques such as backlog management, elicitation methods, and modelling can help ensure all stakeholders’ NFRs are captured, tracked, and prioritized. By properly addressing NFRs, business analysis professionals can deliver high-quality solutions that meet end-user performance and quality attributes, leading to a better customer experience and successful outcomes for the organization.  

---