The purpose of maintain requirements in business analysis is to keep the accuracy and consistency of the requirements throughout and beyond the changes in the project lifecycle. This not only ensures that the requirements can be traced with requirements attributes, but also supports the reuse of requirements in other solutions. Maintaining requirements is one of the major tasks in requirements lifecycle management in Agile development as the requirements are being continually elicited, identified, verified and prioritised. Those requirements that represent ongoing business needs and stakeholder’s requests must be maintained to ensure that they remain valid all the time.
In order to maximise the benefits of maintaining requirements during the project delivery and saving them for future use, it’s not sufficient to just focus on keeping requirements up to date. The basic principle still needs to be applied to “flesh out” the quality of requirements. While the requirements should be consistently represented, they also need to be kept concise, atomic, testable, feasible, unambiguous, understandable, complete and prioritised. Additionally, organisational internal processes and standard operating procedures also ensure the requirements can be reviewed and approved for maintenance properly. Key benefits of maintaining requirements include improved efficiency by reusing requirements in similar projects and greater consistency between related systems. However, it could still go wrong by causing significant errors or linking requirements that may be outdated or have unmatched dependencies there due to blindly copying if the team doesn’t cultivate a culture of requirements maintenance or without standard procedures in place. Below are a few tips I always use for maintaining requirements.
Four Tips to Maintain Requirements in Business Analysis
1. Understand the relationship between requirements and their dependencies
Business analysts need to understand the relationship, dependencies and correlation between different requirements or within a set of requirements in order to ensure the context and original intent of the requirements is preserved. Once the requirements are categorised, along with requirements attributes, I would recommend using requirements repository to track and monitor the changes being made as repositories with accepted taxonomies give an edge over establishing and maintaining links between requirements and facilitate requirements traceability. Make sure the repositories are kept up to date at all times so the right information, data and change requests are captured correctly.
2. Maintain requirements attributes
Requirements attributes which include absolute reference, author, complexity, ownership, priority, risks, source, stability, status and urgency are defined and collected during the requirement elicitation process and comply with the information management approach. While updating requirements in the requirement repository, with extra information is uncovered and further analysis conducted by business analysts, the attributes may also change. Hence, new attributes should be amended on top of existing attributes and reflect the change of requirements.
3. Use information management tools to assist in maintaining requirements
Information management systems. Or information management tools can be used to record requirement changes. These tools also incorporate data flow diagrams, changelogs, functional decomposition, process modelling charts, user cases and scenarios, as well as user stores to support the process of maintaining and managing requirements. While adopting the requirements management to improve the efficiency by automating maintaining requirements and empowering working collectively, the tools can also help with creating a standard operating process for requirements reengineering and reusability.
4. Be mindful about what to reuse
Once requirements are maintained for long-term usage, they may become organisational process assets or be used in the future, business analysts should be aware that not all requirements are appropriate for use and only relevant and useful requirements can be copied or linked to newly conceived project ideas. Depending on the project new initiatives, system relationship and project complexity, non-functional requirements, business rules, security requirements, accessibility requirements and some of the stakeholders’ requirements could be potentially generalised and reused.