Non-Functional Requirements – Did you get the unsaid?

One of the biggest learning I had over the years, while architecture multiple IT solutions, is the criticality and importance of non-functional requirement. This article is a snippet of my learning on these unarticulated but badly needed aspects of any IT solution.

 

As an architect & designer, like most, I also spend lot of time and efforts in understanding the business pains, needs and areas where the proposed or existing solution works. We call those functional or business requirements. There is no way to disagree on the importance of these requirements, as this is the sole purpose for the existence of the solution. But there is another set of requirements, which, most of the time, are unarticulated, undocumented…un***, but has major impact on the acceptability, usability, profitability and overall success of the solution. These set of requirements, called non-functional requirements, if not considered, can badly affect all phases of solution development including architecture, design and implementation.

 

In simple words, if functional requirements say what system should do, non-functional say how well system should do those functional things.

 

So, what are those typical non-functional set of requirements. Unfortunately there is no defined list, and interesting, not all are applicable and desired in all solutions. But still, as systematic approach, let’s categorize those into 2 sub-sets.

 

Run-time Requirements – Which affects the system during execution.  Few of the most common, and vital, runtime non-functional requirements are

• Performance – Your response time, throughput, latency etc.
• Security – Do you check who can enter into?
• Availability – Is your system available 24X7 
• Scalability – How do you react if tomorrow another set of 10K users added or new clients with huge data added to application?

Static (Development- time) Requirements – The set of requirements which are not related with run-time environment, for e.g. 

• Extendibility – Is your solution functionally flexible and extendible within affordable cost?
• Maintainability – Is your solution simple and maintainable over the period?
• Auditing & logging – This is with reference to the audit and logging capabilities of the system.
• Failover – Can your solution auto or manually recover from failure?
• Interoperability – Can your solution operate in multiple environments?
• Legal & regulatory requirements – Have you satisfied legal and regulatory norms?
• Internationalization & Localization – Specific for solutions to be used in multi-lingual environment.
• Configurability – Is your system configurable?

Problems with non-Functional Requirements

More than implementation, non-functional requirements are characterized by their fuzziness. Some of the typical problems associated with non-functional requirements are:

1. They are not clearly defined and subjective in nature – Statements like “System should perform well”, “User shouldn’t wait long to get the response”, “System should be easy to maintain and update”, are examples of subjective nature of these requirements.
2. They are not documents, articulated and noted – Most of the requirement docs have section for NFRs, but those are short and contain bullet points of NFRs.
3. They are not measurable
4. In many situations, they are not achievable (technically feasible), attainable (with given skill set or time) and relevant (for e.g. imposed based on prior experience)
5. They are not clearly classified as in-scope or out-of-scope

Then what is the solution?

I remember, I read one of the best statements regarding non-functional requirements that those have to be SMART. i.e. Specific, Measurable, Attainable (do-able), Realizable (with given skill set, time etc) and Traceable.

In more words:

1. NFRs have to be well defined, documented and elaborated (like functional requirements)
2. Very important, NFRs should be measurable. (for e.g. With 100K transaction per day, the EFT would take 1 second to be verified by transaction monitoring module)
3. A technical study (PoC) must be done to verify the attainability of NFRs
4. NFRs must be considered and addressed in each phase including architecture. They must not be thought of as “do it when you face it”
5. Comparatively, non-runtime (or static) NFRs are more vague. The *abilities are very subjective and must be clearly defined. For e.g. “system should be extendible” is a vague statement which can’t help an architect or designer to address it. Also, these abilities have major impact on the time and cost of the project. Hence a clear understanding (with examples) of extendibility (and other abilities) is a must.

Conclusion

Non-Functional Requirements majorly affect the time, quality and cost of any project. By nature, they are vague and ambiguous, but have major impact on the architecture, design and overall acceptability & usability of the solution. They must be considered, specified, measured and tracked at all stages of development.