Who has changed the demand?

Here, we will not talk about demand changes caused by objective market or project budgets. Here, the demand change refers to the demand change with the necessity of the project and the overall goal of the project being stable.

As we all know, the biggest headache for developers is that when a function (or even the entire project) is developed, the customer requests to change the requirements and change the requirements documents, this causes additional development work or project delays. In this case, the vast majority of developers blame the customer for the reason, which is a problem with their needs. But if you think about it, are these errors true to customers?

For example, if the customer wants a fruit knife, after investigation and demand analysis, the requirement documents are delivered to developers as follows:

1. This knife must be sharp.
2. The knife cannot rust
3. This knife can cut fruit

After obtaining the requirement document, the developer starts coding implementation. The following is the developed fruit knife, which meets all the requirements in the requirement document. There is no problem with unit testing, and there is no problem with integration testing. The project has successfully reached the UAT stage. You can imagine what the customer will say when the UAT is finished. This is too big, so the customer needs to change the requirements, plus one: the size of the knife needs to be 15 cm long and 5 cm wide.

 

 

Is the change in the above requirement caused by the customer? Of course not. The customer only needs a fruit knife, but most of the food knives delivered by developers only meet the requirements of the requirement documents, rather than the customer's requirements.

How can this problem be avoided? Imagine if the requirement document is like this: "The customer needs a knife that can easily cut fruit", will the developer develop a kitchen knife for the customer? Of course not. Although developers may have doubts about the "convenience" standard, they can better understand the customer's "convenience" needs through communication with the customer, this prevents the project from meeting the requirements of the system but not the customer's needs.