I ran across Dean Leffingwell’s work recently through his blog post about Non-Functional requirements. In addition to his thoughts on how to store them in the backlog and typical non-functional requirements seen in practice, he drew attention to where they fit in his Requirements domain model.

I studied the model and noticed there was an empty box labeled “Non Functional Requirements”. I thought I could add something to it, so I cracked open Omni Graffle and whipped out the picture you see above. It’s a Planguage perspective on Non-Functional Requirements that consists of Qualities, Scales, Meters, Constraints, Targets and Benchmarks --- all the typically stuff I’ve talked about here, here, here.... I actually developed this model for a tool called Value Meter that I’ve been hacking on now and then and in practice it works quite well.

So I sent this to Dean and he said thanks and could I put this online. So here it is. Feel free to leave comments with your thoughts on the model. It may help if you read a basic intro to these concepts to get some real world examples. Otherwise, here’s how you read this model:

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)
A 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)

Here’s a real life example from a recent project:










That’s it. Using this model we can:

Define any system quality in a very succinct-yet-powerful definition
Define success and failure levels clearly for all to see (stakeholders and architects)
Measure our “progress to goal” for each quality (or all qualities collectively) as the distance between the most recent benchmark and our target level.
Use the current “progress to goal” to help prioritize and determine where to focus resources for immediate improvement.

We can do lots of other things with this model, perhaps even model the qualities necessary for solving world hunger or implementing change in Washington :-) In the meantime, see if this make sense for more mundane things like your systems and let me know what you think.