By James Wilt, Distinguished Architect
The question before “what” really is “when” do I care about Non-Functional Requirements? The unfortunate answer is “when it’s too late!”
What NFRs Are
Non-Functional Requirements (NFRs) a.k.a. Quality Attributes (Iasa BTABoK) are non-functional characteristics of components or systems. They represent cross-cutting architectural concerns for systems or a system of systems. Some examples are in groups shown to the right. They differ from Service Level Agreements (SLAs) in that they have no contract nor penalty/repercussion.
Four rules to consider when creating & articulating NFRs
Specific – be specific about what is being measured to a fault. Generalized statements lead to subjective measures.
- Bad: The UI should be easy to use.
- Good: The UI should require no more than 3 clicks to get to the desired destination.
Measurable – well articulated tolerances tied to specific non-relative thresholds.
- Bad: The Gateway should be faster than the API.
- Good: The Gateway’s overhead latency should be no more than 8 ms.
Monitored – capturing specific measures will mitigate any subjective inferences from consumers.
- Automation should alert when measurable tolerances are missed. This is important because NFRs can be an early warning to a potential catastrophic situation.
- The Observer Effect does come into play, so be mindful of any negative impacts monitoring may cause.
Practical – reasonable tolerances rule. Understand the costs related to the measures and be sensible with the limits.
- Questionable: 99.999% availability means about 5 minutes down time over a year, however, it will require a more complex architecture/design and come at an outrageous cost. Can this be justified?
- Reasonable: 99.9% availability (standard in many cloud platforms) means down time over a year is about 9 hours — at no additional cost.
With Me or Against Me?
Interactions between NFRs are usually supportive, however, there are situations where they will be contentious. NFR prioritization will be necessary. For example:
- Highly responsive & performant code may be less maintainable, adaptable, and difficult to secure.
- Making code reliable & safe can often create challenges to also be configurable and adaptable.
- Localized solutions have increased maintenance.
Focus on enough NFRs to deliver your desired outcomes and no more than necessary.
Iasa has documented a process and best practices for the selection & prioritization of Quality Attributes in the BTABoK’s In Practice. Here’s a simple pattern for articulating them:
The [what] should [be] [monitor-able attribute] to [specific measureable tolerance(s)]
Some examples:
- All lookup services should be consistently responsive to ensure no more than 1.5 seconds elapse before a response is provided.
- All external facing APIs should ensure robust security by leveraging token exchanges when calling internal services.
- A replaceable microservice should be written or rewritten in a manner that does not exceed one week.