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.