Complexity analysis of software project requirement management

During the development of the software project, the requirements change runs through the whole lifecycle of the software project. From the software project, research and development, maintenance, the user's experience in the increase, the use of the software feel changes, as well as the industry's new dynamic, all for the software to bring continuous improvement functions, optimize performance, improve user-friendly requirements. In the software project management process, the project manager often faces the user's request change. If these requirements changes are not effectively addressed, the project plan will be adjusted repeatedly, the software delivery date is delayed, and the morale of the project's research and development personnel will become increasingly low, which will directly lead to increased project costs, lower quality and delayed project delivery dates. This determines that the project team must have a requirements management strategy.

Complexity analysis of demand management

Software requirements are the most critical input to the entire software development project, compared with the traditional production enterprises, the software demand has the characteristics of fuzziness, uncertainty, variability and subjectivity, unlike the production of automobiles, computers and other hardware needs, is tangible, objective, can be described, detectable, Software requirements are the most difficult problem to grasp in software projects, and his complexity is embodied in the following areas:

1. Description of requirements. Lack of formal complete requirements documents waste a great deal of human and material resources, but there are new problems with requirements documents. The requirements review on the user side is completely formality, because the user simply does not listen to the hundreds of pages of requirements documents he reads. Different levels of customer (user) concerns are not the same, it is unrealistic to want each customer to become a demand expert.

2, the adequacy of the problem of demand. How does the need not be omitted? How to demarcate the system exactly? This is indeed a dilemma, and a slightly larger system is almost impossible to get out of the way, and there is always a need for a demand review meeting, so that the system does not have an accurate scope. Even so, the system is still to develop, there is no way, the scope of the system must be rigidly delineated one, so as to establish a baseline.

3. The time limit of the requirement development. Spend a lot of time on demand, can customers and software companies tolerate it? In order to ensure the correctness and completeness of the requirements, the project manager often insists on spending a lot of time in the demand phase, but the client and the company's top leaders are worried that the project will not be able to see the actual running software. They tend to force the project team to move forward as quickly as possible, and members of the team tend to be exhausted by the complex and fickle demands of the system, and they want to end this phase as soon as possible.

4, the needs of the degree of detail. What is the need to describe how thin it can be? The beholder, the benevolent, and there is no conclusion, if time permits, want to fine can always be fine down. However, the longer the demand cycle, the more likely the changes, the more stringent the restrictions on the design, the requirements of the common extraction requirements higher, so as long as everyone (customers, users, demand analysts, designers, testers) think the description clearly, you can enter the design phase.

5. The change of demand. In the process of software development, if there is only one truth, it must be: the change of demand is eternal, the demand cannot be complete. The process of software development is actually a process of fighting change, and change in demand is not necessarily bad, it can be a good thing, a business opportunity, and a market-sensitive person can spot a market opportunity from a change in demand.

There are many reasons for the change in demand, such as:

No identification at the beginning of the whole, need to increase demand; Business has changed and demand must change; Demand error; The demand is not clear.

The change in demand is a matter of every developer, every project manager has problems and headaches, and once demand changes, you have to revise your design, rewrite your code, modify your test cases, adjust your project plans, and so on, and change your needs like the root of all evils, What about the normal progress of the project? Manage it! To change the demand in a controlled state, rather than to change it randomly, requirements management is to control the change of requirements according to the standard process. Problems follow, change in demand is generally not a sudden revolutionary change, the most common is the project requirements of the gradient (project Scope creep) problem, this kind of gradient is probably not aware of customers and developers, when reached a certain level, the two sides suddenly look back, found that has changed, Changed the world.

II. Requirements Management Strategy

Requirements management needs to adhere to the following policies:

1, the demand must have the inevitable connection with the input.

Demand must have an inevitable connection with the input, otherwise, if the cost of change in demand by the developer to bear, the project needs change becomes inevitable. It is often said that there is no free lunch and there should be no free demand changes. But accepting demand changes is now a bitter pill for software developers to swallow. Therefore, at the beginning of the project both the developer and the investor must be clear about this: demand change, software development input also change.

2. The change of demand should be approved by the investor.

Changes in demand cause the change of input, so through the approval of the investors, so that the change in demand has a cost concept, can be careful to deal with changes in demand. The author has experienced a project, in order to avoid the risk of the project, we invited a user representative to participate in the development process, resulting in a large number of user representatives in the development process of "Small requirements change, when the developer to change the software requirements changes, when the project into the field implementation phase, there are a large number of these changes need to be changed back , the problem is that the members of our project team view the needs of the user representative as the decree, but ignore whether the needs of customers have the right to determine the real decision of the person's approval.

3, small demand changes also need to go through the formal requirements management process.

Small requirements change also need to go through the formal requirements management process, otherwise it will add up. In practice, people are often unwilling to implement the formal requirements management process for small changes in demand, which reduces development efficiency and wastes time. Formal because of this concept to make the requirements of the gradient is not controllable, resulting in the failure of the project.

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

Not the finer the definition of requirements, the more it avoids the need for gradients, which is a 2-level problem. Too-thin requirements definitions have no effect on the requirements gradient. Because the change of demand is eternal, not because of the need to write thin, it will not change. Pay attention to the skills of communication. The actual situation is that users, developers have recognized the above several problems, but because changes in requirements may come from customers, or from developers, and as customers they may not be willing to invest more in changing requirements, the developer may be proactively changing the requirements, and their purpose may be to make the software more sophisticated, Therefore, as a demand manager, the project manager needs to use a variety of communication skills to make all the parties in the project.

Based on the above issues, requirements need to be managed so that requirements can truly become the baseline of software engineering and management, so that software plans, activities, and work products are aligned with the requirements of the application so that requirements can be reused.