What is requirements management in software testing
To be on the same page, requirements management is the process of creating, tracking, and carrying out product requirements. They are what brings a product into shape. You canāt simply tell devs that you want a certain feature ASAP. Create a proper requirement that describes new functionality and lists acceptance criteria without ambiguity ā this is the only way..
Here is how requirements management normally goes:
- Discovery: Project stakeholders, potential end-users, and product ownership people come together to discuss required functionality. Market research, user interviews, and brainstorming sessions are all used to figure out what a new product actually needs to offer. If the product was inspired by some key functionality, then the team looks into what else should be created along it.
- Documentation: Basic ideas and stubs are transformed into product requirement documents (PRDs). Although using a document file for each requirement is possible, most teams prefer using tools for requirements management for easier collaboration and tracking. Cutting-edge solutions like aqua even leverage AI to help you complete, organise, and enhance requirements
- Analysis: Documented requirements undergo preliminary analysis to see if they are actually complete, relevant, and fit the scope and the timeline of initial development. Not everything unsuitable needs to be discarded: some things are perfectly good for backlog before you come back to them
- Validation: Stakeholders that didnāt participate in previous stages and potentially recruited end-users give their input on the selected requirements
- Prioritisation: Requirements that made it past validation are now prioritised. You may take several approaches depending on the project development methodology, the timeline, and the need to enter the market and/or raise funds fast. Most teams would usually still set priorities around getting a functional MVP as soon as possible, but you still need to formalise the importance of remaining requirements.
- Planning: In an Agile team, all you need to do is estimate hours or story points for each task and assign them across sprints. Waterfall makes it a little more difficult, as you need to carefully plan the entire pre-release development and hopefully fall behind it.
- Execution: With requirements locked and assigned, itās time for development and QA work to make them happen.Ā
- Verification: Internal stakeholders and participants of user acceptance testing check whether the final output meets both product requirements and what they expected to do with the software
Why and how requirements can change during a projectās life cycle
The reason why the previous section does not mention the requirement change management process is because that may happen at any stage. Here are some reasons why you may need to suddenly move in a different direction:
- Unfeasible requirements may take a varying amount of time to spot. Sometimes, you just stashed a requirement that was good enough into the backlog, then opened it again and itās actually messy. Then there are times when a requirement becomes unfeasible, e.g. a change in resources / costs/ demand does not make it viable to execute the requirement anymore
- A shift in the business landscape may make you start working on something completely new. A lot of companies probably didnāt consider adding AI functionality until ChatGPT had taken the world by storm. Most manufacturers of home electronics didnāt show much interest in smartphone controls until Philips adopted them and Xiaomi started to aggressively cut into sales of companies that didnāt act.
- Negative UAT results are likely to force some changes to requirements. On the one hand, you may need to change an executed requirement to make it fit the original vision.. On the other hand, you may need to create new requirement(s) because the original set does not help users achieve business goals.
Why itās important to manage requirements changes
Here are the reasons why requirements change management in software engineering requires special attention instead of just letting things get back on track.
- Continuity canāt be maintained without proper management of requirements changes. Market changes and/or general process improvements dictate hosting retrospective sessions. How did basic support chat functionality evolve into an in-house customer support bot? Why did we apply duplicate effort for seemingly the same functionality in different areas of the application? Itās hard to answer these questions and make insights without a complete requirements history ā especially when individual specialists and entire teams change.
- Schedule disruptions get worse and worse. Changing a requirement means that product owners, developers, designers, testers, and even copywriters may need to eventually pause what they are doing and work on the amendments. Every derailed personal timeline is another delay to your plans. The solution is simple: acknowledge that a delay is inevitable and adjust the work plans of every employee affected by a change in requirements.Ā
- You may change too much. New and mature products alike usually have a healthy number of nice-to-have ideas that nobody had the time to implement. When changing a requirement, the team may be eager to implement some of these as well. See if it makes sense to include some things, but usually donāt let them take priority over the initially requested changes.
- Unaccounted requirement change creates blind spots. Good project documentation and consistent software development usually go hand in hand. A change in requirements shakes consistency: your team may feel like going for a ādirtyā implementation just to get back to their tasks. After sorting the schedule disruption and finalising scope, make sure that the team does a reasonably thorough job and documents it for the future.
Impact of requirements change on QA
Changes to requirements affect the entire project pipeline, and that includes quality assurance. Here are the major consequences for testers:Ā
- Test suite stops covering not only the affected area, but the entire app. This is even more relevantĀ when an implemented requirement is amended. While teams always perform regression testing to see if old features break, you now have a mix of old and new.Ā
- QA timeline gets disrupted unless the testers were already idling. Creating new tests, making QA estimations, and executing these tests cut into time allocated for other activities. They may include running and/or improving other tests, and neglecting that for the moment potentially delays the next release too.
- New points of failure are potentially introduced to the software. Unless youāre in a great spot already, a change of requirements usually affects core functionality or at least other dependencies. If the new code does not go through string checks, it may easily make software unusable. This is a bigger burden than a regular feature addition with conventionally planned requirements.
If you are interested in a robust QA structure that can handle management of requirements change, we got you covered. Our testing strategy template equips your team with a practical document outlining the entire QA planning and process. You can easily fit it to your needs and even add points at which requirements may change so your team knows how to tackle the shift.
Testing strategy template to survive any requirement change
Best practices for managing requirements change in QA
As a company with over 20 years in QA consulting, here are the practices that we learned for handling a requirements change:
- Voice your concerns on a change control board session. If you have concerns about the impact of proposed changes, make sure that the team hears them. Updated requirements may indeed suit business goals better, but some things are too complicated to quickly change in a live product
- Formalise the new scope as soon as possible. You will need to develop, validate, and execute tests. You will need to do another, potentially more thorough round of regression tests. There will potentially be new edge cases that you need to analyse before isolating them and/or spending the time to cover the most impactful ones
- Assess the workload and adjust your timeline. While techniques like poker planning may seem redundant for just one requirement, you still need an estimate. Once you have it, make sure to postpone some other activities and make room for testing the code that will be delivered as part of the requirement change
- Use a requirements traceability matrix to track the coverage. Depending on the project organisation, you would create a sub-requirement or a new requirement that lists required changes. Once you have it, feel free to attach test cases that will remain the same. Then, add new tests until you are approaching near-100% coverage.
- Invite the change initiator for a final review. Even if your testers understand business goals well, a sudden change in requirement may be too much to grasp. The cost of not getting changes right is also high, as some if not all affected people will need to change their schedules again. Do an essentially mini-UAT session with key people to see if they got the changes they were looking for.
How to ensure alignment between requirements, test cases, and user acceptance criteria?
The answer to that question is surprisingly simple: you need visualised test coverage. Listing requirements on Jira but running tests as Excel spreadsheets is not a good way to keep track of existing functionality, let alone sudden changes. You will need integrations or an all-in-one tool where stakeholders can list changes for devs to see and testers to validate against.Ā
Similarly, testers and developers need to see each otherās output for a quick resolution. Your devs should not be jumping hoops to see the latest bug reports, while testers should be able to easily see changes to the code.
Here is the ideal flow:
- You decide to change a requirement
- Your test management solution solution already shows test cases that cover it
- You make changes to the requirements
- Testers are alerted to update test cases (having a revision history is crucial)
- Testers create additional test cases if needed
- Both updated and new tests are now displayed on the updated requirementās card
Tools and technologies for requirements change management
Here are a few QA options for successful change management.
- Jira+a QA plugin is a popular option, as Jira gives requirements management and plugins cover for the lack of test management. Alas, these plugins face limitations from both Jira and the market conditions. Most companies that create dedicated Jira plugins for QA compete on price rather than features.
- Traditional all-in-one solutions are a better pick, but they still come with challenges. Some solutions do not have a requirements traceability matrix or a suitable alternative. Others lack the test management scalability that is paramount for tackling a change in requirement.
Your best option here would be an all-in-one solution with a strong QA suite but also modern features to handle dynamic projects. This solution is aqua, a test management solution with ALM functionality to tackle any scope change. Here are the features that illustrate it:Ā
- Requirements narration with AI for inspiration and consistency. Say the changes in your computerās microphone, and aqua AI will update the requirement to meet them. You can further tweak the output by choosing prompts or giving custom requests to the AI.Ā
- Test coverage overview right on the requirements screen. You can see whether a requirement has any test cases or test scenarios covering it. Move the cursor, and aqua will display all relevant tests that you can preview while staying on the requirements page. The relations between requirements, manual & automated tests, and defects discovered by them wonāt ever be a mystery to you anymore.Ā
- Latest tech for AI-powered requirements management and testing. aqua offers test generation with the algorithm behind ChatGPT so you can quickly update tests after a change in requirement or create new tests from scratch. This includes edge cases that will take too long to discover or cover with traditional tests.
- Custom reports and dashboards with KPI Alerts to spot anomalies. When introducing a change to critical requirements, it is essential that there is no significant negative impact to existing users. You can create a dashboard that tracks issues by severity for an individual release. Decide how many issues you are ready to handle, and be alerted if the new build is not good enough yet.
Make requirements change hassle-free with aqua AI
Conclusion
Requirements change is a very disruptive, but also unavoidable part of software development. Companies need solid and structured effort from stakeholders, devs, and testers so that amendments end up benefiting and not breaking the software. Smooth management of requirements changes does not happen without a modern solution that makes product ownership work come together with development and QA output.
