Requirements change, I believe you must have experienced, even if the project has complete requirements at the start of the project, it may change after the start of the project. And because of different management models, changing requirements after a project is launched can be particularly time-consuming.
This is why ** we need an ongoing requirements management process that not only helps control costs and prevent scale from getting out of control, but also ensures full traceability. A good requirements management system can achieve flexible management and deliver functions efficiently when requirements change. ** We have summarized some methods in our practice to help us avoid frequent changes to requirements, which are briefly described below.
First, collect demand from as many channels as possible
The first is gathering requirements. The process should include all relevant channels: new and existing users, management, business analysts, and other participants. Pay particular attention to the users who will actually use the system, because they will give you the best information available in terms of system performance and user interface. Using them as the highest-level source of demand allows your product or service to truly address customer pain points.
How do you get requirements from users?
Pay attention to informal comments or teasing from users – the need may be lurking there.
Capture user responses to preset questions.
Keep brainstorming with managers who can communicate directly with users.
Take a close look at the user’s environment.
Learn more from the perspective of users – how they use the product to perform tasks on a daily basis, their workflow, task sequencing, internal rules, what kind of problems they might encounter, or the communication between users and team members.
Through PingCode, we collect the needs of users, marketing personnel, pre-sales, customer service and other different channels
2. Prioritize requirements
Sorting requirements is not a simple task. As the project matures, we document the requirements and keep all information up to date to ensure traceability during testing and validation. Prioritizing requirements ensures that the team finds gaps, inconsistencies, or duplicates. A clear requirements structure makes it easier to decide which actions to perform during test management, including specifying relevant test cases. These two processes are closely related to each other and can only be achieved under controlled and well-planned procedures.
When discussing the prioritization of requirements with stakeholders, they will naturally come up with a variety of opinions: what is critical, what is desirable, and what is mandatory or optional. Getting all participants to agree on the priorities of requirements is difficult, which is why this is best done early in the project. To better understand the priorities of requirements and their dependencies, organizing them hierarchically in a tree is the best way.
Prioritizing requirements by organizing enables teams to quickly screen out missing, duplicate, or conflicting requirements
Iii. As far as possible, invite all relevant personnel to participate in the review and reach a consensus
Once the requirements are sorted out, a meeting with all relevant personnel is required for review. And as much as possible, make sure project members are involved. Requirements can change even at the last minute of a meeting, which is a critical moment for consensus. Throughout the application lifecycle, we need to ensure that the system is not just being developed blindly to meet a broad set of requirements, but that it should be handled flexibly, prioritizing cost reduction and early delivery. This is why it is important to prioritize requirements early, then assemble them for final review. These requirements and their priorities will dictate the future direction of the project. After that, all that remains is for your requirements specification to be reviewed by colleagues with extensive requirements management experience.
In conclusion, we should pay attention to the following criteria when verifying requirements:
1. Unique and intact whole project process.
2. Easy to test and traceable.
3. Within the scope of the team’s capabilities, so as to facilitate later verification.
If you feel a requirement doesn’t meet these criteria, change it or delete it altogether.
4. Requirements verification
In general, from time to time, have the person who proposed the requirements review the document, and try to help them understand the requirements. When these requirements are implemented, documentation is also available. Depending on the workflow, you should provide different formats such as activity diagrams, workflow model diagrams, and flow diagrams to illustrate the workflow. It is best to organize requirements in folders and display them in a tree for easy validation. This way you can build a usable environment with a few features that users can try different ways to validate before the requirements are finally reviewed. In addition, this organization allows participants to understand how specific requirements represent their work goals and how they form part of the overall goals of the project. Similarly, it is important to clearly show the relationships and problems between all objects.
Assess the impact of changes in requirements
This type of assessment allows the team to recognize the impact of changing requirements and can help the team make the most effective business decisions. Impact analysis is important in projects where quality and safety are important (such as healthcare or automation projects). This analysis is used to examine which components also need to change as a result of changing requirements.
In general, impact analysis refers to:
Understand the impact of changing requirements – for example, adding a set of features to the product may degrade performance and may not be acceptable to some users;
Indicate which documents, models, and files may need to be modified if requirements change.
It is equally important to understand which tasks involve the need for change and how much it will cost to implement the change.
Just as you change existing requirements, the system itself changes. The development team needs a good version management mechanism to control these changes, including test management, and a well-organized post-implementation plan to reduce the risk of misunderstandings among members.
Use requirements management tools well
Manage requirements with PingCode
Gathering and documenting requirements with the right tools is most effective. If your development team uses PingCode, requirements management can be done very well. Because it covers the whole process of R&D management including projects, tasks, requirements, defects, iteration planning, testing and target management.
Take, for instance, demand management by using PingCode, you can through the establishment of a project and convenient collection market, sales personnel, and internal defects requirements or other channels, and using the epic tale/feature/user demand for hierarchical management, make the product owner can set the priority for demand and the business value of the specified requirements. All of these can be used as the basis of iterative planning.
[
] (link.zhihu.com/?target=htt…).
Welcome to PingCode – intelligent R&D management tool
Read more about product development management
What is the experience of writing integration tests and unit tests together?
2, R&D management 101 Catch-22 #001 two weeks of iteration, the formation of continuous habit of the team
Dzmitry Hryb
| WT lury