Note: This is part of a series on a Lean and Scalable Agile Enterprise Requirements Information Model. Refer to that series for additional context.
In an earlier post, Agile Requirements Information Model (5) – For Agile Programs (b): Nonfunctional Requirements, we introduced Non-Functional Requirements as “Backlog Constraints” and highlighted the important role these types of requirements play in building enterprise-class systems.
They appear in the model here:
as well as in the Big Picture:
One set of comments from Ryan Shriver (http://theagileengineer.com) triggered a deeper look. Ryan commented:
“I like how you related Non-Functional requirements to backlog items, I think the concept of constraints make sense. May I propose a way to further investigate the components of Non-Functional requirements?”
Here is Ryan’ specific post on the topic:
In this post, Ryan suggests that a far better label for Non-Functional Requirements is “System Qualities” and that resonates with me. He goes on to note:
“A Non-Functional requirement is expressed as a System Quality. It’s the center of this tiny universe. I prefer the term Qualities over Non-Functional requirements because it says what they are, not what they’re not (if that makes sense).
A Quality can have a Scale, which captures “what” is being measured (the units of measure)
A Quality can have a Meter, which captures “how” the measurement is made (method of measurement)
A Quality can have many Constraints (failure levels), so long as each has a unique label (i.e. Tolerable, Product Failure and SLA penalty could be examples)
A Quality can have many Targets (goal levels), so long as each has a unique label (i.e. Budget Goal, Stretch Goal and Wish could be examples)
6A Quality can have many Benchmarks (previous results), so long as each has a unique label (such as date taken, conditions when results recorded as examples)”
I’m giving some serious thought to just renaming the NFR box in the model to be” System Qualities” as that communicates more directly what these things are and why we care. Of course, I would still describe them as Non-Functional Requirements and Design Constraints, because that’s the way so many people (like me, for example, in Managing Software Requirements: First and Second Editions) have always described them in the past. What do the readers think of this semantic change?
Ryan also pointed me to a long thread on Mike Cohn’s blog which has a deeper discussion, mostly around whether these types of requirements can be expressed in measurable and objective form, and whether they should be expressed using the canonical user story form (as a…).
Tom Gilb, who is an authority on system requirements practices, also opines in comments to the post. You can see Mike’s post and a host of those comments here.