If you have any role in the design of an IT system, you should care about NFRs. As this piece (Nonfunctional requirements: A checklist – IBM Cloud Architecture Center), states:
Defining and addressing the nonfunctional requirements (NFRs) for a system are among the most important of a software architect’s responsibilities. NFRs are the system quality attributes for a system, as distinct from the functional requirements, which detail a system’s business features and capabilities.
Examples of NFRs include key concepts such as reliability, performance, scalability, and security. NFRs are cross-cutting in nature and affect multiple aspects of a system’s architecture. It’s important to articulate and address the NFRs early in the project lifecycle and to keep them under review as the system is produced. To help with that task, you can use the following checklist of key NFRs. The checklist designed to be consulted when you define and evolve a system’s architecture.
The bold text is key. NFRs describe the qualities your system should have. You have functional requirements and you have quality requirements (i.e. , NFRs). Any system design needs to address both.
The number of specified NFRs your system can have are endless. Three of the key ones found at the top of that list are:
Those three are typically covered in any system design I work on. The piece goes on with a great rundown on the various NFRs you’d expect to address in most system architectures.
Three NFRs missing from that list that I think are important and that I would ask you to consider are:
- Accuracy
- Maintainability (related to complexity)
- Cost
There is often a tradeoff with accuracy and other NFRs, such as performance. To gain better performance, data will often be cached and served up even when it is out of date (i.e., inaccurate). That may be fine. But accuracy should always be taken into account and not just assumed.
Maintainability is often ignored, but it is key for the long term success of a system. Two examples of this. One, developers will sometimes not externalize values in their code; changes to the code require a fix and an outage. That is less maintainable than code with external values in a simple text file that can be changed on the fly. Two, code that is not well documented and not peer reviewed will be harder to maintain. Externalization, code reviews and documentation are examples of maintainability requirements you may have and should have for your IT system.
Cost is an important NFR because it causes tradeoffs with most other NFRs. For example, without cost considerations, stakeholders might have availability requirements that are for 99.99999….. It’s only when cost (and complexity and maintainability) become factors do we see often see availability (and other NFRs) scale back.
Finally, NFRs are not just for software architects: they are for everyone. In fact, I wish the term “non-functional requirement” was replaced with “quality requirement”. However I suspect software architects — for whom functional requirements are key — came up with that term, so we all have to live with it. When you think of NFRs, think Quality Requirements. Everyone involved in the design of an IT system wants it to have good quality. Understanding the NFRs/QRs are key to this.
Smart People I Know 