Non Functional requirements are not functional

I attended a lecture lead by Tom Gilb an American systems engineer and acclaimed author about Value Project Management Methodology EVO (Evolutionary Project Management) at BCS London. He alluded briefly to his attitudes towards Non Functional Requirements in a less than positive light this encouraged me to delve further into his works. Given that we are in the middle of a discussion and working through pieces of work that outline some core NFRs that will be used to guide and advise the future processes that other teams need to be aligned alongside the standards proposed. I thought it would be worth writing up a very brief high level view of his theories along side my own personal thoughts.

Consider for a moment that even the term ‘Non Functional Requirements’ is riddled with negativity and ambiguity. In order for any task, project or user story to succeed it needs to be clear and unambiguous, grounded in design and hold a stakeholder focus, we should all be nodding in furious agreement at this point. Non functional requirements fail at the first stage, dictionary antonyms for functional include; worthless, impractical, broken as such are we really willing to suggest that the additional standards we are advising be followed are flawed from the start. That is certainly not the expectation that we want to set when looking through these guidelines.

In his paper Rich Requirement Specs: The use of Planguage to clarify requirements and included in his Planguage (planning Language) book Gilb heavily pushes for clarity, quantification, quality and value in all requirement specifications. He also suggests the below alternatives for renaming the different requirements.

Not an NFR in sight. Interest in the above and for this purpose would extend to the Performance requirements specifically the naming conventions that are applied here. The definition of a function is straight forward; an action, what the system does.  Product qualities are harder to define, Gilb explains it as how well a product interacts with people, other products, or internally within the product itself. Product qualities in turn create value for the stakeholders of the project.

The principle is simple in design, if there is a security requirement specify it as such if there is a requirement that differentiates that product to another product call it a quality requirement. Are there resource requirements? Say so. Is it an Operational requirement e.g transactions failing, then assign the term Operational Requirement and so on. This encourages the shift away from fluffy buzz work terms like ‘Optimal exposure of app status’ or ‘Logging to be relevant, configurable’ (real examples from Betfair confluence) and towards quantitative instructions that can be measured.

There is a lot of documentation out there around NFR both for and against the terminology, we have the scope to change our current approach and adopt an alternative naming convention going forward. Ask yourself can we hand over highly polluted requirements with ambiguity and obscurity to the next stage and expect that the final result will meet all the specificity that is needed when dealing with tools such as Chef, Ansible, Thoughtworks Go and processes such as logshipping or monitoring. Whether you agree with the above is open to interpretation however the take away should be to move away from negative and ambiguous terms such as Non Functional Requirements and towards alternative naming conventions suggested here.

/Stacey Eady is an Infrastructure Automation Engineer in our UK office