Prioritizing Software Requirements With Kano Analysis

Using Kano analysis to prioritize software requirements

We’ve talked before about three ways to prioritize software requirements. We’ve also talked about incorporating risk analysis into ROI calculations for requirements. In this post we will look at how Kano analysis can be applied to prioritizing requirements.

Kano analysis allows us to prioritize requirements as a function of customer satisfaction. Kano defined four categories into which each feature or requirement can be classified (we’ll use an Apple iPod for examples in each of the categories):

1. Surprise and delight. Capabilities that differentiate a product from it’s competition (e.g. the nav-wheel on an iPod).
2. More is better. Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life or song capacity).
3. Must be. Functional barriers to entry – without these capabilities, customers will not use the product (e.g. UL approval).
4. Better not be. Represents things that dissatisfy customers (e.g. inability to increase song capacity via upgrades).

Surprise and delight requirements

For just a moment, think about software as a user, not an accountant. We want software that is fun to use and interesting. Affordances in the user interface that allow us to just “do what comes naturally” and have the software do exactly what we want. New ideas that make software better. We aren’t talking about a button that pops up dancing squirrels when we hit it – we’re talking about valuable features that make software great.

• The nav-wheel on the iPod is a great hardware example.
• Gmail’s use of labels instead of folders for organizing email is a good software example.
• Contextual help buttons that open to exactly the right page in a help file.

All of the examples above are implementation details or the results of design decisions – which we’ve pointed out before are not part of specifying requirements. However, when converting from market requirements to product requirements, we can point our development teams in the right direction, and help our development teams focus on innovating the right problems. These might be the requirements behind the delightfull features listed above

• Users must be able to select songs while holding the iPod in one hand.
• The system must provide an efficient way to organize emails, with the assumption that users will never delete emails.
• The system shall provide relevant help information for the context in which the user requests help.

More is better requirements

These are the most easily graspable concepts – bigger, faster, better, stronger. The challenge in writing a more is better requirement is in knowing when enough is enough. If we were to write requirements that said “minimize” or “maximize”, they would be ambiguous requirements. What’s the theoretical minimum response time for a search engine? A few hundred micro-seconds for the bits to travel from the server to the user, plus a few micro-seconds for switch latency, plus a few nano-seconds for a cpu to find the answer? If we were unambiguously requesting that our developers minimize search time, it would be completely impractical.

Specifying precise objectives can be very difficult as well. The law of diminishing returns comes into play. There’s a concept in economics called utility which represents the tangible and intangible benefits of something. We can consider the utility of a feature with respect to the target users. A graph of the utility for speed of search-result generation would look like the following:

We can see that as the speed of results increases, the associated benefit to the user of further increases in speed is diminished. When writing a requirement, how do we determine the speed that is truly required? We would be ambiguous to say “as fast as possible” or “as fast as reasonable.” And we would be naive to think that we didn’t need to understand something about the implementation before specifying an unambiguous requirement like “search must complete in 2 seconds.”

We have only described the benefit side of the cost-benefit analysis needed to specify the requirement. We have to iterate and interact with our designers to determmine the impact of a speed specification on costs. After getting feedback from our implementation team, we now have an understanding of the cost of implementing search, as shown in the following graph.

As we see, it gets progressively more expensive to make progressively smaller increases in speed. This is our “development reality” and we can’t ignore it when specifying how fast search needs to be. To determine the optimal specification, we have to find the point in the curves where the incrmental benefit of searching faster is equal to the incremental cost of searching faster. We can do that by graphing utility versus cost as shown in the next figure.

The circle shows the point where the slope of the curve equals 1. At this point in the curve, an additional increase in speed provides less benefit than the associated increase in cost. At any point to the left of the circle, we’re “leaving money on the table” because there is a better point to the right. This is the optimal speed to specify.

Reality check

In the real world, we won’t have the precise data that allows us to draw these graphs and quantitatively identify the pareto optimal point on the cost-benefit curve. It is important to understand the fundamental principles of the tradeoff so that we can make informed decisions and judgement calls.

Some analyses will be relatively easy, as our development curves are usually discrete data points based upon estimates of the work required to implement particular designs. We also won’t have access to the full spectrum of design choices, because we will be limited by other constraints on the system as well as the creativity and capabilities of our development team in proposing alternatives.

Must be requirements

These are the requirements that most people think about when they talk about requirements. These are the easiest requirements to elicit.

Stakeholders can usually tell us what they must have in the software. In our Am I hot or not? post on requirements prioritization, we see that 37signals focuses on this as their primary criterion for inclusion in a software initial release. They choose to only put essential, or ‘must be‘ requirements into the initial release of software.

Better not be requirements

This is really just the opposite of surprise and delight. If dreamers think about what makes something great, then critics complain about what holds it back. We don’t think this bucket really has a place in Kano’s analysis. Saying “Users don’t like confusing navigation” doesn’t provide any benefit relative to saying “Users prefer intuitive navigation”. We suggest not using this category at all.

Conclusion

We can apply the Kano techniques to make sure we’re making good prioritization decisions

1. Are our 1.0 release requirements all “Must be” requirements?
2. When we specify “More is better” requirements, are they unambiguous, and are they optimal – or at least practical?
3. Do we have any “Surprise and delight” requirements that will enable us to create an innovative product?

[Update: We’ve continued this analysis in Prioritizing software requirements – Kano take two with details about how to apply this classification system to prioritization decisions]