Requirements change management response and six principles to be followed [zz]

Demand change management

The demand changes because the demand changes. According to the idea of software engineering, the demand statement generally needs to be demonstrated. After the demand statement is demonstrated, new requirements should be added and supplemented on the basis of the original requirements or the original requirements should be modified and reduced, all are demand changes.

Demand changes occur mainly because users often cannot define what they need in the project requirement determination stage. Users often think they are clear about themselves, but in fact their demands are only based on the current work needs, and the new devices and technologies used will change their working methods; or the system to be developed is unknown to users. They have no relevant experience in the past. As the development progresses, the system begins to show the prototype of functions, and the user's understanding of the system is also gradually deepened. As a result, they may think of new features and features, or make changes to previous requirements. The more they know, the more new requirements they have. demand changes are inevitable.

In this case, if the development team does not have a clear requirement change control process or the change control mechanism adopted is invalid, or it does not manage demand changes according to the change control process, this may lead to delays in project progress, low costs, shortage of manpower, or even failure of the entire project. Of course, even if you manage the change control process as required, the software quality will be affected to varying degrees due to the constraints of schedule, cost, and other factors. However, implementing strict software requirement management will limit the negative impact of demand changes on software quality to the maximum extent, which is the purpose of demand change management.

The following six principles must be followed to implement demand change management:

(1) Establish a demand baseline. The demand baseline is the basis for demand changes. In the development process, the first requirement baseline can be established after the requirements are determined and reviewed (the user participates in the review. After each change is reviewed, the new requirement baseline should be redefined.

(2) formulate simple and effective change control procedures and form documents. All changes proposed after the requirement baseline is established must follow this control process for control. At the same time, this process is universal and will be useful for future project development and other projects.

(3) Establish a project Change Control Board (CCB) or similar organizations with relevant functions to determine which changes are accepted. CCB is composed of multiple parties involved in the project and should include the user and the developer's decision-making personnel.

(4) demand changes must be applied for before evaluation, and finally reviewed and confirmed at a level equal to the change size.

(5) After the demand changes, the affected software plans, products, and activities must be changed accordingly to ensure consistency with the updated requirements.

(6) properly save relevant documents generated by changes.

Countermeasures

Demand change control generally takes four steps: Change Application, change evaluation, decision-making, and reply. If the change is accepted, two steps are required: Implementation change and verification. Sometimes, the change is canceled. In view of the change control process, this paper summarizes several countermeasures for software developers in demand change management practices:

Batch implementation of priority sortingThe importance of each requirement is different. Due to restrictions on resources or technical conditions, it may appear "more than less", so it is impossible to complete all the requirements at once. What should I do? Each requirement is divided according to the contribution to the benefit and assigned a priority. The demand with a higher priority is realized first, and the demand with a lower priority is achieved in the current layout. Due to the continuous emergence of new requirements, some requirements may never be implemented by the quilt, but they are not tight. We should record them and sort them together, ensure that important requirements are met before each version is released. It takes time to implement each requirement. No one can fully predict it. However, we can estimate the labor cost based on past experience, then, based on the development personnel and the development cycle, the available manpower investment is obtained as the upper limit. From the demand with a higher priority, until the total labor cost in the selection is just below the upper limit of available investment, this is the requirement admission list. In the future, the software development plan will also be implemented in different collection phases and batches based on this.The most reasonable is not necessarily the highest priority, that is to say, not necessarily the first consideration. The "Economic first" is the final principle guiding priority sorting.

Mutual collaborationIt is hard to imagine that projects that have been resisted by users can succeed. When discussing requirements, developers and users should try to adopt an attitude of mutual understanding and collaboration, and try to solve the problems they can solve. Even if the user puts forward the "excessive" requirement in the View of developers, they should also carefully analyze the reasons and actively propose feasible alternatives.

Full CommunicationThe requirement change management process is largely a process of communication between users and developers. Software developers must learn to carefully listen to user requirements, considerations, and ideas, and analyze and organize them. At the same time, software developers should explain to users what impact and adverse consequences the change will bring to the entire development work after entering the design stage.

Assign full-time personnel to manage demand changesSometimes the development tasks are heavy, and developers are easy to get into the development work and ignore the need to communicate with users at any time. Therefore, a full-time demand change manager is required to communicate with users in a timely manner.

Contract ConstraintsThe impact of demand changes on software development is obvious to all. Therefore, when you sign a contract with a user, you can add some related terms, such as specifying the time when the user proposes a demand change, specifies the situations in which changes can be accepted, rejected, or partially accepted. It can also stipulate that the change control process must be implemented when a demand change occurs.

Differentiated TreatmentAs the development progresses, some users will constantly propose demands that cannot be implemented by the project team or that have a large workload and have a significant impact on the project progress. In this case, the developer can explain to the user that the startup of a project is based on the initial basic requirements. If a large number of new requirements are added (although the user thinks it is a refined requirement, but it is actually a new requirement that increases the workload), so that the project cannot be completed on time. If you insist on implementing new requirements, we recommend that you classify the new requirements based on their importance and urgency as a basis for demand change evaluation. At the same time, pay attention to controlling the frequency of new demands.

Select an appropriate development modelA prototype development model is suitable for development projects with unclear requirements. The developer first establishes a system prototype based on the user's requirements and then communicates with the user. Generally, when users see some actual things, they will have a more detailed explanation of the requirements. developers can further improve the system prototype according to the user's instructions. After this process is repeated several times, the system prototype gradually moves closer to the final user needs, fundamentally reducing the emergence of demand changes. Currently, the most popular stacked Development Method in the industry has a great effect on the demand change control of urgent projects.

User participation in Requirement ReviewAs the demand initiator, the user is naturally one of the most authoritative spokespersons. In fact, in the demand review process, users often can put forward many valuable opinions. At the same time, this is also the opportunity for users to final confirm their needs, which can effectively reduce the occurrence of demand changes.

Change control process.

Cost of demand change

Generally, a demand change usually means an increase in demand, a decrease in demand is relatively small, and it is easier to solve the problem of a decrease in demand. When the customer proposes new requirements, the project developers should analyze the risks arising from these new requirements to the current stage of the project, and obtain the required costs for both parties to meet the change requirements, including time, manpower, and resources.

Changes are costly. You should evaluate the cost of the changes and the impact on the project, During the evaluation and discussion with the customer, Let the customer know the consequences of the change,The biggest problem after the change is that the project is postponed, Let customers make judgments together : " I can modify it, but can you accept the consequences? " . There are three possibilities: the customer accepts the consequence of the extension, and the developer makes corresponding modifications as required by the customer,Let the customer know the price to be extendedIf the customer thinks that the cost is too high, the developer does not have to modify it. The developer can record the requirements and make changes later in the next version. The customer does not accept the cost of the change, leading to project failure. If the customer does not know the price you pay for the change, it will be hard to understand your hard work, and you will not be able to submit new changes.

Reduce demand changes

As mentioned above, demand changes are often inevitable. Usually, the project owner spends a lot of effort to avoid demand changes, but the final demand changes will always happen. However, this does not mean that the project developers should not do this. The correct attitude of the project developers should be the same as that of software testing, minimize demand changes before demand changes occur to minimize the risk of demand changes. Project developers should not try to eliminate demand changes before the project design, which is often laborious and thankless.

Compared with demand developers, customers may have insufficient understanding of demand changes and think they are paying for them,ProgramPersonnel or software development companies need to serve it. Therefore, customers tend to be more comfortable with demand changes, and consider demand changes as a child. They can change their needs as they like. Therefore, when the demand personnel contact the user representatives or the user department supervisor, they should be given a clear attitude and negotiate with them, in particular, it should be clear to them that the software pricing should be related to the software's functions, as well as the owners of risks arising from random changes in demand should be jointly undertaken by customers and project developers. By doing so, the customer should try to have a general understanding and a definite idea of the functions they need before the requirement analysis, instead of waiting for the programmer to start coding, in the previous requirement analysis.

After the customer understands the importance of reducing demand changes, the demand analysis personnel should take appropriate methods to communicate with the customer and help them clarify their needs. The relationship between requirement analysts and customers should not only record personnel and request providers, but also be strategic partnerships. Although demand analysts and customers have relationships between service providers and customers, they share a common goal: to develop software suitable for customers' needs, therefore, in addition to recording the requirements raised by the customer, the requirement analysts should also discuss with the user and propose some suggestions, and use appropriate tools to help the customer propose the requirements. In demand analysis, we should convene as many demand seminars as possible, invite developers and customers to negotiate and discuss, and allow any requests to be raised at the seminar, after these requirements are organized into files, the customer representatives and the requirement analysis personnel will discuss the optional functions, so as to make the requirements as complete as possible. In demand development, it is also a good way for developers to use prototype methods to inspire customers to think about functional requirements.

 

 

 

Although the demand cannot be complete and the change cannot be absent, it is worthwhile to make the demand as complete as possible at the beginning of the project design, the complete requirement process reduces the probability of changes due to unclear requirements.

 

Source: csdn http://sd.csdn.net/n/20060707/92405.html. the original source is not found.