Driving quality through Non-Functional Requirements
Functional Requirements
Functional Requirements (FR) define what the system should do. They describe specific behaviours and are best communicated in User Story format.
Example:
As a customer, I want to be sent a tracking link when my order is marked shipped, so that I know when to expect delivery
Non-Functional Requirements
In contrast, Non-Functional Requirements (NFR) place constraints on how the system should behave. They describe qualities or properties that are not specific to any one Functional Requirement.
NFRs can be thought of as lenses through which groups of FRs are validated.
Example:
Performance:
End user page load times to complete within 3 seconds.
Server-side actions to complete with an Apdex score above 0.9 with t interval of 0.5 sec.
Non-Functional Requirements deserve priority treatment
It’s common for NFRs to take a back seat in requirement gathering sessions. Topics like Scalability and Security are rarely met with the same excitement or urgency as customer facing features, yet they are critical to a development project’s success.
Consider that the misbehaviour or lack of a Functional Requirement in isolation will rarely trigger catastrophic failure of a system. However, continued development of a system running atop an architecture that is not maintainable, performant or secure will create compounding and far reaching problems. The kind of problems that fly under the radar for a period as features build up around them. By the time symptoms bubble to the surface it’s often too late, with the amount of re-work required to retrofit the desired qualities so extensive that it derails the project.
Non-Functional Requirements commonly mark the difference between a development project’s success and its failure.
Hard to define, but worth the effort
NFRs are qualitative in nature, making them challenging to constrain.
How do we know what acceptable “performance” looks like? How can we define “maintainability” before any code has been written?
Ambiguity leads to misaligned expectations and misaligned expectations rarely result in pleasant surprises.
Consider a moment when you purchased an item listed as being of “high quality”. The product turned out to be acceptable from a functional perspective, but that marketer’s definition of quality differed greatly from your own. Now imagine this difference in expectation at the scale of a large software development project spanning thousands of developer effort hours. Each team member and stakeholder with differing personal definitions of success.
How likely is it that everyones expectations will be met? How accurate are time estimates and roadmaps likely to be? How long will it take to realise that the misalignment exists? Can NFRs be retrofitted at that point or will the project have travelled too far in the wrong direction?
The harder a requirement is to specify, the more important that it be specified.
Getting started with Non-Functional Requirements
Even if no other documentation is to exist, be sure to agree on a list of NFRs. Write them down and do so as early as possible. In a Scrum environment this is best handled in Sprint Zero while backlogs are prepared, high level priorities are defined, and architectural decisions are made.
NFRs cover a broad range of qualitative concerns and inclusions should to be specific to the project at hand. The following list serves as a starting point for web-based software development projects:
- Security
- Performance
- Scalability
- Extensibility
- Maintainability
- Testability
- Reliability
- Interoperability
- Deployment
- Disaster recovery
- Usability
- Accessibility
- Compatibility
Objective consideration of each item in the above list will significantly increase the chances of long term success, even if some are defined as not being a constraint (i.e. the absence of a specific requirement).
