The Kano analysis model was developed to identify and contrast essential customer requirements from incremental requirements, and initiate critical thinking.
Noriaki Kano developed the Kano analysis model in the late 1980s to identify and contrast essential customer requirements from incremental requirements. One of his goals was to initiate critical thinking about the nature of requirements. His characterization approach can be used to drive prioritization of software 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 (an Apple® iPod® is used for examples in each of the following four requirement categories):
1.Surprise and delight. Capabilities that differentiate a product from its competition (e.g. the iPod nav-wheel).
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).
For just a moment, think about software as a user, not an accountant. We want software that is interesting and fun to use. 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’re not talking about a button that pops up dancing squirrels when clicked, rather valuable features that make software great.
Great examples of valuable features include:
• The nav-wheel on the iPod, as a good hardware example.
• Google’s Gmail™ use of labels instead of folders for organizing email, as 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—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 them focus on innovative solutions to the right problems. These might be the requirements behind the delightful 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 email, with the assumption that users will never delete email.
• The system shall provide relevant help information for the context in which the user requests help.
These are the most easily grasped concepts—bigger, faster, better, stronger. The challenge in writing a more is better requirement is in knowing when enough is enough. Requirements such as “minimize” or “maximize” are ambiguous. What is the theoretical minimum response time for a search engine? Does it take 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? It would be completely impractical to unambiguously request that our developers minimize search time.
Specifying precise objectives can be very difficult as well. The law of diminishing returns comes into play. There is 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 this:
We can see that as the speed of results increases, the incremental benefit to the user decreases. While utility is strictly increasing, it is increasing by less and less. When writing a requirement, how do we determine the speed that is truly required? It would be ambiguous to say “as fast as possible” or “as fast as is reasonable.” And it would be naive to think that we did not need to understand something about the implementation before specifying an unambiguous requirement like “search must complete in 2 seconds.”
Thus far, 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 development team to determine 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 below:
We can see how 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 incremental benefit of searching faster is equal to the incremental cost of searching faster. We can do that by graphing utility versus cost as shown below:
The circle in the graph above 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 are “leaving money on the table” because there is a better point to the right. This is the optimal speed to specify.
In the real world, we will not 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 trade off so that we can make informed decisions and judgment calls.
Some analyses will be relatively easy, as our development curves are usually discrete data points based on 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 are the easiest to elicit and are the ones that most people consider when they talk about requirements.
Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. Scott is a product management and strategy consultant, and a visiting lecturer for DIT's Product Management program. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers. You can reach Scott at.