Architecture begins with requirements. Functional requirements dictate application and data architecture. Non-functional requirements (NFRs) dictate the technical characteristics of the future solution. To be usable in determining the technology architecture, NFRs should have one clear and important attribute – they should be specific. It is impossible to establish technical architecture shape unless these target specifics are declared.
We think about architecture in terms of concerns: key categories that determine the shape of the target solution. NFRs dictate what these concerns should look like. In technical architecture, the key architectural concerns are performance, scalability, reliability, operability… NFRs relate to one or several architectural concerns and addressing in your design one concern can lead to making it hard to address the other. A highly scalable computer system can end up being too complex for operational staff to run: for example, scalability can make it hard to meet architectural concern of operational simplicity if the solution is based on replication of complexity per system instance.
Here are some of the core NFRs:
| Category | Description |
|---|---|
| Accessibility | Ensuring an equivalent experience for everyone who will use the system. Accessibility means that everyone can perceive, understand, navigate and interact with the system. The aim of accessibility is that there should be no system-related barriers to people contributing equally. |
| Reliability | Reliability requirements refers to the probability of a system or system element performing its intended function under stated conditions without failure for a given period of time. A precise definition must include a detailed description of the function, the environment, the time scale, and what constitutes a failure. |
| Availability | Degree to which users can depend on the system to be up (able to function) during normal operating times. |
| Security | Address what needs to be satisfied to achieve the security attributes of an IT system and meet [Client]’s IT security requirements. |
| Scalability | Scalability is specified as how well the system is able to expand its processing capabilities upward and outward to support business growth. A system is described as scalable, if it will remain effective when there is a significant increase in the number of resources and the number of users. The solution must allow the hardware and the deployed software services and components to be scaled horizontally as well as vertically. Horizontal scaling involves replicating the same functionality across additional nodes; vertical scaling involves adding more resources such as memory, CPU and storage to existing infrastructure. |
| Interoperability | The extent to which the software system can facilitate the interface with other systems. |
| Recoverability | Addresses how quickly a system can be recovered after experiencing a system failure. |
| Operability | Operability is the ability to keep a system in a safe and reliable functioning condition, according to pre-defined operational requirements. |
| Performance | Performance requirements focus on the responsiveness of a system to perform specific actions in a given time span. Performance is measured in terms of throughput or latency. Latency is the time taken by the application to respond to an event. Throughput is the number of events measured in a given time interval. |
| GDPR | The GDPR aims primarily to give control to individuals over their personal data and to simplify the regulatory environment. The regulation contains provisions and requirements pertaining to the processing of personal data of individuals. |
NFR statements should be the key object of attention for a technical architect
me!
Before design is initiated, non-functional requirements need to undergo critical review by the technical architect to make sure they are sufficiently complete, all relate to known architectural concerns, the language used is clear and requirements themselves are realistic. If a functionally rich system is custom built with large user base and variety of interface technologies in real time, queued, batch, etc that all go live at the same time, it will take special skill and experience not to jump to unrealistic NFR statements and agree to them before some facts have been established about performance characteristics and other architectural concerns of the solution.
For example, such architectural concerns as Performance, is initially addressed through sizing models, which then are used in performance tests and can potentially generate significant amount of changes in the expensive area of infrastructure. Here, you can over-size or under-size, or be spot on. This is one place where NFRS statements usually contain pointers to various business documents that specify business volumes to be handled by the system.
Hence NFR statements should be the key object of attention for a technical architect, to be critically reviewed, revisited as more is found out about solution technical characteristics in various environments. Key business models underlying NFR assumptions should be robustly assessed and the client made aware of the role these play in NFR set.
Ultimately, Non-functional requirements, once signed off and agreed, form the basis for answering the question of whether the technical architect did the job well or not.
Below you can find a sample of “lightweight” NFRs I produced during a two-assessment for a SMB client:
….if you want a more detailed view on NFRs then grab a strong cup of coffee and go through this document:
