Recently I was reading a draft requirements document and eventually I came to a section entitled ‘Non-Functional Requirements’ (NFR). As usual there was hardly anything in there. It reminded me of a session at a Extreme Programming camp I attended. The question raised there was, “how do you ensure the non-functional requirements are met”?” Both experiences lead me to believe that NFR are treated as some strange satellite requirement. The upshot of that is they are often just ignored, something that is pushed to the back of the priority stack. At the aforementioned XP camp I argued that there is no such thing as NFR. When I see a functional requirement (FR) I immediately read into it the NFR, I want the NFR to be included in the specification. For example, it is a classic mistake to only consider performance at the end of project, a mistake that is costly to fix. There are just requirements, each requirements is a combination of FR + NFR.
What to do? I would encourage everyone to include NFR with each FR. From a TDD/BDD point of view, we should be seeing references to those NFR. Ok a domain user might not understand the technical terms associated with NFR but even a simple reference to them would be enough to allow/remind more technical readers that they also need to be met.
I totally agree with you! It can be also proved by logic and common sense
Coudn’t agree more. NFRs are emergent qualities of the system or software, that are expressed through design and functionality. I prefer to call them para-functional to reflect that.
Interesting point of view about Non-Functional Requirements