Requirement Analysis Sa-Why customers always repeat

In the development process of software projects, demand changes throughout the entire life cycle of software projects, from software project initiation, R & D, maintenance, and increasing user experience, 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 my software project management career, I almost face user demand changes every day and feel that if I cannot effectively handle these changes, the project plan will be adjusted again and again, the Software Delivery date has been delayed, the user's patience has gradually vanished, and the morale of R & D personnel has been getting lower and lower. Finally, all people are waiting for a result: it is best to end the project immediately. Fortunately, during continuous learning and practice, I have summarized several effective methods to better solve these problems in the software development stage.

1. The requirement analysis stage uses a prototype method to clarify user requirements.

In the demand analysis phase of software projects, a large amount of demand information needs to be collected, filtered, and processed, which is the beginning of demand management. The customer and R & D personnel's understanding of the requirements is characterized by "a large number of consensus and many differences in details. Even through repeated communication, a "user requirement statement" can be provided within the time limit, but with practical experience, user requirements are always described as "not clear" and "not clear. This is mainly because at this stage, the so-called products are all conceived in the minds of everyone. Just as 100 people read "Legend of the Condor Heroes", there are 100 images of Guo Jing, everyone's ideas are roughly the same, while the details are quite different. In this phase, prototype development is a good auxiliary means. It will actually express the virtual environment in the minds of everyone. A single interface, several controls, and the appearance form is fixed, the function description is clear. This is what the R & D department understands about the user's needs. In this case, the user can basically say "this is what I want", or "No, this is not what I want, what I want ......". Generally, there is much more practical need to communicate after the prototype. The understanding of both parties quickly moved closer to a compromise. A demand statement that can guide the R & D process was born.

2. Strict requirement change management procedures are adopted in the R & D process after requirement analysis.

Once the demand analysis stage ends, if you require new requirements to be added to the delivered software system, you need to follow the demand change management process. This process must be agreed with the user at the beginning of the software project establishment. Generally, the software enterprise has a change management process, which can explain the necessity of such management to the user, until consensus is reached with the user on this issue. There is no need to worry that users will not accept the change management process. There is no doubt about the rationality of the change management process with many successful R & D software projects. This is the experience and value of software enterprises, the user will eventually understand and agree.

Each enterprise has its own practice in the demand change management process. To use the CMM requirement management kPa, two levels of demand change management committee (CCB) are required, that is, product CCB and project CCB. Product CCB handles changes in product-level requirements, mainly reflected in the need for multiple functional departments, multiple software projects, and coordination with other product lines; project CCB handles internal demand changes within the project, such as coordination between different teams and interface changes. Each requirement must be approved by CCB to determine whether the attribute description of the requirement is appropriate, such as the time urgency, whether the technology used is risky, and the importance to the system, fluctuation Analysis of demand changes and Resource Status of demand realization. After the participants reach a consensus on the Demand attributes, plan the version of the demand implementation and determine the time plan.

I would like to remind you that you should never be careful with the user's requirements. Before that, you can ask yourself: "If you have done so, you will not be able to finish it on time, will you be able to bear all responsibilities ?" In this way, you will not be able to accept it in a random manner. There is a better way to reduce the trouble, that is, after the demand analysis stage, do not be in close contact with the user, but follow the software project cycle or the initial agreement between the two parties, regularly inform the software development progress. If iterative development is used for software development, you can do this during each phase of product delivery, and the user requirements you have consulted will be included in the software versions of a certain period in the future.

3. Plan the version of the software project that requires frequent changes.

If the software project is relatively large and the cycle is relatively long, for example, more than one year, the demand changes will inevitably be overwhelming. We recommend that you use iterative development to plan the product version for each stage. The first version generally includes the most basic functions of the software system and the functions that users are most concerned about. Its R & D process actually provides system architecture and New Technology Exploration for subsequent versions. A timely delivery version with good quality allows users to maintain confidence in the success of the project, and gives users the opportunity to gradually approach the final product before the final product is available, this process will make the user's needs more clear and complete, in order to improve the probability of a successful final product. Therefore, the completion of the first version is an important milestone of the project. We suggest that the project team hold a celebration at this time to improve cohesion and boost employee morale. The subsequent version planning is generally to improve the demand in stages and continuously improve the system defects. This process continues until the end of the software lifecycle.

Requirement management is the KPA that focuses on CMM Level 2, and its importance is obvious. There are a variety of books on this, but the best practice is effective. I have fully applied the above experience in my project management and can face my customers with ease. I hope it will help your project success.