Requirements Management Process (BA Planning & Monitoring)

Every project initiated with requirements. Gathering requirement is a tricky thing. Sometimes it is hidden at first, and show up in the middle or last. It might be not BA mistakes only, but also can come from clients. It is very important that every requirements should be managed and approved, or the scope will become wider. Previously we talked about communication, and now from the same source : BABOK, let's improve our knowledge about requirements management process.

2.5 Plan Requirements Management Process

#Purpose
Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope.

#Description
This task determines the appropriate requirements management process. It includes determining the process for requirements change, which stakeholder need to approve change, who will be consulted or informed of changes, and by extension, who does not need to be involved. The task also include assessing the need for requirements traceability and determining which requirements attributes will be captured.

#Input
Business Analysis Approach : The selected approach may include a definition of appropriate requirements managements processes.

Business Analysis Plan (s) : The business analysis plan define which deliverables are to be produces and when. Deliverables cannot be managed until they are created.

Organizational Process Assets : Standard templates or processes for requirements management within the organization may exist.

#Elements
1. Repository
A requirements repository is a method of storing requirements, including those under development, those under review and approved requirements. Repositories may include whiteboards, word processing documents, diagrams and model, wikis, requirements management tools and application, or any other method of recording information that allows requirements to be single-sourced and available to all relevant stakeholders for as long as they are needed.

2. Traceability
Determine whether and how to trace requirements based on the complexity of the domain, the number of views of requirements that will be produced, potential impacts from risk, and an understanding of the costs and benefits involved.

***Manage Requirements Traceability (4.2)

3. Select Requirements Attributes
Requirements attributes provide information about requirements, such as the source of the requirement, the importance of the requirement, and other metadata. The information documented by the attributes helps the team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a proposed change.

Some commonly used requirements attributes include :

 --Absolute reference is a unique numeric (preferred) or textual identifier. The reference is not to be altered or re-used if the requirement is moved, changed or deleted.

 --Author of the requirement. If the requirement is later found to be ambiguous, the author may be consulted for clarification.

 --Complexity indicated how difficult the requirements will be to implement. This is often indicated through qualitative scales based on number of interfaces, complexity of essential processes or the number and nature of the resources required.

 --Ownership indicates the individual or group that needs the requirement, or will be the business owner after the project is released into the target environment.

 --Priority indicates which requirements need to be implemented first.

 --Risks associated with meeting or not meeting the requirements.

 --Source of the requirement. Every requirement must originate from a source that has the authority to define this particular set of requirements. The source must be consulted if the requirement changes, or if more information regarding the requirement or the need that drove the requirement has to be obtained.

 --Stability is used to indicate how mature the requirement is. This is used to determine whether the requirement is firm enough to start work on. Note that the ongoing presence of large numbers of unstable core requirements may indicate significant risk to project continuance.

 --Status of the requirement, indicating such things as whether it is proposed, accepted, verified, postponed, cancelled, or implemented.

 --Urgency indicates how soon the requirement is needed. It is usually only necessary to specify this separately from the priority when a deadline exists for implementation.

 --Additional attributes may include information such as cost, resource assignment, and revision number, traced-from and traced-to.

4. Requirements Prioritization Process
Requirements do not all deliver the same value to stakeholders. Requirements prioritization focuses effort on determining which requirements should be investigated first, based on the risk associated with them, the cost to deliver them, the benefits they will produce, or other factors. Timelines, dependencies, resource constraints, and other factor influence how requirements are prioritized.

5. Change Management
Some considerations when planning for handling changes are:

 --Determine the process for requesting changes. The process can, but doesn't not have to, set authorization levels for approving changes.

 --Determine who will authorize changes. The planning activity needs to include a designation of who can approve changes after requirements have been approved.

 --Impact analysis. Specify who will perform the analysis of such impacts as business processes, information requirements, system and hardware interfaces, other software products, other requirements, test strategies and plan, to name a few.

 --Plan the wording of the request. It is important to set the expectation at the beginning of the business analysis activities. The requested change must be expressed in unambiguous terms. Therefore, it will be necessary to discuss the nature of the request with the requestor and other interested stakeholders.

The requirements process needs to spell out the nature of the components within a request for change. These might include :

• Cost and time estimates of change :

• For each item, work product, or technical product affected, a brief assessment of the expected cost of change is to be estimated.

• The estimate will provide an integrated view of the costs, resources needed, implementation timeframe, and any dependencies.

• Benefits and risks of the change.

• How the change aligns with the project and business objectives to help ensure all changes add business value.

• Since there are often unintended consequences to what seems like a favorable change, the request should include a well-structured change analysis form (written or verbal), statements of the expected risks, including both negative and positive influence on project objectives. Benefits considered may include not only financial benefits, but also technical aspects of product features, influences on project scope, time, cost, quality, resources, and the business case.

• Recommended course of action for change.

• The course of action for the change needs to be explained with the understanding of benefits and risks in the previous section.

• The various options considered and the reasoning for the option finally selected needs to be recorded.

• The recommended course of action needs to be complete enough to permit clear coordination of the parties affected by the change.

• Update to the communications plan and the method for communication of the change to affected stakeholders.

• Configuration management and traceability discipline should establish product baselines and version control practices, that will clearly identify which baseline is affected by the change.

 --Coordinate Prioritization Of Change. The priority of the proposed change must be established relative to other competing interests within the current project phase.

6. Tailoring the Requirements Management Process
An organization's requirements management process may need to be tailored to meet the needs of a specific initiative or project. Factors in the tailoring process include:

 --Organizational culture. In organizations where the culture does not support formality, but where informality jeopardizes the end product, it will be necessary to work with the stakeholders to negotiate an appropriate process.

 --Stakeholder preferences. Some stakeholders may require more or less formality.

 --Complexity of project, project phase, or product (product, service or result) being delivered. Formal processes for configuration management and change management are more likely to be used for:

• Projects that have many interfaces, many business and/or system impacts or span a variety of functional areas.

• Products that are built with many components and sub-components, have complex interfaces, will be used by a variety and number of stakeholders, or have other complexities.

 --Organizational maturity. Less mature organizations tend to be less likely to want to spend time or money creating a requirements process, and there may be outright resistance to the idea of having a process to define requirements.

 --Availability of resources needed to support the effort of creating such a process is a major consideration. Internal groups, such as a Project Management Office and external sources such as consulting firms and even vendors may be able to augment organizational resources.

#Techniques

Decision Analysis (9.8) : Can be used to assess the possible value delivered by a change and assess areas of uncertainty.

Problem Tracking (9.20) : Used to track possible changes and ensure that a decision is reached.

Risk Analysis (9.24) : Used to identify possible risks associated with the change management process and possible risks associated with making or choosing not to make the change.

#Stakeholders

Domain SME : Consulted in order to determine the importance of requirements and to assess the value of change requests.

End Users : Consulted in order to determine the importance of requirements and to assess the value of change requests.

Implementation SME : Consulted in order to determine the difficulty of implementing a requirement or proposed change.

Operational Support : Informed of changes to requirements to ensure that the solution can operate effectively.

Project Manager : Responsible for managing changes to the project scope and accountable for delivery of the project scope.

Tester : Informed of changes to requirements to ensure that test plans are effective.

Sponsor : Accountable for the solution scope and must approve prioritization of requirements and changes to requirements.

#Output
Requirements Management Plan. A requirements management plan describe the:

• Approach to be taken to structure traceability.
• Definition of requirements attributes to be used.
• Requirements prioritization process.
• Requirements change process, including how changes will be requested, analyzed, approved, and implemented.

Next : Business Analysis Performance