KANO model in relation to requirements management

Our goal when we build software is to help people do their work faster better etc. (think of any quality attribute), so we put tremendous effort in understanding what the user what wants. Next to that we manage those requirements very strict, and build, test and deploy the solution that realizes those requirements. The last step is the implementation in the organization, in this step the users see the system and are using it. mainly we see 2 types of reactions:

  • The users think it’s ok, that’s great we did out jobs well.
  • The users expected some things different, there we go into the change management cycle. 

A third reaction so see very seldom is wow that systems is great. This come trough the fact the the users heard stories (or read specifications) on what the system would do.

In this post I focus on the 2nd type of reaction (users expected some things imagedifferent). For this users the system works probably as designed, but they hoped for some nice features that make their work easier. Those features where probably set out of scope since the project had a small budget and only the basic features where realized. This will result in the users getting the basic thing they want and expect, so their ok with it. But we want to please the users and deliver a great system.

To plot this on a other product: biscuits. When you buy biscuits you’re requirements are a package containing biscuits which are fresh. When you buy this at a reasonable price you are ok, not extremely happy since a comparable product has the same characters. But when the biscuits are made in an handy form so you don’t have to hassle to get them out you are happy.

These findings can be plotted on the KANO model, below you can find a description of the model.

The Kano model is a theory of product development and customer satisfaction developed in the 80s by Professor Noriaki Kano which classifies customer preferences into five categories:

  • Attractive
  • One-Dimensional
  • Must-Be
  • Indifferent
  • Reverse

These categories have been translated into English using various different names (delighters/exciters, satisfiers, dissatisfiers, etc.), but all refer to the original articles written by Kano.

Attractive Quality These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected, For example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken.

One-dimensional Quality These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled. These are attributes that are spoken of and ones which companies compete for. An example of this would be a milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent then the customer will feel misled and it will lead to dissatisfaction.

Must-be Quality These attributes are taken for granted when fulfilled but result in dissatisfaction when not fulfilled. An example of this would be package of milk that leaks. Customers are dissatisfied when the package leaks, but when it does not leak the result is not increased customer satisfaction. Since customers expect these attributes and view them as basic, then it is unlikely that they are going to tell the company about them when asked about quality attributes.

Indifferent Quality These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction.

Reverse Quality These attributes refer to a high degree of achievement resulting in dissatisfaction and to the fact that not all customers are alike. For example, some customers prefer high-tech products, while others prefer the basic model of a product and will be dissatisfied if a product has too many extra features.[1]

imagehttp://en.wikipedia.org/wiki/Kano_model

 

When you plot this model to requirements management, you can understand it is essential to get the basic requirements clear other wise your product won’t get accepted. But don’t forget the requirements that have an Attractive Quality. When you realize some of these requirements that make the life of an user easier, you are the man and their very happy with the product an will come back to you the next time.

This can also be plotted on the MOSCOW principle:

 

MOSCOW

KANO

Result when in the system

Result when not in the system

Nice to have

Attractive Quality

Verraste emoticon

Verlegen emoticon

Must have

Must-be Quality

Kushand

Duivel

Should have

One-dimensional Quality

Glimlach

Geërgerd

Could have

Indifferent Quality

Emoticon met brede lach

Kushand

Won’t have

Reverse Quality

Boze emoticon

Kushand

 

Probably the Attractive Quality requirements are already defined in the “should” or “could have” section, but they are not distanced from the other requirements the “have One-dimensional” or “Indifferent” Quality.

 

So what I suggest (next to the normal requirements management procedures) is to keep the KANO model in mind when you manage requirements and distinct the requirements the make the user happy (Attractive Quality)

  1. No comments yet.
  1. No trackbacks yet.