QUPER model for better requirements

Today at the Oresund Developer conference, Bjorn Regnell presented the QUPER model, a very interesting way to think about specifying non-functional requirements. QUPER stands for Quality Performance and in the QUPER language Quality represents all the “ilities”. According to Regnell, the most difficult requirements are the ones related to quality. The problem with quality requirements, such as performance targets, is that they are often given without precise explanation. QUPER is a way to increase and align the debate within a company on quality that a project should deliver. The model promises to make tacit requirements explicit, help to introduce a coherent terminology across organisations, give us a more qualified scoping debate, support change management, help evaluate competitor products and allow us to make better product management decisions.

The trick with many of these requirements is that they are not of discrete on/off nature, but often continuous and can be measured on a sliding scale. This is further complicated because the “benefit of quality is non-linear”, said Regnell. More quality gives you benefit, but not always the same. QUPER puts projects into 3D along the axes of cost, value and quality. The idea of the model is to estimate cost-benefit breakpoints and barriers of quality and expose them for discussion.

One of the basic assumptions of the model is that quality produces benefit on the S curve, and that there are three important points on the curve (called breakponts in the language of the model). Utility is a point where the product moves from unusable to usable (eg startup time of a mobile phone is one minute). Differentiation is where the feature starts creating a competitive advantage and becomes an argument in marketing (eg startup time is less than a second). Saturation is where the increase becomes overkill (no real difference to the user if a phone takes one microsecond or two microseconds to start up). “If you go beyond the saturation point, you are investing resources in the wrong area”, said Regnell.

Another assumption of the model is that increases in quality do not cause linear cost increases. At some points, cost becomes very steep (eg product has to be rewritten or there is a significant impact on architecture). These points are called cost barriers in the model.

Exposing barriers and breakpoints and putting them on a scale allows us to have a more meaningful discussion on where the product is compared to the market and where we want it to be. We can use breakpoints and barriers to define relevant targets for different phases of the project and make them measurable. Regnell suggested setting these as intervals rather than discrete points, because that works better with the continuous nature of quality requirements.

The QUPER process for eliciting and specifying quality requirements breaks down to:

  • Define quality aspects
  • Estimate your product’s current quality for a given release and the competing product’s quality (at present or envisioned)
  • For each quality aspect and for each relevant qualifier, estimate the breakpoints
  • Estimate barriers where cost increases steeper
  • Put that on a scale, estimate candidate targets and discuss and decide on actual targets for coming releases.

It’s also important to understand that these breakpoints change over time. Regnell said that Utility and Saturation are relatively stable over time in a mature market but Differentiation still changes.

Although I don’t agree with bundling so many things under the name “quality” and I really dislike talking about “non-functionals” (which often imply hidden functionality), I found this model very interesting to discuss requirements that can’t be measured by discrete on/off switches but work on a sliding scale. It might help to expose hidden assumptions and give us a framework for a much more meaningful discussion than the classic “it has to be fast” statement.

For more information, Regnell suggested reading his article on QUPER from IEEE software journal issue 25.

I’ll be posting many more articles on Oredev in the next few days. Subscribe to my rss reed to get notified about updates

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your User Stories. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

How to get more value out of user stories

Specification by Example Workshops


2 thoughts on “QUPER model for better requirements

  1. Interesting. Seems to owe a lot to Tom Gilb’s work on expressing requirements as quantifiable product qualities, which advocates using well-defined meters (the method for measuring a particular quality) and defining various target levels such as current, acceptable, goal etc.

    Also, the structure and style of the requirement notation looks similar to Gilb’s ‘Planguage’.

  2. Hi, Gojko.
    Interesting to see that you liked this model, and dislike (judging from you comments) Tom Gilb’s presentation, which is really similar to this ideas (if you look into his Competetive Engineering). As well Tom Gilb work contains more elaborated topic, as, for example, how to choose next increment of the quality attributes (Tom Gilb term instead of non-functional requirements), which should be attacked on the next iteration.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>