China Naming Network - Ziwei knowledge - 202 1-04-22 Practice of Demand Paradigm —— How to Avoid Dissipation and Distortion in the Process of Demand Transmission

202 1-04-22 Practice of Demand Paradigm —— How to Avoid Dissipation and Distortion in the Process of Demand Transmission

From the concept in the user's mind to the final working software, the software requirements will go through a long transmission chain. This kind of transmission is different from data replication in the information world, and it depends more on people's expression and understanding, so the dissipation and distortion of information in the process is inevitable.

To avoid the dissipation and distortion of this demand information as much as possible, I have roughly two ways to summarize it. One is to minimize the length of the transmission chain, and the other is to make the information understood by both parties as much as possible.

This paper records the practice of "requirement counter-talk" we tried in the project to help the project team reach a consistent understanding of the requirements. If you can inspire and help your colleagues, it will be very gratifying.

A, the person in charge of the demand side, called me and said that P, the demand and demand engineer, had been told, but he was worried that P might not know anything. He described the demand to me again and said three things, balabala, for a few minutes. He thinks it's relatively simple. Let me pay attention to whether P understands the requirements. Being unfamiliar with my business background, I began to lose my mind during A's speech.

I found P, asked, and found that A told him orally. He made an estimate of the workload, and he also mentioned some doubts when describing it, but he was ready to start work. I asked him to file the request, and then let organization A hold a meeting to discuss and confirm it.

A made an appointment with the heads of two sales departments, and then started at 1: 40 in the afternoon and the discussion ended at 5: 00. During the discussion, we found many places that were not mentioned before, and also confirmed many specific business scenarios and functional operations.

After several hours of intense discussion, everyone thought that the main points to be discussed had been finished, but they were still not quite at ease about whether P was understood in place, so they asked P to talk about the requirements backwards, bring the roles used into the specific scenes of each link, and tell the complete business process from the perspective of business operation. Then p was a little confused at first. After a simple adjustment, he spoke fluently about business processes and functional operations, and found several inconsistencies among them. After discussion and confirmation with the business people, everyone finally reached an agreement.

This requirement discussion process is time-consuming and laborious, but it avoids a series of rework in the later period.

One day at the station meeting, the test said that a test point about this iteration needed to be reviewed. When I bring it up and judge it, he will talk about the demand first.

Requirements analysts and developers attended the review meeting, and test engineers strung requirements according to business scenarios. As a whole, it can be seen that the business logic understood by testers is consistent with that understood by requirements analysts.

In the process of speaking, the requirements analyst gained a bystander's perspective to think about requirements, and found things that were not clearly described before, as well as things that testers did not notice, but did mention in the process of requirements communication.

Because each iteration will not have too many function points, the meeting time of this review will be about 20 minutes, which is a simple but effective meeting.

Demand reversal will increase the time of a single meeting, but it can avoid repetition caused by inconsistent understanding in the later period.

But if there is too much discussion, it becomes unrealistic to talk about demand. Therefore, it is very important to divide the requirements into small iterations for communication and confirmation.

Of course, in the case of a lot of communication content, you can also choose individual key and important ones for counter-talk confirmation.

Also, when explaining requirements to developers, you can draw lots from multiple development engineers to decide who will talk about a module in turn, and you can also keep the attention of participants.