Plan Requirements Management Process - Business Analyst

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 for a particular initiative. It includes determining the process for requirements change, which stakeholders 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 includes 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 management processes.

Business Analysis Plan(s): The business analysis plan(s) define which deliverables are to be produced 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. The business analyst must be knowledgeable about the organization’s approach to requirements definition, as it will greatly influence the process steps, tasks and deliverables required or expected during the requirements planning and monitoring activities.

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 models, wikis, requirements management tools and applications, 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. All approved requirements should be found in a repository (as opposed to using tools such as email, which may not reach all relevant stakeholders and may not be retained) and stakeholders need to be able to locate requirements in that repository.

The system for adding, changing and deleting requirements should be consistent and clearly understood by the team. File or component naming standards will assist with categorizing and maintaining requirements.

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. Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to have value.

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. Attributes aid in the ongoing management of the requirements throughout the project lifecycle. They need to be planned for and determined, along with the requirement themselves, but are not in themselves part of the solution definition.

Requirements attributes allow the requirements team to associate information with individual or related groups of requirements and facilitate the requirements analysis process by expressing such things as which requirements may add project risk or require additional analysis. 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 indicates 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.See below for further discussion on prioritizing and managing requirements.
• 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.
• Statusof 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 factors influence how requirements are prioritized. Planning the requirement prioritization process helps ensure that stakeholders determine and understand how requirements will be prioritized throughout and at the end of the business analysis effort.

Formality. The formality and rigor of the requirements prioritization process is determined partly by the methodology chosen, and by the characteristics of the project itself. Differences will lie in the level of detail, the amount of formal structure in the prioritization process (i.e. formal meetings versus informal conversations) and the amount of documentation needed to support the prioritization process.

Establishing The Process And Technique. The process to plan how requirements prioritization will occur needs to include which prioritization technique(s) will be used.

Plan The Participation. The business analyst, in conjunction with the project manager and sponsor should work together to determine the participants needed for the prioritization process.

Whom to invite and who does the inviting depends on organizational norms and best practices. Since sponsors are ultimately accountable for the solution’s effectiveness and major project decisions, they need to be invited to participate in the discussion, even if they delegate the participation to subject matter experts. Another key stakeholder is the project manager, whose project plan is dependent on which requirements are released and when. The invitees depend on methodologies, organizational norms, and the engagement of the sponsor. When there are multiple limiting factors, invite participants accordingly.

5. Change Management

Some considerations when planning for handling changes are:

Determine the process for requesting changes. The process can, but does not have to, set authorization levels for approving changes. For example, it may be decided that if a change is estimated to take less than a certain number of hours or dollars, the requestor and project manager can approve the change. If a predefined time or cost limit is exceeded,the sponsor has to approve it.

Determine who will authorize changes. The planning activity needs to include a designation of who can approve changes after requirements have been approved. Plan-driven methods usually have a formal Change Control Board (CCB) or Change Authority, which considers the requested change, and provides initial judgment on the merits of that request. The CCB can consist of any number of people in any number of positions. It may or may not include the sponsor, the project manager, the business analyst, subject matter experts, or other parties. Change-driven methods are more likely to allow the project team or a single product owner to have direct control over changes.

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 plans,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 that although the amount of documentation required to request changes is project and methodology dependent, the wording of the request must be clear. 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
  1. For each item,work product, or technical product affected, a brief assessment of the expected cost of change is to be estimated. As a matter of good practice, reusability will yield improvements to the change process by limiting the extent and scope of changes to other components. The goal should be to ensure responsiveness to change, not raising unlimited objections and impediments to the change process.
  2. The estimate will provide an integrated view of the costs, resources needed, implementation time frame,and any dependencies.
• Benefits and risks of the change
  1. How the change aligns with the project and business objectives to help ensure all changes add business value.
  2. 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 the technical aspects of product features, influences on project scope, time, cost, quality, resources, and the business case.
• Recommended course of action for change
  1. The course of action for the change needs to be explained with the understanding of benefits and risks in the previous section. Several alternative courses can be considered, including those recommended by the requestor and by other stakeholders. By weighing the relative benefits, risks, and other criteria for each option, the decision maker, designated by the approval process, can make a choice that will best serve the needs of the project.
  2. The various options considered and the reasoning for the option finally selected needs to be recorded.
  3. The recommended course of action needs to be complete enough to permit clear coordination of the parties affected by the change. For larger changes, this course of action might be a subproject within the context of the overall project, including elements that need to be put into the overall project plan.
  4. Updates to the communications plan and the method for communication of the change to affected stakeholders.
  5. Configuration management and traceability disciplines 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. The requestor should provide a priority as described in the section above. Project decision makers will need to consider the priority as well any potential risk of deferring implementation until a later time.

Change-Driven Methods

Change-driven methodologies (in particular, agile software development methods) do not typically have a change control process that is separate from the requirements prioritization process. All requirements, including “new” and “changed” requirements, are recorded in the product backlog and prioritized. At the beginning of each iteration, the highest priority requirements are selected from the backlog and estimated, and these estimates are used as input to determine whether the requirement will be implemented in that iteration.

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. A sponsor may, for example, want formal approval but may not want a documented process for eliciting requirements. As above, it will be necessary to recommend the most appropriate approach to handling requirements, pointing out risks and impacts as needed.
• 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 subcomponents, 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 : Can be used to assess the possible value delivered by a change and assess areas of uncertainty.

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

Risk Analysis : 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 User: 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. Changes to the solution and requirements scope are almost certain to impact the project scope. Similarly, changes to the project scope may impact the solution and requirements scope. Most projects use a single change management process to handle both and describe the impacts to solution and project scope in a single change request. This will require the involvement of the project manager in this task and agreement on the person responsible for the change management process.

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 describes 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.