5.2.1 Purpose
The purpose of Maintain Requirements is to retain requirement accuracy and consistency throughout and beyond the change during the entire requirements life cycle, and to support reuse of requirements in other solutions.
5.2.2 Description
A requirement that represents an ongoing need must be maintained to ensure that it remains valid over time.
In order to maximize the benefits of maintaining and reusing requirements, the requirements should be:
- consistently represented,
- reviewed and approved for maintenance using a standardized process that defines proper access rights and ensures quality, and
- easily accessible and understandable.
5.2.3 Inputs
- Requirements: include goals, objectives, business requirements, stakeholder requirements, solution requirements, and transition requirements. These should be maintained throughout their life cycle.
- Designs: can be maintained throughout their life cycle, as needed.
5.2.4 Elements
.1 Maintain Requirements
Requirements are maintained so that they remain correct and current after an approved change. Business analysts are responsible for conducting maintenance to ensure this level of accuracy is retained. For requirements to be properly maintained they must be clearly named and defined, and easily available to stakeholders.
Business analysts also maintain the relationships among requirements, sets of requirements, and associated business analysis information to ensure the context and original intent of the requirement is preserved. Repositories with accepted taxonomies assist in establishing and maintaining links between maintained requirements and facilitate requirements and designs traceability.
.2 Maintain Attributes
While eliciting requirements, business analysts elicit requirement attributes. Information such as the requirement’s source, priority, and complexity aid in managing each requirement throughout the life cycle. Some attributes change as the business analyst uncovers more information and conducts further analysis. An
attribute may change even though the requirement does not.
.3 Reusing Requirements
There are situations in which requirements can be reused. Requirements that are candidates for long-term use by the organization are identified, clearly named, defined, and stored in a manner that makes them easily retrievable by other stakeholders. Depending on the level of abstraction and intended need being addressed, requirements can be reused:
- within the current initiative,
- within similar initiatives,
- within similar departments, and
- throughout the entire organization.
Requirements at high levels of abstraction may be written with limited reference to specific solutions. Requirements that are represented in a general manner, without direct ties to a particular tool or organizational structure, tend to be more reusable. These requirements are also less subject to revision during a change. As requirements are expressed in more detail, they become more tightly associated with a specific solution or solution option. Specific references to applications or departments limit the reuse of requirements and designs across an organization.
Requirements that are intended for reuse reflect the current state of the organization. Stakeholders validate the proposed requirements for reuse before they can be accepted into a change.
5.2.5 Guidelines and Tools
- Information Management Approach: indicates how requirements will be managed for reuse.
5.2.6 Techniques
- Business Rules Analysis: used to identify business rules that may be similar across the enterprise in order to facilitate reuse.
- Data Flow Diagrams: used to identify information flow that may be similar across the enterprise in order to facilitate reuse.
- Data Modelling: used to identify data structure that may be similar across the enterprise in order to facilitate reuse.
- Document Analysis: used to analyze existing documentation about an enterprise that can serve as the basis for maintaining and reusing requirements.
- Functional Decomposition: used to identify requirements associated with the components and available for reuse.
- Process Modelling: used to identify requirements associated with the processes that may be available for reuse.
- Use Cases and Scenarios: used to identify a solution component that may be utilized by more than one solution.
- User Stories: used to identify requirements associated with the story that may be available for reuse.
5.2.7 Stakeholders
- Domain Subject Matter Expert: references-maintained requirements on a regular basis to ensure they are accurately reflecting stated needs.
- Implementation Subject Matter Expert: utilizes maintained requirements when developing regression tests and conducting impact analysis for an enhancement.
- Operational Support: maintained requirements are likely to be referenced to confirm the current state.
- Regulator: maintained requirements are likely to be referenced to confirm compliance to standards.
- Tester: maintained requirements are used by testers to aid in test plan and test case creation.
5.2.8 Outputs
- Requirements (maintained): defined once and available for long-term usage by the organization. They may become organizational process assets or be used in future initiatives. In some cases, a requirement that was not approved or implemented may be maintained for a possible future initiative.
- Designs (maintained): may be reusable once defined. For example, as a self-contained component that can be made available for possible future use.
