As a code farmer, every time to get the product to the document, began to achieve this demand, there is no thinking about the product is not gradually become a part of the assembly line of the big company. We could explore more, like, what happened to the requirement before you knew it was coming to you? How was it created?

We can see that a requirement goes through a lot before it is handed to us. Today’s article focuses on a common tool used in step 3 requirements analysis. After we have gone through the requirements gathering stage, we have a variety of requirements that may be implemented, so we need to carefully comb each requirement and determine the business value of each requirement. The business value of a requirement is the most worthy of brainstorming. What determines business value?

  1. Importance (We use Carnot model to analyze importance)
  2. The degree of emergency
  3. The duration of the

So a little bit further on why business value is so important. When we start implementing requirements, how do we decide which one to implement first? We will first achieve cost-effective demand. So what’s the cost performance ratio? Cost performance = business value/development volume. So what I understand is that business value analysis for a company is to grasp the rhythm, the lifeblood, the trend of the whole enterprise. After all, each requirement has to be implemented by the technical team, and how they are prioritized depends on the cost.

Kano model

Now that I’ve laid the groundwork for the Carnot model. Don’t forget that the Carnot model is the materiality section of the business value analysis.

So let’s think about what the x and y axis represents first.

Y: Satisfaction. It gets higher and higher

X: Degree of completion. The higher you go to the right.So in this coordinate system we can draw the following three curves:

Basic requirements

Let’s look at the last curve in the picture below (green). What are the base requirements? As we can observe from the graph, if such requirements are more complete, customer satisfaction does not indicate, but maintains a neutral attitude. But if we don’t perfect these requirements, then customers will be very dissatisfied.

For example, cleanliness is a basic requirement for a hotel. At fancy hotels, even if we could drink toilet water, it wouldn’t improve our satisfaction much. But a hotel, if it’s not clean, it’s already sold out in our minds.

Expect demand

This demand corresponds to the straight line in the middle of us. It is intuitive to see that our satisfaction is directly proportional to the degree of perfection of our demand. The more we do, the more satisfied our customers are. The worse we do, the less satisfied our customers are.

Here’s an example:

For example, when we play games, the better the operation experience, of course, the more satisfied, the worse the less satisfied. Or the efficiency of a complaint center. If you’re more efficient, you’re more satisfied, and if you’re less efficient, you’re less satisfied.

Excited demand

This corresponds to the top line of our graph. We can see that the customer is not dissatisfied if the requirement is not fulfilled, but the satisfaction of the customer is greatly increased once the requirement is fulfilled.

For example, on one of our flights a customer gets upgraded, his satisfaction will skyrocket. Or in the game, there are points that resonate strongly with players like good luck after eating chicken, chicken for dinner. Will make customers very cool.

With this analysis model we can make our requirements more hierarchical in structure, base requirements, extension requirements and value-added requirements, and we can also allocate the appropriate proportion of these requirements in a release iteration pool.