Non-Functional Requirements – The basis of your software architecture
Posted on January 14, 2016
We constantly hear that new applications should use the latest and greatest application architecture… A few years ago everybody was implementing SOA and Onion Architecture, now its CQRS, Micro Services etc. But how do we make a conscious decision on which architecture to choose? The answer is Non-Functional requirements?
What is Non-Functional requirements?
The Non-Functional Requirements (NFR’s) is all the requirements that are not directly involved with the functionality of the application or service being implemented. The NFR’s are typically related to:
- Performance. The expected number of requests that the need to handle. An example on a Performance NFR
could be:
Handle 200 requests / pr second on average. Handle 1000 requests / pr second on peak. - Security. Any requirements regarding security. This can be regulatory requirements etc. An example could be: All sensitive user data must be encrypted. But security can be graduated. There is a hugh difference between creating a system that registers the trucks of a truck company and a system t
hat registers the passport and driver license at a border crossing. Even though both systems might want to secure the data, the consequences of not doing a proper job, is probably a lot worse in the case of passport registration. - Maintainability. (The cost of fixing bugs)
- Extensibility (The cost of adding new functionality)
- Testability (How easy it is to test the application)
- Scalability (How easy we can scale the number of requests, performance etc)
- Usability (How easy it is to use the application)
Lawrence Chung has a presentation describing the different types of non functional requirements and ways to classify them.
When do we identify the NFR’s
The NFR’s are typically not defined formally and often they are hard to enforce during development and evaluate before deployment. And if the NFR’s are defined, the business owner typically want everything.
“I want a secure, fast, maintainable system that can be extended and scale.”,
quote, The Typical Ignorant Business Person
This is alright. But it is our job as tech-people to explain the price of the NFR’s and the consequences of ignoring them.
Following a strict old-school agile methodology, the NFR’s should evolve along with the business requirements. But this have proven to be difficult as the NFR’s have a huge impact on how the system is build. Performance is hard to add as a feature if the system has been build using a slow technology. Security is often very hard to add as a feature 
later – if not thought in from the start of the project, there is a huge chance of lots of open attack vector that can be utilized by evil people.
A more “modern” Agile approach, especially for larger enterprise systems, is the thought of having an architectural runway before the actual implementation of the business value. The runway is a shorter or longer period of time where the general NFR’s can be identified, the interaction with other systems in the enterprise can be identified etc and a prototype of the application architecture (A walking skeleton) can be implemented to verify the ideas.
How do we determine the architecture?
The architecture will, unfortunately, not jump into your arms just because you have defined a se
Hammer, Wrench and screw. Its all a matter of the right tool for the right problem.
t of NFR’s. But the NFR’s can be used to determine the application architecture and the design of the application. If performance is of high performance, and architecture where every call to a service have to go through a service broker, e,g, Biztalk, probably isn’t such a great idea. If the business area is changing a lot, extensibility is of high importance, and a very modular architecture is necessary.
No matter what, having a broad knowledge of different types of architecture and their strengths and weaknesses is important.
It is also important to acknowledge that some parts of the business domain might require special treatment, and that could mean that the domain must be implemented in a different way that the rest of the system. If for instance part of the application contains very sensitive data but performance is less important, it might be a good idea to implement this separate from the rest using the proper techniques for that.
It’s all a matter of using the right hammer for the right type of nail. But if you don’t know what type of nail you’re going to use, you might end up with a screwdriver.
Note
NFR’s are not just attached to the general functionality of an application, but also to the individual business requirements which will be handled during a spring. E.g. “The search result must appear within 2 seks.” or “We must be able to process 3000 customers pr. hour between 2am and 5am” are both requirements that are set for a specific user story or feature. And they can be hard to comply with, even though the architecture is well defined up front.