According to polls, up to 70% of organizations have failed in a project at least once over the last year[1]. The research shows that even 50% of project corrections result from requirements problems. Up to 70% of the projects end in failure due to the low quality of requirements[2]. These numbers make an impression, don’t they? And they prove how significant a project’s requirements are. That’s why it’s worth getting familiarized with best practices of requirements development (requirement elaboration). Today I’d like to introduce to you a model that facilitates discovering various types of requirements.

Where to get requirements from?

To remind you, the most important sources of requirements include the following:

  • Stakeholders
  • Documentation
  • Systems

A BA should collect requirements from different sources, and omitting any of them would lead to requirements that are not fully defined.

As a consequence, this may result in a total failure of a project. The main source of requirements is, of course, stakeholders; however, most of them do not mention those requirements that seem obvious to them. It’s a serious issue, but we can solve it with the help of a model developed in the ’80 of the 20th century by Japanese professor Noriaki Kano.

 

Kano model

The Kano model helps understand what features of the solution improve the satisfaction of potential users by dividing requirements into three primary categories:

  • Dissatisfiers (basic requirements, subconscious requirements; threshold attributes),
  • Satisfiers (desirable requirements, conscious requirements; performance attributes),
  • Delighters (also called exciters; exciting requirements, unconscious requirements; excitement attributes).

Let’s take a look at the diagram presenting the Kano model:

Kano model

Pic 1 – Kano model

Subconscious requirements

These are such requirements that must be absolutely met. If not, then there’s a sudden decrease in our customers’ satisfaction. However, subconscious requirements are considered so basic that they are often not mentioned during discussion expectations. For example, while ordering a pizza, do we recall that it should be well-cooked or delivered on time defined by a seller? No. But not fulfilling these demands considered necessary and known to everyone leads to dissatisfaction with the ordered product.

So how to identify that type of requirement? Asking about them directly is useless as stakeholders do not mention them explicitly because they expect that those demands are clear to everyone. Therefore, a good technique is to, for example, observe similar solutions.

Performance attributes

They cause an increase in customer satisfaction, but a product is acceptable even if those are not implemented. These attributes are also referred to as conscious requirements because we are aware of them, and we know whether they can be met. That’s why we articulate them explicitly. Let’s get back to the example of a pizza order: this type of attribute includes a number of specific ingredients or the pizza’s temperature when delivered. Our expectations are clearly defined. However, if they are not fulfilled, still, the product is acceptable – even if it is not  the source of great satisfaction (I, myself, will accept any pizza!).
Stakeholders discuss these requirements directly; therefore, to collect such expectations, we can use survey techniques, such as polls, interviews, and questionnaires.

Excitement attributes

As the name suggests, this means something causing the wow effect that exceeds expectations and blows customers away. Products with that special something are a source of joy for potential users and draw attention. In the case of the aforementioned pizza takeaway it might be various types of freebies (such as free sauces or soda).
However, how to discover the wow factor if it is about unconscious requirements and we are not aware of their existence until they are introduced? We cannot ask stakeholders about them. Thus, techniques for generating ideas can be beneficial, for example, the good old brainstorming or a change of perspective.

Besides the three above-described main types of requirements, the Kano model also mentions indifferent attributes: those that are totally unnecessary because they do not affect the increase of the customers’ satisfaction or its decrease (such as the color of electrical wiring inside a device since a user doesn’t see them anyway); and reverse attributes whose presence has a negative impact on customers (for example, less space inside a car).

 

Never-ending story

In the case of the Kano model, we must remember one more aspect. With time, delighters become satisfiers, and those satisfiers turn into dissatisfiers, just basics. We can say that humans easily get used to the good things because what seemed groundbreaking in the past, nowadays, is something obvious (for example, seatbelts in vehicles or touchscreens in smartphones).
Also, indifferent attributes may become reversed with time – previously, the amount of plastic used in product packaging probably didn’t matter for most customers. Today, with increased environmental awareness, many users consider too much plastic a factor disqualifying a product.

Vendors of various types of solutions must be mindful that over time, there’s a change in the perception of different attributes. And this means one: the necessity to continuously generate innovative ideas if you don’t want to fall behind the competition. The Kano model can be useful as it focuses on prioritizing requirements (product attributes) according to the level of customer satisfaction. Specifically, it’s helpful when we don’t have much time, our resources are limited, and we need to define MVP (minimum viable product) quickly. The breakdowns of the solution characteristics in compliance with the Kano model categories enable us to determine which requirements must be implemented first, which improve user experience, and which are the cherry on top (or, as some prefer, a strawberry 😊 ), distinguishing our product from others.

Are you hungry already?

[1] https://leocode.com/development/over-70-of-tech-projects-fail/ (22.11.2022)
[2] Info-Tech Research Group, https://www.infotech.com/research/flawed-requirements-trigger-70-of-project-failures (22.11.2022)

Author

  • Małgorzata Trzaska
  • Business Systems Analyst
  • She has been with Craftware for several months, previously worked for international companies from the industrial sector. She enjoys continuous development through work with new technologies and contact with people. In her private life, she is an enthusiast of travel, broadly understood linguistics, and studio cinemas.

Editorial study
Sylwia Soćko
Text translation
Kamil Falarowski
Text revision
Do you want to learn more?
If you cannot see the form, consider turning off adblock.

Join the subscribers of our newsletter