In any software project important enough for sponsors to spend significant amounts of money on, the debate over how to handle non-functional requirements (NFRs) sooner or later comes to a head.  Many people who sponsor, manage, and execute development of software systems simply do not understand NFRs.  This results in increased risks to software projects, Agile or not.  This article explains NFRs in the context of requirements management and how to address them in Agile projects.

Requirements Management

Requirements management is the process of documenting, analyzing, tracking, prioritizing, and controlling changes to system requirements.  Development teams accomplish this work in collaboration with project sponsors, stakeholders, customers and end users (i.e., the Stakeholder Community).  Since software systems change and evolve throughout their useful life, requirements management is a continuous activity, not just something that occurs during development projects.

What is a Requirement?

A requirement is a singular, documented, physical or functional need that a solution (functional or procedural) aims to satisfy.  Requirements specify the things a solution must do and how well it must do them.  The former are functional requirements.  The latter are non-functional requirements.

NFRs Explained

Functional requirements are intuitive for most people.  People feel comfortable voicing what they need a solution to do for them.  The tricky part is characterizing how well a solution must do those things.  This points to how the solution performs or behaves while performing useful work for customers and end users.

For example, a bottle capping machine at a soda plant designed to cap ten bottles per minute would be woefully inadequate if the plant produces 50,000 bottles of soda per day.  Assuming the plant operates 24 hours per day, the machine would need to cap bottles at a rate of at least 35 bottles per minute just to keep up.  That rate may still be too slow in relation to other plant operations and distribution schedules.  No matter how well that capping machine caps bottles (functional requirement) it must do so at an adequate throughput rate (number of bottles per minute). 

A software solution example might entail the number of concurrent users an application must support.  Perhaps the application experiences large swings in the number of users depending on circumstances.  For example, a retail sales website will likely see surges in users around Black Friday.  No matter how well that application handles normal traffic, it must be designed to handle such surges seamlessly.

This is when we get into discussions about how a solution behaves.  In software engineering, we often characterize solution behavior in terms of “-ilities”.  I list examples in the table below:

These “-ilities” apply to the entire system or solution, not just to individual system features or components.  However, each and every part of the system contributes to, or takes away from, its overall behavior.  One underperforming component could degrade the behavior of an entire system.  Thus, it is crucial to take NFRs into consideration when designing and implementing system features and components.  The more frequently development teams integrate them into the larger system and put them through integration and regression testing, the better.

NFRs constrain functional requirements.  In other words, the capabilities designed and developed to address functional requirements must also support or contribute to meeting NFRs at the system level.

Common sources of NFRs include official standards; laws, regulations, and policies (LRPs); and technical specifications (e.g., operating systems, required middleware, hardware specifications).

Handling NFRs Agilely

There is no fundamental difference between how Agile and traditional software development projects handle NFRs.  In either context, we handle NFRs by:

• Writing well-written NFRs
• Ensuring functional requirements address relevant performance/behavioral attributes. 

Well-Written NFRs

A well-written NFR describes a system-level behavior or performance expectation both qualitatively and quantitively.  There is no universally accepted standard way to write NFRs.  However, the following guidelines should help:

• Start with the outcome in mind by providing context about the requirement. 

For example, why is scalability a desirable goal for our system?  The answer is tied to the business or mission processes the system supports.  What does scalability look like from a business or mission perspective?

• Quantitatively, we must define what the right degree of scalability is.  For example:
  • How many concurrent users per day, hours, minute, second?
  • What data volumes can we expect?
  • How much fluctuation in users and data volumes can we expect?  When?  How often?

The more specific we are about our needs, the better we’ll define functional requirements that realize NFRs.  Focus on identifying needs rather than on defining solution approaches or designs.

Addressing NFR Performance & Behavioral Attributes

Functional requirements realize NFRs.  Agile functional requirements adhere to the INVEST criteria:

Agile functional requirements are customer and end-user centric.  They are written from the perspective of what customers and end users need rather than from the point of view of what the system will provide.

To make this discussion more concrete, I will use the User Story requirements format.  A User Story includes:

• A description of what the user needs to accomplish an outcome
• Acceptance criteria that explain the specific behavior and performance characteristics the resulting functionality must exhibit to comply with requirements

User Story Description

The de facto standard format for User Stories is the following:

As <a user, role, or automated client> I want <some capability> so that <desired outcome>

This simple and concise statement tells us:

• Which specific user, role, or automated client needs the capability or feature:  User Stories serve as reminders for future conversations.  They are not meant to document requirements in detail.  User Stories tell us the types of users we need to talk to or learn more about.
• The business or mission capability the user needs:  User Stories are written from the perspective of the business or mission capability a user needs to accomplish a desired outcome.  The resulting software functionality will enable the accomplishment of that business or mission outcome.
•  The desired business or mission outcome the capability or feature will enable:  User Stories answer what tangible business or mission outcome will be achieved as a result of using the implemented feature.  The outcome is often the execution of a business or mission process or task.

User Story Acceptance Criteria

The second part of a well-written User Story are acceptance criteria.  This is where the NFR attributes defined earlier constrain the design and implementation of the resulting functionality.  Acceptance criteria are the results or outcomes the functionality must achieve when executed.  We demonstrate adherence to acceptance criteria through testing.  So, in essence, acceptance criteria are test criteria for the User Story.

Well-written acceptance criteria are testable.  That means that the result is not left to interpretation.  The feature either delivered expected results or did not.  The behavior and performance the feature demonstrates should contribute to (or not degrade) the overall system-level behavior and performance documented by NFRs.

Here is an example:

NFR: The system shall implement authentication and authorization functionality as per corporate security policy XYZ.

Functional Requirement:

As a system administrator (SA), I need to restrict user access to files so that authenticated users only have access to files for which they have access permissions.

Acceptance Criteria:

1. The SA can grant specific authorized users access to specific libraries or documents.
2. The SA can revoke access to specific libraries or documents from specific authorized users.
3. All file access permissions for specific users are automatically revoked if the SA revokes their authorization to access the system.

Conclusion

It is quite common for people engaged in sponsoring, managing, and developing software systems to misunderstand NFRs and struggle in applying them to Agile requirements management.  User Stories make mapping of system-level NFRs to functional requirements easier.  Acceptance criteria link functional requirements to tests that demonstrate satisfaction of NFRs.  Coupled with frequent integrations and regression testing, this approach to NFRs ensures the delivery of expected system behavior to customers and end users.

Last Updated on February 2, 2022