WTF are NFRs?

Articulating and designing to NFRs up-front will diminish angst later as addressing them after-the-fact can mean major design changes.

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!

NFR comic

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.NFR Groups

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.

What are NFRs? Some might say they are your successful product’s best friend!