Requirements are usually not cast in stone. Stakeholders gather insights and more knowledge of their true needs with time. This means that they can change their minds about requirements, no matter how late in the game. Requirements should therefore be managed proactively in anticipation of change.
Managing requirements can be likened to managing time. The same way you would manage your time by keeping track of your daily activities; prioritizing what you need to do; communicating with folks that will help you complete tasks; changing your plan and determining the impact (or at least attempting to), you also need to manage your requirements by keeping track of them; prioritizing them; determining the impact of the proposed changes on other requirements, test cases and design elements; changing requirements when necessary and communicating changes to all affected parties.
Why Manage Requirements?
Well-managed requirements reduce the probability of missing critical requirements and ensure that key requirements are met while less critical ones are optionally scheduled for a later release. Can you think of more reasons?
To manage requirements effectively, here are 10 tips to keep in mind:
1. Prioritize Requirements: A key aspect of managing requirements is knowing which ones should come first. Requirements are prioritized to determine their order of implementation. Prioritization is typically done by considering the benefits, costs and risks of implementing a requirement and comparing it with the other requirements. MoSCoW Technique can be used to achieve this.
2. Prepare Your Requirements Package:
A requirements package is a set of documented requirements that have been structured in a way that is understandable and useable to different stakeholder groups. It is typically presented at the appropriate level of detail for each stakeholder and used as input to other requirements management processes like requirements review sessions and maintaining requirements for re-use.
Managing requirements involves ensuring that stakeholders are constantly carried along and informed of any changes that may have happened to requirements from the time they were elicited and baselined till their final implementation. Requirements packages facilitate effective communication.
3. Organize Requirements Review Sessions: Requirements review sessions are held to ensure that stakeholders understand the requirements and that any ambiguities, inconsistencies and omissions are identified and addressed to facilitate requirements approval or sign-off.
Prior to review sessions, the analyst should ensure that requirements are correct, complete and feasible before presenting them for approval. Sign-off is an indication that stakeholders agree to the quality of requirements and are committed to seeing change in action.
4. Baseline Your Requirements: Once requirements have been approved, they should be baselined. Subsequent change requests would thus require approval by the right authority; a change control board is usually set up to investigate and approve changes to requirements. The objective of baselining is not to prevent or discourage changes, but to ensure that approved changes are relevant and deserve the priorities assigned to them.
5. Conduct Impact Analysis: A change should only be implemented after an extensive impact analysis has been done to assess its full consequence. A request for change does not always translate into a requirement and as such, all changes must be analyzed to determine their merit for inclusion in the current phase or a future phase, if at all, as well as their impact on requirements and other project elements.
6. Trace Your Requirements: Requirements are related to other requirements, business objectives, business rules, design elements, code units and test cases. Managing requirements effectively involves identifying and maintaining the link between these elements throughout the lifecycle of the project and beyond. Maintaining traceability ensures that a complete impact analysis can be done when change requests are made. It also helps in managing scope and tracing the source of defects.
7. Store Requirement Attributes: It's always useful to identify, record and update key attributes of requirements as the project goes along. Requirement attributes give life to requirements by shedding light on their context. Examples of key requirements attributes to store include priority, source, rationale, status, release versions and any other relevant information that will be useful throughout the lifecycle of requirements.
8. Requirements Versioning Matters: Versioning involves maintaining a history of changes to requirements so that their evolution and the reasoning behind that evolution is tracked. Versioning ensures that teams always work on the same version of requirements, especially when they operate from geographically dispersed locations. RSDs should be accessible from a central location and the history of changes recorded so that the evolution of the document is visible and no member of the team is left working with outdated or cancelled requirements.
9. RM Tools Help: Requirements Management tools are best at storing and managing requirements (See 5 Benefits of Requirements Management Software). Requirements may also be stored in databases and less sophisticated applications. RM Tools are meant to reduce the burden of managing requirements by reducing the hassles of manual intervention but can never become a substitute for good requirements.
10. Maintain Your Requirements: Maintaining requirements involves storing requirements information so that they can be accessed and used by other business analysts or stakeholders in the future. This would go a long way to reduce the time spent on future projects. Maintaining requirements can also help in training other business analysts and maintaining previously implemented solutions.
How else can one manage requirements?
Don't forget to leave a comment below.