Guideline/Tool
1) Architecture Management
Software
2) Business Analysis Approach
9) Business Analysis Performance
Assessment
13) Business Constraints
14) Business Objectives
20) Business Policies
24) Change Strategy
Task
5.4 RADD: Define Requirements
Architecture
2.1 EC: Prepare for Elicitation
2.2 EC: Conduct Elicitation
2.4 EC: Communicate BA Information
2.5 EC: Manage Stakeholder Collaboration
4.1 SA: Analyse Current State
4.3 SA: Assess Risks
4.4 SA: Define Change Strategy
1.1 PM: Plan BA Approach
1.2 PM: Plan Stakeholder Engagement
1.3 PM: Plan BA Governance
1.4 PM: Plan BA Information Management
3.3. RLM: Prioritise Requirements
2.1 EC: Prepare for Elicitation
2.5 EC: Manage Stakeholder Collaboration
6.4 SE: Assess Enterprise Limitations
6.5 SE: Recommend Actions to Increase
Solution Value
5.3 RADD: Validate Requirements
5.6 RADD: Analyse Potential Value +
Recommend Soln
1.1 PM: Plan BA Approach
1.3 PM: Plan BA Governance
1.4 PM: Plan BA Information Management
4.3 SA: Assess Risks
1.2 PM: Plan Stakeholder Engagement
Usage
modelling software can help to manage the volume, complexity, and versions of the
relationships within the requirements architecture.
general methodology, types of stakeholders and how they should be involved, list of
stakeholders, timing of the work, expected format and level of detail of elicitation results,
and identified challenges and uncertainties.
influences how each elicitation activity is performed, as it identifies the types of outputs
that will be needed based on the approach.
describes how the various types of information will be disseminated rather than what will
be disseminated. Describes the level of detail and formality required, frequency of the
communications, and how communications could be affected by the number and
geographic dispersion of stakeholders.
describes the nature and level of collaboration required from each stakeholder group to
perform planned business analysis activities.
guides how the business analyst undertakes an analysis of the current state.
guides how the business analyst analyzes risks.
guides how the business analyst defines a change strategy.
provides results of previous assessments that should be reviewed and incorporated into all
planning approaches
regulatory statutes, contractual obligations and business policies define priorities
used to plan and prepare elicitation events, and to develop supporting materials.
used to focus diverse stakeholders on a common vision of the desired business outcomes.
are considered when measuring and determining solution performance.
are considered in evaluating, measuring, and determining solution performance.
ensure the requirements deliver the desired business benefits.
used to calculate the expected benefit.
These policies can influence the business analysis approach.
define the limits within which decisions must be made. They may be described by
regulations, contracts, agreements, warranties, certifications, or other legal obligations.
These may mandate or govern aspects of risk management.
used for improved assessment of stakeholder impact and effective stakeholder engagement

33) Current State Description
39) Design Options
40) Domain Knowledge
43) Elicitation Activity Plan
44) Enterprise Limitation
45) Existing BA Information
3.3 RLM: Prioritise Requirements
3.4 RLM: Assess Requirements Changes
3.5RLM: Approve Requirements
6.1 SE: Measure Solution Performance
6.2 SE: Analyse Performance Measures
6.3 SE: Assess Solution Limitations
6.4 SE: Assess Enterprise Limitations
4.3 SA: Assess Risks
1.2 PM: Plan Stakeholder Engagement
1.3 PM: Plan BA Governance
6.5 SE: Recommend Actions to Increase
Solution Value
4.2 SA: Define Future State
4.3 SA: Assess Risks
5.6 RADD: Analyse Potential Value +
Recommend Soln
4.4 SA: Define Change Strategy
3.1 RLM: Trace Requirements
3.3 RLM: Prioritise Requirements
3.4 RLM: Assess Requirements Changes
2.3 EC: Confirm Elicitation Results
4.1 SA: Analyse Current State
2.1 EC: Prepare for Elicitation
2.2 EC: Conduct Elicitation
2.3 EC: Confirm Elicitation Results
strategies.
information on costs, timelines, and value realization to determine priority of requirements
describes the purpose and direction for changes, establishes the context for the change,
and identifies the critical components for change.
provides information which assists in managing stakeholder consensus
the change strategy used or in use to implement the potential value.
the change strategy that was used or is in use to implement the potential value.
the change strategy used or in use to implement the potential value.
the change strategy used or in use to implement the potential value.
provides the plan to transition from the current state to the future state and achieve the
desired business outcomes. This approach must be assessed to understand risks associated
This information will lead to more effective stakeholder analysis and better understanding
of the impact of the desired change.
provides the context within which the work needs to be completed. This information can
help drive how to make better decisions.
used to assess alternatives and better understand the potential increased value that could
be delivered. It can also help highlight unintended consequences of alternatives that may
otherwise remain undetected.
often used as a starting point for the future state.
used to determine risks associated with the current state.
used to identify and help quantify the value to be delivered from a potential solution.
describe various ways to satisfy the business needs. Each option will come with its own set
of change challenges and the change strategy will be impacted by the option selected as
well as the specific change approach that will be used.
knowledge of and expertise in the business domain needed to support traceability.
knowledge and expertise of the business domain needed to support prioritization.
knowledge of and expertise in the business domain is needed to assess proposed
requirements changes.
used to guide which alternative sources and which elicitation results are to be compared.
used to understand the challenges that exist within the enterprise.
provide a better understanding of the goals of the elicitation activity
may guide the questions posed during elicitation and the approach used to draw out
information from various stakeholders.
used to confirm the results of elicitation activities or to develop additional questions to
draw out more detailed information.
48) Existing Solutions
49) Expert Judgement
50) Future State Description
58) Governance Approach
61) Identified Risks
62) Information Management
Approach
64) Information Management Tools
65) Legal/Regulatory Requirements
5.5 RADD: Define Design Options
1.1 PM: Plan BA Approach
2.5 EC: Manage Stakeholder Collaboration
6.1 SE: Measure Solution Performance
6.2 SE: Analyse Performance Measures
6.4 SE: Assess Enterprise Limitations
4.3 SA: Assess Risks
5.3 RADD: Validate Requirements
5.5 RADD: Define Design Options
5.6 RADD: Analyse Potential Value +
Recommend Soln
3.3 RLM: Prioritise Requirements
3.4 RLM: Assess Requirements Changes
3.5 RLM: Approve Requirements
4.3 SA: Assess Risks
3.1 RLM: Trace Requirements
3.2 RLM: Maintain Requirements
2.4 EC: Communicate BA Information
1.4 PM: Plan BA Information Management
1.3 PM: Plan BA Governance
existing products or services, often third party, that are
considered as a component of a design option.
used to determine the optimal business analysis approach.
Expertise may be provided from a wide range of sources including stakeholders on the
initiative, organizational Centres of Excellence, consultants, or associations and industry
groups. Prior experiences of the business analyst and other stakeholders should be
considered when selecting or modifying an approach.
defines the desired future state and the expected value it delivers which can be used to
focus diverse stakeholders on the common goal.
boundaries of the proposed new, removed, or modified components of the enterprise, and
the potential value expected from the future state.
boundaries of the proposed new, modified, or removed components of the enterprise and
the potential value expected from the future state.
boundaries of the proposed new, removed, or modified components of the enterprise, as
well as the potential value expected from the future state.
determines risks associated with the future state.
ensure the requirements part of the solution scope help achieve desired future state.
helps to ensure design options are viable.
ensure the design options are appropriate.
outlines the approach for prioritizing requirements.
provides guidance regarding the change control and decision-making processes, as well as
the roles of stakeholders within this process.
identifies the stakeholders who have the authority and responsibility to approve business
analysis information, and explains when such approvals will take place and how they will
align to organizational policies.
can be used as a starting point for more thorough risk assessment. These can come from
Risk Analysis Results, from elicitation activities, from previous business analysis experience,
or based on expert opinion.
provides decisions from planning activities concerning the traceability approach.
indicates how requirements will be managed for reuse.
how business analysis information will be packaged and communicated to stakeholders.
each organization uses some tools to store, retrieve, and share business analysis
information. These may be as simple as a whiteboard, or as complex as a global wiki or
robust requirements management tool.
describes legislative rules or regulations that must be followed, and can be used to help
develop a framework that ensures sound business decision making.

71) Methodologies and
Frameworks
73) Metrics & KPIs
74) Modelling Notations/Standards
75) Modelling Tools
76) Organisational Performance
Standards
77) Organisational Strategy
79) Potential Value
81) Recommended Actions
82) Requirements Architecture
1.4 PM: Plan BA Information Management
3.1 RLM: Trace Requirements
3.4 RLM: Assess Requirements Changes
3.5 RLM: Approve Requirements
5.4 RADD: Define Requirements
Architecture
1.1 PM: Plan BA Approach
5.4 RADD: Define Requirements
Architecture
4.2 SA: Define Future State
5.1 RADD: Specify and Model
Requirements
5.1 RADD: Specify and Model
Requirements
1.5 PM: Identify BA Performance
Improvement
4.1 SA: Analyse Current State
4.2 SA: Define Future State
2.1 EC: Prepare for Elicitation
5.3 RADD: Validate Requirements
2.5 EC: Manage Stakeholder Collaboration
3.3 RLM: Prioritise Requirements
3.4 RLM: Assess Requirements Changes
5.1 RADD: Specify and Model
Requirements
describes legislative rules or regulations that must be followed, and helps determine how
business analysis information will be managed.
may need to be considered when defining traceability rules.
may impact requirements and must be considered when making changes.
may impact the requirements and designs approval process.
may impact the requirements architecture or its outputs. Additionally, contractual or
standards-based constraints may also need to be considered.
providing methods, techniques, procedures, working concepts, and rules. They may need to
be tailored to better meet the needs of the specific business challenge.
predetermined set of models, and relationships between the models, to be used to
represent different viewpoints
the key performance indicators and metrics which will be used to determine whether the
desired future state has been achieved.
allow requirements and designs to be precisely specified, as is appropriate for the audience
and the purpose of the models. Standard templates and syntax help to ensure that the right
information is provided about the requirements.
facilitate drawing and storing matrices and diagrams to represent requirements. This
functionality may or may not be part of requirements life cycle management tools.
may include performance metrics or expectations for business analysis work mandated by
the organization.
an organization will have a set of goals and objectives which guides operations, establishes
direction, and provides a vision for the future state. can be implicitly or explicitly stated.
describes the path, method, or approach an enterprise or organization will take to achieve
its desired future state. This can be implicitly or explicitly stated.
describes the value to be realized by implementing the proposed future state, and can be
used to shape elicitation events.
can be used as a benchmark against which the value delivered by reqs can be assessed.
communicating what should be done to improve the value of a solution can help to
galvanize support and focus stakeholders on a common goal.
including a requirements attribute for prioritization can help the business analyst to sort
and access requirements by priority.
requirements may be related to each other, therefore the business analyst examines and
analyzes the requirement relationships to determine which requirements will be impacted
by a requested requirements change.
requirements and interrelationships among them can be used to ensure models are
complete and consistent.
85) Requirements Life Cycle
Management Tools
87) Requirements Management
Tools/Repository
90) Requirements (Validated)
91) Requirements (Traced)
92) Risk Analysis Results
97) Solution Limitation
98) Solution Performance Goals
99) Solution Performance Measures
100) Solution Recommendations
101) Solution Scope
5.1 RADD: Specify and Model
Requirements
5.2 RADD: Verify Requirements
3.1 RLM: Trace Requirements
3.3 RLM: Prioritise Requirements
3.5 RLM: Approve Requirements
6.1 SE: Measure Solution Performance
5.4 RADD: Define Design Options
EC: Manage Stakeholder Collaboration
6.2 SE: Analyse Performance Measures
6.3 SE: Assess Solution Limitations
6.4 SE: Assess Enterprise Limitations
5.5 RADD: Analyse Potential Value and
Recommend Solution
4.1 SA: Analyse Current State
4.2 SA: Analyse Current State
4.1 SA: Analyse Current State
4.1 SA: Define Change Strategy
3.3 RLM: Prioritise Requirements
3.4 RLM: Assess Requirements Changes
3.5 RLM: Approve Requirements
software products that facilitate recording, organizing, storing, and sharing requirements
and designs.
some tools have functionality to check for issues related to many of the characteristics,
such as atomic, unambiguous, and prioritized.
used to store and manage business analysis information. The tool may be as simple as a
text document or as complex as a dedicated requirements management tool.
including a requirements attribute for prioritization can help the business analyst to sort
and access requirements by priority.
tool to record requirements approvals.
a set of requirements that have been analyzed and appraised to determine their value.
define the design options that best fulfill known requirements.
stakeholder-related risks will need to be addressed to ensure stakeholder collaboration
activities are successful.
the overall level of risk and the planned approach to modifying the individual risks.
the overall level of risk and the planned approach to modifying the individual risks.
the overall level of risk and the planned approach to modifying the individual risks.
the potential value of design options includes an assessment of the level of risk associated
with the design options or initiative.
used to understand the current state and the challenges of existing solutions.
measure the current performance of an enterprise or solution, and serve as a baseline for
setting future state goals and measuring improvement.
describe the actual performance of existing solutions.
identifying the possible solutions which can be pursued in order to achieve the future state,
which includes recommendations of SMEs, helps the business analyst determine the types
of changes to the organization.
considered when prioritizing requirements to ensure scope is managed.
Assists with fully understanding the impact of a proposed change.
Assists when approving requirements to accurately assess alignment and completeness.
 6.1 SE: Measure Solution Performance
6.2 SE: Analyse Performance Measures
6.3 SE: Assess Solution Limitations
6.4 SE: Assess Enterprise Limitations
6.5 SE: Recommend Actions to Increase
Solution Value
5.1 RADD: Specify and Model
Requirements
5.3 RADD: Validate Requirements
5.4 RADD: Define Design Options
5.5 RADD: Analyse Potential Value and
Recommend Solution
113) Stakeholder Analysis Results 4.1 SA: Analyse Current State
114) Stakeholder Engagement 1.1 PM: Plan BA Approach
Approach
2.2 EC: Conduct Elicitation
4.3 SA: Assess Risks
117) Supporting Materials 2.2 EC: Conduct Elicitation
the solution boundaries to measure and evaluate.
boundaries of the solution provide boundaries for the requirements and designs models.
ensures the requirements that provide benefit are within the scope of the desired solution.
defines the boundaries when selecting viable design options.
defines the scope of the solution that is being delivered so that a relevant evaluation can be
made that is within the scope boundaries.
stakeholders from across the organization will contribute to an understanding and analysis
of the current state.
understanding the stakeholders and their concerns and interests may influence decisions
made when determining the business analysis approach.
provides collaboration and communication approaches that might be effective during
elicitation.
understanding stakeholders and stakeholder groups helps identify and assess the potential
impact of internal and external forces.
includes any materials to prepare both the business analyst and participants before
elicitation, as well as any information, tools, or equipment to be used during the elicitation.