What you did is not what I want !!!

I recently reviewed the book "Software Engineering" with the following sentence: "What you do is not what I want ". After reading it, I feel the same way. For details, I divide the related situations into three levels:

1. You don't understand what I mean, but you don't understand what I want.

2. What I said, you understand, but you don't understand what I want.

3. What I said, You understand what you understand is what I want.

The above are several situations that are prone to occur in the software demand stage. This does not include the lack of internal transfers from demand engineers to analysts. In general, there are several levels of understanding of requirements when we discuss requirements with the buyer.

Most of the first cases occurred during communication with the buyer. At this time, we often do not have the knowledge in this field in the buyer's environment. Therefore, it is best to study hard and ask the buyer for such questions. We should not think that we can start working as soon as we have the need, so we can forgive the demanders. However, there are fewer such cases. In many cases, the demand is easily understood by the buyer.

After a period of communication, we will find that there is no ambiguity in understanding the demand of the buyer. At this time, we will start to do the subsequent work in development. In fact, I personally think that it is still not busy at this time. If it is started at this time, I am afraid there will still be many requirements marked during project acceptance, but not what the user wants, this area is mostly non-functional, so at this time, we should spend some time exploring the demand and give the buyer a multi-angle and multi-level understanding. Only in this way can you really do what the customer wants, that is, the third aspect, otherwise there will still be repeated in the project.

Of course, the requirements will change throughout the development. This is what our developers have learned. But one thing is that the more we fully implement the demand side at the beginning, the smaller the user's subsequent changes may be. Do not wait for the user to propose anything. If possible, the developer can also propose anything, in this way, the demand can be relatively improved, and the user needs can be fully understood for reasonable commercial transactions. Further, the demand will not suddenly increase at the end of the day, people are busy, the progress cannot keep up, the project will be delayed, and so on.

Most of these have been encountered or are encountered in my work. I write them frequently to avoid forgetting them. Haha!