8

 

TRACEABILITY AND MONITORING

Traceability and Monitoring includes the processes used to establish relationships and dependencies between requirements and other product information, which helps ensure that requirements are approved and managed, and that the impact of changes to them is assessed.

The Traceability and Monitoring processes are as follows:

8.1 Determine Traceability and Monitoring Approach—The process of considering how traceability will be performed on the portfolio, program, project, or product, and defining how requirement changes will be managed.

8.2 Establish Relationships and Dependencies—The process of tracing or setting linkages between and among requirements and other product information.

8.3 Select and Approve Requirements—The process of facilitating discussions with stakeholders to negotiate and confirm which requirements should be incorporated within an iteration, release, or project.

8.4 Manage Changes to Requirements and Other Product Information—The process of examining changes or defects that arise during a project by understanding the value and impact of the changes. As changes are agreed upon, information about those changes is reflected wherever necessary to support prioritization and eventual product development.

Figure 8-1 provides an overview of the Traceability and Monitoring processes. The business analysis processes are presented as discrete processes with defined interfaces, while in practice, they overlap and interact in ways that cannot be completely detailed in this guide.

KEY CONCEPTS FOR TRACEABILITY AND MONITORING

Traceability is the ability to track information across the product life cycle by establishing linkages between objects. These linkages are also known as relationships or dependencies. Traceability is sometimes qualified as bidirectional, or forward and backward, because requirements are traced in more than one direction. For instance, backward traceability is performed from the requirements to the scope features and business goals and objectives that triggered them; forward traceability is performed from the requirements to design and test components and, ultimately, the final product. Tracing can also be performed laterally—for instance, tracing textual product information to models. For additional details on the type of information that can be traced, see Section 5.2.1 in Business Analysis for Practitioners: A Practice Guide.

Monitoring ensures that product information remains accurate from the point when product information has been approved through its implementation. Monitoring includes managing changes to product information and determining recommended actions to maintain the quality of the product.

The kind of thinking inherent in Traceability and Monitoring applies to all projects and all life cycles. Thinking about the relationships between requirements and their relationships to other project considerations, such as tests and releases, is critical for ensuring project consistency and completeness. Traceability principles that enable change impact analysis are the basis for confirming the fulfillment of objectives and ensuring test coverage. Traceability enables the discovery of missing and extraneous requirements. There is a need to track and monitor completed requirements, no matter what type of life cycle is used for a project or what format is used to document the requirements.

8.1 DETERMINE TRACEABILITY AND MONITORING APPROACH

Determine Traceability and Monitoring Approach is the process of considering how traceability will be performed on the portfolio, program, project, or product, and defining how requirement changes will be managed. The key benefit of this process is that it appropriately sizes the level of traceability and formality of the requirements change management process for the situation. The inputs, tools and techniques, and outputs of the process are depicted in Figure 8-2. Figure 8-3 depicts the data flow diagram for the process.

The traceability and monitoring approach defines the traceability and change management processes for the portfolio, program, project, or product. Each should be structured at a level of formality that is sufficient to meet the needs of the portfolio, program, project, and product. An appropriately sized traceability and monitoring approach ensures:

• A traceability process that minimizes the likelihood of missing requirements in the final product;
• A traceability process that is not time-consuming and wasteful to maintain;
• A change management process that ensures that changes align with the business and/or project objectives;
• A change management process that makes it simple to implement necessary changes; and
• A traceability and change management process that aligns to organizational standards, satisfies regulatory requirements, and addresses future needs, including providing valuable information about the product over the long term, beyond the current project.

Components of the traceability and monitoring approach related to traceability may include:

• Types of objects to be traced;
• Level of detail needed in traceability;
• Relationships that will be established and maintained;
• Where relationships will be tracked (e.g., using requirements attributes, traceability matrix, or requirements management tools, etc.); and
• Requirement states that drive the requirements life cycle (e.g., approve, defer, reject, etc.).

Components of the traceability and monitoring approach related to change management may include:

• How requirements changes will be proposed;
• How changes will be reviewed;
• How change management decisions will be documented;
• How requirement changes will be communicated;
• How changes to requirements, models, traceability, and other product information will be completed and made available once a change is approved; and
• Roles and responsibilities for the requirements change process.

The traceability approach defines the requirements architecture that will be used to specify how requirements, models, and other product information will be related to one another, including which components of product information will be most appropriate to trace to and how they will be traced to one another. Traceability needs will vary across portfolios, programs, projects, and products; therefore, the specific items that will be traced should be clearly indicated. For a project following a predictive life cycle, the project team may trace many types of product information among other objects, whereas a project that follows an adaptive life cycle may not. Traceability decisions, regardless of the life cycle followed, should be based on the short- and long-term value attainable from creating and maintaining the traceability information. Traceability is not limited to tracing product information. Traceability may also be performed on deliverables or components of work that are not part of business analysis activities, such as product design or development. For information on what may be traced and on defining a traceability approach, see Sections 3.4.10 and 5.2.1 in Business Analysis for Practitioners: A Practice Guide.

The change management process defines how changes to product information will be handled across the project. The requirements change process is performed differently depending on the selected project life cycle. For a project following a predictive life cycle, the project team may use a formal change management process, whereas a project following an adaptive life cycle does not. Adaptive approaches expect that requirements will evolve over time. For information on defining requirements change processes, see Section 3.4.14 in Business Analysis for Practitioners: A Practice Guide.

8.1.1 DETERMINE TRACEABILITY AND MONITORING APPROACH: INPUTS

8.1.1.1 COMPLIANCE OR REGULATORY STANDARDS

Described in Section 2.2. Compliance or regulatory standards are a type of enterprise environmental factor imposed by external organizations commonly for reasons related to security, protecting personal information, legal considerations, or safety reasons. Because the traceability and monitoring approach needs to adhere to compliance and regulatory standards, the tailoring options may be constrained. Compliance and regulatory standards often mandate more formal approaches to traceability and monitoring.

8.1.1.2 CONFIGURATION MANAGEMENT STANDARDS

Described in Section 2.3.2. Configuration management is a collection of formal documented processes, templates, and documentation used to apply governance to changes to the solution or subcomponent under development. Configuration management ensures that the product being built conforms to its approved requirements. The traceability and monitoring approach should adhere to the configuration management standards in place within the organization. When such standards are not developed or in place, the team needs to determine what the configuration management process will be for all aspects of the program or project, including the business analysis work. Configuration management for business analysis ensures that the requirements and requirements-related product information, such as models, traceability matrix, and issues list, are stored where they can be easily accessed by project stakeholders, safeguarded from loss, and where access to previous versions is available, when needed. A business analyst may achieve these objectives with a configuration management system (CMS), a requirements management repository, or with a wiki platform.

8.1.1.3 PRODUCT SCOPE

Described in Section 4.6.3.2. The product scope is defined as the features and functions that characterize a solution. The product scope is used to understand the level of product complexity used to determine an appropriate size for the traceability and change management approach.

8.1.2 DETERMINE TRACEABILITY AND MONITORING APPROACH: TOOLS AND TECHNIQUES

8.1.2.1 RETROSPECTIVES AND LESSONS LEARNED

Retrospectives and lessons learned provide past performance information to the product team for use in improving future performance and, ultimately, the end product. When determining how best to approach traceability and monitoring, product teams can rely upon acquired knowledge and learning to determine which traceability and monitoring approach to follow. Retrospectives and lessons learned, combined with experience and expert judgment, are the basis for tailoring the traceability and change management processes to fit the portfolio, program, or project and the needs of the organization. For more information on retrospectives and lessons learned, see Section 5.7.2.4.

8.1.3 DETERMINE TRACEABILITY AND MONITORING APPROACH: OUTPUTS

8.1.3.1 TRACEABILITY AND MONITORING APPROACH

The traceability and monitoring approach defines how traceability and change management activities will be performed throughout the portfolio, program, or project. The traceability components of the approach include types of objects to trace, types of relationships, the level of tracing detail required, and information about where tracing information will be tracked. The monitoring components of the approach include how changes are proposed and reviewed, how decisions are documented and communicated, and how changes are made to existing product information. Both approaches describe the roles and responsibilities and how the information is stored.

8.1.4 DETERMINE TRACEABILITY AND MONITORING APPROACH: TAILORING CONSIDERATIONS

Adaptive and predictive tailoring considerations for Determine Traceability and Monitoring Approach are described in Table 8-1.

Table 8-1. Adaptive and Predictive Tailoring for Determine Traceability and Monitoring Approach

Aspects to Be Tailored	Typical Adaptive Considerations	Typical Predictive Considerations
Name	Not a formally named process	Determine Traceability and Monitoring Approach
Approach	May be planned at a high level in iteration 0. Tracing and managing changes to product information are often not considered, as these processes are already built into adaptive approaches. Traceability performed via story splitting or story mapping and change management is performed via backlog management.	A high-level traceability and monitoring approach is defined early, during planning. The traceability and monitoring approach is refined throughout the portfolio, program or project. Often, large components of product information and deliverables are traced. A change management process often exists, but the level of formality is dependent on multiple factors, including organizational maturity, size and the complexity of the initiative.
Deliverables	Not a separate deliverable.	Detailed traceability and monitoring approach might reside in a business analysis plan.

8.1.5 DETERMINE TRACEABILITY AND MONITORING APPROACH: COLLABORATION POINT

Portfolio, program, and project managers may contribute to the development of the traceability and monitoring approach to ensure that it is appropriately sized and does not incur unnecessary cost or risk by being over- or underperformed for the needs of the product and portfolio, program, or project. The project manager will be interested in ensuring that the approach for traceability and monitoring is aligned with the tasks, resources, and level of effort specified for this work in the project management plan.

8.2 ESTABLISH RELATIONSHIPS AND DEPENDENCIES

Establish Relationships and Dependencies is the process of tracing or setting linkages between and among requirements and other product information. The key benefits of this process are that it helps in checking that each requirement adds business value and meets the customer's expectations, and it supports monitoring and controlling of product scope. The inputs, tools and techniques, and outputs of the process are depicted in Figure 8-4. Figure 8-5 depicts the data flow diagram for the process.

As product information is progressively elaborated and additional details surface, relationships and dependencies are created and progressively elaborated. Product information is traced to help provide different and complete views of the product scope. The linkages among different components of product information help do the following:

• Ensure that product information adds business value and meets customer expectations. Tracing each component of product information to the business need, goals, and objectives helps ensure its relevancy.
• Manage scope. Non-value-added product information is highlighted through product information that cannot be traced back to the product scope and business goals and objectives.
• Minimize the probability of missing requirements. Forward traceability helps ensure that product information is not dropped as product information is elaborated, built, tested, and implemented.
• Perform impact analysis. While analyzing changes to product information, the linkages provide a comprehensive view of the related components that may also require changes.
• Make release decisions. Implementation, benefit or value relationships, and dependencies between product information may inform certain release decisions.

Because requirements are often related to other requirements, sometimes a requirement is not able to be satisfied in a solution without including the other requirements to which it is related. Some examples of relationships between requirements are as follows:

• Subsets. A requirement may be a subset of another requirement. Figure 8-6 displays requirements 1, 2, and 3, each as a subset of requirement A. For example, requirements 1, 2, and 3 could represent different nuances of a process where A represents common elements across the subsets. Requirements 1, 2, and 3 could also represent the different components of the parent process A.
• Implementation dependency. Some requirements are dependent on the implementation of other requirements before they can be implemented. For instance, if requirement A is dependent on requirement B, then A cannot be implemented until B is implemented.
• Benefit or value dependency. Sometimes the benefit of a requirement is unable to be realized unless another requirement is implemented first. For instance, requirement A can be implemented, but the benefit from doing so may not be achieved until requirement C is also implemented. This relationship may sound similar to implementation dependency, but it is not about whether A can be implemented; rather, it is whether the value from A can be recognized.

Relationships and dependencies are further discussed in Section 5.3 of Business Analysis for Practitioners: A Practice Guide.

Predictive projects provide a better case for formal traceability than adaptive projects; however, the project life cycle is not the only factor that determines the optimal amount of traceability. Other factors include whether the business is highly regulated, organizational standards, product complexity, the risk of product errors, and the degree to which the traceability results are actually used.

8.2.1 ESTABLISH RELATIONSHIPS AND DEPENDENCIES: INPUTS

8.2.1.1 PRODUCT SCOPE

Described in Section 4.6.3.2. The product scope is defined as the features and functions that characterize a solution. Product information is traced to the features and functions that make up the definition of product scope. When there are components of product information that are unable to trace back to the features and functions defined in product scope, the value of including them should be questioned. If it is determined that the product information should be included, then the product scope may need to be reevaluated.

8.2.1.2 REQUIREMENTS AND OTHER PRODUCT INFORMATION

Described in Section 7.3.3.1. Requirements and other product information include all information about a solution and are the culmination of results from elicitation and analysis activities. Relationships and dependencies are established between the requirements and other product information resulting from elicitation and analysis.

8.2.1.3 TRACEABILITY AND MONITORING APPROACH

Described in Section 8.1.3.1. The traceability and monitoring approach defines the decisions made by the team about how traceability will be performed on the portfolio, program, or project. The traceability and monitoring approach may include details about the objects that will be traced, to what level traceability will be performed, and where relationships will be tracked or maintained. As the portfolio, program, or project progresses, more objects are created, increasing the opportunities to establish linkages among these objects. The product team will monitor the approach as it is followed to ensure that the traceability work is adding value. Too much traceability will become time-consuming to maintain, and if the team abandons the traceability work, information will become outdated. While preplanning is performed to ensure that the right traceability approach is established for the portfolio, program, or project, the traceability and monitoring approach can be revised as the team assesses the value throughout the course of its work.

8.2.2 ESTABLISH RELATIONSHIPS AND DEPENDENCIES: TOOLS AND TECHNIQUES

8.2.2.1 FEATURE MODEL

A feature model is a scope model that visually represents all the features of a solution arranged in a tree or hierarchical structure. The feature model shows relationships between features and which features are subfeatures of other ones. The feature model helps teams establish and communicate relationships between different features. For more information on feature models, see Section 7.2.2.8.

8.2.2.2 REQUIREMENTS MANAGEMENT TOOL

Requirements management tools allow requirements and other product information to be captured and stored in a repository. These tools often have functionality to:

• Maintain audit trails and perform version control to assist with change management,
• Facilitate review and approval processes through workflow functionality,
• Generate visual models and interactive prototypes,
• Support team collaboration,
• Integrate with office productivity software for easy imports and exports,
• Track and report on requirements status, and
• Assist in performing detailed traceability based on trace links established in the tool.

Requirements management tools catered to adaptive projects may include additional functionality to create and manage product and iteration backlogs, and product burndown charts. A requirements management tool does not help define high-quality product information, but can assist with the process of storing, managing, and maintaining product information. Selecting the right tool and tool adoption can sometimes be challenging. Requirements management tools should be evaluated on how well they meet the organization's needs to increase the probability of tool adoption. Traceability support is a common feature in most requirements management tools today.

8.2.2.3 STORY MAPPING

Story mapping is a technique used to sequence user stories, based upon their business value and the order in which their users typically perform them, so that teams can arrive at a shared understanding of what will be built. Horizontally, the story map shows what will be delivered within an iteration, and vertically the story map depicts higher-level groupings or categories of user stories. User stories may be grouped by different categories such as functionality, themes, or application. Story mapping can be used to establish relationships between user stories to iterations and the higher-level categories. For more information on story mapping, see Section 7.2.2.16.

8.2.2.4 STORY SLICING

Story slicing is a technique used to split requirements or user stories from a higher level to a lower level. Story slicing is a means of establishing relationships between requirements as lower-level requirements or user stories are subsets of higher-level requirements or epics. For more information on story slicing, see Section 7.3.2.7.

8.2.2.5 TRACEABILITY MATRIX

A traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The matrix can support linkages among many different types of objects, providing a mechanism for tracking product information through the project and product life cycles. A traceability matrix can be used to establish relationships among product information, deliverables, and project work to ensure that each relates back to business objectives. Establishing these linkages manages scope creep by ensuring that only relevant product information is incorporated into the solution. Traceability matrices are further discussed in Section 5.2.3 of Business Analysis for Practitioners: A Practice Guide.

On projects using an adaptive project life cycle, the product team may choose to develop an interaction matrix. An interaction matrix is a lightweight version of a traceability matrix that is used to determine whether requirements are sufficiently detailed or if any entities are missing. The main difference between these two types of traceability matrices is that an interaction matrix is a temporary artifact that represents a snapshot in time, whereas a traceability matrix is typically maintained throughout a portfolio, program, or project. For more information on interaction matrices, see Section 7.2.2.10.

8.2.3 ESTABLISH RELATIONSHIPS AND DEPENDENCIES: OUTPUTS

8.2.3.1 RELATIONSHIPS AND DEPENDENCIES

Relationships and dependencies are the linkages established among objects, such as components of product information, deliverables, and project work. Relationships and dependencies are established to help ensure that product information adds business value and meets customer expectations, manages scope, decreases the probability of missing requirements, performs impact analysis, and makes release decisions.

8.2.4 ESTABLISH RELATIONSHIPS AND DEPENDENCIES: TAILORING CONSIDERATIONS

Adaptive and predictive tailoring considerations for Establish Relationships and Dependencies are described in Table 8-2.

Table 8-2. Adaptive and Predictive Tailoring for Establish Relationships and Dependencies

Aspects to Be Tailored	Typical Adaptive Considerations	Typical Predictive Considerations
Name	Backlog Refinement	Establish Relationships and Dependencies or Trace Requirements
Approach	Typically establishes linkages between user stories and acceptance criteria. Might trace to objectives. Epics or user stories may be traced to features and acceptance tests. Any components of product information might trace forward to design and test and ultimately to the solution. Performed iteratively via story slicing or story mapping as new items are added to the product backlog. May be forms of direct tracing such as attaching a visual model to a story or linking user stories and acceptance criteria.	Minimal to extensive tracing, bidirectional between all components of product information, and deliverables that may contain product information. Established throughout the product life cycle. As more product information is defined, more detailed traceability is performed. Performed after an analysis phase of a project to trace forward to design and test and ultimately, the final solution.
Deliverables	Feature model, story map, interaction matrix, or linked product information like stories and acceptance criteria that may be stored in a requirements management tool.	Small to large traceability matrices. Regulatory environments often dictate formal traceability. Traceability information may be stored in a requirements management tool.

8.2.5 ESTABLISH RELATIONSHIPS AND DEPENDENCIES: COLLABORATION POINT

Joint review of the relationships and dependencies with project team members is needed as these relationships may impact release decisions. On predictive projects, tracing may be performed between business analysis deliverables and deliverables produced by other project team members, such as project requirements and design, development, and test components. Business analysis work to define product information may be performed by different people; therefore, collaboration is required to understand the relationships between the different components of product information.

8.3 SELECT AND APPROVE REQUIREMENTS

Select and Approve Requirements is the process of facilitating discussions with stakeholders to negotiate and confirm which requirements should be incorporated within an iteration, release, or project. The key benefit of this process is that it provides authorization to consider how and when to build all or part of a solution to develop or modify a product. The inputs, tools and techniques, and outputs of the process are depicted in Figure 8-7. Figure 8-8 depicts the data flow diagram for the process.

Approving requirements is performed to obtain agreement that the requirements accurately depict what the product team is being asked to build. Requirements that are approved establish the requirements baseline. The requirements baseline is the boundary that contains all the approved requirements for the solution, project, project phase, iteration, increment, release, or any other part of a project or solution. On projects that use a predictive life cycle, once the baseline has been established, changes can only be made by performing the change management procedures defined for the project. On projects using an adaptive life cycle, requirements are effectively baselined when they are identified as planned work to be addressed in the next or subsequent iteration, and can only change if the team agrees to make the change or the product owner decides to abnormally terminate the user story, task, or perhaps the entire iteration. When user stories or tasks are terminated, they can be moved back onto the product backlog for future consideration or marked as no longer needed.

Organizations and projects vary in how requirements are approved. Some organizations require a formal sign-off on a requirements package, such as a business requirements document. In other organizations or for specific types of projects, the approval of requirements may be informal, requiring only verbal approval. On adaptive projects, approved requirements could be represented by a list of backlog items ready for development or the results of iteration planning, where decisions on the list of backlog items to be addressed in the current or next iteration are made.

Obtaining approval of requirements and other product information requires those authorized to select and approve requirements to reach consensus that the requirements are correct and complete. Conflicting requirements are not uncommon. Often, consensus is achieved through negotiation. Business analysis includes facilitating discussions among stakeholders to work through different viewpoints and conflicts in the requirements and to negotiate an agreed-upon outcome and, ultimately, approval.

Approvals should be tracked and, in situations where stakeholders are hesitant to approve, concerns should be understood and addressed. Additional authorization of work hinges on the approval of the requirements; therefore, if consensus is not possible among the immediate team, the authority levels governing the requirements approval process set forth in the stakeholder engagement approach are followed.

8.3.1 SELECT AND APPROVE REQUIREMENTS: INPUTS

8.3.1.1 PRODUCT SCOPE

Described in Section 4.6.3.2. Product scope is defined as the features and functions that characterize a solution. Requirements approval is performed to confirm with stakeholders that the defined product information is correct and within the established scope parameters.

8.3.1.2 RELATIONSHIPS AND DEPENDENCIES

Described in Section 8.2.3.1. Relationships and dependencies define the links between requirements. Relationships can be parent to child, as requirements are progressively elaborated from a high level to a low level of detail, or they can be dependency relationships such as implementation, benefit, or value. Relationships and dependencies may indicate which requirements may need to be selected and approved together.

8.3.1.3 STAKEHOLDER ENGAGEMENT AND COMMUNICATION APPROACH

Described in Section 5.3.3.1. The stakeholder engagement and communication approach summarizes all the agreements for governing how stakeholders will be engaged and communicated with across the portfolio, program, or project. It contains the decisions about the role responsibilities and authority levels governing the requirements approval process. The approach identifies who has responsibility for reviewing, approving, rejecting, and proposing changes to requirements.

8.3.1.4 VALIDATED REQUIREMENTS AND OTHER PRODUCT INFORMATION

Described in Section 7.6.3.1. Validated requirements and other product information is product information that the stakeholders agree meets the business goals and objectives. Although verification and validation do not have to be sequenced, commonly the requirements and supporting product information are both verified and validated prior to being presented to stakeholders for review and approval.

8.3.1.5 VERIFIED REQUIREMENTS AND OTHER PRODUCT INFORMATION

Described in Section 7.5.3.1. Verified requirements and other product information are product information that has been evaluated to ensure that it is free from errors and adheres to the quality standards to which the information will be held. Although verification and validation do not have to be sequenced, commonly the requirements and supporting product information are both verified and validated prior to being presented to stakeholders for review and approval.

8.3.2 SELECT AND APPROVE REQUIREMENTS: TOOLS AND TECHNIQUES

8.3.2.1 BACKLOG MANAGEMENT

Backlog management is a technique used in adaptive approaches to maintain the requirements list. The list is ranked in order of business value or importance to the customer and sized by the development team so that the team can work on the highest-value items that it can deliver over the specified duration. The prioritization of the backlog can be interpreted as approval. For more information on backlog management, see Section 7.7.2.1.

8.3.2.2 COLLABORATIVE GAMES

Collaborative games are a collection of elicitation techniques that foster collaboration, innovation, and creativity to obtain the goal of the elicitation activity. Collaborative games can be used to work through requirements-related conflicts and help teams work toward consensus on requirements. For more information on collaborative games, see Section 6.3.2.2.

8.3.2.3 DEFINITION OF READY

The definition of ready is a series of conditions that the entire team agrees to complete before a user story is considered sufficiently understood so that work can begin to construct it. The definition of ready can be used in place of approval in adaptive life cycles to help the project team know that the user story is sufficiently elaborated and ready to be brought into an iteration for the development team to work on. For more information on the definition of ready, see Section 7.3.2.2.

8.3.2.4 DELPHI

Delphi is a consensus-building technique. Experts on the subject participate in this technique anonymously. A facilitator uses a questionnaire to elicit ideas about the important points related to the subject. The responses are summarized and are then recirculated to the experts for further comments. Additional rounds are repeated to solicit comments from the experts again, until the results start to converge. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and prevents any one person from having undue influence on the outcome. Delphi can be used to gain consensus on anything, including requirements approval, requirements validity, estimation, prioritization, and design option preferences. Delphi is further discussed in Section 4.15.1 of Business Analysis for Practitioners: A Practice Guide.

8.3.2.5 FACILITATED WORKSHOPS

Facilitated workshops use a structured meeting led by a skilled, neutral facilitator and a carefully selected group of stakeholders to collaborate and work toward a stated objective. Facilitated workshops can be used to bring product teams together to select and approve requirements, or resolve requirements conflicts that are hindering the team from reaching consensus. Workshops are considered a primary technique for reconciling stakeholder differences. For more information on facilitated workshops, see Section 6.3.2.4.

8.3.2.6 FORCE FIELD ANALYSIS

Force field analysis is a decision-making technique that can be used to help product teams analyze whether there is sufficient support to pursue a change. A description of the change is placed in the middle of the model. The team identifies the forces for or against the proposed change. Forces that support the change are listed on the left and the forces that are impediments are listed on the right. Each of the forces is provided a weight based on how significant the force is and how easy it will be to influence it. Positive forces are conditions that need to be strengthened and negative forces are those that need to be weakened or eliminated. Scores are tallied to determine whether there is enough organizational support to pursue the change. When support is lacking, the team discusses whether there are factors that can be used to influence the situation. When negative forces outweigh positive forces or when negative forces cannot be influenced enough to develop sufficient organizational support for the change, the change should be avoided. Figure 8-9 shows a sample format of a force field analysis model.

8.3.2.7 GROUP DECISION-MAKING TECHNIQUES

Group decision-making techniques are techniques that can be used in a group setting to bring participants to a final decision on an issue or topic under discussion. Some techniques help the team reach consensus, while other techniques have the objective of reaching a decision that does not necessarily reflect agreement by everyone. During business analysis planning, the team should establish how decisions will be made across the business analysis effort to avoid misunderstandings or conflict later on when performing the work. A few decision-making techniques include the following:

• Autocratic. One individual makes the decision for the group.
• Delphi. Reduces bias and prevents any one person from imposing undue influence on the team. Delphi reaches a decision through consensus. For more information on Delphi, see Section 8.3.2.4.
• Force field analysis. Reaches a decision by exploring the forces that are for or against a change and assessing which is greatest. For more information on force field analysis, see Section 8.3.2.6.
• Majority. Reaches a decision when support is obtained from more than 50% of the members of the group.
• Plurality. Obtains a decision by taking the most common answer received from among the decision makers.
• Unanimity. Reaches a decision by everyone agreeing on a single course of action.

Group decision-making techniques can be used in conjunction with other techniques to solve requirements-related conflicts.

8.3.2.8 ITERATION PLANNING

In adaptive approaches, iteration planning, or sprint planning, is the activity used to identify the subset of product backlog items from the product backlog that the development team will work on for the current iteration or sprint. Because the results of iteration planning provide the backlog items that will be considered the planned work for the current or next iteration, these items can be interpreted as approved. For more information on iteration planning, see Section 7.7.2.3.

8.3.2.9 PRIORITIZATION SCHEMES

Prioritization schemes are different methods used to prioritize requirements, features, or other product information. Prioritization schemes can also be used to resolve requirements-related conflicts. The stakeholder engagement and communication approach defines which prioritization schemes to use and when. For more information on prioritization schemes, see Section 7.7.2.5.

8.3.2.10 REQUIREMENTS MANAGEMENT TOOL

Requirements management tools allow requirements and other product information to be captured and stored in a repository. Requirements management tools often include workflow functionality to facilitate review and approval processes. Requirements management tools catered to adaptive projects may include functionality to create and manage product and iteration backlogs. For more information on requirements management tools, see Section 8.2.2.2.

8.3.2.11 STORY MAPPING

Story mapping is a technique used to sequence user stories, based upon their business value and the order in which their users typically perform them, so that teams can arrive at a shared understanding of what will be built. Story mapping can be used to perform release allocation in which features or solution components are assigned to different product releases. For more information on story mapping, see Section 7.2.2.16.

8.3.3 SELECT AND APPROVE REQUIREMENTS: OUTPUTS

8.3.3.1 APPROVED REQUIREMENTS

Approved requirements are requirements that are:

• Verified, in that the requirements are of sufficient quality; and
• Validated, in that the requirements meet business needs.

Approved requirements are an indication that those with the authority to approve requirements have agreed that the requirements as stated are what the product development team should build. On projects using an adaptive life cycle, approved requirements can be represented by a prioritized backlog ready for development or stories chosen from the product backlog as the planned work for the next or subsequent iteration.

On predictive projects, requirements, once reviewed, are approved by decision makers and the approved set of requirements establishes the requirements baseline. The process to approve requirements may involve written approval or sign-off or could involve verbal acceptance. During planning, the product team determines the approval process, including the roles that should participate.

8.3.4 SELECT AND APPROVE REQUIREMENTS: TAILORING CONSIDERATIONS

Adaptive and predictive tailoring considerations for Select and Approve Requirements are described in Table 8-3.

Table 8-3. Adaptive and Predictive Tailoring for Select and Approve Requirements

Aspects to Be Tailored	Typical Adaptive Considerations	Typical Predictive Considerations
Name	Backlog Refinement or Iteration Planning	Select and Approve Requirements
Approach	The product owner's prioritization of the backlog can be interpreted as approval. Definition of ready may also be used in place of approval. Prioritization of backlog occurs continuously until a set of items is moved into an iteration. Requirements management tools may be used to create and manage product and iteration backlogs.	Approval is obtained after verification and validation, but before design. May require sign-off of a document—for example, a requirements package, such as a business requirements document (BRD). In some cases, verbal approval may suffice. A requirements management tool may be used to facilitate review and approval processes.
Deliverables	Prioritized backlog ready for development, or decision on content to be built in an iteration or sprint, or designation of what gets pulled next from “to do” to “doing” on a kanban board.	Baselined requirements package and approvals may be stored in a repository, such as a requirements management tool.

8.3.5 SELECT AND APPROVE REQUIREMENTS: COLLABORATION POINT

On adaptive projects, team collaboration helps prepare the backlog and guide the team to make a decision on what can be accomplished in each iteration. The product owner is a key contributor to defining scope for an iteration. On predictive projects, approvals are milestones that should be communicated to the project team, as their work may depend on the results of the approval decisions. The project manager is dependent on the approved product requirements to confirm scope, determine the project requirements, and refine estimates on the work required to deliver the solution. Approved requirements are typically a major milestone in the predictive life cycle that a project manager would track in the project plan.

8.4 MANAGE CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION

Manage Changes to Requirements and Other Product Information is the process of examining changes or defects that arise during a project by understanding the value and impact of the changes. As changes are agreed upon, information about those changes is reflected wherever necessary to support prioritization and eventual product development. The key benefits of this process include facilitating the incorporation of important solution changes for projects, limiting unnecessary changes, and providing understanding of how change will impact the end product. The inputs, tools and techniques, and outputs of the process are depicted in Figure 8-10. Figure 8-11 depicts the data flow diagram for the process.

Managing changes to requirements and other product information entails maintaining the integrity of the requirements and the associated deliverables and work products and ensuring that each new requirement aligns with the business need and business objectives. The key benefit of a requirements change process is that it provides a process to manage changes to approved requirements while minimizing product and project risks associated with uncontrolled and unapproved change. Negative impacts to the product and project often arise from making changes without taking into consideration any dependencies, and how the change will affect the overall product and project, including expected business value.

On adaptive projects, change is ongoing. The team utilizes emergent learning, where stakeholders discover their requirements as portions of the solution are delivered over time. Adaptive methods expect that requirements will change as stakeholders learn what they want as they see the solution evolve. On adaptive projects, a prioritization process is used to determine if and when a change is considered for inclusion in the product. For more information on prioritization, see Section 7.7.

On predictive projects, a change is a modification that is requested after requirements have been baselined. Changes may arise at any point, but changes are harder and more expensive to accommodate in a predictive life cycle. Changes are reviewed as requested by a governing body for the impact on the in-process work and approved requirements. If the value of pursuing the change is deemed greater than the impact on cost, time, and resources, the change is more likely to be approved.

The following courses of actions are possible after the proposed change is evaluated:

• Change approved. Necessary updates to the impacted business analysis deliverables are made. Planned and in-process business analysis activities are adjusted when they are impacted. In an adaptive life cycle, there is no concept of “approved,” because any proposed change can be added to the backlog.
• Change deferred. The decision to defer making the change is documented, along with a rationale for the decision. When the change is provided with a proposed date for a future product release, it is noted and reflected in the appropriate plans to ensure that the change is addressed at the requested future date. In adaptive life cycles, this is equivalent to the proposed change being assigned a lower ranking in the product backlog.
• Change rejected. The decision to reject the proposed change is documented, along with the rationale for the decision. Unlike the action for a deferred change, there are no future date reminders established in the plans, because this work will not occur. In adaptive life cycles, this means not adding the item to the backlog or removing the item from the backlog.
• More information required. Despite best efforts to ensure that the impact analysis is thoroughly constructed, sometimes the change control board (CCB) or approval team requests more information. Conditions in the business may have changed since the project was first approved, or the CCB may now be considering different solutions or working from new data that were unavailable previously. This, in turn, involves another round of elicitation and analysis, an update to the impact analysis, and a resubmittal to the authoritative body considering the change. In adaptive life cycles, backlog items are elaborated just enough to prioritize the product backlog, then, if they are chosen for an iteration, items are elaborated further to obtain the necessary details required for development. The idea that a change will require more information is inevitable as the process of elaboration is factored into the approach.

The applied level of change management depends upon many factors, such as the application area, the organizational culture, the organizational process assets, the complexity of the specific project and end result, contractual requirements, the project life cycle, and the context and environment in which the project is performed. The degree of formality and the amount of documentation needed for the change control process depends upon the organizational policies and processes or external regulations.

8.4.1 MANAGE CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION: INPUTS

8.4.1.1 APPROVED REQUIREMENTS

Described in Section 8.3.3.1. Approved requirements are requirements that are verified, validated, and deemed an accurate representation of what the product development team should build. In predictive life cycles, change requests are evaluated against the approved requirements to conduct an impact analysis.

8.4.1.2 BUSINESS GOALS AND OBJECTIVES

Described in Section 4.3.3.1. Business goals and objectives specify stated targets that the business is seeking to achieve. New or revised requirements or product information is evaluated to ensure that these requirements are aligned with and supporting the attainment of the stated goals and objectives.

8.4.1.3 CHANGE REQUESTS

Change requests are appeals to make a change to a requirement or other suggestions for changes to product information raised by the business stakeholders or project team after a set of requirements is baselined. Change requests may arise from many sources, such as new regulations, internal or external constraints, missed requirements, or stakeholder recommendations after seeing part or all of the solution in development or completed. If an impact analysis has been performed, evaluated acceptance results may be looked at in conjunction with the change request. Not all change requests impact product requirements, but when they do, business analysis is required to analyze the impacts of the proposed change.

In adaptive approaches, there is no formal change request process. When a stakeholder requests a change, it is written in the form of a user story and added to the backlog. These are typically not referred to as change requests. A prioritization process is used to evaluate product backlog items against existing backlog items to determine which items will be included in the next iteration. The prioritization process works to ensure that the team focuses development efforts on the stories deemed of highest importance and value. For more information on prioritizing change requests, see Section 7.7.1.3.

8.4.1.4 PRODUCT SCOPE

Described in Section 4.6.3.2. Product scope is defined as the features and functions that characterize a solution. In adaptive life cycles, additional features are added to the product backlog and prioritized based on an assessment of the benefits or value; therefore, product scope evolves over time. In predictive life cycles, new or revised product information is evaluated against the product scope to assess the size of the change and impacts. When a proposed change is determined to be outside of the defined product scope, decision makers will need to consider whether a modification to the product scope is viable.

8.4.1.5 RELATIONSHIPS AND DEPENDENCIES

Described in Section 8.2.3.1. Relationships and dependencies are the linkages established between objects, such as components of product information, deliverables, and project work. In adaptive life cycles, this information is used when prioritizing the backlog, as a newly added backlog item may have linkages to other items in the backlog and these may be grouped and prioritized together. In predictive approaches, relationships and dependencies can be used to identify other impacted backlog items to size up the impact of making a change. In a predictive life cycle, relationships and dependencies decrease the probability of missing requirements, support impact analysis, and help the team maintain scope.

8.4.1.6 TRACEABILITY AND MONITORING APPROACH

Described in Section 8.1.3.1. The traceability and monitoring approach defines how traceability and change management activities will be performed throughout the portfolio, program, or project. The approach includes information on who can propose and approve changes and how those changes are proposed and evaluated.

8.4.2 MANAGE CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION: TOOLS AND TECHNIQUES

8.4.2.1 BACKLOG MANAGEMENT

Backlog management is a technique used in adaptive approaches to maintain the list of backlog items to be worked on during a project. The list is ranked in order of business value or importance to the customer and sized by the development team so that the highest-value items are selected and delivered in the next development cycle. Proposed changes or new stories are added to the bottom of the backlog, where they sit until the next time the backlog is reprioritized. In adaptive life cycles, backlog management is the technique used to manage changes. For more information on backlog management, see Section 7.7.2.1.

8.4.2.2 CHANGE CONTROL TOOLS

On projects following a predictive life cycle, change control tools can be manual or automated and are used to manage change requests and the resulting decisions. These tools may already be in place within the organization. When a change control tool is being introduced on a project, the needs of all stakeholders involved in the change control process should be considered. Two examples of change control tools are the following:

• Configuration management system (CMS). Configuration management helps ensure that the solution being built conforms to its approved product information. It provides a process for verifying this conformance, documenting changes, and reporting the status of each change throughout the project life cycle. It includes documentation, a tracking process, and defined approval levels necessary for authorizing changes. It enables managing changes to aspects of a solution in the context of the entire product, as well as the context of other products on which it depends or that depend upon it.
• Version control system (VCS). A VCS tracks the history of revisions of any type of work product. A VCS is like a baseline in that the original work product is established, and changes to that work product are tracked. A VCS falls under the umbrella of a CMS and is one of the many functions that comprise configuration management.

Change control tools are further discussed in Section 5.8.2 of Business Analysis for Practitioners: A Practice Guide.

8.4.2.3 GROUP DECISION-MAKING TECHNIQUES

Group decision-making techniques are techniques that can be used in a group setting to bring participants to a final decision on an issue or topic under discussion. Group decision-making techniques can be used in conjunction with other techniques to decide whether proposed changes should be acted on. For more information on group decision-making techniques, see Section 8.3.2.7.

8.4.2.4 IMPACT ANALYSIS

Impact analysis is a technique used to evaluate a change in relation to how it will affect related elements. When a change to product information is proposed, an impact analysis is performed to evaluate the proposed change in relation to how it will affect components of the portfolio, program, project, and product, including requirements and other product information. Impact analysis includes identifying the risks associated with the change, the work required to incorporate the change, and the schedule and cost implications. A key benefit of completing an impact analysis is that it allows for changes within the project to be considered in an integrated fashion, thereby minimizing project and product risk. Impact analysis is further discussed in Section 5.8.3 of Business Analysis for Practitioners: A Practice Guide.

8.4.2.5 REQUIREMENTS MANAGEMENT TOOL

Requirements management tools allow requirements and other product information to be captured and stored in a repository. Requirements management tools often include functionality to maintain audit trails and perform version control to assist with change control. Workflow functionality can facilitate review and approval processes for changes. Traceability information stored in requirements management tools assists with impact analysis. Requirements management tools configured to adaptive projects may include functionality to create and manage product and iteration backlogs. For more information on requirements management tools, see Section 8.2.2.2.

8.4.2.6 TRACEABILITY MATRIX

The traceability matrix contains information on the relationships and dependencies between requirements and other product information. The components of product information that are impacted by the change can be easily identified within a traceability matrix. The affected relationships are easily recognized and can be used to quickly and roughly quantify the size and complexity of the change. As described in Section 8.2, in adaptive approaches, formal traceability matrices are rarely used or named as such, but the concept of tracing to understand impacts to things that are already built still applies. For more information on traceability matrices, see Section 8.2.2.5.

8.4.3 MANAGE CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION: OUTPUTS

8.4.3.1 RECOMMENDED CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION

Recommended changes to requirements and other product information describe the course of action that is proposed after analyzing all the impacts associated with making a proposed change, including impacts to product and project scope, product usage, value, risk, schedule, and cost. The possible courses of action include approving the change, deferring the change, rejecting the change, or requesting additional information before making a decision about the change.

8.4.4 MANAGE CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION: TAILORING CONSIDERATIONS

Adaptive and predictive tailoring considerations for Manage Changes to Requirements and Other Product Information are described in Table 8-4.

Table 8-4. Adaptive and Predictive Tailoring for Manage Changes to Requirements and Other Product Information

Aspects to Be Tailored	Typical Adaptive Considerations	Typical Predictive Considerations
Name	Backlog Refinement	Manage Changes to Requirements and Other Product Information or Change Control
Approach	No formal change management procedures. Change is expected and embraced. Change can occur anytime, outside an iteration. Additional details can be added to stories within an iteration if the team agrees to it. New stories are added to the product backlog and change is prioritized through refining the backlog or iteration planning.	Change control begins after requirements are approved. Formalized change management process is followed, including roles and process steps. New product information is captured in a change request. Change is often treated like a mini-project, with elicitation, analysis, assessment of value, and requirements approval.
Deliverables	Scaled impact analysis is conducted. Determination where the change should be prioritized within the backlog.	Impact analysis with recommended course of action. Revised requirements documentation and updated or new models.

8.4.5 MANAGE CHANGES TO REQUIREMENTS AND OTHER PRODUCT INFORMATION: COLLABORATION POINT

Functional managers may be the source of changes, as they may be some of the first from the business side to become aware of business changes, including new regulations or changes in the competitive environment that may prompt a need for change. Subject matter experts (SMEs) provide information needed to understand the change and participate in elicitation activities as requested.