Making Effective Requirement Management and Planning When Software Project Requirements Change Frequently
Overview
This section describes how to make effective management and planning for frequent project requirement changes in terms of background, problem analysis, and solution.
Background
Frequent requirement changes are the biggest constraint for both project-based software and product-based software development. According to China DevOps Status Report 2019, more than half of enterprises believe that frequent requirement changes are the main culprit behind delayed software delivery. Therefore, it is imperative to solve or mitigate the impact of frequent requirement changes.
Problem Analysis
Customer collaboration models, personnel capabilities, and R&D processes vary with enterprises. Such variation causes different symptoms and root causes of frequent requirement changes. As a result, measures should be taken case by case. Based on our observation and communication with enterprises, we summarize the following scenarios:
- Requirements are disordered and frequently changed, making it difficult to manage.
- Requirement priorities are continuously adjusted, disrupting the development plan.
- Requirements are missing.
The following is the detailed analysis of some scenarios:
- Scenario 1: A software project has a clear structure at its early stage, but the requirements change frequently and in detail at the later stage. How can the requirements be effectively managed and planned?
Project team members are troubled by unclear and incomplete requirements at the early stage. As a result, the requirements need to be modified at the later stage.
In this case, requirements are not correctly planned. Requirement levels are not clearly divided and there is no standard mechanism. For example, a customer plans a user login function, as shown in the following figure. The customer plans to release the task of administrator login in the first version. Later, a mobile number login requirement is added. This task is set to be released in the second version. As a result, a story contains multiple tasks released in different versions (or sprints), which is inconvenient for management. In this case, the key to this problem is managing requirements in a structured manner and root causes are:
- Failed to distinguish fragmented requirements that are continuously generated during project implementation and iterative system/product functions and features
- Misunderstood and misused the "Epic-Feature-Story" requirement structure provided by CodeArts.
Figure 1 Requirement structure
- Scenario 2: Some leader wants to upgrade requirements in a software project. How can we deal with it in the agile R&D mode?
Upgrading requirements means raising their priorities in implementation. Therefore, this problem is about requirement priority management. To solve this problem, we need to understand:
- Why does the leader need to upgrade requirements? If it is reasonable, the team needs to optimize the work arrangement process to minimize the impact on R&D and improve the response speed and capability.
- How often does this happen? Frequent requirement upgrades are a bad norm. The team needs to consider the causes and how to adjust the process, system, collaboration model, or personnel capabilities. For occasional requirement upgrades, find a solution accordingly. There is no need to adjust processes and regulations.
- Is there anything in common of the requirements to be upgraded? For example, are they related to a customer or a function domain (such as refund)? We can figure out solutions based on commonalities.
- Scenario 3: Some urgent requirements are often added due to external reasons.
These requirements are unexpected and definitely important. Therefore, it is about managing requirement priorities.
It is a problem of missing important requirements, which is caused by the failure to predict requirements. To deal with this problem, the team needs to know:- What are the external causes? Check whether these causes have something in common and take corresponding solutions.
- Is there anything in common of the added requirements? If yes, handle them accordingly.
- How temporary is the addition? If the team can adjust and respond more quickly so that the temporary requirements do not affect the team, this problem is no longer a problem.
- Why does not the team adjust the process or work style? Is it unuseful, or does not the team know how to adjust the process or work style?
Solution
Based on the root causes obtained in the preceding analysis, the problems to be solved can be classified as follows:
- How can we manage requirements in a structured manner?
- How can we manage requirement priorities?
- How can we avoid missing important requirements?
- How can we manage requirements in a structured manner?
First, we do not need structured requirement management in all circumstances. Structured requirement management is required only when there are a large number of interrelated requirements and implemented requirements need to be managed and maintained. In this case, the team needs to use the Scrum project template in CodeArts, whose "Epic-Feature-Story" structure and requirement planning function are helpful for structured management. So what is this structure based on? The answer is product or system functions and features. Information such as versions, customers, and modules that software project management focuses on can be implemented through different attributes or even tags of requirements.
Simply speaking, perform the following steps:
- Establish a CodeArts project for products or systems.
- Establish an "Epic-Feature-Story" requirement structure.
- Manage different modules and versions using the attributes of work items.
For details, see Managing Requirements in a Structured Manner.
- How can we manage requirement priorities?
Requirement priority management helps determine the sequence of requirement fulfillment, thereby maximizing the return and minimizing the risk or investment. To properly manage priorities, we need to:
- Determine the priority model, such as Kano Model. The model includes factors to be considered and comprehensive judgment principle of the factors.
- Prioritize requirements based on specific factor quantification and sorting criteria. For example, cost-benefit approach determines the requirement sequence by revenue and profit.
- Adjust requirement priorities.
- Improve the priority model. Adjust the model or the implementation details based on the feedback.
For details, see Managing Requirement Priorities.
- How can we avoid missing important requirements?
We can take measures based on different time points, that is, before, during, and after important requirement missing. According to the Pareto principle, we need to ensure that: (1) For general problems, there are solutions for software project members to follow. (2) In special cases, there is an emergency mechanism that guides on-site handling, and a troubleshooting review.
- In-event: Solve the problem using a common or special solution.
- Post-event: Perform a review based on the model or approach to form a new common practice or special handling method.
- Pre-event: Specify how to distinguish between common and special situations and develop corresponding handling methods or emergency mechanisms.
For details, see Avoiding Missing Important Requirements.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot
