Last updated on December 24th, 2021 at 02:43 pm
Non-functional requirements are sometimes named -ilities. Other popular terms used are quality attributes, architecture concerns and architecture characteristics.
Examples of these -ilities include maintainability, reliability, usability, scalability, availability, and security.
Usually, the developers are less concerned about these non-functional requirements when writing their code. But as an architect, identifying the driving architectural characteristics (non-functional requirements) is one of the most important and challenging tasks you need to focus on early in the project.
The requirements specify what the application should do while architectural characteristics define the important aspects of the system, how to implement the requirements and why justify the decisions that are made
So, the architectural characteristics define the important aspects of the system independent of the problem domain such as: performance, security and scalability.
Some of the architecture characteristics are explicitly stated in the requirements (E.g. d numbers of users that will connect to your system) other are implicit and it is the architect responsibility to identify them.
The following are to keep in mind when looking for non-functional requirements:
- Depending on the system you are building, not all the “-bilities” are equal. Some are probably most important, and you need to identify and focus on those (usually 3 to 5).
- One of the common mistakes of the new architects is to try to build a generic architecture that support all the non-requirements but in fact doesn’t support none of them. As stated above, you need to focus on the most important ones.
- Work closely with domain stakeholders to identify (explicit and implicit) non-functional requirements.