Even if you launch your project with a complete set of requirements, expect changes to crop up once the project is up and running. Depending on which project management model you choose, adding, modifying, or removing requirements after you start can be quite costly. That’s why you need a formal requirements management process, which helps control costs and avoid scope creep, ensuring end-to-end traceability. A smart requirements management process will also ensure that when changes do occur, you will be able to manage them flexibly, without losing your focus on delivering the desired capabilities efficiently. Here are 6 best practices to help you with that.
Elicit requirements from multiple sources
Your first step is requirements collection. Remember to include all relevant sources such as new and seasoned users, managers, and other stakeholders. Pay close attention to operational users, because they are the ones who will provide you with most critical requirements for both system performance and user interface. Treating this group as your top requirements source will enable you to deliver a product or service that helps to solve real problems experienced by your customers.
How to get requirements from users?
- Look at users’ informal narratives – requirements may appear in them explicitly or indirectly
- Capture user responses to targeted questions
- Hold brainstorming sessions with managers who communicate with users
- Take a closer look at the user environment
- Learn more about the users – for example, the tasks they perform with the product on a regular basis, their workflows and task sequencing, internal rules, types of problems they may encounter, or interactions with other users and staff members.
Organize and prioritize requirements
Categorizing a long list of requirements can be a daunting task. As your project matures, you will need to document requirements attributes and keep all information up to date in order to remain traceable during testing and verification. By organizing and prioritizing your requirements, you will enable your team to identify what’s missing, contradictory, or duplicated.
To prioritize requirements, ask stakeholders to assign a priority to each requirement you collected from them. Naturally, stakeholders may differ in opinion about which one is critical, desirable, mandatory, or optional. Defining priorities in agreement with all stakeholders is quite challenging – that’s why it’s best to start doing that early on the project. One of the best ways to easily see the assigned priorities and dependencies between requirements is organizing them into a tree structure.
By organizing and prioritizing your requirements, you will enable your team to identify missing, contradictory, or duplicate ones
Make sure all stakeholders are in agreement
Once you collect your requirements, it’s a good idea to hold a special meeting where you review them with stakeholders. Make sure to include project team members if you can. Sometimes last minute changes may arise during this meeting, and that’s when it’s critical to reach consensus among all stakeholders. You need to be flexible throughout all the application lifecycle to ensure that development and implementation of the system don’t just blindly aim to meet a broad set of requirements, whereas you could reduce costs or provide an earlier delivery. That’s why you need to prioritize requirements correctly. All that’s left is documenting requirements for final approval – that type of document will provide a direction for the project’s future. If you’ve got people on board who are experienced in requirements management and know how to tell good requirements from bad ones, have them review your specifications.
In general, aim for requirements that are uniquely identified, consistent throughout the project, complete, are easy to test, fully traceable, attainable by your team and verifiable by the stakeholders. If you spot a requirement that doesn’t meet these standards, modify or delete it.
Prepare requirements for validation
It’s common to ask stakeholders to review documentation that includes requirements they supplied once in a while. You should provide them with all the help for interpreting requirements. Be prepared also to offer a description of outcomes when these requirements are implemented. Depending on your workflow, you can give stakeholders these explanations in different forms including activity diagrams, workflow models, flowcharts, or use cases. It’s also smart to prepare models for validation based on your requirements – that way you will build a limited functioning context where users can try different alternatives before assessing the requirements. Additionally, models will show stakeholders clearly how specific requirements represent their objectives and whether they are consistent with the overall goals of the project.
Use case models show stakeholders clearly how specific requirements represent their objectives and whether they are consistent with the overall project goals
Invest in change impact analysis
That type of assessment provides teams with an understanding of the implications of a proposed change. It helps them make the best possible business decisions about change proposals. Impact analysis is essential in projects where quality and safety are important (for example, in healthcare or automotive projects). The analysis examines the proposed change and identifying components that might need to be modified, rejected or added.
In general, impact analysis is based on:
- understanding the implications of the change – for example, including many functionalities in a product may reduce its performance to a level users find unacceptable;
- identifying documents, models and files that might need to be modified if the requested change is incorporated;
- detecting the tasks required to implement the change, as knowing how much effort it will take to implement the change is important as well.
Naturally, as you add new requirements and alter or discard the existing ones, the requirements of the system will change as well. Teams need a solid requirements versioning practice to control these changes.
Use smart requirements management tools
Collecting and documenting requirements is most efficient with the help of a right tool. If your development team uses Jira, there’s no reason why you shouldn’t try out its potential for requirements management. Even though it was designed as a tool for issue and project tracking, Jira combined with another Atlassian product, Confluence, can become the right tool for the job, as proved by worldwide experts like Tarun Sapra. You can use Confluence for general requirements gathering and project discussion on particular pages. Thanks to Confluence and Jira integration, you can create development issues directly from these requirements pages. That way, your team will be able to view requirements together with corresponding Jira tasks. Developers can use the wiki platform to view or edit the requirements, ensuring that all stakeholders stay up to speed. Confluence also ships with a Blueprint template to help teams in writing down requirements.
A product requirements page in Confluence. Source: Atlassian Documentation
You can also customize your Jira instance with dedicated apps for requirements management, such as ReqFLO. It is a smart tool for requirements management that supports documenting, structuring, tracing, and agreeing on requirements right inside your Jira. Take a free 30-day trial from the Atlassian Marketplace.