Brief description of project requirement Management in software development

I. Preface

In the process of software project development, demand changes throughout the entire life cycle of the software project, from the software project establishment, research and development, maintenance, user experience is increasing, the changes in the feeling of using software and the new developments in the entire industry have brought the software to constantly improve functions, optimize performance, and improve user friendliness. In the software project management process, the project manager often changes user requirements. If these demand changes cannot be effectively handled, the project plan will be adjusted repeatedly, the Software Delivery date will be delayed, and the morale of the Project R & D personnel will decrease, this will directly increase project costs, decrease quality, and decrease the project delivery date. This determines that the project team must have a requirement management policy.

Ii. Requirement management complexity analysis

Software requirements are the most critical input of the entire software development project. Compared with traditional production enterprises, software requirements are characterized by ambiguity, uncertainty, variability, and subjectivity, unlike the need to produce hardware such as automobiles and computers, he is tangible, objective, descriptive, and testable. software requirements are the most difficult to grasp for software projects, its complexity is embodied in the following aspects:

1. Description of the requirement. The lack of formal and complete Requirement documents wastes a lot of manpower and material resources, but there are new problems with the requirement documents. The demand review conducted by the user will be conducted in full form, because the user does not listen to the Requirement documents he has read on the last hundred pages. Different levels of customers (users) have different concerns. It is unrealistic to want each customer to become a demand expert.

2. Completeness of requirements. How can we eliminate any omissions in requirements? How can we accurately define the scope of the system? This is indeed a dilemma. For a slightly larger system, it is almost impossible to raise the demand without a requirement. Every time a demand review is held, new requirements will emerge, so that the system does not have an accurate scope definition. Even in this case, the system still needs to be developed, and there is no way. The scope of the system must be hard defined to establish a baseline.

3. Demand development period issues. Customers and software companies have spent a lot of time on demand. Can customers and software companies tolerate this? To ensure the correctness and completeness of requirements, the Project Manager often insists on spending a lot of time in the demand phase, however, the customer and the company's senior leaders are worried about the delay in seeing the software that can be run! They tend to force the project team to move forward as soon as possible, and the members of the project team tend to exhaust the complicated and changing demands of the system. They also hope to end this stage as soon as possible.

4. Detailed requirements. How detailed is the requirement? The wise man sees wisdom, and there is no final conclusion. If time permits, the wise man can always be fine-tuned. However, the longer the demand cycle, the more possible changes, the stricter the design restrictions, the higher the requirements for the extraction of common requirements, so long as you (customers, users, demand analysts, designers, testers) think that the description is clear, you can enter the design stage.

5. demand changes. If there is only one truth in the process of software development, it must be: demand changes are permanent and demand cannot be complete. The process of software development is actually a process of struggle with changes. Changes in demand are not necessarily a bad thing, but may also be a good thing or a business opportunity, people sensitive to the market can find market opportunities from changes in demand.

There are many reasons for demand changes, such:

· Not fully identified at the beginning, and more needs need to be added;
· The business has changed and the demand must change;
· Incorrect requirements;
· Unclear requirements.

The change in requirements is a problem that every developer and project manager has encountered and is also the biggest headache. Once a change in requirements occurs, you have to modify your design, rewrite your code, modify your test cases, adjust your project plan, and so on. demand changes are like the source of evil, what should I do if the normal progress of the project is not complicated? Manage it! To make the demand change under a controlled state, rather than randomly changing, demand management is to control the change of the demand according to the standard process. The challenge arises. changes in requirements are generally not sudden revolutionary changes. The most common problems are the gradual change of Project Scope creep, this kind of gradient is probably not realized by both the customer and the developer. When it reaches a certain level, the two sides suddenly look back and find that they have changed the world.

　　Iii. Demand management policies

Demand management must comply with the following policies:

1. The requirement must be related to the input.

The requirement must be related to the input. Otherwise, if the cost of the demand change is borne by the developer, the change of the project requirement will become inevitable. It is often said that there is no free lunch in the world, and there should be no change in demand for free. However, the acceptance of demand changes is the result that software developers have to swallow. Therefore, at the beginning of the project, both the developer and the investor must clarify this article: the demand changes, and the investment in software development changes.

2. Changes to requirements must be approved by the investors.

Changes in demand have led to changes in investment. Therefore, it is necessary to pass the approval of the investor so that there is a cost for the change in demand, and the change in demand can be treated with caution. I have experienced a project. To avoid project risks, we invited user representatives to participate in the development process. As a result, this user representative proposed a large number of "small demand changes" during the development process, when developers modify the software as needed, a large number of such changes need to be modified when the project enters the on-site implementation stage, the problem is that our project team members regard the needs of the user representative as the sacred purpose, but ignore whether the requirements have been recognized by the customers who have the right to make decisions.

3. Small demand changes must also go through the formal requirement management process.

Small demand changes must also go through the formal demand management process. Otherwise, they will accumulate less. In practice, people often do not want to implement formal demand management processes for small demand changes. They believe that this reduces development efficiency and wastes time. This concept makes the demand gradient uncontrollable, and ultimately leads to project failure.

4. Precise requirements and scope definitions do not prevent demand changes.

The finer the definition of the requirement, the more you can avoid the gradient of the requirement. This is a problem at two levels. Too detailed requirement definitions have no effect on demand gradient. Because demand changes are permanent and will not change, not because of the need details. Pay attention to communication skills. The actual situation is that users and developers have recognized the above issues, but the changes may come from the customer or the developer, as customers, they may not want to invest more in demand changes. Developers may have changed their needs on their own initiative. Their purpose may be to make the software more refined, as a result, the demand manager and project manager need to adopt various communication skills to implement various projects.

Based on the above problems, requirements must be managed so that they can truly become baselines of software engineering and management, so that software plans, activities and work products are consistent with software requirements, this allows reuse of requirements.