Shulou(Shulou.com)06/03 Report--

The death of demand Review

Requirements review has been reduced to a superfluous existence in the process of software project management, and many enterprises have always muddled along in the face of this matter. Perhaps it is due to the lack of technical personnel, from product to design to development to testing, one person arranged, naturally feel that the requirements review is not necessary; perhaps the requirements department in charge is too strong, arbitrary, the draft requirements is finalized. In addition, the growth companies, which are struggling with the crisscross of various chaotic processes, are going through the pain of standardization, and the matter is wavering.

The reason why the demand review will become the target of public criticism is that it will not only bring an increase in workload and trivia, but more importantly, he needs a person to carry the pot. The accuracy and rationality of software requirements are directly related to the developer's work efficiency and project duration, and the requirements review itself is the re-examination of the requirements, which directly determines the quality of the requirements. It is naturally hard work to do such an important responsibility well. Not doing a good job leads to project rework and developers complain that it is a sinner. As a result, not many people are willing to take the initiative to carry the pot.

Each shows his magical powers.

Looking at the textbooks of software engineering and project management, we will find that the theory is very exquisite. But once put into practice, you will soon find that the situation is not as ideal as you think. But the theory is the method guidance, only a system framework, the practical application also needs to combine the different work flow of each company, give full play to each. Here on the needs review of this link, the author talks about his own experience.

In fact, in order to ensure that the requirements review does not become the target of formalism and public criticism, we can refer to the following process methods to cut more and make up less.

1. Define the scope of requirements review in advance.

Before starting the requirements review meeting, it is necessary to determine the content of the requirements review in advance and define the demand boundary of this discussion, so as to prevent the unlimited expansion of the discussion content due to excessive divergence of thinking and deviation from the topic during the meeting, which will affect the completion of the review objectives. Our goal is very clear, this discussion to solve what problem is what problem, in the process of divergence, appropriate record, should immediately return to the subject.

2. Determine the attendees before the meeting.

Participants are divided into two categories, one is those who must attend, the other is those who participate selectively. Those who must attend include: the presenter of the requirements review meeting and the people directly related to the project. In general, the people directly involved in the requirements review meeting must be multi-role, because no matter how powerful they are, they cannot be versatile and have no dead ends in all aspects of their ideas, which needs to include: requirements people, interaction designers, UI designers, architects, back-end developers, front-end developers, and testers. The people who are directly related to these projects are also those whose tasks are closely related to the needs, and their review opinions are very important. Small companies may be "architects, back-end developers, front-end developers" are the same group of people, or even the same person. To arrange different roles to participate in the review, it is necessary for this person or these people to evaluate the rationality of the requirements and the cost of development from different angles, and to consider the possible problems and areas for improvement of the requirements from different angles. try our best to find the problems of the demand itself in the early stage to prevent excessive deviation of the demand.

3. Control the meeting time

Determine the time and duration of the meeting, clearly predict the expected length of the meeting in advance, and inform everyone in advance, so that everyone can have a number in mind to facilitate their own arrangement of the work at hand. If the content is not finished within the expected time, then the meeting should also be terminated at the right time, and another time should be chosen to continue the discussion, so as not to fight for a long time. In the end, fighting for a long time will only make a lot of content hasty.

4. Participants preview the contents of the meeting in advance

Distribute the discussion draft to the attendees one hour in advance (half an hour is too short), let the attendees read and organize the contents in advance, and directly present their opinions at the meeting to improve the efficiency of the meeting.

5. The decision maker who determines the requirements before the meeting

Be sure to let them participate in the meeting, and when there is a stalemate in the discussion process, you need a decision maker to type it. This is very important!

6. determine the minutes of the meeting before the meeting.

The person in charge of updating the requirements document, let him participate seriously, and record the discussion process. After the meeting, the minutes of the meeting need to be published, that is, the requirements review records, which will be included in the document database.

7. Specify the time of the next review meeting

After the discussion of the meeting, we need to make it clear when the next review will be, so as to advance the work progress efficiently. ! [insert it here

The rest of the crap

In fact, the process of requirements review is really implemented attentively, and it will not take too much time. On the contrary, it plays a very important role in improving the quality and efficiency of software projects. What is mentioned above is not the content of the textbook. But the author's actual work experience. If you want to become a big tree, you must know the growth process of the big tree, and the growth of one branch and one leaf is not superfluous in the process of requirements review, but mainly because of the existing process that people are used to and are unwilling to change.

Postscript

The requirements of many software development companies may be decided by the boss, the project manager or even the developer, so how well the requirements review is done depends on the experience and professional competence of the relevant leaders of the company.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.