The non-functional view allows you to re-iterate or summarise the key non-functional requirements as well as explicitly highlighting those that are deemed as architecturally significant and influence the architecture.
Each non-functional requirement should be precise, leaving no interpretation to the reader. Examples where this isn’t the case include; "the request must be serviced quickly", "there should be no overhead", "as fast as possible" , "as small as possible" and "as many customers as possible". A non-functional view should answer the following types of questions.
- Is there a clear understanding of the non-functional requirements that the architecture must satisfy?
- Are the non-functional requirements specific, measurable, achievable, relevant and timely?
- Have non-functional requirements that are usually taken for granted been explicitly marked as out of scope if they are not needed (e.g. "user interface elements will only be presented in English" to specify multi-language support out of scope).
- Are any of the non-functional requirements unrealistic? (e.g. true 24x7 availability is typically very costly to implement).
Here are some of the most common non-functional requirements:
- Performance (e.g. latency and throughput)
- Scalability (e.g. data and traffic volumes)
- Availability (e.g. uptime, downtime, scheduled maintenance, 24x7, 99.9%, etc)
- Security (e.g. authentication, authorisation, data confidentiality)
- Monitoring and management
- Failover/disaster recovery targets (e.g. manual vs automatic, how long will this take?)
- Legal and regulatory requirements (e.g. data protection act)
- Internationalisation and localisation
Typically, very few people will give you a set of non-functional requirements, let alone write them down. This is why management of the non-functional requirements is a key part of the software architecture role, so I find it useful to include them in the software architecture document.