Non-functional requirements are important yet often forgotten


Most software professionals in my experience lapse into talking about “requirements” while meaning only functional requirements. We seem to forget that there are also non-functional requirements, and that non-functional requirements are usually just as important as functional requirements to the end user or customer. Sometimes the non-functional requirements are more important.


Just to set some context, I would describe “functional requirements” as software requirements that are described by asking who, what, where, and when questions. Generally: “what should the system do?” Specifically, this works out in requirements such as “Where will the document be saved?”

Therefore, my definition of non-functional requirements is

software requirements that can be measured by asking how or why questions

Non-functional requirements are also called quality attributes, performance characteristics, or some combination of the three. Some people call them the “-ilities” because many of them end in “ility” (reliability, flexibility). Many of them don’t, though (security, robustness).

Here are some common examples:

Question Attribute(s)
How will the system behave under load? Availability
How fast does the response from this API need to come back? Performance
How well does the system defend against SQL injection? Security
How easy is it to test? Testability
How much will it cost? Maintainability

As you can see, these are big important issues. They are important to all parties, both the customers/end users and the software creators/maintainers. Non-functional requirements should not be forgotten! Indeed, they cannot be forgotten because sooner or later, someone will start asking about them, often when the system is failing to meet an hitherto implicitly assumed non-functional requirement!

For good references on non-functional requirements / quality attributes, check out these sources:

Wiegers, K. E. (2003). Software requirements: Practical techniques for gathering and managing requirements throughout the product development cycle, 2nd ed. Redmond, WA: Microsoft Press.

Bass, L., Clements, P., & Kazman, R. (2013). Software architecture in practice. Upper Saddle River, NJ: Addison-Wesley.

Leave a Reply

Your email address will not be published. Required fields are marked *