A GUIDE TO THE BUSINESS ANALYSIS
BODY OF KNOWLEDGE
®
v3
BABOK
®
v3
A GUIDE TO THE BUSINESS ANALYSIS
BODY OF KNOWLEDGE
®
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
International Institute of Business Analysis, Toronto, Ontario, Canada.
©2005, 2006, 2008, 2009, 2015 International Institute of Business Analysis. All rights reserved.
Version 1.0 and 1.4 published 2005. Version 1.6 Draft published 2006. Version 1.6 Final published 2008. Version 2.0
published 2009. Version 3.0 published 2015.
ISBN-13: 97978-1-927584-03-3
Permission is granted to reproduce this document for your own personal, professional, or educational use. If you have
purchased a license to use this document from IIBA
®
, you may transfer ownership to a third party. IIBA® members may not
transfer ownership of their complimentary copy.
This document is provided to the business analysis community for educational purposes. IIBA® does not warrant that it is
suitable for any other purpose and makes no expressed or implied warranty of any kind and assumes no responsibility for
errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the
use of the information contained herein.
IIBA
®
, the IIBA
®
logo, BABOK
®
and Business Analysis Body of Knowledge
®
are registered trademarks owned by
International Institute of Business Analysis. CBAP
®
is a registered certification mark owned by International Institute of
Business Analysis. Certified Business Analysis Professional, EEP and the EEP logo are trademarks owned by International
Institute of Business Analysis.
Archimate
®
is a registered trademark of The Open Group in the US and other countries.
Business Model Canvas is copyrighted by BusinessModelGeneration.com and released under Creative Commons license.
CMMI
®
is a registered trademark of Carnegie Mellon University.
COBIT
®
is a trademark of the Information Systems Audit and Control Association and the IT Governance Institute.
Mind Map
®
is a registered trademark of the Buzan Organization.
Scaled Agile Framework
®
and SAFe™ are trademarks of Scaled Agile, Inc.
TOGAF
®
is a registered trademark of The Open Group in the US and other countries.
Unified Modelling Language™ and UML
®
are trademarks of the Object Management Group.
Zachman Framework for Enterprise Architecture is a trademark of the Zachman Institute for Framework Advancement.
No challenge to the status or ownership of these or any other trademarked terms contained herein is intended by the
International Institute of Business Analysis.
Any inquiries regarding this publication, requests for usage rights for the material included herein, or corrections should be
sent by email to bok@iiba.org.
i
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Table of Contents
Chapter 1: Introduction
1.1 Purpose of the BABOK
®
Guide 1
1.2 What is Business Analysis? 2
1.3 Who is a Business Analyst? 2
1.4 Structure of the BABOK
®
Guide 3
Chapter 2: Business Analysis Key Concepts
2.1 The Business Analysis Core Concept Model™ 12
2.2 Key Terms 14
2.3 Requirements Classification Schema 16
2.4 Stakeholders 16
2.5 Requirements and Designs 19
Chapter 3: Business Analysis Planning and Monitoring
3.1 Plan Business Analysis Approach 24
3.2 Plan Stakeholder Engagement 31
3.3 Plan Business Analysis Governance 37
3.4 Plan Business Analysis Information Management 42
3.5 Identify Business Analysis Performance Improvements 47
Table of Contents
ii
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Chapter 4: Elicitation and Collaboration
4.1 Prepare for Elicitation 56
4.2 Conduct Elicitation 61
4.3 Confirm Elicitation Results 65
4.4 Communicate Business Analysis Information 67
4.5 Manage Stakeholder Collaboration 71
Chapter 5: Requirements Life Cycle Management
5.1 Trace Requirements 79
5.2 Maintain Requirements 83
5.3 Prioritize Requirements 86
5.4 Assess Requirements Changes 91
5.5 Approve Requirements 95
Chapter 6: Strategy Analysis
6.1 Analyze Current State 103
6.2 Define Future State 110
6.3 Assess Risks 120
6.4 Define Change Strategy 124
Chapter 7: Requirements Analysis and Design Definition
7.1 Specify and Model Requirements 136
7.2 Verify Requirements 141
7.3 Validate Requirements 144
7.4 Define Requirements Architecture 148
7.5 Define Design Options 152
7.6 Analyze Potential Value and Recommend Solution 157
Chapter 8: Solution Evaluation
8.1 Measure Solution Performance 166
8.2 Analyze Performance Measures 170
8.3 Assess Solution Limitations 173
8.4 Assess Enterprise Limitations 177
8.5 Recommend Actions to Increase Solution Value 182
Chapter 9: Underlying Competencies
9.1 Analytical Thinking and Problem Solving 188
Table of Contents
iii
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
9.2 Behavioural Characteristics 194
9.3 Business Knowledge 199
9.4 Communication Skills 203
9.5 Interaction Skills 207
9.6 Tools and Technology 211
Chapter 10: Techniques
10.1 Acceptance and Evaluation Criteria 217
10.2 Backlog Management 220
10.3 Balanced Scorecard 223
10.4 Benchmarking and Market Analysis 226
10.5 Brainstorming 227
10.6 Business Capability Analysis 230
10.7 Business Cases 234
10.8 Business Model Canvas 236
10.9 Business Rules Analysis 240
10.10 Collaborative Games 243
10.11 Concept Modelling 245
10.12 Data Dictionary 247
10.13 Data Flow Diagrams 250
10.14 Data Mining 253
10.15 Data Modelling 256
10.16 Decision Analysis 261
10.17 Decision Modelling 265
10.18 Document Analysis 269
10.19 Estimation 271
10.20 Financial Analysis 274
10.21 Focus Groups 279
10.22 Functional Decomposition 283
10.23 Glossary 286
10.24 Interface Analysis 287
10.25 Interviews 290
10.26 Item Tracking 294
10.27 Lessons Learned 296
10.28 Metrics and Key Performance Indicators (KPIs) 297
10.29 Mind Mapping 299
10.30 Non-Functional Requirements Analysis 302
10.31 Observation 305
10.32 Organizational Modelling 308
Table of Contents
iv
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
10.33 Prioritization 311
10.34 Process Analysis 314
10.35 Process Modelling 318
10.36 Prototyping 323
10.37 Reviews 326
10.38 Risk Analysis and Management 329
10.39 Roles and Permissions Matrix 333
10.40 Root Cause Analysis 335
10.41 Scope Modelling 338
10.42 Sequence Diagrams 341
10.43 Stakeholder List, Map, or Personas 344
10.44 State Modelling 348
10.45 Survey or Questionnaire 350
10.46 SWOT Analysis 353
10.47 Use Cases and Scenarios 356
10.48 User Stories 359
10.49 Vendor Assessment 361
10.50 Workshops 363
Chapter 11: Perspectives
11.1 The Agile Perspective 368
11.2 The Business Intelligence Perspective 381
11.3 The Information Technology Perspective 394
11.4 The Business Architecture Perspective 408
11.5 The Business Process Management Perspective 424
Appendix A: Glossary 441
Appendix B: Techniques to Task Mapping 457
Appendix C: Contributors 473
Appendix D: Summary of Changes from BABOK
®
Guide v 2.0 483
v
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Preface
IIBA
®
was founded in Toronto, Canada in October of 2003 to support the business analysis community
by:
• creating and developing awareness and recognition of the value and contribution of the business
analyst,
• defining the Business Analysis Body of Knowledge
®
(BABOK
®
),
providing a forum for knowledge sharing and contribution to the business analysis profession, and
• publicly recognizing and certifying qualified practitioners through an internationally
acknowledged certification program.
The Body of Knowledge Committee was formed in October of 2004 to define and draft a global
standard for the practice of business analysis. In January of 2005, IIBA released version 1.0 of A Guide
to the Business Analysis Body of Knowledge
®
(BABOK
®
Guide) for feedback and comment. That version
included an outline of the proposed content and some key definitions. Version 1.4 was released in
October of 2005, with draft content in some knowledge areas. Version 1.6, which included detailed
information regarding most of the knowledge areas, was published in draft form in June of 2006 and
updated to incorporate errata in October of 2008.
The Body of Knowledge Committee developed version 2.0 of A Guide to the Business Analysis Body of
Knowledge
®
(BABOK
®
Guide) with the guidance of expert writing teams, and feedback garnered from
expert, practitioner, and public reviews. Version 2.0 introduced such concepts as the Requirements
Classification Schema and the Input/Output models. Version 2.0 was published in 2009 and became the
globally recognized standard for the practice of business analysis.
Following the publication of version 2.0, IIBA sought out a number of recognized experts in business
analysis and related fields and solicited their feedback on the content of that edition. The Body of
Knowledge Committee used these comments to plan the vision and scope of this revision. The Body of
Knowledge Committee worked with teams of expert writers to revise and update the content. The
revised draft of A Guide to the Business Analysis Body of Knowledge
®
(BABOK
®
Guide) was reviewed
by teams of both expert and practitioner reviewers. The Body of Knowledge Committee used the
feedback provided to further enhance and refine the text and then made the content available to the
business analysis community for review in 2014. The thousands of items of feedback from this public
review were used to further revise the text to form A Guide to the Business Analysis Body of
Knowledge
®
(BABOK
®
Guide) version 3.0.
The goal of this revision was to:
incorporate new concepts and practices in use since the last revision,
address the broadening and evolving scope of the profession,
incorporate lessons learned from practitioners who have worked with the current version,
improve the readability and usability of the guide,
improve the consistency and quality of text and illustrations, and
improve consistency with other generally accepted standards relating to the practice of business
analysis.
vi
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
The major changes in this release include:
• the inclusion of the Business Analysis Core Concept Model™ (BACCM™),
• the expanded scope of the role of business analysis in creating better business outcomes,
• the inclusion of Perspectives which describe specialized ways in which business analysis
professionals provide unique value to the enterprise,
new and expanded Underlying Competencies to better reflect the diverse skill sets of the business
analyst, and
• new techniques that have emerged in the practice of business analysis.
This publication supersedes A Guide to the Business Analysis Body of Knowledge
®
(BABOK
®
Guide)
version 2.0.
The BABOK
®
Guide contains a description of generally accepted practices in the field of business
analysis. The content included in this release has been verified through reviews by practitioners, surveys
of the business analysis community, and consultations with recognized experts in the field. The data
available to IIBA demonstrates that the tasks and techniques described in this publication are in use by a
majority of business analysis practitioners. As a result, we can have confidence that the tasks and
techniques described in the BABOK
®
Guide should be applicable in most contexts where business
analysis is performed, most of the time.
The BABOK
®
Guide should not be construed to mandate that the practices described in this publication
should be followed under all circumstances. Any set of practices must be tailored to the specific
conditions under which business analysis is being performed. In addition, practices which are not
generally accepted by the business analysis community at the time of publication may be equally
effective, or more effective, than the practices described in the BABOK
®
Guide. As such practices
become generally accepted, and as data is collected to verify their effectiveness, they will be
incorporated into future editions of this publication. IIBA encourages all practitioners of business
analysis to be open to new approaches and new ideas, and wishes to encourage innovation in the
practice of business analysis.
IIBA would like to extend its thanks and the thanks of the business analysis community to all those who
volunteered their time and effort to the development of this revision, as well as those who provided
informal feedback to us in other ways.
1
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
1
Introduction
A Guide to the Business Analysis Body of Knowledge
®
(BABOK
®
Guide) is the
globally recognized standard for the practice of business analysis. The BABOK
®
Guide describes business analysis knowledge areas, tasks, underlying
competencies, techniques and perspectives on how to approach business
analysis.
1.1 Purpose of the BABOK
®
Guide
The primary purpose of the BABOK
®
Guide is to define the profession of business
analysis and provide a set of commonly accepted practices. It helps practitioners
discuss and define the skills necessary to effectively perform business analysis
work. The BABOK
®
Guide also helps people who work with and employ business
analysts to understand the skills and knowledge they should expect from a skilled
practitioner.
Business analysis is a broad profession in which business analysts might perform
work for many different types of initiatives across an enterprise. Practitioners may
employ different competencies, knowledge, skills, terminology, and attitudes that
they use when performing business analysis tasks. The BABOK
®
Guide is a
common framework for all perspectives, describing business analysis tasks that
are performed to properly analyze a change or evaluate the necessity for a
change. Tasks may vary in form, order, or importance for individual business
analysts or for various initiatives.
The six knowledge areas of the BABOK
®
Guide (Business Analysis Planning and
Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management,
Strategy Analysis, Requirements Analysis and Design Definition (RADD), and
What is Business Analysis? Introduction
2
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Solution Evaluation) describe the practice of business analysis as it is applied
within the boundaries of a project or throughout enterprise evolution and
continuous improvement. The following image shows how three of the
knowledge areas support the delivery of business value before, during, and after
the life cycle of a project.
Figure 1.1.1: Business Analysis Beyond Projects
1.2 What is Business Analysis?
Business analysis is the practice of enabling change in an enterprise by defining
needs and recommending solutions that deliver value to stakeholders. Business
analysis enables an enterprise to articulate needs and the rationale for change,
and to design and describe solutions that can deliver value.
Business analysis is performed on a variety of initiatives within an enterprise.
Initiatives may be strategic, tactical, or operational. Business analysis may be
performed within the boundaries of a project or throughout enterprise evolution
and continuous improvement. It can be used to understand the current state, to
define the future state, and to determine the activities required to move from the
current to the future state.
Business analysis can be performed from a diverse array of perspectives. The
BABOK
®
Guide describes several of these perspectives: agile, business
intelligence, information technology, business architecture, and business process
management. A perspective can be thought of as a lens through which the
business analysis practitioner views their work activities based on the current
context. One or many perspectives may apply to an initiative, and the perspectives
outlined in the BABOK
®
Guide do not represent all the contexts for business
analysis or the complete set of business analysis disciplines.
1.3 Who is a Business Analyst?
A business analyst is any person who performs business analysis tasks described in
the BABOK
®
Guide, no matter their job title or organizational role. Business
analysts are responsible for discovering, synthesizing, and analyzing information
Pre-Project Post-Project
Benefits
Project
Delivery
Strategy Analysis
RADD
Rationale
Project
Solution Evaluation
Introduction Structure of the BABOK
®
Guide
3
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
from a variety of sources within an enterprise, including tools, processes,
documentation, and stakeholders. The business analyst is responsible for eliciting
the actual needs of stakeholders—which frequently involves investigating and
clarifying their expressed desires—in order to determine underlying issues and
causes.
Business analysts play a role in aligning the designed and delivered solutions with
the needs of stakeholders. The activities that business analysts perform include:
• understanding enterprise problems and goals,
• analyzing needs and solutions,
• devising strategies,
• driving change, and
• facilitating stakeholder collaboration.
Other common job titles for people who perform business analysis include:
• business architect,
• business systems analyst,
• data analyst,
• enterprise analyst,
• management consultant,
• process analyst,
• product manager,
• product owner,
• requirements engineer, and
• systems analyst.
1.4 Structure of the BABOK
®
Guide
The core content of the BABOK
®
Guide is composed of business analysis tasks
organized into knowledge areas. Knowledge areas are a collection of logically
(but not sequentially) related tasks. These tasks describe specific activities that
accomplish the purpose of their associated knowledge area.
The Business Analysis Key Concepts, Underlying Competencies, Techniques, and
Perspectives sections form the extended content in the BABOK
®
Guide that helps
guide business analysts to better perform business analysis tasks.
Business Analysis Key Concepts: define the key terms needed to
understand all other content, concepts, and ideas within the BABOK
®
Guide.
Underlying Competencies: provide a description of the behaviours,
characteristics, knowledge, and personal qualities that support the effective
practice of business analysis.
Structure of the BABOK
®
Guide Introduction
4
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Techniques: provide a means to perform business analysis tasks. The
techniques described in the BABOK
®
Guide are intended to cover the most
common and widespread techniques practiced within the business analysis
community.
Perspectives: describe various views of business analysis. Perspectives help
business analysts working from various points of view to better perform
business analysis tasks, given the context of the initiative.
1.4.1 Key Concepts
The Business Analysis Key Concepts chapter provides a basic understanding of
the central ideas necessary for understanding the BABOK
®
Guide.
This chapter consists of:
• Business Analysis Core Concept Model™ (BACCM™)
• Key Terms
• Requirements Classification Schema
• Stakeholders
• Requirements and Design
1.4.2 Knowledge Areas
Knowledge areas represent areas of specific business analysis expertise that
encompass several tasks.
The six knowledge areas are:
Each knowledge
area includes a
visual
representation of
its inputs and
outputs.
Business Analysis Planning and Monitoring: describes the tasks that
business analysts perform to organize and coordinate the efforts of
business analysts and stakeholders. These tasks produce outputs that are
used as key inputs and guidelines for the other tasks throughout the
BABOK
®
Guide.
Elicitation and Collaboration: describes the tasks that business analysts
perform to prepare for and conduct elicitation activities and confirm the
results obtained. It also describes the communication with stakeholders
once the business analysis information is assembled and the ongoing
collaboration with them throughout the business analysis activities.
Requirements Life Cycle Management: describes the tasks that business
analysts perform in order to manage and maintain requirements and design
information from inception to retirement. These tasks describe establishing
meaningful relationships between related requirements and designs, and
assessing, analyzing and gaining consensus on proposed changes to
requirements and designs.
Strategy Analysis: describes the business analysis work that must be
performed to collaborate with stakeholders in order to identify a need of
strategic or tactical importance (the business need), enable the enterprise to
Introduction Structure of the BABOK
®
Guide
5
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
address that need, and align the resulting strategy for the change with
higher- and lower-level strategies.
Requirements Analysis and Design Definition: describes the tasks that
business analysts perform to structure and organize requirements
discovered during elicitation activities, specify and model requirements and
designs, validate and verify information, identify solution options that meet
business needs, and estimate the potential value that could be realized for
each solution option. This knowledge area covers the incremental and
iterative activities ranging from the initial concept and exploration of the
need through the transformation of those needs into a particular
recommended solution.
Solution Evaluation: describes the tasks that business analysts perform to
assess the performance of and value delivered by a solution in use by the
enterprise, and to recommend removal of barriers or constraints that
prevent the full realization of the value.
The following diagram shows a general relationship between the knowledge
areas.
Figure 1.4.1: Relationships Between Knowledge Areas
1.4.3 Tasks
A task is a discrete piece of work that may be performed formally or informally as
part of business analysis. The BABOK
®
Guide defines a list of business analysis
tasks. The definition of a given task is universally applicable to business analysis
efforts, independent of the initiative type. A business analyst may perform other
activities as assigned by their organization, but these additional activities are not
Business Analysis
Planning and
Monitoring
Requirements Life
Cycle Management
Solution Evaluation
Elicitation and
Collaboration
Requirements
Analysis and Design
Definition
Strategy Analysis
Structure of the BABOK
®
Guide Introduction
6
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
considered to be part of the business analysis profession.
Tasks are grouped into knowledge areas. Business analysts perform tasks from all
knowledge areas sequentially, iteratively, or simultaneously. The BABOK
®
Guide
does not prescribe a process or an order in which tasks are performed. Tasks may
be performed in any order, as long as the necessary inputs to a task are present.
A business analysis initiative may start with any task, although likely candidates
are Analyze Current State (p. 103) or Measure Solution Performance (p. 166).
Each task in the BABOK
®
Guide is presented in the following format:
• Purpose
• Description
• Inputs
• Elements
• Guidelines/Tools
• Techniques
• Stakeholders
• Outputs
.1 Purpose
The Purpose section provides a short description of the reason for a business
analyst to perform the task, and the value created through performing the task.
.2 Description
The Description section explains in greater detail what the task is, why it is
performed, and what it should accomplish.
.3 Inputs
The Inputs section lists the inputs for the task. Inputs are information consumed
or transformed to produce an output, and represent the information necessary
for a task to begin. They may be explicitly generated outside the scope of
business analysis or generated by a business analysis task. Inputs that are
generated outside of the business analysis efforts are identified with the qualifier
'(external)' in the input list.
There is no assumption that the presence of an input means that the associated
deliverable is complete or in its final state. The input only needs to be sufficiently
complete to allow successive work to begin. Any number of instances of an input
may exist during the life cycle of an initiative.
The Inputs section includes a visual representation of the inputs and outputs, the
other tasks that use the outputs, as well as the guidelines and tools listed in the
task.
.4 Elements
The Elements section describes the key concepts that are needed to understand
Introduction Structure of the BABOK
®
Guide
7
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
how to perform the task. Elements are not mandatory as part of performing a
task, and their usage might depend upon the business analysis approach.
.5 Guidelines and Tools
The Guidelines and Tools section lists resources that are required to transform the
input into an output. A guideline provides instructions or descriptions on why or
how to undertake a task. A tool is something used to undertake a task.
Guidelines and tools can include outputs of other tasks.
.6 Techniques
The Techniques section lists the techniques that can be used to perform the
business analysis task.
.7 Stakeholders
The Stakeholders section is composed of a generic list of stakeholders who are
likely to participate in performing that task or who will be affected by it. The
BABOK
®
Guide does not mandate that these roles be filled for any given
initiative.
.8 Outputs
The Outputs section describes the results produced by performing the task.
Outputs are created, transformed, or changed in state as a result of the successful
completion of a task. An output may be a deliverable or be a part of a larger
deliverable. The form of an output is dependent on the type of initiative
underway, standards adopted by the organization, and best judgment of the
business analyst as to an appropriate way to address the information needs of key
stakeholders.
As with inputs, an instance of a task may be completed without an output being
in its final state. Tasks that use a specific output do not necessarily have to wait
for its completion for work within the task to begin.
1.4.4 Underlying Competencies
Underlying competencies reflect knowledge, skills, behaviours, characteristics,
and personal qualities that help one successfully perform the role of the business
analyst. These underlying competencies are not unique to the business analysis
profession. However, successful execution of tasks and techniques is often
dependent on proficiency in one or more underlying competencies.
Underlying competencies have the following structure:
• Purpose
• Definition
• Effectiveness Measures
Structure of the BABOK
®
Guide Introduction
8
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.1 Purpose
The Purpose section describes why it is beneficial for business analysts to have this
underlying competency.
.2 Definition
The Definition section describes the skills and expertise involved in the application
of this competency.
.3 Effectiveness Measures
The Effectiveness Measures section describes how to determine whether a person
is demonstrating skills in this underlying competency.
1.4.5 Techniques
Techniques provide additional information on ways that a task may be performed.
The list of techniques included in the BABOK
®
Guide is not exhaustive. There are
multiple techniques that may be applied alternatively or in conjunction with other
techniques to accomplish a task. Business analysts are encouraged to modify
existing techniques or engineer new ones to best suit their situation and the goals
of the tasks they perform.
Techniques have the following structure:
• Purpose
• Description
• Elements
• Usage Considerations
.1 Purpose
The Purpose section describes what the technique is used for and the
circumstances under which it is most likely to be applicable.
.2 Description
The Description section describes what the technique is and how it is used.
.3 Elements
The Elements section describes key concepts that are needed to understand how
to use the technique.
.4 Usage Considerations
The Usage Considerations section describes the conditions under which the
technique may be more or less effective.
Introduction Structure of the BABOK
®
Guide
9
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
1.4.6 Perspectives
Perspectives are used within business analysis work to provide focus to tasks and
techniques specific to the context of the initiative. Most initiatives are likely to
engage one or more perspectives. The perspectives included in the BABOK
®
Guide are:
• Agile
• Business Intelligence
• Information Technology
• Business Architecture
• Business Process Management
These perspectives do not presume to represent all the possible perspectives from
which business analysis is practiced. The perspectives discussed in the BABOK
®
Guide represent some of the more common views of business analysis at the time
of writing.
Perspectives are not mutually exclusive, in that a given initiative might employ
more than one perspective.
Perspectives have the following structure:
• Change Scope
• Business Analysis Scope
• Methodologies, Approaches, and Techniques
• Underlying Competencies
• Impact on Knowledge Areas
.1 Change Scope
The Change Scope section describes what parts of the enterprise the change
encompasses when viewed from this perspective and to what extent it impacts
both the objectives and operations of the enterprise. The change scope also
identifies the type of problems solved, the nature of the solutions being sought,
and the approach to delivering these solutions and measuring their value.
.2 Business Analysis Scope
The Business Analysis Scope section describes the key stakeholders, including a
profile of the likely types of sponsors, the target stakeholders, and the business
analyst's role within an initiative. It also defines likely outcomes that would be
expected from business analysis work in this perspective.
.3 Methodologies, Approaches, and Techniques
The composition of this section is unique to each perspective. In each case it
describes the methodologies, approaches, or techniques that are common and
specific to the application of business analysis in the perspective. Methodologies
Structure of the BABOK
®
Guide Introduction
10
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
and approaches are specialized ways of undertaking the business analysis work.
The techniques included in this section are techniques that are not included in the
Techniques chapter of the BABOK
®
Guide but are especially relevant to the
perspective.
In the Business Architecture perspective, reference models are listed instead of
methodologies or approaches. In the Business Process Management perspective,
frameworks are listed instead of approaches.
.4 Underlying Competencies
The Underlying Competencies section describes the competencies that are most
prevalent in the perspective.
.5 Impact on Knowledge Areas
The Impact on Knowledge Areas section describes how knowledge areas are
applied or modified. It also explains how specific activities within a perspective are
mapped to tasks in the BABOK
®
Guide.
11
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
2
Business Analysis Key Concepts
The Business Analysis Key Concepts chapter includes information that provides a
foundation for all other content, concepts, and ideas within the BABOK
®
Guide.
It provides business analysts with a basic understanding of the central ideas
necessary for understanding and employing the BABOK
®
Guide in their daily
practice of business analysis.
This chapter consists of:
Business Analysis Core Concept Model™ (BACCM™): defines a
conceptual framework for the business analysis profession.
Key Terms: provides definitions of essential concepts, which are
highlighted because of their importance to the BABOK
®
Guide.
Requirements Classification Schema: identifies levels or types of
requirements that assist the business analyst and other stakeholders in
categorizing requirements.
Stakeholders: defines roles, and characteristics of groups or individuals
participating in or affected by the business analysis activities within a
change.
Requirements and Designs: describes the distinction between—and the
importance of—requirements and designs as they relate to business
analysis.
The Business Analysis Core Concept Model™ Business Analysis Key Concepts
12
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
2.1 The Business Analysis Core Concept Model™
The Business Analysis Core Concept Model™ (BACCM™) is a conceptual
framework for business analysis. It encompasses what business analysis is and
what it means to those performing business analysis tasks regardless of
perspective, industry, methodology, or level in the organization. It is composed of
six terms that have a common meaning to all business analysts and helps them
discuss both business analysis and its relationships with common terminology.
Each of these terms is considered to be a core concept.
The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder,
Value, and Context. Each core concept is an idea fundamental to the practice of
business analysis, and all the concepts are equal and necessary. Each core concept
is defined by the other five core concepts and cannot be fully understood until all
the concepts are understood. No single concept holds greater importance or
significance over any other concept. These concepts are instrumental to
understanding the type of information elicited, analyzed, or managed in business
analysis tasks.
The BACCM can be used to:
• describe the profession and domain of business analysis,
• communicate about business analysis with a common terminology,
• evaluate the relationships of key concepts in business analysis,
• perform better business analysis by holistically evaluating the relationships
among these six concepts, and
evaluate the impact of these concepts and relationships at any point during
a work effort in order to establish both a foundation and a path forward.
Table 2.1.1: The BACCM
Core Concept Description
Change The act of transformation in response to a need.
Change works to improve the performance of an enterprise.
These improvements are deliberate and controlled through
business analysis activities.
Need A problem or opportunity to be addressed.
Needs can cause changes by motivating stakeholders to act.
Changes can also cause needs by eroding or enhancing the
value delivered by existing solutions.
Solution A specific way of satisfying one or more needs in a context.
A solution satisfies a need by resolving a problem faced by
stakeholders or enabling stakeholders to take advantage of
an opportunity.
Business Analysis Key Concepts The Business Analysis Core Concept Model™
13
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
The core concepts can be used by business analysts to consider the quality and
completeness of the work being done. Within each knowledge area description
there are examples of how the core concepts may be used and/or applied during
the tasks within the knowledge area. While planning or performing a task or
technique, business analysts can consider how each core concept is addressed by
asking questions such as:
• What are the kinds of changes we are doing?
• What are the needs we are trying to satisfy?
• What are the solutions we are creating or changing?
Stakeholder A group or individual with a relationship to the change, the
need, or the solution.
Stakeholders are often defined in terms of interest in, impact
on, and influence over the change. Stakeholders are
grouped based on their relationship to the needs, changes,
and solutions.
Value The worth, importance, or usefulness of something to a
stakeholder within a context.
Value can be seen as potential or realized returns, gains, and
improvements. It is also possible to have a decrease in value
in the form of losses, risks, and costs.
Value can be tangible or intangible. Tangible value is directly
measurable. Tangible value often has a significant monetary
component. Intangible value is measured indirectly.
Intangible value often has a significant motivational
component, such as a company's reputation or employee
morale.
In some cases, value can be assessed in absolute terms, but
in many cases is assessed in relative terms: one solution
option is more valuable than another from the perspective of
a given set of stakeholders.
Context The circumstances that influence, are influenced by, and
provide understanding of the change.
Changes occur within a context. The context is everything
relevant to the change that is within the environment.
Context may include attitudes, behaviours, beliefs,
competitors, culture, demographics, goals, governments,
infrastructure, languages, losses, processes, products,
projects, sales, seasons, terminology, technology, weather,
and any other element meeting the definition.
Table 2.1.1: The BACCM (Continued)
Core Concept Description
Key Terms Business Analysis Key Concepts
14
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Who are the stakeholders involved?
• What do stakeholders consider to be of value?
• What are the contexts that we and the solution are in?
If any of the core concepts experience a change, it should cause us to re-evaluate
these core concepts and their relationships to value delivery.
Figure 2.1.1: The BACCM
2.2 Key Terms
Business Analysis
For more
information, see
What is Business
Analysis? (p. 2).
The BABOK
®
Guide describes and defines business analysis as the practice of
enabling change in an enterprise by defining needs and recommending solutions
that deliver value to stakeholders.
Business Analysis Information
Business analysis information refers to the broad and diverse sets of information
that business analysts analyze, transform, and report. It is information of any
Stakeholders Contexts
SolutionsNeeds
Value
Changes
Business Analysis Key Concepts Key Terms
15
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
kind—at any level of detail—that is used as an input to, or is an output of,
business analysis work. Examples of business analysis information include
elicitation results, requirements, designs, solution options, solution scope, and
change strategy.
It is essential to expand the object of many business analysis activities from
'requirements' to 'information' to ensure that all inputs and outputs of business
analysis are subject to the tasks and activities described in the BABOK
®
Guide. For
example, when performing 'Plan Business Analysis Information Management' it
includes all the examples listed above. If the BABOK
®
Guide described 'Plan
Requirements Management', it would exclude important outputs like elicitation
results, solution options, and change strategy.
Design
For more
information, see
Requirements and
Designs (p. 19).
A design is a usable representation of a solution. Design focuses on
understanding how value might be realized by a solution if it is built. The nature
of the representation may be a document (or set of documents) and can vary
widely depending on the circumstances.
Enterprise
An enterprise is a system of one or more organizations and the solutions they use
to pursue a shared set of common goals. These solutions (also referred to as
organizational capabilities) can be processes, tools or information. For the
purpose of business analysis, enterprise boundaries can be defined relative to the
change and need not be constrained by the boundaries of a legal entity,
organization, or organizational unit. An enterprise may include any number of
business, government, or any other type of organization.
Organization
An autonomous group of people under the management of a single individual or
board, that works towards common goals and objectives. Organizations often
have a clearly defined boundary and operate on a continuous basis, as opposed
to an initiative or project team, which may be disbanded once its objectives are
achieved.
Plan
A plan is a proposal for doing or achieving something. Plans describe a set of
events, the dependencies among the events, the expected sequence, the
schedule, the results or outcomes, the materials and resources needed, and the
stakeholders involved.
Requirement
For more
information, see
Requirements and
Designs (p. 19).
A requirement is a usable representation of a need. Requirements focus on
understanding what kind of value could be delivered if a requirement is fulfilled.
The nature of the representation may be a document (or set of documents), but
can vary widely depending on the circumstances.
Requirements Classification Schema Business Analysis Key Concepts
16
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Risk
Risk is the effect of uncertainty on the value of a change, a solution, or the
enterprise. Business analysts collaborate with other stakeholders to identify,
assess, and prioritize risks, and to deal with those risks by altering the likelihood of
the conditions or events that lead to the uncertainty: mitigating the
consequences, removing the source of the risk, avoiding the risk altogether by
deciding not to start or continue with an activity that leads to the risk, sharing the
risk with other parties, or accepting or even increasing the risk to deal with an
opportunity.
2.3 Requirements Classification Schema
For the purposes of the BABOK
®
Guide, the following classification schema
describes requirements:
Business requirements: statements of goals, objectives, and outcomes
that describe why a change has been initiated. They can apply to the whole
of an enterprise, a business area, or a specific initiative.
Stakeholder requirements: describe the needs of stakeholders that must
be met in order to achieve the business requirements. They may serve as a
bridge between business and solution requirements.
Solution requirements: describe the capabilities and qualities of a
solution that meets the stakeholder requirements. They provide the
appropriate level of detail to allow for the development and
implementation of the solution. Solution requirements can be divided into
two sub-categories:
functional requirements: describe the capabilities that a solution
must have in terms of the behaviour and information that the solution
will manage, and
For more
information, see
Non-Functional
Requirements
Analysis (p. 302).
non-functional requirements or quality of service requirements:
do not relate directly to the behaviour of functionality of the solution,
but rather describe conditions under which a solution must remain
effective or qualities that a solution must have.
Transition requirements: describe the capabilities that the solution must
have and the conditions the solution must meet to facilitate transition from
the current state to the future state, but which are not needed once the
change is complete. They are differentiated from other requirements types
because they are of a temporary nature. Transition requirements address
topics such as data conversion, training, and business continuity.
2.4 Stakeholders
Each task includes a list of stakeholders who are likely to participate in the
execution of that task or who will be affected by it. A stakeholder is an individual
or group that a business analyst is likely to interact with directly or indirectly. The
Business Analysis Key Concepts Stakeholders
17
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
BABOK
®
Guide does not mandate that these roles be filled for any given
initiative. Any stakeholder can be a source of requirements, assumptions, or
constraints.
This list is not intended to be an exhaustive list of all possible stakeholder
classifications. Some additional examples of people who fit into each of these
generic roles are listed in the definitions below. In most cases there will be
multiple stakeholder roles found within each category. Similarly, a single
individual may fill more than one role.
For the purpose of the BABOK
®
Guide, the generic list of stakeholders includes
the following roles:
• business analyst,
• customer,
• domain subject matter expert,
• end user,
• implementation subject matter
expert,
• operational support,
• project manager,
• regulator,
• sponsor,
• supplier, and
• tester.
2.4.1 Business Analyst
The business analyst is inherently a stakeholder in all business analysis activities.
The BABOK
®
Guide presumes that the business analyst is responsible and
accountable for the execution of these activities. In some cases the business
analyst may also be responsible for performing activities that fall under another
stakeholder role.
2.4.2 Customer
A customer uses or may use products or services produced by the enterprise and
may have contractual or moral rights that the enterprise is obliged to meet.
2.4.3 Domain Subject Matter Expert
A domain subject matter expert is any individual with in-depth knowledge of a
topic relevant to the business need or solution scope. This role is often filled by
people who may be end users or people who have in-depth knowledge of the
solution such as managers, process owners, legal staff, consultants, and others.
2.4.4 End User
End users are stakeholders who directly interact with the solution. End users can
include all participants in a business process, or who use the product or solution.
2.4.5 Implementation Subject Matter Expert
An implementation subject matter expert is any stakeholder who has specialized
knowledge regarding the implementation of one or more solution components.
Stakeholders Business Analysis Key Concepts
18
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
While it is not possible to define a listing of implementation subject matter expert
roles that are appropriate for all initiatives, some of the most common roles are:
project librarian, change manager, configuration manager, solution architect,
developer, database administrator, information architect, usability analyst, trainer,
and organizational change consultant.
2.4.6 Operational Support
Operational support is responsible for the day-to-day management and
maintenance of a system or product.
While it is not possible to define a listing of operational support roles that are
appropriate for all initiatives, some of the most common roles are: operations
analyst, product analyst, help desk, and release manager.
2.4.7 Project Manager
Project managers are responsible for managing the work required to deliver a
solution that meets a business need, and for ensuring that the project's objectives
are met while balancing the project factors including scope, budget, schedule,
resources, quality, and risk.
While it is not possible to completely define a listing of project management roles
that are appropriate for all initiatives, some of the most common roles are: project
lead, technical lead, product manager, and team leader.
2.4.8 Regulator
Regulators are responsible for the definition and enforcement of standards.
Standards can be imposed on the solution by regulators through legislation,
corporate governance standards, audit standards, or standards defined by
organizational centers of competency. Alternate roles are government, regulatory
bodies, and auditor.
2.4.9 Sponsor
Sponsors are responsible for initiating the effort to define a business need and
develop a solution that meets that need. They authorize the work to be
performed, and control the budget and scope for the initiative. Alternate roles are
executive and project sponsor.
2.4.10 Supplier
A supplier is a stakeholder outside the boundary of a given organization or
organizational unit. Suppliers provide products or services to the organization and
may have contractual or moral rights and obligations that must be considered.
Alternate roles are providers, vendors, and consultants.
Business Analysis Key Concepts Requirements and Designs
19
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
2.4.11 Tester
Testers are responsible for determining how to verify that the solution meets the
requirements defined by the business analyst, as well as conducting the
verification process. Testers also seek to ensure that the solution meets applicable
quality standards, and that the risk of defects or failures is understood and
minimized. An alternate role is quality assurance analyst.
2.5 Requirements and Designs
Eliciting, analyzing, validating, and managing requirements have consistently
been recognized as key activities of business analysis. However, it is important to
recognize that business analysts are also responsible for the definition of design,
at some level, in an initiative. The level of responsibility for design varies based on
the perspective within which a business analyst is working.
Requirements are focused on the need; designs are focused on the solution. The
distinction between requirements and designs is not always clear. The same
techniques are used to elicit, model, and analyze both. A requirement leads to a
design which in turn may drive the discovery and analysis of more requirements.
The shift in focus is often subtle.
The classification as a requirement or a design may become less significant as the
business analyst's work progresses to a greater understanding of and eventual
fulfillment of the need. The tasks in the BABOK
®
Guide such as Trace
Requirements (p. 79) or Specify and Model Requirements (p. 136) may refer to
requirements, but the intent is to include designs as well.
Business analysis can be complex and recursive. A requirement (or set of
requirements) may be used to define a design. That design may then be used to
elicit additional requirements that are used to define more detailed designs. The
business analyst may hand off requirements and designs to other stakeholders
who may further elaborate on the designs. Whether it is the business analyst or
some other role that completes the designs, the business analyst often reviews
the final designs to ensure that they align with the requirements.
The following table provides some basic examples of how information may be
viewed as either a requirement or a design.
Table 2.5.1: Requirements and Design
Requirement Design
View six months sales data across multiple
organizational units in a single view.
A sketch of a dashboard.
Reduce amount of time required to pick
and pack a customer order.
Process model.
Record and access a medical patient’s
history.
Screen mock-up showing specific
data fields.
Requirements and Designs Business Analysis Key Concepts
20
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Stakeholders may present a need or a solution to an assumed need. A business
analyst uses activities found in Elicitation and Collaboration (p. 53), Strategy
Analysis (p. 99), Requirements Analysis and Design Definition (p. 133), and
Solution Evaluation (p. 163) to transform that request into a requirement or
design. Regardless of the focus of the stakeholder, the importance of the role of
the business analyst lies in continuously asking the question ‘why?’. For example,
“Why is either the requirement or design necessary to provide value to an
enterprise and to facilitate the realization of an enterprise’s goals and objectives?”
Figure 2.5.1: Requirements and Design Cycle
Develop business strategy, goals, and
objectives for a new business.
Business Capability Model.
Provide information in English and French. Prototype with text displayed in
English and French.
Table 2.5.1: Requirements and Design (Continued)
Requirement Design
Transition
Requirements
What are the
conditions?
Business
Requirements
Why do I want it?
Solution
Requirements
What do I want?
Stakeholder
Requirements
What are the needs?
Cycle continues until
requirements are met.
A
s
s
e
s
s
O
u
t
c
o
m
e
s
D
e
s
i
g
n
D
e
s
i
g
n
D
e
s
i
g
n
21
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
3
Business Analysis Planning
and Monitoring
The Business Analysis Planning and Monitoring knowledge area tasks organize
and coordinate the efforts of business analysts and stakeholders. These tasks
produce outputs that are used as key guidelines for the other tasks throughout
the BABOK
®
Guide.
The Business Analysis Planning and Monitoring knowledge area includes the
following tasks:
Plan Business Analysis Approach: describes the planning of business
analysis work from creation or selection of a methodology to planning the
individual activities, tasks, and deliverables.
Plan Stakeholder Engagement: describes understanding which
stakeholders are relevant to the change, what business analysts need from
them, what they need from business analysts, and the best way to
collaborate.
Plan Business Analysis Governance: defines the components of business
analysis that are used to support the governance function of the
organization. It helps ensure that decisions are made properly and
consistently, and follows a process that ensures decision makers have the
information they need. Examples of this include requirements
management, business analysis risk management, and allocation of
business analysis resources.
Plan Business Analysis Information Management: defines how
information developed by business analysts (including requirements and
designs) is captured, stored, and integrated with other information for
long-term use.
Business Analysis Planning and Monitoring
22
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Identify Business Analysis Performance Improvements: describes
managing and monitoring how business analysis work is performed to
ensure that commitments are met and continuous learning and
improvement opportunities are realized.
The Core Concept Model in Business Analysis
Planning and Monitoring
The Business Analysis Core Concept Model™ (BACCM™) describes the
relationships among the six core concepts. The following table describes the
usage and application of each of the core concepts within the context of Business
Analysis Planning and Monitoring.
Table 3.0.1: The Core Concept Model in Business Analysis Planning and Monitoring
Core Concept During Business Analysis Planning and
Monitoring, business analysts...
Change: the act of
transformation in response to a
need.
are responsible for determining how
changes to business analysis results will
be requested and authorized.
Need: a problem or opportunity
to be addressed.
choose a business analysis approach that
provides adequate analysis for the
change.
Solution: a specific way of
satisfying one or more needs in a
context.
evaluate if business analysis performance
was a key contributor to the successful
implementation of a solution.
Stakeholder: a group or
individual with a relationship to
the change, the need, or the
solution.
perform a stakeholder analysis to ensure
planning and monitoring activities reflect
stakeholder needs and account for
stakeholder characteristics.
Value: the worth, importance, or
usefulness of something to a
stakeholder within a context.
conduct performance analysis to ensure
business analysis activities continue to
produce sufficient value for the
stakeholders.
Context: the circumstances that
influence, are influenced by, and
provide understanding of the
change.
ensure a complete understanding of the
context under analysis in order to develop
an efficient business analysis approach.
Business Analysis Planning and Monitoring
23
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 3.0.1: Business Analysis Planning and Monitoring Input/Output Diagram
Input
Tasks
3.3
Plan Business
Analysis
Governance
3.2
Plan Stakeholder
Engagement
3.1
Plan Business
Analysis Approach
3.4
Plan Business
Analysis
Information
Management
3.5
Identify Business
Analysis
Performance
Improvements
Needs
Performance
Objectives (external)
3.1
Business Analysis
Approach
3.2
Stakeholder
Engagement
Approach
3.3
Governance Approach
3.5
Business Analysis
Performance
Assessment
3.4
Information
Management
Approach
Output
Plan Business Analysis Approach Business Analysis Planning and Monitoring
24
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
3.1 Plan Business Analysis Approach
3.1.1 Purpose
The purpose of Plan Business Analysis Approach is to define an appropriate
method to conduct business analysis activities.
3.1.2 Description
Business analysis approaches describe the overall method that will be followed
when performing business analysis work on a given initiative, how and when
tasks will be performed, and the deliverables that will be produced.
The business analyst may also identify an initial set of techniques to use. This list
may change as the initiative proceeds and the business analyst gains a deeper
understanding of the change and its stakeholders.
The business analysis approach may be defined by a methodology or by
organizational standards. In some organizations, elements of the business
analysis approach may be standardized and formalized into a repeatable business
analysis process which can be leveraged for each effort. Even where a standard
approach exists, it may be tailored to the needs of a specific initiative. Tailoring
may be governed by standards that define which approaches are permitted,
which elements of those processes may be tailored, and general guidelines for
selecting a process.
If organizational standards do not exist, the business analyst works with the
appropriate stakeholders to determine how the work will be completed. For
example, if the change is delivered via a project, the standards and approach may
be developed during the project planning phase.
The business analysis approach should:
• align to the overall goals of the change,
• coordinate the business analysis tasks with the activities and deliverables of
the overall change,
• include tasks to manage any risks that could reduce the quality of business
analysis deliverables or impede task efficiency, and
• leverage approaches and select techniques and tools that have historically
worked well.
3.1.3 Inputs
• Needs: the business analysis approach is shaped by the problem or opportunity
faced by the organization. It is necessary to consider what is known about the
need at the time of planning, while acknowledging that understanding evolves
throughout business analysis activities.
Business Analysis Planning and Monitoring Plan Business Analysis Approach
25
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 3.1.1: Plan Business Analysis Approach Input/Output Diagram
Input
Guidelines and Tools
Tasks Using This Output
Output
3.1 Plan Business Analysis
Approach
Business Analysis
Performance Assessment
3.1
Business Analysis
Approach
3.2
Plan Stakeholder
Engagement
Needs
Business Policies
Expert Judgment
Methodologies and
Frameworks
Stakeholder Engagement
Approach
3.3
Plan Business
Analysis
Governance
3.4
Plan Business
Analysis
Information
Management
3.5
Identify Business
Analysis
Performance
Improvements
4.1
Prepare for
Elicitation
4.2
Conduct Elicitation
4.4
Communicate
Business Analysis
Information
4.5
Manage
Stakeholder
Collaboration
6.1
Analyze Current
State
6.3
Assess Risks
6.4
Define Change
Strategy
Plan Business Analysis Approach Business Analysis Planning and Monitoring
26
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
3.1.4 Elements
.1 Planning Approach
There are various planning methods used across perspectives, industries, and
enterprises. Many planning methods fit somewhere along a continuum between
predictive and adaptive approaches.
Predictive approaches focus on minimizing upfront uncertainty and ensuring that
the solution is defined before implementation begins in order to maximize control
and minimize risk. These approaches are often preferred in situations where
requirements can effectively be defined ahead of implementation, the risk of an
incorrect implementation is unacceptably high, or when engaging stakeholders
presents significant challenges.
Adaptive approaches focus on rapid delivery of business value in short iterations
in return for acceptance of a higher degree of uncertainty regarding the overall
delivery of the solution. These approaches tend to be preferred when taking an
exploratory approach to finding the best solution or for incremental improvement
of an existing solution.
Different approaches may be used within the same initiative. Among other
factors, the business analyst may consider the organization’s standards, tolerance
for uncertainty, and previous experience with different approaches when
planning for business analysis activities.
Regardless of the approach, planning is an essential task to ensure value is
delivered to an enterprise. Planning typically occurs more than once on a given
initiative as plans are updated to address changing business conditions and newly
raised issues. The business analysis approach should describe how plans will be
altered if changes are required.
.2 Formality and Level of Detail of Business Analysis Deliverables
When defining the business analysis approach, consider the level of formality that
is appropriate for approaching and planning the initiative.
Predictive approaches typically call for formal documentation and
representations. Business analysis information may be captured in a formal
document or set of representations following standardized templates.
Information is captured at various levels of detail. The specific content and format
of business analysis information can vary depending on the organizational
methodologies, processes, and templates in use.
Adaptive approaches favour defining requirements and designs through team
interaction and gathering feedback on a working solution. Mandatory
requirements representations are often limited to a prioritized requirements list.
Additional business analysis documentation may be created at the discretion of
the team, and generally consists of models developed to enhance the team’s
understanding of a specific problem. Formal documentation is often produced
after the solution is implemented to facilitate knowledge transfer.
Business Analysis Planning and Monitoring Plan Business Analysis Approach
27
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Other considerations that may affect the approach include:
• the change is complex and high risk,
• the organization is in, or interacts with, heavily regulated industries,
• contracts or agreements necessitate formality,
• stakeholders are geographically distributed,
• resources are outsourced,
• staff turnover is high and/or team members may be inexperienced,
• requirements must be formally signed off, and
• business analysis information must be maintained long-term or handed
over for use on future initiatives.
Figure 3.1.2: Formality and Level of Detail of Business Analysis Deliverables
.3 Business Analysis Activities
A business analysis approach provides a description of the types of activities that
the business analyst will perform. Frequently the organization’s adopted
methodologies influence the activities that are selected.
Integrating business analysis activities in the business analysis approach includes:
• identifying the activities required to complete each deliverable and then
breaking each activity into tasks,
• dividing the work into iterations, identifying the deliverables for each
iteration, and then identifying the associated activities and tasks, or
Predictive
Tasks are performed in
specific phases.
Tasks are performed
iteratively.
Solution
Definition
Level of
Formality
Activities
Timing
Activities required to
complete deliverables are
identified first and then
divided into tasks.
Activities are divided into
iterations with deliverables
first and then the associated
tasks are identified.
Formal—information is
captured in standardized
templates.
Informal—information is
gathered through team
interaction and feedback.
Defined before
implementation to maximize
control and minimize risk.
Defined in iterations to
arrive at best solution or
improve an existing solution.
Adaptive
Approach
Plan Business Analysis Approach Business Analysis Planning and Monitoring
28
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• using a previous similar initiative as an outline and applying the detailed
tasks and activities unique to the current initiative.
.4 Timing of Business Analysis Work
Business analysts determine when the business analysis tasks need to be
performed and if the level of business analysis effort will need to vary over time.
This type of planning includes determining whether the business analysis tasks
performed within the other knowledge areas will be performed primarily in
specific phases or iteratively over the course of the initiative.
The timing of business analysis activities can also be affected by:
• the availability of resources,
• priority and/or urgency of the initiative,
• other concurrent initiatives, or
• constraints such as contract terms or regulatory deadlines.
.5 Complexity and Risk
The complexity and size of the change and the overall risk of the effort to the
organization are considered when determining the business analysis approach. As
complexity and risk increase or decrease, the nature and scope of business
analysis work can be altered and reflected in the approach.
The approach may also be altered based on the number of stakeholders or
business analysis resources involved in the initiative. As the number of
stakeholders increases, the approach may be adjusted to include additional
process steps to better manage the business analysis work.
Other factors that can impact complexity include:
• size of the change,
• number of business areas or systems affected,
• geographic and cultural considerations,
• technological complexities, and
• any risks that could impede the business analysis effort.
Factors that can impact the risk level of a business analysis effort include:
• experience level of the business analyst,
• extent of domain knowledge held by the business analyst,
• level of experience stakeholders have in communicating their needs,
• stakeholder attitudes about the change and business analysis in general,
• amount of time allocated by stakeholders to the business analysis activities,
• any pre-selected framework, methodology, tools, and/or techniques
Business Analysis Planning and Monitoring Plan Business Analysis Approach
29
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
imposed by organizational policies and practices, and
• cultural norms of the organization.
.6 Acceptance
The business analysis approach is reviewed and agreed upon by key stakeholders.
In some organizations, the business analysis process may be more structured and
require key stakeholders to sign off on the approach to ensure all business
analysis activities have been identified, estimates are realistic, and the proposed
roles and responsibilities are correct. Any issues raised by stakeholders when
reviewing the approach are documented by the business analyst and resolutions
are sought. Stakeholders also play a role in reviewing and accepting changes to
the approach as alterations are made to accommodate changing conditions
across the initiative.
3.1.5 Guidelines and Tools
• Business Analysis Performance Assessment: provides results of previous
assessments that should be reviewed and incorporated into all planning
approaches.
• Business Policies: define the limits within which decisions must be made. They
may be described by regulations, contracts, agreements, deals, warranties,
certifications, or other legal obligations. These policies can influence the
business analysis approach.
• Expert Judgment: 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.
• Methodologies and Frameworks: shape the approach that will be used by
providing methods, techniques, procedures, working concepts, and rules. They
may need to be tailored to better meet the needs of the specific business
challenge.
• Stakeholder Engagement Approach: understanding the stakeholders and
their concerns and interests may influence decisions made when determining
the business analysis approach.
3.1.6 Techniques
Brainstorming: used to identify possible business analysis activities,
techniques, risks and other relevant items to help build the business analysis
approach.
Business Cases: used to understand whether elements of the problem or
opportunity are especially time-sensitive, high-value, or whether there is any
particular uncertainty around elements of the possible need or solution.
Plan Business Analysis Approach Business Analysis Planning and Monitoring
30
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Document Analysis: used to review existing organizational assets that might
assist in planning the approach.
Estimation: used to determine how long it may take to perform business
analysis activities.
Financial Analysis: used to assess how different approaches (and the
supported delivery options) affect the value delivered.
Functional Decomposition: used to break down complex business analysis
processes or approaches into more feasible components.
Interviews: used to help build the plan with an individual or small group.
Item Tracking: used to track any issues raised during planning activities with
stakeholders. Can also track risk related items raised during discussions when
building the approach.
Lessons Learned: used to identify an enterprise’s previous experience (both
successes and challenges) with planning business analysis approach.
Process Modelling: used to define and document the business analysis
approach.
Reviews: used to validate the selected business analysis approach with
stakeholders.
Risk Analysis and Management: used to assess risks in order to select the
proper business analysis approach.
Scope Modelling: used to determine the boundaries of the solution as an
input to planning and to estimating.
Survey or Questionnaire: used to identify possible business analysis activities,
techniques, risks and other relevant items to help build the business analysis
approach.
Workshops: used to help build the plan in a team setting.
3.1.7 Stakeholders
• Domain Subject Matter Expert: can be a source of risk when their
involvement is required and availability is lacking. The approach taken may
depend on availability and level of their involvement with the initiative.
• Project Manager: determines that the approach is realistic for the overall
schedule and timelines. The business analysis approach must be compatible
with other activities.
• Regulator: may be needed to provide approval for aspects of the business
analysis approach or decisions made in tailoring the process, especially in
organizations where the business analysis process is audited.
• Sponsor: can provide needs and objectives for the approach and ensures that
organizational policies are followed. The selected approach may depend on
availability and involvement with the initiative.
Business Analysis Planning and Monitoring Plan Stakeholder Engagement
31
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
3.1.8 Outputs
• Business Analysis Approach: identifies the business analysis approach and
activities that will be performed across an initiative including who will perform
the activities, the timing and sequencing of the work, the deliverables that will
be produced and the business analysis techniques that may be utilized. The
remaining outputs of the Business Analysis Planning and Monitoring knowledge
area may be integrated into an overall approach or be independent based upon
methodology, organization, and perspective.
3.2 Plan Stakeholder Engagement
3.2.1 Purpose
The purpose of Plan Stakeholder Engagement is to plan an approach for
establishing and maintaining effective working relationships with the
stakeholders.
3.2.2 Description
Plan Stakeholder Engagement involves conducting a thorough stakeholder
analysis to identify all of the involved stakeholders and analyze their
characteristics. The results of the analysis are then utilized to define the best
collaboration and communication approaches for the initiative and to
appropriately plan for stakeholder risks.
When planning for stakeholder engagement, the degree of complexity can
increase disproportionately as the number of stakeholders involved in the
business analysis activities increases. This is important because new or different
techniques for the management of stakeholders may be required when the
engagement moves from collaborating with a few stakeholders into dozens,
hundreds, or even thousands of people.
3.2.3 Inputs
• Needs: understanding the business need and the parts of the enterprise that it
affects helps in the identification of stakeholders. The need may evolve as
stakeholder analysis is performed.
• Business Analysis Approach: incorporating the overall business analysis
approach into the stakeholder analysis, collaboration, and communication
approaches is necessary to ensure consistency across the approaches.
Plan Stakeholder Engagement Business Analysis Planning and Monitoring
32
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 3.2.1: Plan Stakeholder Engagement Input/Output Diagram
3.2.4 Elements
.1 Perform Stakeholder Analysis
Stakeholder analysis involves identifying the stakeholders (who will be directly or
indirectly impacted by the change) and their characteristics, as well as analyzing
the information once collected. Stakeholder analysis is performed repeatedly as
business analysis activities continue.
A thorough and detailed stakeholder list ensures that stakeholders are not
overlooked. Understanding who the stakeholders are, the impact of proposed
changes on them, and the influence they may have on the change is vital to
understanding what needs, wants, and expectations must be satisfied by a
Tasks Using This Output
Output
3.2 Plan Stakeholder
Engagement
Business Analysis
Performance Assessment
3.2
Stakeholder
Engagement
Approach
3.3
Plan Business
Analysis
Governance
3.1
Business Analysis
Approach
Needs
Change Strategy
Current State Description
3.4
Plan Business
Analysis
Information
Management
4.1
Prepare for
Elicitation
4.5
Manage
Stakeholder
Collaboration
4.2
Conduct Elicitation
4.4
Communicate
Business Analysis
Information
6.3
Assess Risks
6.4
Define Change
Strategy
3.1
Plan Business
Analysis Approach
Input
Guidelines and Tools
Business Analysis Planning and Monitoring Plan Stakeholder Engagement
33
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
solution. If stakeholders are not identified, the business analyst may miss
uncovering critical needs. Stakeholder needs uncovered late will often require a
revision to business analysis tasks that are either in progress or are completed.
This can result in increased costs and decreased stakeholder satisfaction.
How business analysts perform stakeholder analysis can vary between projects,
methodologies, and organizations. A company’s organizational chart and
business processes can serve as an initial source for identifying internal
stakeholders. The sponsor may also identify stakeholders. Stakeholders outside
the organization may be identified and can be uncovered by understanding any
existing contracts that may be in place, anticipated vendors that may have a role
based on existing relationships with the organization, as well as regulatory and
governing bodies that may influence the work. Shareholders, customers, and
suppliers are also considered when searching for external stakeholders.
Roles
Business analysts identify stakeholder roles in order to understand where and
how the stakeholders will contribute to the initiative. It is important that the
business analyst is aware of the various roles a stakeholder is responsible for
within the organization.
Attitudes
Stakeholder attitudes can positively or negatively impact a change. Business
analysts identify stakeholder attitudes in order to fully understand what may
impact a stakeholder’s actions and behaviours. Knowing how a stakeholder
perceives the initiative allows an opportunity for the business analyst to
specifically plan their collaboration and engagement with that stakeholder.
Business analysts analyze stakeholder attitudes about:
• business goals, objectives of the initiative, and any proposed solutions,
• business analysis in general,
• the level of interest in the change,
• the sponsor,
• team members and other stakeholders, and
• collaboration and a team-based approach.
Stakeholders with positive attitudes may be strong champions and great
contributors. Other stakeholders may not see value in the work, may
misunderstand the value being provided, or may be concerned about the effect
the change will have on them. Stakeholders who are expected to serve in key
roles and participate heavily in business analysis activities, but who view a change
negatively, may require collaboration approaches that increase their cooperation.
Decision Making Authority
Business analysts identify the authority level a stakeholder possesses over business
analysis activities, deliverables, and changes to business analysis work.
Plan Stakeholder Engagement Business Analysis Planning and Monitoring
34
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Understanding authority levels upfront eliminates confusion during the business
analysis effort and ensures the business analyst collaborates with the proper
stakeholders when looking for a decision to be made or seeking approvals.
Level of Power or Influence
Understanding the nature of influence and the influence structures and channels
within an organization can prove invaluable when seeking to build relationships
and trust. Understanding the influence and attitude each stakeholder may have
can help develop strategies for obtaining buy-in and collaboration. Business
analysts evaluate how much influence is needed to implement a change
compared to the amount of influence the key stakeholders can bring. If there is a
mismatch between the influence required and the amount of influence the
stakeholder has or is perceived to have, business analysts develop risk plans,
responses and other strategies that might be needed to obtain the required level
of support.
.2 Define Stakeholder Collaboration
Ensuring effective collaboration with stakeholders is essential for maintaining
their engagement in business analysis activities. Collaboration can be a
spontaneous event. However, much collaboration is deliberate and planned, with
specific activities and outcomes determined ahead of time during planning
activities.
The business analyst may plan different collaboration approaches for internal and
external stakeholders, and approaches may differ by business analysis activity. The
objective is to select the approaches that work best to meet the needs of each
stakeholder group and ensure their interest and involvement is maintained across
the initiative. Some considerations when planning collaboration include:
• timing and frequency of collaboration,
• location,
• available tools such as wikis and online communities,
• delivery method such as in-person or virtual, and
• preferences of the stakeholders.
Planning considerations can be documented in the form of a stakeholder
collaboration plan. As factors change, plans can be revisited, and adjustments
and adaptations can be made to ensure ongoing engagement of stakeholders.
.3 Stakeholder Communication Needs
The business analyst evaluates:
• what needs to be communicated,
• what is the appropriate delivery method (written or verbal),
• who the appropriate audience is,
• when communication should occur,
• frequency of communication,
Business Analysis Planning and Monitoring Plan Stakeholder Engagement
35
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• geographic location of stakeholders who will receive communications,
• level of detail appropriate for the communication and stakeholder, and
• level of formality of communications.
Communication considerations can be documented in the form of a stakeholder
communication plan. Business analysts build and review communication plans
with stakeholders to ensure their communication requirements and expectations
are met.
3.2.5 Guidelines and Tools
• Business Analysis Performance Assessment: provides results of previous
assessments that should be reviewed and incorporated.
• Change Strategy: used for improved assessment of stakeholder impact and
the development of more effective stakeholder engagement strategies.
• Current State Description: provides the context within which the work needs
to be completed. This information will lead to more effective stakeholder
analysis and better understanding of the impact of the desired change.
3.2.6 Techniques
Brainstorming: used to produce the stakeholder list and identify stakeholder
roles and responsibilities.
Business Rules Analysis: used to identify stakeholders who were the source
of the business rules.
Document Analysis: used to review existing organizational assets that might
assist in planning stakeholder engagement.
Interviews: used to interact with specific stakeholders to gain more
information or knowledge about stakeholder groups.
Lessons Learned: used to identify an enterprise’s previous experience (both
successes and challenges) with planning stakeholder engagement.
Mind Mapping: used to identify potential stakeholders and help understand
the relationships between them.
Organizational Modelling: used to determine if the organizational units or
people listed have any unique needs and interests that should be considered.
Organizational models describe the roles and functions in the organization and
the ways in which stakeholders interact which can help to identify stakeholders
who will be affected by a change.
Process Modelling: used to categorize stakeholders by the systems that
support their business processes.
Risk Analysis and Management: used to identify risks to the initiative
resulting from stakeholder attitudes or the inability of key stakeholders to
participate in the initiative.
Plan Stakeholder Engagement Business Analysis Planning and Monitoring
36
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Scope Modelling: used to develop scope models to show stakeholders that
fall outside the scope of the solution but still interact with it in some way.
Stakeholder List, Map, or Personas: used to depict the relationship of
stakeholders to the solution and to one another.
Survey or Questionnaire: used to identify shared characteristics of a
stakeholder group.
Workshops: used to interact with groups of stakeholders to gain more
information about stakeholder groups.
3.2.7 Stakeholders
• Customers: a source of external stakeholders.
• Domain Subject Matter Expert: may help to identify stakeholders and may
themselves be identified to fulfill one or more roles on the initiative.
• End User: a source of internal stakeholders.
• Project Manager: may be able to identify and recommend stakeholders.
Responsibility for stakeholder identification and management may be shared
with the business analyst.
• Regulator: may require that specific stakeholder representatives or groups be
involved in the business analysis activities.
• Sponsor: may request that specific stakeholders be involved in the business
analysis activities.
• Supplier: a source of external stakeholders.
3.2.8 Outputs
• Stakeholder Engagement Approach: contains a list of the stakeholders,
their characteristics which were analyzed, and a listing of roles and
responsibilities for the change. It also identifies the collaboration and
communication approaches the business analyst will utilize during the initiative.
Business Analysis Planning and Monitoring Plan Business Analysis Governance
37
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
3.3 Plan Business Analysis Governance
3.3.1 Purpose
The purpose of Plan Business Analysis Governance is to define how decisions are
made about requirements and designs, including reviews, change control,
approvals, and prioritization.
3.3.2 Description
Business analysts ensure that a governance process is in place and clarify any
ambiguities within it. A governance process identifies the decision makers,
process, and information required for decisions to be made. A governance
process describes how approvals and prioritization decisions are made for
requirements and designs.
When planning the governance approach, business analysts identify:
• how business analysis work will be approached and prioritized,
what the process for proposing a change to business analysis information is,
• who has the authority and responsibility to propose changes and who
should be involved in the change discussions,
• who has responsibility for analyzing change requests,
• who has the authority to approve changes, and
• how changes will be documented and communicated.
3.3.3 Inputs
• Business Analysis Approach: incorporating the overall business analysis
approach into the governance approach is necessary to ensure consistency
across the approaches.
• Stakeholder Engagement Approach: identifying stakeholders and
understanding their communication and collaboration needs is useful in
determining their participation in the governance approach. The engagement
approach may be updated based on the completion of the governance
approach.
Plan Business Analysis Governance Business Analysis Planning and Monitoring
38
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 3.3.1: Plan Business Analysis Governance Input/Output Diagram
3.3.4 Elements
.1 Decision Making
Decisions are made throughout the initiative. A stakeholder may serve in various
roles in the decision-making process such as:
• participant in decision-making discussions,
• subject matter expert (SME) lending experience and knowledge to the
decision-making process,
• reviewer of information, and
• approver of decisions.
The decision-making process defines what happens when teams cannot reach
consensus, by identifying escalation paths and key stakeholders who hold final
decision-making authority.
Output
Input
Guidelines and Tools
Tasks Using This Output
3.3 Plan Business Analysis
Governance
Business Analysis
Performance Assessment
3.3
Governance
Approach
3.4
Plan Business
Analysis
Information
Management
3.2 Stakeholder
Engagement
Approach
3.1
Business Analysis
Approach
Business Policies
Current State Description
5.3
Prioritize
Requirements
5.4
Assess
Requirements
Changes
5.5
Approve
Requirements
Legal/Regulatory
Information
Business Analysis Planning and Monitoring Plan Business Analysis Governance
39
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.2 Change Control Process
When business analysts develop a change control process, they:
Determine the process for requesting changes: specify which
requirements and designs the change control process covers and determine
whether it applies to all changes or only to changes of a specific size, cost,
or level of effort. This process details the steps for proposing a change,
when changes can be proposed, who can propose changes and how
change requests are communicated.
Determine the elements of the change request: identify the
information to be included in a proposal to support decision making and
implementation if it is approved.
Possible components to consider on a change request are:
Cost and time estimates: for each area affected by the proposed
change, the expected cost of change is estimated.
Benefits: an explanation of how the change aligns with the initiative
and business objectives to show how the change adds value. Benefits
considered include both financial benefits and tactical benefits such as
implications to scope, time, cost, quality, and resources.
Risks: an analysis of risks to the initiative, the solution, or business
objectives.
Priority: the level of importance of the change relative to other factors
such as organizational objectives, regulatory compliance requirements,
and stakeholder needs.
Course(s) of action: the course of action for the change includes an
assessment of the components of the change request (cost, time,
benefits, risks and priority). It is common to identify several alternative
courses, including those recommended by the requester and by other
stakeholders so decision makers can make a choice that will best serve
the needs of the initiative.
Determine how changes will be prioritized: the priority of the proposed
change is established relative to other competing interests within the
current initiative.
Determine how changes will be documented: configuration
management and traceability standards establish product baselines and
version control practices that identify which baseline is affected by the
change.
Determine how changes will be communicated: how proposed
changes, changes under review, and approved, declined, or deferred
changes will be communicated to stakeholders.
Determine who will perform the impact analysis: specify who is
responsible for performing an analysis of the impacts the proposed change
will have across the initiative.
Plan Business Analysis Governance Business Analysis Planning and Monitoring
40
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Determine who will authorize changes: include a designation of who
can approve changes and what business analysis information their authority
covers.
.3 Plan Prioritization Approach
For more
information, see
Prioritize
Requirements
(p. 86).
Timelines, expected value, dependencies, resource constraints, adopted
methodologies, and other factors influence how requirements and designs are
prioritized.
When planning the prioritization process, business analysts determine the:
• formality and rigour of the prioritization process,
• participants who will be involved in prioritization,
• process for deciding how prioritization will occur, including which
prioritization techniques will be utilized, and
• criteria to be used for prioritization. For example, requirements may be
prioritized based on cost, risk, and value.
The approach should also determine which stakeholders will have a role in
prioritization.
.4 Plan for Approvals
An approval formalizes the agreement between all stakeholders that the content
and presentation of the requirements and designs are accurate, adequate, and
contain sufficient detail to allow for continued progress to be made.
The timing and frequency of approvals are dependent on the size and complexity
of the change and associated risks of foregoing or delaying an approval.
The business analyst must determine the type of requirements and designs to be
approved, the timing for the approvals, the process to follow to gain approval,
and who will approve the requirements and designs.
When planning the appropriate approval process, business analysts consider the
organizational culture and the type of information being approved. For example,
new systems or processes for highly regulated industries such as financial,
pharmaceutical, or healthcare are likely to require frequent and rigorous review
and approval of very detailed specifications. For other types of initiatives, a less
intensive approval process may be more appropriate and result in a faster
implementation.
Planning for approvals also includes the schedule of events where approvals will
occur and how they will be tracked. Stakeholder availability, attitude, and
willingness to engage determine the efficiency of the approval process and may
significantly affect delivery timelines.
3.3.5 Guidelines and Tools
• Business Analysis Performance Assessment: provides results of previous
assessments that should be reviewed and incorporated into all planning
approaches.
Business Analysis Planning and Monitoring Plan Business Analysis Governance
41
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Business Policies: define the limits within which decisions must be made. They
may be described by regulations, contracts, agreements, warranties,
certifications or other legal obligations.
• Current State Description: provides the context within which the work needs
to be completed. This information can help drive how to make better decisions.
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed, and can be used to help develop a framework that ensures
sound business decision making.
3.3.6 Techniques
Brainstorming: used to generate an initial list of potential stakeholder names
who may need approval roles in the defined governance process.
Document Analysis: used to evaluate existing governance processes or
templates.
Interviews: used to identify possible decision-making, change control,
approval, or prioritization approaches and participants with an individual or
small group.
Item Tracking: used to track any issues that arise when planning a governance
approach.
Lessons Learned: used to find if past initiatives have identified valuable
experiences with governance that can be leveraged on current or future
initiatives.
Organizational Modelling: used to understand roles/responsibilities within
the organization in an effort to define a governance approach that involves the
right stakeholders.
Process Modelling: used to document the process or method for governing
business analysis.
Reviews: used to review the proposed governance plan with key stakeholders.
Survey or Questionnaire: used to identify possible decision-making, change
control, approval, or prioritization approaches and participants.
Workshops: used to identify possible decision-making, change control,
approval, or prioritization approaches and participants within a team setting.
3.3.7 Stakeholders
• Domain Subject Matter Expert: may be a possible source of a requested
change or may be identified as needing to be involved in change discussions.
• Project Manager: works with the business analyst to ensure that overall
project governance aligns with the business analysis governance approach.
• Regulator: may impose rules or regulations that need to be considered when
determining the business analysis governance plan. May also be a possible
source of a requested change.
Plan Business Analysis Information Management Business Analysis Planning and Monitoring
42
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Sponsor: can impose their own requirements for how business analysis
information should be managed. Participates in change discussions and
approves proposed changes.
3.3.8 Outputs
• Governance Approach: identifies the stakeholders who will have the
responsibility and authority to make decisions about business analysis work
including who will be responsible for setting priorities and who will approve
changes to business analysis information. It also defines the process that will be
utilized to manage requirement and design changes across the initiative.
3.4 Plan Business Analysis Information Management
3.4.1 Purpose
The purpose of Plan Business Analysis Information Management is to develop an
approach for how business analysis information will be stored and accessed.
3.4.2 Description
Business analysis information is comprised of all the information business analysts
elicit, create, compile, and disseminate in the course of performing business
analysis. Models, scope statements, stakeholder concerns, elicitation results,
requirements, designs, and solution options are just a few examples. This includes
requirements and designs, from lightweight user stories to formal requirement
documents to functioning prototypes.
Information management entails identifying:
• how information should be organized,
• the level of detail at which information should be captured,
• any relationships between the information,
how information may be used across multiple initiatives and throughout the
enterprise,
• how information should be accessed and stored, and
• characteristics about the information that must be maintained.
Information management helps ensure that business analysis information is
organized in a functional and useful manner, is easily accessible to appropriate
personnel, and is stored for the necessary length of time.
3.4.3 Inputs
• Business Analysis Approach: incorporating the overall business analysis
approach into the information management approach is necessary to ensure
consistency across the approaches.
Business Analysis Planning and Monitoring Plan Business Analysis Information Management
43
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Governance Approach: defines how business analysts manage changes to
requirements and designs, how decisions and approvals for business analysis
deliverables will be made, and how priorities will be set.
• Stakeholder Engagement Approach: identifying stakeholders and
understanding their communication and collaboration needs is useful in
determining their specific information management needs.
Figure 3.4.1: Plan Business Analysis Information Management Input/Output
Diagram
3.4.4 Elements
.1 Organization of Business Analysis Information
Business analysts are responsible for organizing business analysis information in a
manner that allows for efficient access and use. Information must be well
structured to ensure it is not difficult to locate, conflicts with other information, or
is needlessly duplicated.
Output
Input
3.4 Plan Business Analysis
Information Management
Business Analysis
Performance Assessment
3.4
Information
Management
Approach
4.4
Communicate
Business Analysis
Information
3.2
Stakeholder
Engagement
Approach
3.1
Business Analysis
Approach
Business Policies
Information Management
Tools
5.1
Trace
Requirements
5.2
Maintain
Requirements
7.4
Define
Requirements
Architecture
3.3
Governance
Approach
Guidelines and Tools
Tasks Using This Output
Legal/Regulatory
Information
Plan Business Analysis Information Management Business Analysis Planning and Monitoring
44
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
The business analyst determines how best to structure and organize the business
analysis information at the start of an initiative. This involves taking into
consideration the type and amount of information to be collected, the
stakeholder's access and usage needs, and the size and complexity of the change.
Relationships among the types of information must be defined to assist in
managing the effect of new or changed information in the future.
.2 Level of Abstraction
Level of abstraction describes the breadth and depth of the information being
provided. Representations of information may range from highly conceptual or
summarized to very detailed. In determining how much detail each stakeholder
may require as the initiative evolves, consideration is given to the needs of the
stakeholders, the complexity of what is being explained, and the importance of
the change. Rather than present the same information to all stakeholders,
business analysts should present information with appropriate breadth and level
of detail based on each stakeholder's role. Business analysis information
regarding a topic of significant importance or high level of risk is frequently
represented in greater detail.
.3 Plan Traceability Approach
The traceability approach is based on:
For more
information, see
Trace
Requirements
(p. 79).
• the complexity of the domain,
• the number of views of requirements that will be produced,
• any requirement-related risks, organizational standards, applicable
regulatory requirements, and
• an understanding of the costs and benefits involved with tracing.
Business analysts plan to ensure the approach is at a level of detail to add value
without excessive overhead.
.4 Plan for Requirements Reuse
Reusing requirements can save an organization time, effort, and cost—provided
the requirements are accessible and structured in a manner that supports their
reuse.
Requirements that are potential candidates for long-term use are those an
organization must meet on an ongoing basis such as:
• regulatory requirements,
• contractual obligations,
• quality standards,
• service level agreements,
• business rules,
• business processes, or
• requirements describing products the enterprise produces.
Business Analysis Planning and Monitoring Plan Business Analysis Information Management
45
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Requirements may also be reused when describing common features or services
that are used across multiple systems, processes, or programs.
To make requirements useful beyond the current change, business analysts plan
ahead for requirements reuse by identifying how best to structure, store, and
access requirements so they are usable and accessible for future business analysis
efforts.
In order for requirements to be reused they must be clearly named, defined, and
stored in a repository that is available to other business analysts.
.5 Storage and Access
Business analysis information can be stored in many ways. Storage decisions
depend on many factors such as who must access the information, how often
they need to access it, and what conditions must be present for access.
Organizational standards and tool availability also influence storage and access
decisions. The business analysis approach defines how various tools will be used
on the initiative and how the information will be captured and stored within
those tools. Tools may shape the selection of business analysis techniques,
notations to be used, and the way that information is organized.
The repository may need to store information other than requirements and
designs. It should be able to indicate the status of any stored information, and
allow for modification of that information over time.
.6 Requirements Attributes
Requirements attributes provide information about requirements, and aid in the
ongoing management of the requirements throughout the change. They are
planned for and determined with the requirements themselves.
Requirements attributes allow business analysts to associate information with
individual or related groups of requirements. The information documented by the
attributes helps the team efficiently and effectively make trade-offs between
requirements, identify stakeholders affected by potential changes, and
understand the effect of a proposed change.
Some commonly used requirements attributes include:
Absolute reference: provides a unique identifier. The reference is not
altered or reused if the requirement is moved, changed, or deleted.
Author: provides the name of the person who needs to be consulted
should the requirement later be found to be ambiguous, unclear, or in
conflict.
Complexity: indicates how difficult the requirement will be to implement.
Ownership: indicates the individual or group that needs the requirement
or will be the business owner after the solution is implemented.
Priority: indicates relative importance of requirements. Priority can refer to
the relative value of a requirement or to the sequence in which it will be
implemented.
Plan Business Analysis Information Management Business Analysis Planning and Monitoring
46
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Risks: identifies uncertain events that may impact requirements.
Source: identifies the origin of the requirement. The source is often
consulted if the requirement changes or if more information regarding the
requirement or the need that drove the requirement has to be obtained.
Stability: indicates the maturity of the requirement.
Status: indicates the state of the requirement, 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.
3.4.5 Guidelines and Tools
• Business Analysis Performance Assessment: provides results of previous
assessments that should be reviewed and incorporated into all planning
approaches.
• Business Policies: define the limits within which decisions must be made. They
may be described by regulations, contracts, agreements, warranties,
certifications, or other legal obligations.
• Information Management Tools: 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.
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed, and helps determine how business analysis information will
be managed.
3.4.6 Techniques
Brainstorming: used to help stakeholders uncover their business analysis
information management needs.
Interviews: used to help specific stakeholders uncover their business analysis
information management needs.
Item Tracking: used to track issues with current information management
processes.
Lessons Learned: used to create a source of information for analyzing
approaches for efficiently managing business analysis information.
Mind Mapping: used to identify and categorize the kinds of information that
need to be managed.
Process Modelling: used to document the process or method for managing
business analysis information.
Business Analysis Planning and Monitoring Identify Business Analysis Performance Improvements
47
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Survey or Questionnaire: used to ask stakeholders to provide input into
defining business analysis information management.
Workshops: used to uncover business analysis information management needs
in a group setting.
3.4.7 Stakeholders
• Domain Subject Matter Expert: may need to access and work with business
analysis information, and will be interested in a more specific view of business
analysis information which relates to their area of expertise.
• Regulator: may define rules and processes related to information
management.
• Sponsor: reviews, comments on, and approves business analysis information.
3.4.8 Outputs
• Information Management Approach: includes the defined approach for
how business analysis information will be stored, accessed, and utilized during
the change and after the change is complete.
3.5 Identify Business Analysis Performance
Improvements
3.5.1 Purpose
The purpose of Identify Business Analysis Performance Improvements is to assess
business analysis work and to plan to improve processes where required.
3.5.2 Description
To monitor and improve performance, it is necessary to establish the performance
measures, conduct the performance analysis, report on the results of the analysis,
and identify any necessary preventive, corrective, or developmental actions.
Performance analysis should occur throughout an initiative. Once potential
performance improvements are identified, they become guidelines for the next
time a task is executed.
3.5.3 Inputs
• Business Analysis Approach: identifies business analysis deliverables that will
be produced, activities that will need to be performed (including when they will
be performed and who will be performing them), and techniques that will be
used.
• Performance Objectives (external): describe the desired performance
outcomes that an enterprise or organization is hoping to achieve.
Identify Business Analysis Performance Improvements Business Analysis Planning and Monitoring
48
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 3.5.1: Identify Business Analysis Performance Improvements Input/Output
Diagram
3.5.4 Elements
.1 Performance Analysis
What constitutes effective business analysis work depends on the context of a
particular organization or initiative. Reports on business analysis performance can
be informal and verbal, or they may include formal documentation. Reports on
business analysis performance are designed and tailored to meet the needs of the
various types of reviewers.
.2 Assessment Measures
If current measures exist, the business analyst may leverage them or determine
new measures. The business analyst may also elicit assessment measures from
stakeholders.
Performance measures may be based on deliverable due dates as specified in the
Output
Input
Guidelines and Tools
3.5 Identify Business Analysis
Performance Improvements
Organizational Performance
Standards
3.5
Business Analysis
Performance
Assessment
3.1
Plan Business
Analysis Approach
3.1
Business Analysis
Approach
Performance
Objectives
(external)
3.2
Plan Stakeholder
Engagement
3.3
Plan Business
Analysis
Governance
3.4
Plan Business
Analysis
Information
Management
4.5
Manage
Stakeholder
Collaboration
Tasks Using This Output
Business Analysis Planning and Monitoring Identify Business Analysis Performance Improvements
49
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
business analysis plan, metrics such as the frequency of the changes to business
analysis work products, the number of review cycles required, task efficiency, or
qualitative feedback from stakeholders and peers regarding the business analyst’s
deliverables. Appropriate performance measures enable the business analyst to
determine when problems are occurring that may affect the performance of
business analysis or identify opportunities for improvement. Measures may be
both quantitative and qualitative. Qualitative measures are subjective and can be
heavily influenced by the stakeholder’s attitudes, perceptions, and other
subjective criteria.
All performance
metrics will
encourage certain
behaviours and
discourage others.
Poorly chosen
metrics may drive
behaviour that is
detrimental to the
enterprise as a
whole.
Some possible measures are:
Accuracy and Completeness: determine whether the business analyst
work products were correct and relevant when delivered, or whether
ongoing revisions were needed to gain acceptance by stakeholders.
Knowledge: assess whether the business analyst had the skills and/or
experience to perform the assigned task.
Effectiveness: assess whether the business analyst work products were
easy to use as standalone deliverables or whether they required extensive
explanation in order to be understood.
Organizational Support: assess whether there were adequate resources
available to complete business analysis activities as needed.
Significance: consider the benefit obtained from the work products and
assess whether the cost, time, and resource investments expended to
produce the work products were justified for the value they delivered.
Strategic: look at whether business objectives were met, problems were
solved, and improvements were achieved.
Timeliness: evaluate whether the business analyst delivered the work on
time per stakeholder expectations and schedule.
.3 Analyze Results
The business analysis process and deliverables are compared against the set of
defined measures. The analysis may be performed on the business analysis
process, the resources involved, and the deliverables.
Performance may be determined from the point of view of the stakeholders who
are the recipients of the business analysis work. Other times a personnel manager
or a Centre of Excellence may make this determination and provide assessments.
All stakeholders may have input in assessing the value of the business analysis
work but organizations may differ in terms of who has the authority to set the
targets against which performance is measured.
.4 Recommend Actions for Improvement
Once the analysis of performance results is complete, the business analyst
engages the appropriate stakeholders to identify the following actions:
Preventive: reduces the probability of an event with a negative impact.
Identify Business Analysis Performance Improvements Business Analysis Planning and Monitoring
50
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Corrective: establishes ways to reduce the negative impact of an event.
Improvement: establishes ways to increase the probability or impact of
events with a positive impact.
These actions are likely to result in changes to the business analysis approach,
repeatable processes, and tools.
3.5.5 Guidelines and Tools
• Organizational Performance Standards: may include performance metrics
or expectations for business analysis work mandated by the organization.
3.5.6 Techniques
Brainstorming: used to generate ideas for improvement opportunities.
Interviews: used to gather assessments of business analysis performance.
Item Tracking: used to track issues that occur during the performance of
business analysis for later resolution.
Lessons Learned: used to identify recommended changes to business analysis
processes, deliverables, templates, and other organizational process assets that
can be incorporated into the current initiative and future work.
Metrics and Key Performance Indicators (KPIs): used to determine what
metrics are appropriate for assessing business analysis performance and how
they may be tracked.
Observation: used to witness business analysis performance.
Process Analysis: used to analyze existing business analysis processes and
identify opportunities for improvement.
Process Modelling: used to define business analysis processes and understand
how to improve those processes to reduce problems from hand-offs, improve
cycle times, or alter how business analysis work is performed to support
improvements in downstream processes.
Reviews: used to identify changes to business analysis processes and
deliverables that can be incorporated into future work.
Risk Analysis and Management: used to identify and manage potential
conditions or events that may impact business analysis performance.
Root Cause Analysis: used to help identify the underlying cause of failures or
difficulties in accomplishing business analysis work.
Survey or Questionnaire: used to gather feedback from stakeholders about
their satisfaction with business analysis activities and deliverables.
Workshops: used to gather assessments of business analysis performance and
generate ideas for improvement opportunities.
Business Analysis Planning and Monitoring Identify Business Analysis Performance Improvements
51
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
3.5.7 Stakeholders
• Domain Subject Matter Experts: should be informed about the business
analysis activities in order to set expectations regarding their involvement in the
work and to elicit their feedback regarding possible improvements to the
approach.
• Project Manager: is accountable for the success of a project and must be kept
informed of the current status of business analysis work. If potential problems
or opportunities for improvement are identified, the project manager must be
consulted before changes are implemented to assess whether those changes
will have an impact on the project. They may also deliver reports on business
analysis performance to the sponsor and other stakeholders.
• Sponsor: may require reports on business analysis performance to address
problems as they are identified. A manager of business analysts may also
sponsor initiatives to improve the performance of business analysis activities.
3.5.8 Outputs
• Business Analysis Performance Assessment: includes a comparison of
planned versus actual performance, identifying the root cause of variances from
the expected performance, proposed approaches to address issues, and other
findings to help understand the performance of business analysis processes.
Identify Business Analysis Performance Improvements Business Analysis Planning and Monitoring
52
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
53
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4
Elicitation and Collaboration
The Elicitation and Collaboration knowledge area describes the tasks that
business analysts perform to obtain information from stakeholders and confirm
the results. It also describes the communication with stakeholders once the
business analysis information is assembled.
Elicitation is the drawing forth or receiving of information from stakeholders or
other sources. It is the main path to discovering requirements and design
information, and might involve talking with stakeholders directly, researching
topics, experimenting, or simply being handed information. Collaboration is the
act of two or more people working together towards a common goal. The
Elicitation and Collaboration knowledge area describes how business analysts
identify and reach agreement on the mutual understanding of all types of
business analysis information. Elicitation and collaboration work is never a 'phase'
in business analysis; rather, it is ongoing as long as business analysis work is
occurring.
Elicitation and collaboration can be planned, unplanned, or both. Planned
activities such as workshops, experiments, and/or surveys can be structured and
organized in advance. Unplanned activities happen in the moment without
notice, such as last-minute or 'just in time' collaboration or conversations.
Business analysis information derived from an unplanned activity may require
deeper exploration through a planned activity.
Eliciting business analysis information is not an isolated activity. Information is
elicited while performing any task that includes interaction with stakeholders and
while the business analyst is performing independent analytical work. Elicitation
may trigger additional elicitation for details to fill in gaps or increase
understanding.
Elicitation and Collaboration
54
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
The Elicitation and Collaboration knowledge area is composed of the following
tasks:
Prepare for Elicitation: involves ensuring that the stakeholders have the
information they need to provide and that they understand the nature of
the activities they are going to perform. It also sets a shared set of
expectations regarding the outcomes of the activity. Preparation may also
involve identifying research sources or preparing to conduct an experiment
to see if a process change actually results in an improvement.
Conduct Elicitation: describes the work performed to understand
stakeholder needs and identify potential solutions that may meet those
needs. This may involve direct interaction with stakeholders, doing research,
or running experiments.
Confirm Elicitation Results: involves ensuring that stakeholders have a
shared understanding of the outcomes of elicitation, that elicited
information is recorded appropriately, and that the business analyst has the
information sought from an elicitation activity. This task also involves
comparing the information received with other information to look for
inconsistencies or gaps.
Communicate Business Analysis Information: provides stakeholders
with the information they need, at the time they need it. The information is
presented in a useful form, using the right terminology and concepts.
Manage Stakeholder Collaboration: describes working with
stakeholders to engage them in the overall business analysis process and to
ensure that the business analyst can deliver the outcomes needed.
The Core Concept Model in Elicitation and
Collaboration
The Business Analysis Core Concept Model™ (BACCM™) describes the
relationships among the six core concepts.
The following table describes the usage and application of each of the core
concepts within the context of Elicitation and Collaboration.
Elicitation and Collaboration
55
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Table 4.0.1: The Core Concept Model in Elicitation and Collaboration
Core Concept During Elicitation and Collaboration,
business analysts...
Change: the act of transformation
in response to a need.
use a variety of elicitation techniques to
fully identify the characteristics of the
change including concerns that
stakeholders have about the change. The
change itself may determine the
appropriate types and extent of elicitation
and collaboration.
Need: a problem or opportunity to
be addressed.
elicit, confirm, and communicate needs
and supporting business analysis
information. As elicitation is iterative and
incremental, the understanding of needs
may evolve over time.
Solution: a specific way of
satisfying one or more needs in a
context.
elicit, confirm, and communicate
necessary or desired characteristics of
proposed solutions.
Stakeholder: a group or
individual with a relationship to
the change, the need, or the
solution.
manage the collaboration with the
stakeholders who participate in the
business analysis work. All stakeholders
may participate in different roles and at
different times during a change.
Value: the worth, importance, or
usefulness of something to a
stakeholder within a context.
collaborate with stakeholders to assess
the relative value of information provided
through elicitation, and apply a variety of
techniques to confirm and communicate
that value.
Context: the circumstances that
influence, are influenced by, and
provide understanding of the
change.
apply a variety of elicitation techniques to
identify business analysis information
about the context that may affect the
change.
Prepare for Elicitation Elicitation and Collaboration
56
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 4.0.1: Elicitation and Collaboration Input/Output Diagram
4.1 Prepare for Elicitation
4.1.1 Purpose
The purpose of Prepare for Elicitation is to understand the scope of the elicitation
activity, select appropriate techniques, and plan for (or procure) appropriate
supporting materials and resources.
Input
Tasks
4.3
Confirm Elicitation
Results
4.2
Conduct Elicitation
4.1
Prepare for
Elicitation
4.4
Communicate
Business Analysis
Information
4.5
Manage
Stakeholder
Collaboration
Needs
Business Analysis
Information
3.5
Business Analysis
Performance
Assessment
3.2
Stakeholder
Engagement
Approach
4.1
Elicitation Activity
Plan
4.2
Elicitation Results
(unconfirmed)
4.3
Elicitation Results
(confirmed)
4.5
Stakeholder
Engagement
4.4
Business Analysis
Information
(communicated)
Output
Elicitation and Collaboration Prepare for Elicitation
57
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.1.2 Description
Business analysts prepare for elicitation by defining the desired outcomes of the
activity, considering the stakeholders involved and the goals of the initiative. This
includes determining which work products will be produced using the elicitation
results, deciding which techniques are best suited to produce those results,
establishing the elicitation logistics, identifying any supporting materials needed,
and understanding circumstances to foster collaboration during an elicitation
activity.
4.1.3 Inputs
• Needs: guides the preparation in terms of the scope and purpose of elicitation
activities. Elicitation can be used to discover the needs, but in order to get
started there must be some need that exists—even if it has not yet been fully
elicited or understood.
• Stakeholder Engagement Approach: understanding stakeholders'
communication and collaboration needs helps plan and prepare appropriate
and effective elicitation events.
Figure 4.1.1: Prepare for Elicitation Input/Output Diagram
Tasks Using This Output
Output
4.1 Prepare for Elicitation
Business Analysis Approach
4.1
Elicitation
Activity Plan
4.2
Conduct Elicitation
3.2
Stakeholder
Engagement
Approach
Needs
Business Objectives
Existing Business Analysis
Information
Potential Value
4.3
Confirm Elicitation
Results
Guidelines and Tools
Input
Prepare for Elicitation Elicitation and Collaboration
58
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.1.4 Elements
.1 Understand the Scope of Elicitation
To determine the type of business analysis information to be discovered during
the elicitation activity and the techniques that may be used, business analysts
consider:
• business domain,
• overall corporate culture and environment,
• stakeholder locations,
• stakeholders who are involved and their group dynamics,
• expected outputs the elicitation activities will feed,
• skills of the business analysis practitioner,
• other elicitation activities planned to complement this one,
• strategy or solution approach,
• scope of future solution, and
• possible sources of the business analysis information that might feed into
the specific elicitation activity.
Understanding the scope of the elicitation activity allows business analysts to
respond if the activity strays from the intended scope. It also allows them to
recognize if people and materials are not available in time, and when the activity
is complete.
.2 Select Elicitation Techniques
In most cases, multiple techniques are used during an elicitation activity. The
techniques used depend on cost and time constraints, the types of business
analysis information sources and their access, the culture of the organization, and
the desired outcomes. The business analyst may also factor in the needs of the
stakeholders, their availability, and their location (co-located or dispersed).
Choosing the right techniques and ensuring each technique is performed
correctly is extremely important to the success of the elicitation activity. When
selecting elicitation techniques, business analysts consider:
• techniques commonly used in similar initiatives,
• techniques specifically suited to the situation, and
• the tasks needed to prepare, execute, and complete each technique.
Due to changing dynamics and situations, the business analyst may be required to
adjust the initial selections by incorporating more appropriate techniques. A
thorough understanding of the variety of techniques available assists the business
analyst in adapting to changing circumstances.
Elicitation and Collaboration Prepare for Elicitation
59
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.3 Set Up Logistics
Logistics are planned prior to an elicitation activity. The logistics for each
elicitation activity include identifying:
• the activity's goals,
• participants and their roles,
• scheduled resources, including people, rooms, and tools,
• locations,
• communication channels,
• techniques, and
• languages used by stakeholders (oral and written).
The logistics may also involve creating an agenda if other stakeholders are
involved.
.4 Secure Supporting Material
Business analysts identify sources of information that are needed to conduct the
elicitation activity. There might be a great deal of information needed to conduct
elicitation including people, systems, historical data, materials and documents.
Documents could include existing system documents, relevant business rules,
organizational polices, regulations, and contracts. Supporting materials might
also take the form of outputs of analysis work, such as draft versions of analysis
models (see Specify and Model Requirements (p. 136)). Business analysts procure
or develop the materials and tools needed. Additional planning for experimental
elicitation might be required if novel tools, equipment, or techniques are going to
be used.
.5 Prepare Stakeholders
Business analysts may need to educate stakeholders on how an elicitation
technique works or what information is needed. It may be helpful to explain an
elicitation technique to stakeholders not involved in the activity to help them
understand the validity and relevance of the information elicited. Stakeholders
may be unresponsive or challenging during an elicitation activity if they feel that it
is not aligned to their individual objectives, don't understand the purpose, or are
confused about the process. In preparing for elicitation, the business analyst
should ensure that there is buy-in from all necessary stakeholders.
Business analysts may also prepare stakeholders by requesting that they review
supporting materials prior to the elicitation activity in order to make it as effective
as possible. An agenda might be provided in advance to support stakeholders in
coming prepared to the activity with the necessary frame of mind and
information.
Eliciting through research or exploration may be a solo activity for the business
analyst and not require preparing other stakeholders.
Prepare for Elicitation Elicitation and Collaboration
60
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.1.5 Guidelines and Tools
• Business Analysis Approach: sets the general strategy to be used to guide
the business analysis work. This includes the 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.
• Business Objectives: describe the desired direction needed to achieve the
future state. They can be used to plan and prepare elicitation events, and to
develop supporting materials.
• Existing Business Analysis Information: may provide a better understanding
of the goals of the elicitation activity, and aid in preparing for elicitation.
• Potential Value: describes the value to be realized by implementing the
proposed future state, and can be used to shape elicitation events.
4.1.6 Techniques
Brainstorming: used to collaboratively identify and reach consensus about
which sources of business analysis information should be consulted and which
elicitation techniques might be most effective.
Data Mining: used to identify information or patterns that require further
investigation.
Document Analysis: used to identify and assess candidate sources of
supporting materials.
Estimation: used to estimate the time and effort required for the elicitation
and the associated cost.
Interviews: used to identify concerns about the planned elicitation, and can be
used to seek authority to proceed with specific options.
Mind Mapping: used to collaboratively identify and reach consensus about
which sources of business analysis information should be consulted and which
elicitation techniques might be most effective.
Risk Analysis and Management: used to identify, assess, and manage
conditions or situations that could disrupt the elicitation, or affect the quality
and validity of the elicitation results. The plans for the elicitation should be
adjusted to avoid, transfer, or mitigate the most serious risks.
Stakeholder List, Map, or Personas: used to determine who should be
consulted while preparing for the elicitation, who should participate in the
event, and the appropriate roles for each stakeholder.
4.1.7 Stakeholders
• Domain Subject Matter Expert: provides supporting materials as well as
guidance about which other sources of business analysis information to consult.
May also help to arrange research, experiments, and facilitated elicitation.
Elicitation and Collaboration Conduct Elicitation
61
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Project Manager: ensures that the appropriate people and resources are
available to conduct the elicitation.
• Sponsor: has the authority to approve or deny a planned elicitation event, and
to authorize and require the participation of specific stakeholders.
4.1.8 Outputs
• Elicitation Activity Plan: used for each elicitation activity. It includes logistics,
scope of the elicitation activity, selected techniques, and supporting materials.
4.2 Conduct Elicitation
4.2.1 Purpose
The purpose of Conduct Elicitation is to draw out, explore, and identify
information relevant to the change.
4.2.2 Description
There are three common types of elicitation:
Collaborative: involves direct interaction with stakeholders, and relies on
their experiences, expertise, and judgment.
Research: involves systematically discovering and studying information
from materials or sources that are not directly known by stakeholders
involved in the change. Stakeholders might still participate in the research.
Research can include data analysis of historical data to identify trends or
past results.
Experiments: involves identifying information that could not be known
without some sort of controlled test. Some information cannot be drawn
from people or documents—because it is unknown. Experiments can help
discover this kind of information. Experiments include observational studies,
proofs of concept, and prototypes.
One or more elicitation techniques may be used to produce the desired outcome
within the scope of elicitation.
Stakeholders may collaborate in elicitation by:
• participating and interacting during the elicitation activity, and
• researching, studying, and providing feedback on documents, systems,
models, and interfaces.
4.2.3 Inputs
• Elicitation Activity Plan: includes the planned elicitation activities and
techniques, activity logistics (for example, date, time, location, resources,
Conduct Elicitation Elicitation and Collaboration
62
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
agenda), scope of the elicitation activity, and available sources of background
information.
Figure 4.2.1: Conduct Elicitation Input/Output Diagram
4.2.4 Elements
.1 Guide Elicitation Activity
Understanding the proposed representations of business analysis information,
which were defined in planning, helps ensure that the elicitation activities are
focused on producing the intended information at the desired level of detail. This
applies to each instance of an elicitation activity throughout a change and may
vary based on the activity. In order to help guide and facilitate towards the
expected outcomes, business analysts consider:
• the elicitation activity goals and agenda,
• scope of the change,
• what forms of output the activity will generate,
• what other representations the activity results will support,
• how the output integrates into what is already known,
• who provides the information,
Tasks Using This Output
Output
4.2
Conduct Elicitation
Business Analysis Approach
4.2
Elicitation
Results
(unconfirmed)
4.3
Confirm Elicitation
Results
4.1
Elicitation Activity
Plan
Existing Business Analysis
Information
Stakeholder Engagement
Approach
Supporting Materials
Input
Guidelines and Tools
Elicitation and Collaboration Conduct Elicitation
63
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• who will use the information, and
• how the information will be used.
While most of these are considered when planning for the elicitation activity (see
Prepare for Elicitation (p. 56)), they are also all important while performing the
elicitation activity in order to keep it on track and achieve its goal. For example,
stakeholders might have discussions that are out of scope for the activity or
change, and the business analyst needs to recognize that in the moment to
determine the next step; either acknowledge it and continue, or guide the
conversation differently.
The business analyst also uses this information to determine when there has been
sufficient elicitation, in order to stop the activity.
.2 Capture Elicitation Outcomes
Conducting elicitation is frequently iterative and takes place in a series of
sessions—in parallel or in sequence—according to the scope of the elicitation
activity (see Prepare for Elicitation (p. 56)). If the elicitation activity is unplanned,
outcomes are captured and integrated into the appropriate planned outcomes.
Capturing the elicitation outcomes helps to ensure that the information produced
during elicitation activities is recorded for later reference and use.
4.2.5 Guidelines and Tools
• Business Analysis Approach: influences how each elicitation activity is
performed, as it identifies the types of outputs that will be needed based on the
approach.
• Existing Business Analysis Information: may guide the questions posed
during elicitation and the approach used to draw out information from various
stakeholders.
• Stakeholder Engagement Approach: provides collaboration and
communication approaches that might be effective during elicitation.
• Supporting Materials: 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.
4.2.6 Techniques
Benchmarking and Market Analysis: used as a source of business analysis
information by comparing a specific process, system, product, service, or
structure with some external baseline, such as a similar organization or baseline
provided by an industry association. Market analysis is used to determine what
customers want and what competitors provide.
Brainstorming: used to generate many ideas from a group of stakeholders in a
short period, and to organize and prioritize those ideas.
Conduct Elicitation Elicitation and Collaboration
64
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Business Rules Analysis: used to identify the rules that govern decisions in an
organization and that define, constrain, or enable organizational operations.
Collaborative Games: used to develop a better understanding of a problem or
to stimulate creative solutions.
Concept Modelling: used to identify key terms and ideas of importance and
define the relationships between them.
Data Mining: used to identify relevant information and patterns.
Data Modelling: used to understand entity relationships during elicitation.
Document Analysis: used to review existing systems, contracts, business
procedures and policies, standards, and regulations.
Focus Groups: used to identify and understand ideas and attitudes from a
group.
Interface Analysis: used to understand the interaction, and characteristics of
that interaction, between two entities, such as two systems, two organizations,
or two people or roles.
Interviews: used to ask questions of stakeholders to uncover needs, identify
problems, or discover opportunities.
Mind Mapping: used to generate many ideas from a group of stakeholders in
a short period, and to organize and prioritize those ideas.
Observation: used to gain insight about how work is currently done, possibly
in different locations and in different circumstances.
Process Analysis: used to understand current processes and to identify
opportunities for improvement in those processes.
Process Modelling: used to elicit processes with stakeholders during elicitation
activities.
Prototyping: used to elicit and validate stakeholders' needs through an
iterative process that creates a model of requirements or designs.
Survey or Questionnaire: used to elicit business analysis information,
including information about customers, products, work practices, and attitudes,
from a group of people in a structured way and in a relatively short period of
time.
Workshops: used to elicit business analysis information, including information
about customers, products, work practices, and attitudes, from a group of
people in a collaborative, facilitated way.
4.2.7 Stakeholders
• Customer: will provide valuable business analysis information during
elicitation.
• Domain Subject Matter Expert: has expertise in some aspect of the situation
and can provide the required business analysis information. Often guides and
Elicitation and Collaboration Confirm Elicitation Results
65
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
assists the business analyst in identifying appropriate research sources, and may
help to arrange research, experiments, and facilitated elicitation.
• End User: the user of existing and future solutions, who should participate in
elicitation.
• Implementation Subject Matter Expert: designs and implements a solution
and provides specialist expertise, and can participate in elicitation by asking
clarifying questions and offering alternatives.
• Sponsor: authorizes and ensures that the stakeholders necessary to participate
in elicitation are involved.
• Any stakeholders: could have relevant knowledge or experience to participate
in elicitation activities.
4.2.8 Outputs
• Elicitation Results (unconfirmed): captured information in a format that is
specific to the elicitation activity.
4.3 Confirm Elicitation Results
4.3.1 Purpose
The purpose of Confirm Elicitation Results is to check the information gathered
during an elicitation session for accuracy and consistency with other information.
4.3.2 Description
Elicited information is confirmed to identify any problems and resolve them
before resources are committed to using the information. This review may
discover errors, omissions, conflicts, and ambiguity.
The elicitation results can be compared against their source and other elicitation
results to ensure consistency. Collaboration with stakeholders might be necessary
to ensure their inputs are correctly captured and that they agree with the results
of non-facilitated elicitation. If information is not correct, the business analyst
determines what is correct, which can require more elicitation. Committing
resources to business analysis activities based on unconfirmed elicitation results
may mean stakeholder expectations are not met. If the results are inconsistent,
additional elicitation might need to be conducted to resolve the discrepancies.
Confirming the elicitation results is a much less rigorous and formal review than
occurs during analysis.
4.3.3 Inputs
• Elicitation Results (unconfirmed): capture information in a format specific to
the elicitation activity.
Confirm Elicitation Results Elicitation and Collaboration
66
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 4.3.1: Confirm Elicitation Results
4.3.4 Elements
.1 Compare Elicitation Results Against Source Information
Task Conduct Elicitation (p. 61) describes sources from which elicitation results
may be derived, including documents and stakeholder knowledge. The business
analyst may lead follow-up meetings where stakeholders correct the elicitation
results. Stakeholders may also confirm the elicitation results independently.
.2 Compare Elicitation Results Against Other Elicitation Results
Business analysts compare results collected through multiple elicitation activities
to confirm that the information is consistent and accurately represented. As
comparisons are drawn, business analysts identify variations in results and resolve
them in collaboration with stakeholders. Comparisons may also be made with
historical data to confirm more recent elicitation results.
Inconsistencies in elicitation results are often uncovered when business analysts
develop specifications and models. These models may be developed during an
elicitation activity to improve collaboration.
Tasks Using This Output
Output
4.3
Confirm Elicitation Results
Elicitation Activity Plan
4.3
Elicitation Results
(confirmed)
6.1
Analyze Current
State
4.2
Elicitation Results
(unconfirmed)
Existing Business Analysis
Information
6.3
Assess Risks
Guidelines and Tools
Input
Elicitation and Collaboration Communicate Business Analysis Information
67
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.3.5 Guidelines and Tools
• Elicitation Activity Plan: used to guide which alternative sources and which
elicitation results are to be compared.
• Existing Business Analysis Information: can be used to confirm the results
of elicitation activities or to develop additional questions to draw out more
detailed information.
4.3.6 Techniques
Document Analysis: used to confirm elicitation results against source
information or other existing documents.
Interviews: used to confirm the business analysis information and to confirm
that the integration of that information is correct.
Reviews: used to confirm a set of elicitation results. Such reviews could be
informal or formal depending on the risks of not having correct, useful, and
relevant information.
Workshops: used to conduct reviews of the drafted elicitation results using any
level of formality. A predetermined agenda, scripts, or scenario tests may be
used to walk through the elicitation results, and feedback is requested from the
participants and recorded.
4.3.7 Stakeholders
• Domain Subject Matter Experts: people with substantial knowledge,
experience, or expertise about the business analysis information being elicited,
or about the change or the solution, help to confirm that elicitation results are
correct, and can help to identify omissions, inconsistencies and conflicts in
elicitation results. They can also confirm that the right business analysis
information has been elicited.
• Any stakeholder: all types of stakeholders may need to participate in
confirming elicitation results.
4.3.8 Outputs
• Elicitation Results (confirmed): integrated output that the business analyst
and other stakeholders agree correctly reflects captured information and
confirms that it is relevant and useful as an input to further work.
4.4 Communicate Business Analysis Information
4.4.1 Purpose
The purpose of Communicate Business Analysis Information is to ensure
stakeholders have a shared understanding of business analysis information.
Communicate Business Analysis Information Elicitation and Collaboration
68
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.4.2 Description
Business analysts must communicate appropriate information to stakeholders at
the right time and in formats that meet their needs. Consideration is given to
expressing the information in language, tone, and style that is appropriate to the
audience.
Communication of business analysis information is bi-directional and iterative. It
involves determining the recipients, content, purpose, context, and expected
outcomes. Task Plan Stakeholder Engagement (p. 31) evaluates communication
needs and plans anticipated messages.
Communicating information does not simply involve pushing information out and
assuming it was received and understood. Business analysts engage stakeholders
to ensure they understand the information and gain agreement. The business
analyst acts on any disagreements. The method of delivering the information may
need to change if the stakeholders are not receiving or understanding it. Multiple
forms of communication might be required for the same information.
4.4.3 Inputs
• Business Analysis Information: any kind of information at any level of detail
that is used as an input or output of business analysis work. Business analysis
information becomes an input for this task when the need is discovered to
communicate the information to additional stakeholders.
• Stakeholder Engagement Approach: describes stakeholder groups, roles,
and general needs regarding communication of business analysis information.
Figure 4.4.1: Communicate Business Analysis Information Input/Output Diagram
Output
4.4
Communicate Business Analysis
Information
Business Analysis Approach
4.4
Business Analysis
Information
(communicated)
3.2
Stakeholder
Engagement
Approach
Business Analysis
Information
Information Management
Approach
Guidelines and Tools
Input
Elicitation and Collaboration Communicate Business Analysis Information
69
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.4.4 Elements
.1 Determine Objectives and Format of Communication
Business analysis information packages may be prepared for a number of reasons
including—but not limited to—the following:
• communication of requirements and designs to stakeholders,
• early assessment of quality and planning,
• evaluation of possible alternatives,
• formal reviews and approvals,
• inputs to solution design,
• conformance to contractual and regulatory obligations, and
• maintenance for reuse.
The primary goal of developing a package is to convey information clearly and in
usable format for continuing change activities. To help decide how to present
requirements, business analysts ask the following types of questions:
• Who is the audience of the package?
• What will each type of stakeholder understand and need from the
communication?
• What is each stakeholder’s preferred style of communication or learning?
• What information is important to communicate?
• Are the presentation and format of the package, and the information
contained in the package, appropriate for the type of audience?
• How does the package support other activities?
• Are there any regulatory or contractual constraints to conform to?
Possible forms for packages may include:
Formal Documentation: is usually based on a template used by the
organization and may include text, matrices, or diagrams. It provides a
stable, easy to use, long-term record of the information.
Informal Documentation: may include text, diagrams, or matrices that
are used during a change but are not part of a formal organizational
process.
Presentations: deliver a high-level overview appropriate for understanding
goals of a change, functions of a solution, or information to support
decision making.
Consideration is given to the best way to combine and present the materials to
convey a cohesive and effective message to one or more stakeholder groups.
Packages can be stored in different online or offline repositories, including
documents or tools.
Communicate Business Analysis Information Elicitation and Collaboration
70
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.2 Communicate Business Analysis Package
The purpose of communicating the business analysis package is to provide
stakeholders with the appropriate level of detail about the change so they can
understand the information it contains. Stakeholders are given the opportunity to
review the package, ask questions about the information, and raise any concerns
they may have.
Selecting the appropriate communication platform is also important. Common
communication platforms include:
Group collaboration: used to communicate the package to a group of
relevant stakeholders at the same time. It allows immediate discussion
about the information and related issues.
Individual collaboration: used to communicate the package to a single
stakeholder at a time. It can be used to gain individual understanding of the
information when a group setting is not feasible, most productive, or going
to yield the best results.
E-mail or other non-verbal methods: used to communicate the package
when there is a high maturity level of information that will need little or no
verbal explanation to support it.
4.4.5 Guidelines and Tools
• Business Analysis Approach: describes how the various types of information
will be disseminated rather than what will be disseminated. It 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.
• Information Management Approach: helps determine how business analysis
information will be packaged and communicated to stakeholders.
4.4.6 Techniques
Interviews: used to individually communicate information to stakeholders.
Reviews: used to provide stakeholders with an opportunity to express
feedback, request required adjustments, understand required responses and
actions, and agree or provide approvals. Reviews can be used during group or
individual collaboration.
Workshops: used to provide stakeholders with an opportunity to express
feedback and to understand required adjustments, responses, and actions. They
are also useful for gaining consensus and providing approvals. Typically used
during group collaboration.
4.4.7 Stakeholders
• End User: needs to be communicated with frequently so they are aware of
relevant business analysis information.
• Customer: needs to be communicated with frequently so they are aware of
relevant business analysis information.
Elicitation and Collaboration Manage Stakeholder Collaboration
71
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Domain Subject Matter Expert: needs to understand the business analysis
information as part of confirming and validating it throughout the change
initiative.
• Implementation Subject Matter Expert: needs to be aware of and
understand the business analysis information, particularly requirements and
designs, for implementation purposes.
• Tester: needs to be aware of and understand the business analysis information,
particularly requirements and designs for testing purposes.
• Any stakeholder: all types of stakeholders will likely need to be
communicated with at some point during the change initiative.
4.4.8 Outputs
• Business Analysis Information (communicated): business analysis
information is considered communicated when the target stakeholders have
reached an understanding of its content and implications.
4.5 Manage Stakeholder Collaboration
4.5.1 Purpose
The purpose of Manage Stakeholder Collaboration is to encourage stakeholders
to work towards a common goal.
4.5.2 Description
Business analysis work lends itself to many collaboration opportunities between
groups of stakeholders on the business analysis work products. Stakeholders hold
various degrees of influence and authority over the approval of work products,
and are also an important source of needs, constraints, and assumptions. As the
business analysis work progresses, the business analyst identifies stakeholders,
confirms their roles, and communicates with them to ensure that the right
stakeholders participate at the right times and in the appropriate roles.
Managing stakeholder collaboration is an ongoing activity. Although managing
stakeholder collaboration begins once stakeholders have been identified and
analyzed, new stakeholders may be identified at any point during an initiative. As
new stakeholders are identified, their role, influence, and relationship to the
initiative are analyzed. Each stakeholder's role, responsibility, influence, attitude,
and authority may change over time.
The more significant the impact of the change or its visibility within the
organization, the more attention is directed to managing stakeholder
collaboration. Business analysts manage stakeholder collaboration to capitalize
on positive reactions, and mitigate or avoid negative reactions. The business
analyst should constantly monitor and assess each stakeholder’s attitude to
determine if it might affect their involvement in the business analysis activities.
Manage Stakeholder Collaboration Elicitation and Collaboration
72
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Poor relationships with stakeholders can have many detrimental effects on
business analysis, including:
• failure to provide quality information,
• strong negative reactions to setbacks and obstacles,
• resistance to change,
• lack of support for, and participation in, business analysis work, and
• business analysis information being ignored.
These effects can be modified in part through strong, positive, and trust-based
relationships with stakeholders. Business analysts actively manage relationships
with stakeholders who:
provide services to the business analyst, including inputs to business analysis
tasks and other support activities,
• depend on services provided by the business analyst, including outputs of
business analysis tasks, and
• participate in the execution of business analysis tasks.
4.5.3 Inputs
• Stakeholder Engagement Approach: describes the types of expected
engagement with stakeholders and how they might need to be managed.
• Business Analysis Performance Assessment: provides key information
about the effectiveness of business analysis tasks being executed, including
those focused on stakeholder engagement.
Figure 4.5.1: Manage Stakeholder Collaboration Input/Output Diagram
Output
4.5
Manage Stakeholder
Collaboration
Business Analysis Approach
4.5
Stakeholder
Engagement
3.5 Business
Analysis
Performance
Assessment
3.2
Stakeholder
Engagement
Approach
Business Objectives
Future State Description
Recommended Actions
Risk Analysis Results
Guidelines and Tools
Input
Elicitation and Collaboration Manage Stakeholder Collaboration
73
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.5.4 Elements
.1 Gain Agreement on Commitments
Stakeholders participate in business analysis activities that may require time and
resource commitments. The business analyst and stakeholders identify and agree
upon these commitments as early in the initiative as possible. The specific details
of the commitments can be communicated formally or informally, as long as there
is explicit understanding of the expectations and desired outcomes of the
commitment.
There may be dialogue and negotiation regarding the terms and conditions of the
commitments. Effective negotiation, communication, and conflict resolution skills
are important to effective stakeholder management (see Negotiation and Conflict
Resolution (p. 210)).
.2 Monitor Stakeholder Engagement
Business analysts monitor the participation and performance of stakeholders to
ensure that:
• the right subject matter experts (SMEs) and other stakeholders are
participating effectively,
• stakeholder attitudes and interest are staying constant or improving,
• elicitation results are confirmed in a timely manner, and
• agreements and commitments are maintained.
Business analysts continually monitor for such risks as:
• stakeholders being diverted to other work,
• elicitation activities not providing the quality of business analysis
information required, and
• delayed approvals.
.3 Collaboration
Stakeholders are more likely to support change if business analysts collaborate
with them and encourage the free flow of information, ideas, and innovations.
Genuine stakeholder engagement requires that all stakeholders involved feel that
they are heard, their opinions matter, and their contributions are recognized.
Collaboration involves regular, frequent, and bi-directional communication.
Collaborative relationships help maintain the free flow of information when
obstacles and setbacks occur, and promote a shared effort to resolve problems
and achieve desired outcomes.
Manage Stakeholder Collaboration Elicitation and Collaboration
74
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
4.5.5 Guidelines and Tools
• Business Analysis Approach: describes the nature and level of collaboration
required from each stakeholder group to perform planned business analysis
activities.
• Business Objectives: describe the desired direction needed to achieve the
future state. They can be used to focus diverse stakeholders on a common
vision of the desired business outcomes.
• Future State Description: defines the desired future state and the expected
value it delivers which can be used to focus diverse stakeholders on the
common goal.
• Recommended Actions: communicating what should be done to improve the
value of a solution can help to galvanize support and focus stakeholders on a
common goal.
• Risk Analysis Results: stakeholder-related risks will need to be addressed to
ensure stakeholder collaboration activities are successful.
4.5.6 Techniques
Collaborative Games: used to stimulate teamwork and collaboration by
temporarily immersing participants in a safe and fun situation in which they can
share their knowledge and experience on a given topic, identify hidden
assumptions, and explore that knowledge in ways that may not occur during
the course of normal interactions.
Lessons Learned: used to understand stakeholders' satisfaction or
dissatisfaction, and offer them an opportunity to help improve the working
relationships.
Risk Analysis and Management: used to identify and manage risks as they
relate to stakeholder involvement, participation, and engagement.
Stakeholder List, Map, or Personas: used to determine who is available to
participate in the business analysis work, show the informal relationships
between stakeholders, and understand which stakeholders should be consulted
about different kinds of business analysis information.
4.5.7 Stakeholders
• All stakeholders: all types of stakeholders who might be involved in
collaboration during change.
4.5.8 Outputs
• Stakeholder Engagement: willingness from stakeholders to engage in
business analysis activities and interact with the business analyst when
necessary.
75
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5
Requirements Life Cycle Management
The Requirements Life Cycle Management knowledge area describes the tasks
that business analysts perform in order to manage and maintain requirements
and design information from inception to retirement. These tasks describe
establishing meaningful relationships between related requirements and designs,
assessing changes to requirements and designs when changes are proposed, and
analyzing and gaining consensus on changes.
The purpose of requirements life cycle management is to ensure that business,
stakeholder, and solution requirements and designs are aligned to one another
and that the solution implements them. It involves a level of control over
requirements and over how requirements will be implemented in the actual
solution to be constructed and delivered. It also helps to ensure that business
analysis information is available for future use.
The requirements life cycle:
• begins with the representation of a business need as a requirement,
• continues through the development of a solution, and
• ends when a solution and the requirements that represent it are retired.
The management of requirements does not end once a solution is implemented.
Throughout the life of a solution, requirements continue to provide value when
they are managed appropriately.
Within the Requirements Life Cycle Management knowledge area, the concept of
a life cycle is separate from a methodology or process used to govern business
analysis work. Life cycle refers to the existence of various phases or states that
requirements pass through as part of any change. Requirements may be in
multiple states at one time.
Requirements Life Cycle Management
76
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
The states listed
here are not
intended to be a
comprehensive
listing.
Figure 5.0.1: Requirements Life Cycle Management
The Requirements Life Cycle Management knowledge area includes the following
tasks:
Trace Requirements: analyzes and maintains the relationships between
requirements, designs, solution components, and other work products for
impact analysis, coverage, and allocation.
Maintain Requirements: ensures that requirements and designs are
accurate and current throughout the life cycle and facilitates reuse where
appropriate.
Prioritize Requirements: assesses the value, urgency, and risks associated
with particular requirements and designs to ensure that analysis and/or
delivery work is done on the most important ones at any given time.
Assess Requirements Changes: evaluates new and changing stakeholder
requirements to determine if they need to be acted on within the scope of a
change.
Approve Requirements: works with stakeholders involved in the
governance process to reach approval and agreement on requirements and
designs.
The Core Concept Model in Requirements Life Cycle
Management
The Business Analysis Core Concept Model™ (BACCM™) describes the
relationships among the six core concepts.
The following table describes the usage and application of each of the core
concepts within the context of Requirements Life Cycle Management.
Assess
Approval/
Consensus
Potential
Requirement
Yes
No
Yes
No
Trace
Maintain
Prioritize
Manage
Bring Forward
Requirements Life Cycle Management
77
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Table 5.0.1: The Core Concept Model in Requirements Life Cycle Management
Core Concept During Requirements Life Cycle
Management, business analysts...
Change: the act of transformation
in response to a need.
manage how proposed changes to
requirements and designs are evaluated
during an initiative.
Need: a problem or opportunity to
be addressed.
trace, prioritize and maintain
requirements to ensure that the need is
met.
Solution: a specific way of
satisfying one or more needs in a
context.
trace requirements and designs to
solution components to ensure that the
solution satisfies the need.
Stakeholder: a group or
individual with a relationship to
the change, the need, or the
solution.
work closely with key stakeholders to
maintain understanding, agreement, and
approval of requirements and designs.
Value: the worth, importance, or
usefulness of something to a
stakeholder within a context.
maintain requirements for reuse to extend
value beyond the current initiative.
Context: the circumstances that
influence, are influenced by, and
provide understanding of the
change.
analyze the context to support tracing
and prioritization activities.
Requirements Life Cycle Management
78
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 5.0.2: Requirements Life Cycle Management Input/Output Diagram
Tasks
Output
5.3
Prioritize
Requirements
5.2
Maintain
Requirements
5.1
Trace
Requirements
5.4
Assess
Requirements
Changes
5.5
Approve
Requirements
Requirements Designs Proposed Change
7.2
Requirements
(verified)
5.1
Requirements (traced)
5.1
Designs (traced)
5.2
Requirements
(maintained)
5.3
Requirements
(prioritized)
5.2
Designs (maintained)
5.3
Designs (prioritized)
5.4
Designs Change
Assessment
5.4
Requirements Change
Assessment
5.5
Requirements
(approved)
5.5
Designs (approved)
Input
Requirements Life Cycle Management Trace Requirements
79
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5.1 Trace Requirements
5.1.1 Purpose
The purpose of Trace Requirements is to ensure that requirements and designs at
different levels are aligned to one another, and to manage the effects of change
to one level on related requirements.
5.1.2 Description
Requirements traceability identifies and documents the lineage of each
requirement, including its backward traceability, its forward traceability, and its
relationship to other requirements. Traceability is used to help ensure that the
solution conforms to requirements and to assist in scope, change, risk, time, cost,
and communication management. It is also used to detect missing functionality
or to identify if there is implemented functionality that is not supported by any
requirement.
Traceability enables:
• faster and simpler impact analysis,
• more reliable discovery of inconsistencies and gaps in requirements,
• deeper insights into the scope and complexity of a change, and
• reliable assessment of which requirements have been addressed and which
have not.
For more
information on
allocation, see
Define
Requirements
Architecture
(p. 148).
It is often difficult to accurately represent needs and solutions without taking into
account the relationships that exist between them. While traceability is valuable,
the business analyst balances the number of relationship types with the benefit
gained by representing them. Traceability also supports both requirements
allocation and release planning by providing a direct line of sight from
requirement to expressed need.
The following images show examples of visual representations of traceability for a
process and for software requirements.
Trace Requirements Requirements Life Cycle Management
80
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 5.1.1: Process Traceability
Figure 5.1.2: Software Requirements Traceability
5.1.3 Inputs
• Requirements: may be traced to other requirements (including goals,
objectives, business requirements, stakeholder requirements, solution
requirements, and transition requirements), solution components, visuals,
business rules, and other work products.
• Designs: may be traced to other requirements, solution components, and other
work products.
Value Chain
Business
Process
Sub-process
Activity
Task
Business Needs
Business
Requirements
Stakeholder
Requirements
Design
Code
Test
Solution
Requirements
Requirements Life Cycle Management Trace Requirements
81
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 5.1.3: Trace Requirements Input/Output Diagram
5.1.4 Elements
.1 Level of Formality
When tracing requirements, business analysts consider the value that each link is
supposed to deliver, as well as the nature and use of the specific relationships that
are being created.
The effort to trace requirements grows significantly when the number of
requirements or level of formality increases.
.2 Relationships
There are several types of relationships that the business analyst considers when
defining the traceability approach:
Derive: relationship between two requirements, used when a requirement
is derived from another requirement. This type of relationship is appropriate
to link the requirements on different levels of abstraction. For example, a
solution requirement derived from a business or a stakeholder requirement.
Output
5.1
Trace Requirements
Domain Knowledge
DesignsRequirements
Information Management
Approach
Legal/Regulatory
Information
Requirements Management
Tools/Repository
Tasks Using This Output
5.1
Requirements
(traced)
5.1
Designs
(traced)
7.5
Define Design
Options
Input
Guidelines and Tools
Trace Requirements Requirements Life Cycle Management
82
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Depends: relationship between two requirements, used when a
requirement depends on another requirement. Types of dependency
relationships include:
Necessity: when it only makes sense to implement a particular
requirement if a related requirement is also implemented.
Effort: when a requirement is easier to implement if a related
requirement is also implemented.
Satisfy: relationship between an implementation element and the
requirements it is satisfying. For example, the relationship between a
functional requirement and a solution component that is implementing it.
Validate: relationship between a requirement and a test case or other
element that can determine whether a solution fulfills the requirement.
.3 Traceability Repository
Requirements traceability is documented and maintained in accordance with the
methods identified by the business analysis approach. Requirements
management tools can provide significant benefits when there is a need to trace
a large number of requirements that may be deemed unmanageable with manual
approaches.
5.1.5 Guidelines and Tools
• Domain Knowledge: knowledge of and expertise in the business domain
needed to support traceability.
• Information Management Approach: provides decisions from planning
activities concerning the traceability approach.
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed. These may need to be considered when defining traceability
rules.
• Requirements Management Tools/Repository: 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.
5.1.6 Techniques
Business Rules Analysis: used to trace business rules to requirements that
they support, or rules that support requirements.
Functional Decomposition: used to break down solution scope into smaller
components for allocation, as well as to trace high-level concepts to low-level
concepts.
Process Modelling: used to visually show the future state process, as well as
tracing requirements to the future state process.
Scope Modelling: used to visually depict scope, as well as trace requirements
to the area of scope the requirement supports.
Requirements Life Cycle Management Maintain Requirements
83
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5.1.7 Stakeholders
• Customers: are affected by how and when requirements are implemented, and
may have to be consulted about, or agree to, the traceability relationships.
• Domain Subject Matter Expert: may have recommendations regarding the
set of requirements to be linked to a solution component or to a release.
• End User: may require specific dependency relationships that allow certain
requirements to be implemented at the same time or in a specific sequence.
• Implementation Subject Matter Expert: traceability ensures that the
solution being developed meets the business need and brings awareness of
dependencies between solution components during implementation.
• Operational Support: traceability documentation provides another reference
source for help desk support.
• Project Manager: traceability supports project change and scope
management.
• Sponsor: is required to approve the various relationships.
• Suppliers: are affected by how and when requirements are implemented.
• Tester: needs to understand how and where requirements are implemented
when creating test plans and test cases, and may trace test cases to
requirements.
5.1.8 Outputs
• Requirements (traced): have clearly defined relationships to other
requirements, solution components, or releases, phases, or iterations, within a
solution scope, such that coverage and the effects of change are clearly
identifiable.
• Designs (traced): clearly defined relationships to other requirements, solution
components, or releases, phases, or iterations, within a solution scope, such
that coverage and the effects of change are clearly identifiable.
5.2 Maintain Requirements
5.2.1 Purpose
The purpose of Maintain Requirements is to retain requirement accuracy and
consistency throughout and beyond the change during the entire requirements
life cycle, and to support reuse of requirements in other solutions.
5.2.2 Description
A requirement that represents an ongoing need must be maintained to ensure
that it remains valid over time.
Maintain Requirements Requirements Life Cycle Management
84
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
In order to maximize the benefits of maintaining and reusing requirements, the
requirements should be:
• consistently represented,
• reviewed and approved for maintenance using a standardized process that
defines proper access rights and ensures quality, and
• easily accessible and understandable.
5.2.3 Inputs
• Requirements: include goals, objectives, business requirements, stakeholder
requirements, solution requirements, and transition requirements. These should
be maintained throughout their life cycle.
• Designs: can be maintained throughout their life cycle, as needed.
Figure 5.2.1: Maintain Requirements Input/Output Diagram
5.2.4 Elements
.1 Maintain Requirements
Requirements are maintained so that they remain correct and current after an
approved change. Business analysts are responsible for conducting maintenance
to ensure this level of accuracy is retained. For requirements to be properly
maintained they must be clearly named and defined, and easily available to
stakeholders.
Business analysts also maintain the relationships among requirements, sets of
requirements, and associated business analysis information to ensure the context
and original intent of the requirement is preserved. Repositories with accepted
Output
Input
5.2
Maintain Requirements
Information Management
Approach
5.2
Requirements
(maintained)
DesignsRequirements
5.2
Designs
(maintained)
Guidelines and Tools
Requirements Life Cycle Management Maintain Requirements
85
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
taxonomies assist in establishing and maintaining links between maintained
requirements, and facilitate requirements and designs traceability.
.2 Maintain Attributes
While eliciting requirements, business analysts elicit requirement attributes.
Information such as the requirement’s source, priority, and complexity aid in
managing each requirement throughout the life cycle. Some attributes change as
the business analyst uncovers more information and conducts further analysis. An
attribute may change even though the requirement does not.
.3 Reusing Requirements
There are situations in which requirements can be reused.
Requirements that are candidates for long-term use by the organization are
identified, clearly named, defined, and stored in a manner that makes them easily
retrievable by other stakeholders. Depending on the level of abstraction and
intended need being addressed, requirements can be reused:
• within the current initiative,
• within similar initiatives,
• within similar departments, and
• throughout the entire organization.
Requirements at high levels of abstraction may be written with limited reference
to specific solutions. Requirements that are represented in a general manner,
without direct ties to a particular tool or organizational structure, tend to be more
reusable. These requirements are also less subject to revision during a change. As
requirements are expressed in more detail, they become more tightly associated
with a specific solution or solution option. Specific references to applications or
departments limit the reuse of requirements and designs across an organization.
Requirements that are intended for reuse reflect the current state of the
organization. Stakeholders validate the proposed requirements for reuse before
they can be accepted into a change.
5.2.5 Guidelines and Tools
• Information Management Approach: indicates how requirements will be
managed for reuse.
5.2.6 Techniques
Business Rules Analysis: used to identify business rules that may be similar
across the enterprise in order to facilitate reuse.
Data Flow Diagrams: used to identify information flow that may be similar
across the enterprise in order to facilitate reuse.
Data Modelling: used to identify data structure that may be similar across the
enterprise in order to facilitate reuse.
Prioritize Requirements Requirements Life Cycle Management
86
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Document Analysis: used to analyze existing documentation about an
enterprise that can serve as the basis for maintaining and reusing requirements.
Functional Decomposition: used to identify requirements associated with the
components and available for reuse.
Process Modelling: used to identify requirements associated with the
processes that may be available for reuse.
Use Cases and Scenarios: used to identify a solution component that may be
utilized by more than one solution.
User Stories: used to identify requirements associated with the story that may
be available for reuse.
5.2.7 Stakeholders
• Domain Subject Matter Expert: references maintained requirements on a
regular basis to ensure they are accurately reflecting stated needs.
• Implementation Subject Matter Expert: utilizes maintained requirements
when developing regression tests and conducting impact analysis for an
enhancement.
• Operational Support: maintained requirements are likely to be referenced to
confirm the current state.
• Regulator: maintained requirements are likely to be referenced to confirm
compliance to standards.
• Tester: maintained requirements are used by testers to aid in test plan and test
case creation.
5.2.8 Outputs
• Requirements (maintained): defined once and available for long-term usage
by the organization. They may become organizational process assets or be used
in future initiatives. In some cases, a requirement that was not approved or
implemented may be maintained for a possible future initiative.
• Designs (maintained): may be reusable once defined. For example, as a self-
contained component that can be made available for possible future use.
5.3 Prioritize Requirements
5.3.1 Purpose
The purpose of Prioritize Requirements is to rank requirements in the order of
relative importance.
Requirements Life Cycle Management Prioritize Requirements
87
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5.3.2 Description
Prioritization is the act of ranking requirements to determine their relative
importance to stakeholders. When a requirement is prioritized, it is given greater
or lesser priority. Priority can refer to the relative value of a requirement, or to the
sequence in which it will be implemented. Prioritization is an ongoing process,
with priorities changing as the context changes.
Inter-dependencies between requirements are identified and may be used as the
basis for prioritization. Prioritization is a critical exercise that seeks to ensure the
maximum value is achieved.
5.3.3 Inputs
• Requirements: any requirements in the form of text, matrices, or diagrams
that are ready to prioritize.
• Designs: any designs in the form of text, prototypes, or diagrams that are ready
to prioritize.
Figure 5.3.1: Prioritize Requirements Input/Output Diagram
Output
Input
Tasks Using This Output
5.3
Prioritize Requirements
Business Constraints
5.3
Requirements
(prioritized)
DesignsRequirements
Change Strategy
Domain Knowledge
Governance Approach
5.3
Designs
(prioritized)
Requirements Architecture
6.3
Assess Risks
Requirements Management
Tools/Repository
Solution Scope
Guidelines and Tools
Prioritize Requirements Requirements Life Cycle Management
88
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5.3.4 Elements
.1 Basis for Prioritization
The basis on which requirements are prioritized is agreed upon by relevant
stakeholders as defined in the Business Analysis Planning and Monitoring
knowledge area.
Typical factors that influence prioritization include:
Benefit: the advantage that accrues to stakeholders as a result of
requirement implementation, as measured against the goals and objectives
for the change. The benefit provided can refer to a specific functionality,
desired quality, or strategic goal or business objective. If there are multiple
stakeholders, each group may perceive benefits differently. Conflict
resolution and negotiation may be employed to come to consensus on
overall benefit.
Penalty: the consequences that result from not implementing a given
requirement. This includes prioritizing requirements in order to meet
regulatory or policy demands imposed on the organization, which may take
precedence over other stakeholder interests. Penalty may also refer to the
negative consequence of not implementing a requirement that improves
the experience of a customer.
Cost: the effort and resources needed to implement the requirement.
Information about cost typically comes from the implementation team or
the vendor. Customers may change the priority of a requirement after
learning the cost. Cost is often used in conjunction with other criteria, such
as cost-benefit analysis.
Risk: the chance that the requirement cannot deliver the potential value, or
cannot be met at all. This may include many factors such as the difficulty of
implementing a requirement, or the chance that stakeholders will not
accept a solution component. If there is a risk that the solution is not
technically feasible, the requirement that is most difficult to implement may
be prioritized to the top of the list in order to minimize the resources that
are spent before learning that a proposed solution cannot be delivered. A
proof of concept may be developed to establish that high risk options are
possible.
Dependencies: relationships between requirements where one
requirement cannot be fulfilled unless the other requirement is fulfilled. In
some situations, it may be possible to achieve efficiencies by implementing
related requirements at the same time. Dependencies may also be external
to the initiative, including but not limited to other teams’ decisions, funding
commitments, and resource availability. Dependencies are identified as part
of the task Trace Requirements (p. 79).
Time Sensitivity: the 'best before' date of the requirement, after which
the implementation of the requirement loses significant value. This includes
time-to-market scenarios, in which the benefit derived will be exponentially
Requirements Life Cycle Management Prioritize Requirements
89
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
greater if the functionality is delivered ahead of the competition. It can also
refer to seasonal functionality that only has value at a specific time of year.
Stability: the likelihood that the requirement will change, either because it
requires further analysis or because stakeholders have not reached a
consensus about it. If a requirement is not stable, it may have a lower
priority in order to minimize unanticipated rework and wasted effort.
Regulatory or Policy Compliance: requirements that must be
implemented in order to meet regulatory or policy demands imposed on the
organization, which may take precedence over other stakeholder interests.
.2 Challenges of Prioritization
Prioritization is an assessment of relative value. Each stakeholder may value
something different. When this occurs, there may be conflict amongst
stakeholders. Stakeholders may also have difficulty characterizing any
requirement as a lower priority, and this may impact the ability to make necessary
trade-offs. In addition, stakeholders may (intentionally or unintentionally) indicate
priority to influence the result to their desired outcome.
Different types of requirements may not all respond to the criteria in the same
way and may appear to conflict. There may be a need for stakeholders to make
trade-offs in prioritization.
.3 Continual Prioritization
Priorities may shift as the context evolves and as more information becomes
available. Initially, prioritization is done at a higher level of abstraction. As the
requirements are further refined, prioritization is done at a more granular level
and will incorporate additional bases for prioritization as they become
appropriate. The basis for prioritization may be different at various stages of the
change. For example, stakeholders may initially prioritize based on benefits. The
implementation team may then re-prioritize the requirements based on the
sequence in which they must be implemented due to technical constraints. Once
the implementation team has provided the cost of each requirement, the
stakeholders may re-prioritize yet again.
5.3.5 Guidelines and Tools
• Business Constraints: regulatory statutes, contractual obligations and
business policies that may define priorities.
• Change Strategy: provides information on costs, timelines, and value
realization which are used to determine priority of requirements.
• Domain Knowledge: knowledge and expertise of the business domain
needed to support prioritization.
• Governance Approach: outlines the approach for prioritizing requirements.
• Requirements Architecture: utilized to understand the relationship with
other requirements and work products.
Prioritize Requirements Requirements Life Cycle Management
90
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Requirements Management Tools/Repository: including a requirements
attribute for prioritization can help the business analyst to sort and access
requirements by priority.
• Solution Scope: considered when prioritizing requirements to ensure scope is
managed.
5.3.6 Techniques
Backlog Management: used to compare requirements to be prioritized. The
backlog can be the location where the prioritization is maintained.
Business Cases: used to assess requirements against identified business goals
and objectives to determine importance.
Decision Analysis: used to identify high-value requirements.
Estimation: used to produce estimates for the basis of prioritization.
Financial Analysis: used to assess the financial value of a set of requirements
and how the timing of delivery will affect that value.
Interviews: used to gain an understanding of a single or small group of
stakeholders' basis of prioritization or priorities.
Item Tracking: used to track issues raised by stakeholders during prioritization.
Prioritization: used to facilitate the process of prioritization.
Risk Analysis and Management: used to understand the risks for the basis of
prioritization.
Workshops: used to gain an understanding of stakeholders' basis of
prioritization or priorities in a facilitated group setting.
5.3.7 Stakeholders
• Customer: verifies that the prioritized requirements will deliver value from a
customer or end-user perspective. The customer can also negotiate to have the
prioritization changed based on relative value.
• End User: verifies that the prioritized requirements will deliver value from a
customer or end-user perspective.
• Implementation Subject Matter Expert: provides input relating to technical
dependencies and can negotiate to have the prioritization changed based on
technical constraints.
• Project Manager: uses the prioritization as input into the project plan and into
the allocation of requirements to releases.
• Regulator: can verify that the prioritization is consistent with legal and
regulatory constraints.
• Sponsor: verifies that the prioritized requirements will deliver value from an
organizational perspective.
Requirements Life Cycle Management Assess Requirements Changes
91
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5.3.8 Outputs
• Requirements (prioritized): prioritized or ranked requirements are available
for additional work, ensuring that the highest valued requirements are
addressed first.
• Designs (prioritized): prioritized or ranked designs are available for additional
work, ensuring that the highest valued designs are addressed first.
5.4 Assess Requirements Changes
5.4.1 Purpose
The purpose of Assess Requirements Changes is to evaluate the implications of
proposed changes to requirements and designs.
5.4.2 Description
The Assess Requirements Changes task is performed as new needs or possible
solutions are identified. These may or may not align to the change strategy and/
or solution scope. Assessment must be performed to determine whether a
proposed change will increase the value of the solution, and if so, what action
should be taken.
Business analysts assess the potential effect of the change to solution value, and
whether proposed changes introduce conflicts with other requirements or
increase the level of risk. Business analysts also ensure each proposed change can
be traced back to a need.
When assessing changes, business analysts consider if each proposed change:
• aligns with the overall strategy,
• affects value delivered to the business or stakeholder groups,
• impacts the time to deliver or the resources required to deliver the value,
and
• alters any risks, opportunities, or constraints associated with the overall
initiative.
The results of the assessment must support the decision making and change
control approaches defined by the task Plan Business Analysis Governance (p. 37).
5.4.3 Inputs
• Proposed Change: can be identified at any time and impact any aspect of
business analysis work or deliverables completed to date. There are many
triggers for a proposed change including business strategy changes,
stakeholders, legal requirements, or regulatory changes.
Assess Requirements Changes Requirements Life Cycle Management
92
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Requirements: may need to be assessed to identify the impact of a proposed
modification.
• Designs: may need to be assessed to identify the impact of a proposed
modification.
Figure 5.4.1: Assess Requirements Changes Input/Output Diagram
5.4.4 Elements
.1 Assessment Formality
Business analysts will determine the formality of the assessment process based on
the information available, the apparent importance of the change, and the
governance process. Many proposed changes may be withdrawn from
consideration or declined before any formal approval is required. A predictive
approach may indicate a more formal assessment of proposed changes. In
predictive approaches, the impact of each change can be disruptive; the change
can potentially generate a substantial reworking of tasks and activities completed
in previous activities. An adaptive approach may require less formality in the
assessment of proposed changes. While there may be reworking needed as a
result of each change, adaptive approaches try to minimize the impact of changes
by utilizing iterative and incremental implementation techniques. This idea of
continuous evolution may reduce the need for formal impact assessment.
.2 Impact Analysis
Impact analysis is performed to assess or evaluate the effect of a change.
Traceability is a useful tool for performing impact analysis. When a requirement
Output
5.4
Assess Requirements Changes
Change Strategy
DesignsRequirements
Domain Knowledge
Governance Approach
Legal/Regulatory
Information
5.1
Requirements
Change
Assessment
5.1
Designs Change
Assessment
Proposed Change
Requirements Architecture
Solution Scope
Guidelines and Tools Input
Requirements Life Cycle Management Assess Requirements Changes
93
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
changes, its relationships to other requirements or solution components can be
reviewed. Each related requirement or component may also require a change to
support the new requirement.
When considering changes or additions to existing requirements, business
analysts assess the impact of the proposed change by considering:
Benefit: the benefit that will be gained by accepting the change.
Cost: the total cost to implement the change including the cost to make
the change, the cost of associated rework, and the opportunity costs such
as the number of other features that may need to be sacrificed or deferred
if the change is approved.
Impact: the number of customers or business processes affected if the
change is accepted.
Schedule: the impact to the existing delivery commitments if the change is
approved.
Urgency: the level of importance including the factors which drive
necessity such as regulator or safety issues.
.3 Impact Resolution
Depending on the planned approach, various stakeholders (including the business
analyst) may be authorized to approve, deny, or defer the proposed change. All
impacts and resolutions resulting from the change analysis are to be documented
and communicated to all stakeholders. How decisions and changes will be made
and communicated across an initiative is determined by the task Plan Business
Analysis Governance (p. 37).
5.4.5 Guidelines and Tools
• Change Strategy: describes the purpose and direction for changes, establishes
the context for the change, and identifies the critical components for change.
• Domain Knowledge: knowledge of and expertise in the business domain is
needed to assess proposed requirements changes.
• Governance Approach: provides guidance regarding the change control and
decision-making processes, as well as the roles of stakeholders within this
process.
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed. These may impact requirements and must be considered
when making changes.
• Requirements Architecture: 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.
• Solution Scope: must be considered when assessing changes to fully
understand the impact of a proposed change.
Assess Requirements Changes Requirements Life Cycle Management
94
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
5.4.6 Techniques
Business Cases: used to justify a proposed change.
Business Rules Analysis: used to assess changes to business policies and
business rules, and develop revised guidance.
Decision Analysis: used to facilitate the change assessment process.
Document Analysis: used to analyze any existing documents that facilitate an
understanding of the impact of the change.
Estimation: used to determine the size of the change.
Financial Analysis: used to estimate the financial consequences of a proposed
change.
Interface Analysis: used to help business analysts identify interfaces that can
be affected by the change.
Interviews: used to gain an understanding of the impact on the organization
or its assets from a single or small group of stakeholders.
Item Tracking: used to track any issues or conflicts discovered during impact
analysis.
Risk Analysis and Management: used to determine the level of risk
associated with the change.
Workshops: used to gain an understanding of the impact or to resolve
changes in a group setting.
5.4.7 Stakeholders
• Customer: provides feedback concerning the impact the change will have on
value.
• Domain Subject Matter Expert: has expertise in some aspect of the situation
and can provide insight into how the change will impact the organization and
value.
• End User: uses the solution or is a component of the solution, and can offer
information about the impact of the change on their activities.
• Operational Support: provides information on both their ability to support
the operation of the solution and their need to understand the nature of the
change in the solution in order to be able to support it.
• Project Manager: reviews the requirements change assessment to determine if
additional project work is required for a successful implementation of the
solution.
Requirements Life Cycle Management Approve Requirements
95
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Regulator: changes are likely to be referenced by auditors to confirm
compliance to standards.
• Sponsor: accountable for the solution scope and can provide insight to be
utilized when assessing change.
• Tester: consulted for establishing impact of the proposed changes.
5.4.8 Outputs
• Requirements Change Assessment: the recommendation to approve,
modify, or deny a proposed change to requirements.
• Designs Change Assessment: the recommendation to approve, modify, or
deny a proposed change to one or more design components.
5.5 Approve Requirements
5.5.1 Purpose
The purpose of Approve Requirements is to obtain agreement on and approval of
requirements and designs for business analysis work to continue and/or solution
construction to proceed.
5.5.2 Description
Business analysts are responsible for ensuring clear communication of
requirements, designs, and other business analysis information to the key
stakeholders responsible for approving that information.
Approval of requirements and designs may be formal or informal. Predictive
approaches typically perform approvals at the end of the phase or during planned
change control meetings. Adaptive approaches typically approve requirements
only when construction and implementation of a solution meeting the
requirement can begin. Business analysts work with key stakeholders to gain
consensus on new and changed requirements, communicate the outcome of
discussions, and track and manage the approval.
5.5.3 Inputs
• Requirements (verified): a set of requirements that have been verified to be
of sufficient quality to be used as a reliable body of work for further
specification and development.
• Designs: a set of designs that have been determined as ready to be used for
further specification and development.
Approve Requirements Requirements Life Cycle Management
96
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 5.5.1: Approve Requirements Input/Output Diagram
Once a
requirement has
been approved, it
is a finalized
business analysis
work product,
and is
implemented.
5.5.4 Elements
.1 Understand Stakeholder Roles
The approval process is defined by the task Plan Business Analysis Governance
(p. 37). Part of defining the approval process is understanding stakeholder roles
and authority levels. Business analysts are responsible for obtaining stakeholder
approvals and are required to understand who holds decision-making
responsibility and who possesses authority for sign-off across the initiative.
Business analysts also consider any influential stakeholders who should be
consulted or informed about the requirements. Few stakeholders may have the
authority to approve or deny changes, but many stakeholders may be able to
influence these decisions.
.2 Conflict and Issue Management
To maintain stakeholder support for the solution, consensus among stakeholders
is usually sought prior to requesting approval of requirements. The approach for
determining how to secure decisions and resolve conflicts across an initiative is
planned for in the task Plan Business Analysis Governance (p. 37).
Stakeholder groups frequently have varying points of view and conflicting
priorities. A conflict may arise among stakeholders as a result of different
interpretations of requirements or designs and conflicting values placed on them.
The business analyst facilitates communication between stakeholders in areas of
conflict so that each group has an improved appreciation for the needs of the
others. Conflict resolution and issue management may occur quite often, as the
business analyst is reviewing requirements and designs, and aiming to secure
sign-off.
Output
5.5
Approve Requirements
Change Strategy
Designs
Requirements
(verified)
Governance Approach
Legal/Regulatory
Information
Requirements Management
Tools/Repository
5.5
Requirements
(approved)
5.5
Designs
(approved)
Solution Scope
Guidelines and Tools
Input
Requirements Life Cycle Management Approve Requirements
97
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.3 Gain Consensus
Business analysts are responsible for ensuring that the stakeholders with approval
authority understand and accept the requirements. Approval may confirm that
stakeholders believe that sufficient value will be created for the organization to
justify investment in a solution. Business analysts obtain approval by reviewing the
requirements or changes to requirements with the accountable individuals or
groups and requesting that they approve, indicating their agreement with the
solution or designs described.
Using the methods and means established in the tasks Plan Business Analysis
Governance (p. 37) and Communicate Business Analysis Information (p. 67)
business analysts present the requirements to stakeholders for approval. Business
analysts facilitate this approval process by addressing any questions or providing
additional information when requested.
Complete agreement may not be necessary for a successful change, but if there is
a lack of agreement, the associated risks are to be identified and managed
accordingly.
.4 Track and Communicate Approval
The business analyst records approval decisions, possibly in requirements
maintenance and tracking tools. In order to communicate the status of
requirements, it is necessary to keep accurate records of current approval status.
Stakeholders must be able to determine what requirements and designs are
currently approved and in line for implementation. There may be value in
maintaining an audit history of changes to requirements: what was changed,
who made the change, the reason for the change, and when it was made.
5.5.5 Guidelines and Tools
• Change Strategy: provides information which assists in managing stakeholder
consensus regarding the needs of all stakeholders.
• Governance Approach: 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.
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed. They may impact the requirements and designs approval
process.
• Requirement Management Tools/Repository: tool to record requirements
approvals.
• Solution Scope: must be considered when approving requirements to
accurately assess alignment and completeness.
5.5.6 Techniques
Acceptance and Evaluation Criteria: used to define approval criteria.
Approve Requirements Requirements Life Cycle Management
98
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Decision Analysis: used to resolve issues and gain agreement.
Item Tracking: used to track issues identified during the agreement process.
Reviews: used to evaluate requirements.
Workshops: used to facilitate obtaining approval.
5.5.7 Stakeholders
• Customer: may play an active role in reviewing and approving requirements
and designs to ensure needs are met.
• Domain Subject Matter Expert: may be involved in the review and approval
of requirements and designs as defined by stakeholder roles and responsibilities
designation.
• End User: people who use the solution, or who are a solution component, and
may be involved in the review, validation, and prioritization of requirements and
designs as defined by the stakeholder roles and responsibilities designation.
• Operational Support: responsible for ensuring that requirements and designs
are supportable within the constraints imposed by technology standards and
organizational capability plans. Operational support personnel may have a role
in reviewing and approving requirements.
• Project Manager: responsible for identifying and managing risks associated
with solution design, development, delivery, implementation, operation and
sustainment. The project manager may manage the project plan activities
pertaining to review and/or approval.
• Regulator: external or internal party who is responsible for providing opinions
on the relationship between stated requirements and specific regulations, either
formally in an audit, or informally as inputs to requirements life cycle
management tasks.
• Sponsor: responsible to review and approve the business case, solution or
product scope, and all requirements and designs.
• Tester: responsible for ensuring quality assurance standards are feasible within
the business analysis information. For example, requirements have the testable
characteristic.
5.5.8 Outputs
• Requirements (approved): requirements which are agreed to by stakeholders
and are ready for use in subsequent business analysis efforts.
• Designs (approved): designs which are agreed to by stakeholders and are
ready for use in subsequent business analysis or solution development efforts.
99
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6
Strategy Analysis
Strategy defines the most effective way to apply the capabilities of an enterprise
in order to reach a desired set of goals and objectives. Strategies may exist for the
entire enterprise, for a division, department or region, and for a product, project,
or iteration.
The Strategy Analysis knowledge area describes the business analysis work that
must be performed to collaborate with stakeholders in order to identify a need of
strategic or tactical importance (the business need), enable the enterprise to
address that need, and align the resulting strategy for the change with higher-
and lower-level strategies.
Strategy analysis focuses on defining the future and transition states needed to
address the business need, and the work required is defined both by that need
and the scope of the solution space. It covers strategic thinking in business
analysis, as well as the discovery or imagining of possible solutions that will
enable the enterprise to create greater value for stakeholders, and/or capture
more value for itself.
Strategy analysis provides context to requirements analysis and design definition
for a given change. Strategy analysis should be performed as a business need is
identified. This allows stakeholders to make the determination of whether to
address that need or not. Strategy analysis is an ongoing activity that assesses any
changes in that need, in its context, or any new information that may indicate
that an adjustment to the change strategy may be required.
The following image illustrates the spectrum of value as business analysis
activities progress from delivering potential value to actual value.
Strategy Analysis
100
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 6.0.1: Business Analysis Value Spectrum
When performing strategy analysis, business analysts must consider the context
in which they are working, and how predictable the range of possible outcomes
is. When a change will have a predictable outcome, the future state and possible
transition states can typically be clearly defined, and a clear strategy can be
planned out. If the outcome of a change is difficult to predict, the strategy may
need to focus more on mitigating risk, testing assumptions, and changing course
until a strategy that will succeed in reaching the business goals can be identified
or until the initiative has ended. These tasks may be performed in any order,
though they are often performed concurrently, as strategy must be shaped by
what is actually achievable.
A strategy may be captured in a strategic plan, product vision, business case,
product roadmap, or other artifacts.
The Strategy Analysis knowledge area includes the following tasks:
Analyze Current State: understands the business need and how it relates
to the way the enterprise functions today. Sets a baseline and context for
change.
Define Future State: defines goals and objectives that will demonstrate
that the business need has been satisfied and defines what parts of the
enterprise need to change in order to meet those goals and objectives.
Assess Risks: understands the uncertainties around the change, considers
the effect those uncertainties may have on the ability to deliver value
through a change, and recommends actions to address risks where
appropriate.
Define Change Strategy: performs a gap analysis between current and
future state, assesses options for achieving the future state, and
recommends the highest value approach for reaching the future state
including any transition states that may be required along the way.
Solution Evaluation
Potential
Requirements Analysis
& Design Definition
Strategy Analysis
Need
Solution
Scope
Requirements Design
Proof of Concept/
Prototype
Pilot/Beta Operating
Actual
Strategy Analysis
101
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
The Core Concept Model in Strategy Analysis
The Business Analysis Core Concept Model™ (BACCM™) describes the
relationships among the six core concepts. The following table describes the
usage and application of each of the core concepts within the context of Strategy
Analysis.
Table 6.0.1: The Core Concept Model in Strategy Analysis
Core Concept During Strategy Analysis, business
analysts...
Change: the act of transformation
in response to a need.
define the future state and develop a
change strategy to achieve the future
state.
Need: a problem or opportunity to
be addressed.
identify needs within the current state and
prioritize needs to determine the desired
future state.
Solution: a specific way of
satisfying one or more needs in a
context.
define the scope of a solution as part of
developing a change strategy.
Stakeholder: a group or
individual with a relationship to
the change, the need, or the
solution.
collaborate with stakeholders to
understand the business need and to
develop a change strategy and future
state that will meet those needs.
Value: the worth, importance, or
usefulness of something to a
stakeholder in a context.
examine the potential value of the
solution to determine if a change is
justified.
Context: the circumstances that
influence, are influenced by, and
provide understanding of the
change.
consider the context of the enterprise in
developing a change strategy.
Strategy Analysis
102
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 6.0.2: Strategy Analysis Input/Output Diagram
Tasks
Output
6.3
Assess Risks
6.2
Define Future State
6.1
Analyze Current
State
6.4
Define Change
Strategy
Needs
Influences
(internal, external)
3.2
Stakeholder
Engagement
Approach
5.3
Designs
(prioritized)
4.3
Elicitation Results
(confirmed)
6.1
Current State
Description
6.1
Business
Requirements
6.2
Business Objectives
6.2
Potential Value
6.2
Future State
Description
6.3
Risk Analysis Results
6.4
Change Strategy
6.4
Solution Scope
4.2
Elicitation Results
(unconfirmed)
5.3
Requirements
(prioritized)
Input
Strategy Analysis Analyze Current State
103
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.1 Analyze Current State
6.1.1 Purpose
The purpose of Analyze Current State is to understand the reasons why an
enterprise needs to change some aspect of how it operates and what would be
directly or indirectly affected by the change.
6.1.2 Description
The starting point for any change is an understanding of why the change is
needed. Potential change is triggered by problems or opportunities that cannot
be addressed without altering the current state. Business analysts work to help
stakeholders enable change by exploring and articulating the business needs that
drive the desire to change. Without clearly understood business needs, it is
impossible to develop a coherent strategy, and the resulting change initiative is
almost certain to be driven by a mix of conflicting stakeholder demands.
Change always occurs in a context of existing stakeholders, processes,
technology, and policies which constitute the current state of the enterprise.
Business analysts examine the current state in the context of the business need to
understand what may influence proposed changes, and what will be affected by
them. The current state is explored in just enough detail to validate the need for
a change and/or the change strategy. Understanding the current state of the
enterprise prior to the change is necessary to identify what will need to change to
achieve a desired future state and how the effect of the change will be assessed.
The scope of the current state describes the important existing characteristics of
the environment. The boundaries of the current state scope are determined by
the components of the enterprise and its environment as they relate to the needs.
The current state can be described on different levels, ranging from the entire
enterprise to small components of a solution. Creating a model of the current
state might require collaboration throughout or outside the enterprise. For small
efforts, the scope might be only a small component of an enterprise.
The current state of an enterprise is rarely static while a change is being
developed and implemented. Internal and external influencers, as well as other
organizational changes, can affect the current state in ways that force alterations
in the desired future state, change strategy, or requirements and designs.
6.1.3 Inputs
• Elicitation Results: used to define and understand the current state.
• Needs: the problem or opportunity faced by an enterprise or organization often
launches business analysis work to better understand these needs.
Analyze Current State Strategy Analysis
104
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 6.1.1: Analyze Current State Input/Output Diagram
6.1.4 Elements
.1 Business Needs
Business needs are the problems and opportunities of strategic importance faced
by the enterprise. An issue encountered in the organization, such as a customer
complaint, a loss of revenue, or a new market opportunity, usually triggers the
evaluation of a business need.
Output
Tasks Using This Output
Business Analysis Approach
6.1
Current State
Description
4.3
Elicitation Results
(confirmed)
Needs
Enterprise Limitation
Organizational Strategy
Solution Limitation
6.1 Business
Requirements
Solution Performance Goals
6.2
Define Future State
Solution Performance
Measures
Stakeholder Analysis
Results
6.3
Assess Risks
6.4
Define Change
Strategy
7.6
Analyze Potential
Value and
Recommend
Solution
8.4
Assess Enterprise
Limitations
8.5
Recommend
Actions to Increase
Solution Value
Tasks Using This Output
6.2
Define Future State
3.2
Plan Stakeholder
Engagement
3.3
Plan Business
Analysis
Governance
Guidelines and Tools Input
Task
6.1 Analyze Current State
Strategy Analysis Analyze Current State
105
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
A business need may be identified at many different levels of the enterprise:
From the top-down: a strategic goal that needs to be achieved.
From the bottom-up: a problem with the current state of a process,
function or system.
From middle management: a manager needs additional information to
make sound decisions or must perform additional functions to meet
business objectives.
From external drivers: customer demand or business competition in the
marketplace.
The definition of business needs is frequently the most critical step in any business
analysis effort. A solution must satisfy the business needs to be considered
successful. The way the need is defined determines which alternative solutions
will be considered, which stakeholders will be consulted, and which solution
approaches will be evaluated. Business needs are always expressed from the
perspective of the enterprise, and not that of any particular stakeholder.
Business needs are often identified or expressed along with a presumed solution.
The business analyst should question the assumptions and constraints that are
generally buried in the statement of the issue to ensure that the correct problem
is being solved and the widest possible range of alternative solutions are
considered.
A solution to a set of business needs must have the potential to generate benefits
for the enterprise or its stakeholders, or avoid losses that would otherwise occur.
Factors the business analyst may consider include:
• adverse impacts the problem is causing within the organization and
quantify those impacts (for example, potential lost revenue, inefficiencies,
dissatisfied customers, low employee morale),
• expected benefits from any potential solution (for example, increased
revenue, reduced costs, increased market share),
• how quickly the problem could potentially be resolved or the opportunity
could be taken, and the cost of doing nothing, and
• the underlying source of the problem.
Business needs will drive the overall analysis of the current state. Although it isn’t
necessary to fully detail all aspects of the current state before further developing
the change strategy, this exploration will often uncover deeper underlying causes
of the problem or the opportunity that triggered the investigation (which then
become additional business needs).
.2 Organizational Structure and Culture
Organizational structure defines the formal relationships between people
working in the enterprise. While communication channels and relationships are
not limited to that structure, they are heavily influenced by it, and the reporting
structure may aid or limit a potential change.
Analyze Current State Strategy Analysis
106
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Organizational culture is the beliefs, values, and norms shared by the members of
an organization. These beliefs drive the actions taken by an organization.
Business analysts perform a cultural assessment to:
• identify if cultural changes are required to better achieve the goals,
identify whether stakeholders understand the rationale for the current state
of the enterprise and the value delivered by it, and
• ascertain whether the stakeholders view the current state as satisfactory or
if change is needed.
.3 Capabilities and Processes
Capabilities and processes describe the activities an enterprise performs. They also
include the knowledge the enterprise has, the products and services it provides,
the functions it supports, and the methods it uses to make decisions. Core
capabilities or processes describe the essential functions of the enterprise that
differentiate it from others. They are measured by performance indicators that
can be used to assess the benefits of a change.
Business analysts may use:
• A capability-centric view of the enterprise when looking for innovative
solutions that combine existing capabilities to produce a new outcome. A
capability-based view is useful in this situation because capabilities are
generally organized in a functional hierarchy with relationships to other
capabilities, making it easier to identify any gaps.
• A process-centric view of the enterprise when looking for ways to improve
the performance of current activities. A process-based view is useful in this
situation because processes are organized in an end-to-end fashion across
the enterprise to deliver value to its customers, making it easier to ensure
that a change does in fact increase performance.
.4 Technology and Infrastructure
Information systems used by the enterprise support people in executing
processes, making decisions, and in interactions with suppliers and customers.
The infrastructure describes the enterprise’s environment with respect to physical
components and capabilities. The infrastructure can include components such as
computer hardware, physical plants, and logistics, as well as their operation and
upkeep.
.5 Policies
Policies define the scope of decision making at different levels of an enterprise.
They generally address routine operations rather than strategic change. They
ensure that decisions are made correctly, provide guidance to staff on permitted
and appropriate behaviour and actions, support governance, and determine
when and how new resources can be acquired. Identification of relevant policies
may shape the scope of the solution space and may be a constraint on the types
Strategy Analysis Analyze Current State
107
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
of action that can be pursued.
.6 Business Architecture
No part of the current state should be assessed in complete isolation from the
rest. Business analysts must understand how all of these elements of the current
state fit together and support one another in order to recommend changes that
will be effective. The existing business architecture typically meets an assortment
of business and stakeholder needs. If those needs are not recognized or do not
continue to be met by a proposed transition or future state, changes are likely to
result in a loss of value.
.7 Internal Assets
Business analysts identify enterprise assets used in the current state. Resources
can be tangible or intangible, such as financial resources, patents, reputation, and
brand names.
.8 External Influencers
There are external influences on the enterprise that do not participate in a change
but might present constraints, dependencies, or drivers on the current state.
Sources of external influence include:
Industry Structure: individual industries have distinct ways in which value
is created within that industry. This is a particularly important influencer if a
proposed change involves entering a new industry.
Competitors: the nature and intensity of competitors between enterprises
within an industry can be significant. The entry of a new competitor may
also change the nature of the industry or increase competition.
Customers: the size and nature of existing and potential customer
segments can provide influences such as negotiating power and a degree of
price sensitivity. Alternatively, the emergence of new alternative ways that
customers can meet their needs may drive the enterprise to deliver greater
value.
Suppliers: the variety and diversity of suppliers might be an influencer, as
can the power that suppliers have over their customers.
Political and Regulatory Environment: there is often influence from the
current and potential impact of laws and regulations upon the industry.
Technology: the productivity enhancing potential of recent and expected
technological innovations might influence the need.
Macroeconomic Factors: the constraints and opportunities that exist
within the existing and expected macroeconomic environment (for
example, trade, unemployment, or inflation) might influence the need.
Some of these sources might use different terminology, based on whether the
enterprise is a for-profit corporation, a non-profit enterprise, or a government
agency. For example, a country does not have customers; it has citizens.
Analyze Current State Strategy Analysis
108
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.1.5 Guidelines and Tools
• Business Analysis Approach: guides how the business analyst undertakes an
analysis of the current state.
• Enterprise Limitation: used to understand the challenges that exist within the
enterprise.
• Organizational Strategy: an organization will have a set of goals and
objectives which guides operations, establishes direction, and provides a vision
for the future state. This can be implicitly or explicitly stated.
• Solution Limitation: used to understand the current state and the challenges
of existing solutions.
• Solution Performance Goals: measure the current performance of an
enterprise or solution, and serve as a baseline for setting future state goals and
measuring improvement.
• Solution Performance Measures: describe the actual performance of existing
solutions.
• Stakeholder Analysis Results: stakeholders from across the organization will
contribute to an understanding and analysis of the current state.
6.1.6 Techniques
Benchmarking and Market Analysis: provides an understanding of where
there are opportunities for improvement in the current state. Specific
frameworks that may be useful include 5 Forces analysis, PEST, STEEP, CATWOE,
and others.
Business Capability Analysis: identifies gaps and prioritizes them in relation
to value and risk.
Business Model Canvas: provides an understanding of the value proposition
that the enterprise satisfies for its customers, the critical factors in delivering
that value, and the resulting cost and revenue streams. Helpful for
understanding the context for any change and identifying the problems and
opportunities that may have the most significant impact.
Business Cases: used to capture information regarding the business need and
opportunity.
Concept Modelling: used to capture key terms and concepts in the business
domain and define the relationships between them.
Data Mining: used to obtain information on the performance of the
enterprise.
Document Analysis: analyzes any existing documentation about the current
state, including (but not limited to) documents created during the
implementation of a solution, training manuals, issue reports, competitor
information, supplier agreements, published industry benchmarks, published
technology trends, and performance metrics.
Strategy Analysis Analyze Current State
109
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Financial Analysis: used to understand the profitability of the current state
and the financial capability to deliver change.
Focus Groups: solicits feedback from customers or end users about the current
state.
Functional Decomposition: breaks down complex systems or relationships in
the current state.
Interviews: facilitate dialogue with stakeholders to understand the current
state and any needs evolving from the current state.
Item Tracking: tracks and manages issues discovered about the current state.
Lessons Learned: enables the assessment of failures and opportunities for
improvement in past initiatives, which may drive a business need for process
improvement.
Metrics and Key Performance Indicators (KPIs): assesses performance of
the current state of an enterprise.
Mind Mapping: used to explore relevant aspects of the current state and
better understand relevant factors affecting the business need.
Observation: may provide opportunities for insights into needs within the
current state that have not been identified previously by a stakeholder.
Organizational Modelling: describes the roles, responsibilities, and reporting
structures that exist within the current state organization.
Process Analysis: identifies opportunities to improve the current state.
Process Modelling: describes how work occurs within the current solution.
Risk Analysis and Management: identifies risks to the current state.
Root Cause Analysis: provides an understanding of the underlying causes of
any problems in the current state in order to further clarify a need.
Scope Modelling: helps define the boundaries on the current state
description.
Survey or Questionnaire: helps to gain an understanding of the current state
from a large, varied, or disparate group of stakeholders.
SWOT Analysis: evaluates the strengths, weaknesses, opportunities, and
threats to the current state enterprise.
Vendor Assessment: determines whether any vendors that are part of the
current state are adequately meeting commitments, or if any changes are
needed.
Workshops: engage stakeholders to collaboratively describe the current state
and their needs.
Define Future State Strategy Analysis
110
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.1.7 Stakeholders
• Customer: makes use of the existing solution and might have input about
issues with a current solution.
• Domain Subject Matter Expert: has expertise in some aspect of the current
state.
• End User: directly uses a solution and might have input about issues with a
current solution.
• Implementation Subject Matter Expert: has expertise in some aspect of the
current state.
• Operational Support: directly involved in supporting the operations of the
organization and provides information on their ability to support the operation
of an existing solution, as well as any known issues.
• Project Manager: may use information on current state as input to planning.
• Regulator: can inform interpretations of relevant regulations that apply to the
current state in the form of business policies, business rules, procedures, or role
responsibilities. The regulator might have unique input to the operational
assessment, as there might be new laws and regulations with which to comply.
• Sponsor: might have context for performance of existing solutions.
• Supplier: might be an external influencer of the current state.
• Tester: able to provide information about issues with any existing solutions.
6.1.8 Outputs
• Current State Description: the context of the enterprise’s scope, capabilities,
resources, performance, culture, dependencies, infrastructure, external
influences, and significant relationships between these elements.
• Business Requirements: the problem, opportunity, or constraint which is
defined based on an understanding of the current state.
6.2 Define Future State
6.2.1 Purpose
The purpose of Define Future State is to determine the set of necessary conditions
to meet the business need.
6.2.2 Description
All purposeful change must include a definition of success. Business analysts work
to ensure that the future state of the enterprise is well defined, that it is
achievable with the resources available, and that key stakeholders have a shared
Strategy Analysis Define Future State
111
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
consensus vision of the outcome. As with current state analysis, the purpose of
future state analysis is not to create a comprehensive description of the outcome
at a level of detail that will directly support implementation. The future state will
be defined at a level of detail that:
• allows for competing strategies to achieve the future state to be identified
and assessed,
• provides a clear definition of the outcomes that will satisfy the business
needs,
• details the scope of the solution space,
• allows for value associated with the future state to be assessed, and
• enables consensus to be achieved among key stakeholders.
The future state description can include any context about the proposed future
state. It describes the new, removed, and modified components of the enterprise.
It can include changes to the boundaries of the organization itself, such as
entering a new market or performing a merger or acquisition. The future state
can also be simple changes to existing components of an organization, such as
changing a step in a process or removing a feature from an existing application.
Change may be needed to any component of the enterprise, including (but not
limited to):
• business processes,
• functions,
• lines of business,
• organization structures,
• staff competencies,
• knowledge and skills,
• training,
• facilities,
• desktop tools,
• organization locations,
• data and information,
• application systems, and/or
• technology infrastructure.
Descriptions may include visual models and text to clearly show the scope
boundaries and details. Relevant relationships between entities are identified and
described. The effort required to describe the future state varies depending on the
nature of the change. The expected outcomes from a change might include
specific metrics or loosely defined results. Describing the future state allows
stakeholders to understand the potential value that can be realized from a
solution, which can be used as part of the decision-making process regarding the
change strategy. In environments where changes result in predictable outcomes
and predictable delivery of value, and where there are a large number of possible
changes that can increase value, the purpose of future state analysis is to gather
sufficient information to make the best possible choices among potential options.
In cases where it is difficult to predict the value realized by a change, the future
state may be defined by identification of appropriate performance measures (to
produce an agreed-upon set of measures for business value), and the change
strategy will support exploration of multiple options.
Define Future State Strategy Analysis
112
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.2.3 Inputs
• Business Requirements: the problems, opportunities, or constraints that the
future state will address.
Figure 6.2.1: Define Future State Input/Output Diagram
Guidelines and Tools
Tasks Using This Output
Constraints
Business
Objectives
Business
Requirements
Current State Description
Metrics and Key Performance
Indicators (KPIs)
Organizational Strategy
Potential Value
4.5
Manage
Stakeholder
Collaboration
6.4
Define Change
Strategy
7.3
Validate
Requirements
7.5
Define Design
Options
7.6
Analyze Potential
Value and
Recommend
Solution
8.1
Measure Solution
Performance
Tasks Using This Output
6.3
Assess Risks
6.2
Future State
Description
7.3
Validate
Requirements
7.6
Analyze Potential
Value and
Recommend
Solution
8.2
Analyze
Performance
Measures
8.4
Assess Enterprise
Limitations
Tasks Using This Output
6.3
Assess Risks
7.3
Validate
Requirements
7.6
Analyze Potential
Value and
Recommend
Solution
8.1
Measure Solution
Performance
8.4
Assess Enterprise
Limitations
8.5
Recommend
Actions to Increase
Solution Value
8.2
Analyze
Performance
Measures
4.1
Prepare for
Elicitation
4.5
Manage
Stakeholder
Collaboration
6.3
Assess Risks
4.1
Prepare for
Elicitation
Input
Output
6.2
Define Future State
Strategy Analysis Define Future State
113
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.2.4 Elements
.1 Business Goals and Objectives
A future state can be described in terms of business objectives or goals in order to
guide the development of the change strategy and identify potential value.
Business goals and objectives describe the ends that the organization is seeking to
achieve. Goals and objectives can relate to changes that the organization wants
to accomplish, or current conditions that it wants to maintain.
Goals are longer term, ongoing, and qualitative statements of a state or condition
that the organization is seeking to establish and maintain. Examples of business
goals include:
• Create a new capability such as a new product or service, address a
competitive disadvantage, or create a new competitive advantage.
• Improve revenue by increasing sales or reducing cost.
• Increase customer satisfaction.
• Increase employee satisfaction.
• Comply with new regulations.
• Improve safety.
• Reduce time to deliver a product or service.
High-level goals can be decomposed to break down the general strategy into
areas that may lead to desired results, such as increased customer satisfaction,
operational excellence, and/or business growth. For example, a goal may be to
"increase number of high-revenue customers" and then be further refined into a
goal to "increase number of high revenue customers in the 30-45 age bracket by
30% within 6 months".
As goals are analyzed they are converted into more descriptive, granular and
specific objectives, and linked to measures that make it possible to objectively
assess if the objective has been achieved. Objectives that are measurable enable
teams to know if needs were addressed and whether a change was effective.
Defining measurable objectives is often critical to justify completing the change
and might be a key component to a business case for the change. A common test
for assessing objectives is to ensure that they are SMART:
S
pecific: describing something that has an observable outcome,
M
easurable: tracking and measuring the outcome,
A chievable: testing the feasibility of the effort,
R
elevant: aligning with the enterprise’s vision, mission, and goals, and
T
ime-bounded: defining a time frame that is consistent with the need.
Define Future State Strategy Analysis
114
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.2 Scope of Solution Space
Decisions must be made about the range of solutions that will be considered to
meet the business goals and objectives. The scope of the solution space defines
which kinds of options will be considered when investigating possible solutions,
including changes to the organizational structure or culture, capabilities and
processes, technology and infrastructure, policies, products, or services, or even
creating or changing relationships with organizations currently outside the scope
of the extended enterprise. Solutions in each of these areas generally require
specific expertise from both the business analysis and the delivery team. The
analysis for this might happen on different levels in the enterprise, and the scope
of the solution space is not necessarily related to the size of the change. Even a
small change might require looking at the enterprise-level business objectives to
ensure alignment.
If multiple future states can meet the business needs, goals and objectives, it will
be necessary to determine which ones will be considered. This decision is typically
based on the value to be delivered to stakeholders and requires an understanding
of possible change strategies. The critical considerations for the decision are
dependent on the overall objectives of the enterprise, but will involve an
understanding of the quantitative and qualitative value of each option, the time
needed to achieve each future state, and the opportunity cost to the enterprise.
.3 Constraints
Constraints describe aspects of the current state, aspects of the planned future
state that may not be changed by the solution, or mandatory elements of the
design. They must be carefully examined to ensure that they are accurate and
justified.
Constraints may reflect any of the following:
• budgetary restrictions,
• time restrictions,
• technology,
• infrastructure,
• policies,
• limits on the number of resources available,
• restrictions based on the skills of the team and stakeholders,
• a requirement that certain stakeholders not be affected by the
implementation of the solution,
• compliance with regulations, and
• any other restriction.
Strategy Analysis Define Future State
115
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.4 Organizational Structure and Culture
The formal and informal working relationships that exist within the enterprise
may need to change to facilitate the desired future state. Changes to reporting
lines can encourage teams to work more closely together and facilitate alignment
of goals and objectives. Elements of the organizational structure and culture may
need to change to support the future state. Describing the components of the
future state provides insight into potential conflicts, impact, and limits.
.5 Capabilities and Processes
Identify new kinds of activities or changes in the way activities will be performed
to realize the future state. New or changed capabilities and processes will be
needed to deliver new products or services, to comply with new regulations, or to
improve the performance of the enterprise.
.6 Technology and Infrastructure
If current technology and infrastructure are insufficient to meet the business
need, the business analyst identifies the changes necessary for the desired future
state.
The existing technology may impose technical constraints on the design of the
solution. These may include development languages, hardware and software
platforms, and application software that must be used. Technical constraints may
also describe restrictions such as resource utilization, message size and timing,
software size, maximum number of and size of files, records, and data elements.
Technical constraints include any IT architecture standards that must be followed.
.7 Policies
If current polices are insufficient to meet the business need, the business analyst
identifies the changes necessary for the desired future state.
Policies are a common source of constraints on a solution or on the solution
space. Business policies may mandate what solutions can be implemented given
certain levels of approval, the process for obtaining approval, and the necessary
criteria a proposed solution must meet in order to receive funding. In some
instances, a change to an existing policy may open up alternative solutions that
would not otherwise be considered.
.8 Business Architecture
The elements of any future state must effectively support one another and all
contribute to meeting the business goals and objectives. In addition, they should
be integrated into the overall desired future state of the enterprise as a whole,
and support that future state.
Define Future State Strategy Analysis
116
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
.9 Internal Assets
The analysis of resources might indicate that existing resources need to be
increased or require increased capabilities, or that new resources need to be
developed. When analyzing resources, business analysts examine the resources
needed to maintain the current state and implement the change strategy, and
determine what resources can be used as part of a desired future state. The
assessment of existing and needed resources is considered when performing a
feasibility analysis on possible solution approaches for the change strategy.
.10 Identify Assumptions
Most strategies are predicated on a set of assumptions that will determine
whether or not the strategy can succeed, particularly when operating in a highly
uncertain environment. It will often be difficult or impossible to prove that the
delivery of a new capability will meet a business need, even in cases where it
appears reasonable to assume that the new capability will have the desired effect.
These assumptions must be identified and clearly understood, so that appropriate
decisions can be made if the assumption later proves invalid. Change strategies in
uncertain environments can be structured in order to test these assumptions as
early as possible to support a redirection or termination of the initiative.
.11 Potential Value
Meeting the business objectives alone does not justify the transition to a future
state; the potential value must be evaluated to see if it is sufficient to justify a
change.
When defining the future state, business analysts identify the potential value of
the solution. The potential value of the future state is the net benefit of the
solution after operating costs are accounted for. A change must result in greater
value for the enterprise than would be achieved if no action was taken. However,
it is possible that the future state will represent a decrease in value from the
current state for some stakeholders or even for the enterprise as a whole. New
regulations or increased competition, for example, might need to be addressed
for the enterprise to remain operating but could still decrease the overall value
captured.
While determining the future state, business analysts consider increased or
decreased potential value from:
• external opportunities revealed in assessing external influences,
• unknown strengths of new partners,
• new technologies or knowledge,
• potential loss of a competitor in the market, and
• mandated adoption of a change component.
Business analysts identify the specific opportunities for potential alterations in
value, as well as the probability of those increases for the individual components
Strategy Analysis Define Future State
117
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
of the proposed change. Business analysts estimate a total potential value by
aggregating across all opportunities.
The potential value, including the details of the expected benefit and costs and
the likely result if no change is made, is a key component to making a business
case for the change. Relating descriptions of potential value to measures of actual
value currently being achieved enables stakeholders to understand the expected
change in value. In most cases, the future state will not address all of the
opportunities for improvement. Any unaddressed opportunities might remain
valid after the solution is implemented and should be noted for future analysis in
other changes.
In addition to the potential value of the future state, this analysis should consider
the acceptable level of investment to reach the future state. While the actual
investment will depend on the change strategy, this information guides the
selection of possible strategies.
6.2.5 Guidelines and Tools
• Current State Description: provides the context within which the work needs
to be completed. It is often used as a starting point for the future state.
• Metrics and Key Performance Indicators (KPIs): the key performance
indicators and metrics which will be used to determine whether the desired
future state has been achieved.
• Organizational Strategy: 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.
6.2.6 Techniques
Acceptance and Evaluation Criteria: used to identify what may make the
future state acceptable and/or how options may be evaluated.
Balanced Scorecard: used to set targets for measuring the future state.
Benchmarking and Market Analysis: used to make decisions about future
state business objectives.
Brainstorming: used to collaboratively come up with ideas for the future state.
Business Capability Analysis: used to prioritize capability gaps in relation to
value and risk.
Business Cases: used to capture the desired outcomes of the change initiative.
Business Model Canvas: used to plan strategy for the enterprise by mapping
out the needed infrastructure, target customer base, financial cost structure,
and revenue streams required to fulfill the value proposition to customers in the
desired future state.
Decision Analysis: used to compare the different future state options and
understand which is the best choice.
Define Future State Strategy Analysis
118
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Decision Modelling: used to model complex decisions regarding future state
options.
Financial Analysis: used to estimate the potential financial returns to be
delivered by a proposed future state.
Functional Decomposition: used to break down complex systems within the
future state for better understanding.
Interviews: used to talk to stakeholders to understand their desired future
state, which needs they want to address, and what desired business objectives
they want to meet.
Lessons Learned: used to determine which opportunities for improvement will
be addressed and how the current state can be improved upon.
Metrics and Key Performance Indicators (KPIs): used to determine when
the organization has succeeded in achieving the business objectives.
Mind Mapping: used to develop ideas for the future state and understand
relationships between them.
Organizational Modelling: used to describe the roles, responsibilities, and
reporting structures that would exist within the future state organization.
Process Modelling: used to describe how work would occur in the future
state.
Prototyping: used to model future state options and could also help determine
potential value.
Scope Modelling: used to define the boundaries of the enterprise in the future
state.
Survey or Questionnaire: used to understand stakeholders' desired future
state, which needs they want to address, and what desired business objectives
they want to meet.
SWOT Analysis: used to evaluate the strengths, weaknesses, opportunities,
and threats that may be exploited or mitigated by the future state.
Vendor Assessment: used to assess potential value provided by vendor
solution options.
Workshops: used to work with stakeholders to collaboratively describe the
future state.
6.2.7 Stakeholders
• Customer: might be targeted purchasers or consumers in a future state who
might or might not be ready or able to consume a new state.
• Domain Subject Matter Expert: provides insight into current state and
potential future states.
• End User: expected to use, or be a component of, a solution that implements
the future state.
Strategy Analysis Define Future State
119
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Implementation Subject Matter Expert: provides information regarding the
feasibility of achieving the future state.
• Operational Support: directly involved in supporting the operations of the
enterprise and provides information on their ability to support the operation of
a proposed future state.
• Project Manager: might have input on what is a reasonable and manageable
desired future state.
• Regulator: ensures that laws, regulations, or rules are adhered to in the desired
future state. Interpretations of relevant regulations must be included in the
future state description in the form of business policies, business rules,
procedures, or role responsibilities.
• Sponsor: helps determine which business needs to address and sets the
business objectives that a future state will achieve. Authorizes and ensures
funding to support moving towards the future state.
• Supplier: might help define the future state if they are supporting delivery of
the change or deliver any part of the future state operation.
• Tester: responsible for ensuring an envisioned future state can be sufficiently
tested and can help set an appropriate level of quality to target.
6.2.8 Outputs
• Business Objectives: the desired direction that the business wishes to pursue
in order to achieve the future state.
• Future State Description: the future state description includes boundaries of
the proposed new, removed, and modified components of the enterprise and
the potential value expected from the future state. The description might
include the desired future capabilities, policies, resources, dependencies,
infrastructure, external influences, and relationships between each element.
• Potential Value: the value that may be realized by implementing the proposed
future state.
Assess Risks Strategy Analysis
120
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.3 Assess Risks
6.3.1 Purpose
The purpose of Assess Risks is to understand the undesirable consequences of
internal and external forces on the enterprise during a transition to, or once in,
the future state. An understanding of the potential impact of those forces can be
used to make a recommendation about a course of action.
6.3.2 Description
Assessing risks includes analyzing and managing them. Risks might be related to
the current state, a desired future state, a change itself, a change strategy, or any
tasks being performed by the enterprise.
The risks are analyzed for the:
• possible consequences if the risk occurs,
• impact of those consequences,
• likelihood of the risk, and
• potential time frame when the risk might occur.
The collection of risks is used as an input for selecting or coordinating a change
strategy. A risk assessment can include choosing to accept a risk if either the
effort required to modify the risk or the level of risk outweighs the probable loss.
If the risks are understood and the change proceeds, then the risks can be
managed to minimize their overall impact to value.
Important A number of methods include 'positive risk' as a way of managing opportunities.
Although the formal definition of risk in the BABOK
®
Guide doesn't preclude this
usage, 'opportunities' are captured as needs (and managed accordingly), and risk
is used for uncertain events that can produce negative outcomes.
6.3.3 Inputs
• Business Objectives: describing the desired direction needed to achieve the
future state can be used to identify and discuss potential risks.
• Elicitation Results (confirmed): an understanding of what the various
stakeholders perceive as risks to the realization of the desired future state.
• Influences: factors inside of the enterprise (internal) and factors outside of
the enterprise (external) which will impact the realization of the desired future
state.
• Potential Value: describing the value to be realized by implementing the
proposed future state provides a benchmark against which risks can be
assessed.
• Requirements (prioritized): depending on their priority, requirements will
influence the risks to be defined and understood as part of solution realization.
Strategy Analysis Assess Risks
121
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 6.3.1: Assess Risks Input/Output Diagram
6.3.4 Elements
.1 Unknowns
When assessing a risk, there will be uncertainty in the likelihood of it occurring,
and the impact if it does occur. Business analysts collaborate with stakeholders to
assess risks based on current understanding. Even when it is not possible to know
all that will occur as a result of a particular change strategy, it is still possible to
estimate the impact of unknown or uncertain events or conditions occurring.
Business analysts consider other historical contexts from similar situations to
assess risks. The lessons learned from past changes and expert judgment from
stakeholders assist business analysts in guiding the team in deciding the impact
Tasks Using This Output
Output
Business Analysis Approach
6.3
Risk Analysis
Results
4.5
Manage
Stakeholder
Collaboration
4.3
Elicitation Results
(confirmed)
Influences
(internal and
external)
Business Policies
Change Strategy
7.6
Analyze Potential
Value and
Recommend
Solution
8.2
Analyze
Performance
Measures
8.4
Assess Enterprise
Limitations
Current State Description
5.3
Designs
(prioritized)
Future State Description
Identified Risks
Stakeholder Engagement
Approach
6.2
Business
Objectives
6.2
Potential Value
6.4
Define Change
Strategy
8.3
Assess Solution
Limitations
5.3
Requirements
(prioritized)
Input
Guidelines and Tools
6.3
Assess Risks
Assess Risks Strategy Analysis
122
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
and likelihood of risks for the current change.
.2 Constraints, Assumptions, and Dependencies
Constraints, assumptions, and dependencies can be analyzed for risks and
sometimes should be managed as risks themselves. If the constraint, assumption,
or dependency is related to an aspect of a change, it can be restated as a risk by
identifying the event or condition and consequences that could occur because of
the constraint, assumption, or dependency.
.3 Negative Impact to Value
Risks are expressed as conditions that increase the likelihood or severity of a
negative impact to value. Business analysts clearly identify and express each risk
and estimate its likelihood and impact to determine the level of risk. Business
analysts estimate a total risk level from the aggregated set of risks, indicating the
overall potential impact for the risks being assessed. In some cases overall risk
level can be quantified in financial terms, or in an amount of time, effort, or other
measures.
.4 Risk Tolerance
How much uncertainty a stakeholder or an enterprise is willing to take on in
exchange for potential value is referred to as risk tolerance.
In general, there are three broad ways of describing attitude toward risk:
Risk-aversion: An unwillingness to accept much uncertainty; there may be
a preference to either avoid a course of action which carries too high a level
of risk, or to invest more (and therefore accept a lower potential value) to
reduce the risks.
Neutrality: some level of risk is acceptable, provided the course of action
does not result in a loss even if the risks occur.
Risk-seeking: A willingness to accept or even take on more risk in return
for a higher potential value.
An individual or organization may exhibit different risk tolerances at different
times. If there is low tolerance for risk, there may be more effort on avoidance,
transfer or mitigation strategies. If the tolerance for risk is high, more risks are
likely to be accepted. Typically, the highest level risks are dealt with no matter
what the risk tolerance level.
.5 Recommendation
Based on the analysis of risks, business analysts recommend a course of action.
Business analysts work with stakeholders to understand the overall risk level and
their tolerance for risk.
The recommendation usually falls into one of the following categories:
• pursue the benefits of a change regardless of the risk,
Strategy Analysis Assess Risks
123
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• pursue the benefits of a change while investing in reducing risk (likelihood
and/or impact),
• seek out ways to increase the benefits of a change to outweigh the risk,
• identify ways to manage and optimize opportunities, and
• do not pursue the benefits of a change.
If the change proceeds with risks, stakeholders should be identified to monitor
the risks and consequences if the risk event occurs. The risk may alter the current
state of the enterprise and require revision of the change strategy. A plan of
action in this case may be developed before the risk materializes.
6.3.5 Guidelines and Tools
• Business Analysis Approach: guides how the business analyst analyzes risks.
• Business Policies: define the limits within which decisions must be made.
These may mandate or govern aspects of risk management.
• Change Strategy: 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 with the change.
• Current State Description: provides the context within which the work needs
to be completed. It can be used to determine risks associated with the current
state.
• Future State Description: determines risks associated with the future state.
• Identified Risks: 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.
• Stakeholder Engagement Approach: understanding stakeholders and
stakeholder groups helps identify and assess the potential impact of internal
and external forces.
6.3.6 Techniques
Brainstorming: used to collaboratively identify potential risks for assessment.
Business Cases: used to capture risks associated with alternative change
strategies.
Decision Analysis: used to assess problems.
Document Analysis: used to analyze existing documents for potential risks,
constraints, assumptions, and dependencies.
Financial Analysis: used to understand the potential effect of risks on the
financial value of the solution.
Interviews: used to understand what stakeholders think might be risks and the
various factors of those risks.
Lessons Learned: used as a foundation of past issues that might be risks.
Define Change Strategy Strategy Analysis
124
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Mind Mapping: used to identify and categorize potential risks and understand
their relationships.
Risk Analysis and Management: used to identify and manage risks.
Root Cause Analysis: used to identify and address the underlying problem
creating a risk.
Survey or Questionnaire: used to understand what stakeholders think might
be risks and the various factors of those risks.
Workshops: used to understand what stakeholders think might be risks and
the various factors of those risks.
6.3.7 Stakeholders
• Domain Subject Matter Expert: provides input to the risk assessment based
on their knowledge of preparation required in their area of expertise.
• Implementation Subject Matter Expert: provides input to the risk
assessment based on their knowledge of preparation required in their area of
expertise.
• Operational Support: supports the operations of the enterprise and can
identify likely risks and their impact.
• Project Manager: helps to assess risk and is primarily responsible for managing
and mitigating risk to the project.
• Regulator: identifies any risks associated with adherence to laws, regulations,
or rules.
• Sponsor: needs to understand risks as part of authorizing and funding change.
• Supplier: there might be risk associated with using a supplier.
• Tester: identifies risks in the change strategy, from a validation or verification
perspective.
6.3.8 Outputs
Risk Analysis Results: an understanding of the risks associated with achieving the
future state, and the mitigation strategies which will be used to prevent those
risks, reduce the impact of the risk, or reduce the likelihood of the risk occurring.
6.4 Define Change Strategy
6.4.1 Purpose
The purpose of Define Change Strategy is to develop and assess alternative
approaches to the change, and then select the recommended approach.
Strategy Analysis Define Change Strategy
125
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.4.2 Description
Developing a change strategy is simpler when the current state and the future
state are already defined because they provide some context for the change.
The change strategy clearly describes the nature of the change in terms of:
• context of the change,
• identified alternative change strategies,
• justification for why a particular change strategy is the best approach,
• investment and resources required to work toward the future state,
• how the enterprise will realize value after the solution is delivered,
• key stakeholders in the change, and
• transition states along the way.
The appropriate representation of a change strategy depends on the perspective
of the change team and their stakeholders. The change strategy might be
presented as part of a business case, Statement of Work (SOW), an enterprise’s
strategic plan, or in other formats.
Defining a change strategy usually involves identifying several strategies and
ultimately selecting the strategy that is most appropriate for the situation.
Change strategies can entail attaining only parts of a future state initially, and
therefore include only some components of a complete solution. For each
transition state along the path to reaching the future state, the change strategy
should clarify which parts of the solution are completed and which are not, as
well as which parts of the value can be realized and which cannot.
6.4.3 Inputs
• Current State Description: provides context about the current state, and
includes assessments of internal and external influences to the enterprise under
consideration.
• Future State Description: provides context about the desired future state.
• Risk Analysis Results: describe identified risks and exposure of each risk.
• Stakeholder Engagement Approach: understanding stakeholders'
communication and collaboration needs can help identify change-related
activities that need to be included as part of the change strategy.
Define Change Strategy Strategy Analysis
126
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 6.4.1: Define Change Strategy Input/Output Diagram
Input
Guidelines and Tools
Tasks Using This Output
Business Analysis
Approach
6.4
Change Strategy
6.1
Current State
Description
3.2
Stakeholder
Engagement
Approach
Design Options
Solution
Recommendations
6.4
Solution Scope
3.2
Plan Stakeholder
Engagement
5.3
Prioritize
Requirements
5.4
Assess
Requirements
Changes
5.5
Approve
Requirements
6.3
Assess Risks
7.5
Define Design
Options
Tasks Using This Output
5.3
Prioritize
Requirements
6.3
Risk Analysis
Results
6.2
Future State
Description
5.4
Assess
Requirements
Changes
8.1
Measure Solution
Performance
8.2
Analyze
Performance
Measures
8.3
Assess Solution
Limitations
8.4
Assess Enterprise
Limitations
5.5
Approve
Requirements
7.1
Specify and Model
Requirements
7.3
Validate
Requirements
7.4
Define
Requirements
Architecture
7.5
Define Design
Options
7.6
Analyze Potential
Value and
Recommend
Solution
8.1
Measure Solution
Performance
8.2
Analyze
Performance
Measures
8.3
Assess Solution
Limitations
8.4
Assess Enterprise
Limitations
8.5
Recommend
Actions to Increase
Solution Value
Output
6.4
Define Change Strategy
Strategy Analysis Define Change Strategy
127
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
6.4.4 Elements
.1 Solution Scope
The solution is the outcome of a change that allows an enterprise to satisfy a
need. Multiple solution options might be evaluated and, as part of a change
strategy, the best solution approach is justified and selected. The solution scope
defines the boundaries of the solution, and is described in enough detail to
enable stakeholders to understand which new capabilities the change will deliver.
It also describes how the proposed solution enables the future state's goals. The
solution scope might evolve throughout an initiative as more information is
discovered.
The solution scope might be described in different ways, including the use of:
• capabilities,
• technology,
• business rules,
• business decisions,
• data,
• processes,
• resources,
• knowledge and skills,
• models and descriptions of
markets,
• functions,
• locations,
• networks,
• organizational structures,
• workflows,
• events,
• sequence,
• motivations, or
• business logic.
The solution scope can also include descriptions of out-of-scope solution
components to provide clarity.
.2 Gap Analysis
A gap analysis identifies the difference between current state and future state
capabilities. To perform gap analysis, both current state and future state should
be defined. Using the same techniques to describe both current and future states
assists in gap analysis, as it simplifies the comparison.
Gap analysis can help identify the gaps that prevent the enterprise from meeting
needs and achieving goals. It can be used to determine if the enterprise can meet
its needs using its existing structure, resources, capabilities, and technology. If the
enterprise can meet the need with the current state capabilities, then the change
will likely be relatively small, or there may be no change at all. In any other case, a
change strategy is needed to create the missing capabilities or improve the
existing ones. The capabilities analyzed in a gap analysis can include:
• processes,
• functions,
• lines of business,
• organizational structures,
• staff competencies,
• knowledge and skills,
• training,
• facilities,
Define Change Strategy Strategy Analysis
128
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• locations,
• data and information,
• application systems, and
• technology infrastructure.
The gaps will need to be addressed in the transition and future states.
.3 Enterprise Readiness Assessment
Business analysts analyze the enterprise to assess its capacity to make the change
and to sustain the change in the future state. The readiness assessment considers
the enterprise’s capacity not only to make the change, but to use and sustain the
solution, and realize value from the solution. The assessment also factors in the
cultural readiness of the stakeholders and operational readiness in making the
change, the timeline from when the change is implemented to when value can be
realized, and the resources available to support the change effort.
.4 Change Strategy
A change strategy is a high-level plan of key activities and events that will be used
to transform the enterprise from the current state to the future state. Change
strategies may be a singular initiative composed of smaller changes which might
be structured as a set or sequence of projects, or as various continuous
improvement efforts. Each element of change might not completely address the
need, so multiple changes might be necessary.
During the course of the development of a change strategy, several options are
identified, explored, and described in enough detail to determine which options
are feasible. Alternatives can be identified through brainstorming and consulting
subject matter experts (SMEs). Sources of ideas can include historical ideas,
historical changes, other markets' strategies, and competitors' approaches.
A preferred change strategy is selected from this set of options and developed in
more detail. The preferred change strategy should be selected considering:
• organizational readiness to make the change,
• major costs and investments needed to make the change,
• timelines to make the change,
• alignment to the business objectives,
• timelines for value realization, and
• opportunity costs of the change strategy.
Business analysts may develop a business case for each potential change strategy
to support decision making. The opportunity cost of each change strategy also
needs to be considered. Opportunity cost refers to the benefits that could have
been achieved by selecting an alternative change strategy. The options considered
and rejected are an important component of the final strategy, providing
stakeholders with an understanding of the pros and cons of various approaches
to making the change.
When defining the change strategy, the investment to make the change to the
future state is also considered. The net benefits of a future state may be very high,
Strategy Analysis Define Change Strategy
129
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
but if the investment is unbearable ("they just can't afford the change") the
enterprise may pass on the opportunity, and invest in something else.
The potential value, including the details of the expected benefit and costs, are
key components to making a business case for the change. Relating descriptions
of potential value to measures of actual value currently being achieved enables
stakeholders to understand the expected change in value. While every change
facilitated by business analysts is intended to increase value, some changes
decrease value in parts of an enterprise while increasing it in others.
.5 Transition States and Release Planning
In many cases, the future state will need to be achieved over time rather than
through a single change, meaning that the enterprise will have to operate in one
or more transition states. Release planning is concerned with determining which
requirements to include in each release, phase, or iteration of the change.
Business analysts help facilitate release planning discussions to help stakeholders
reach decisions. There are many factors that guide these decisions, such as the
overall budget, deadlines or time constraints, resource constraints, training
schedules, and the ability of the business to absorb changes within a defined time
frame. There may be organizational restraints or policies that must be adhered to
in any implementation. Business analysts assist in planning the timing of the
implementation in order to cause minimal disruption to business activities, and to
ensure all parties understand the impact to the organization.
6.4.5 Guidelines and Tools
• Business Analysis Approach: guides how the business analyst defines a
change strategy.
• Design Options: 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.
• Solution Recommendations: identifying the possible solutions which can be
pursued in order to achieve the future state, which includes the
recommendations of various subject matter experts (SMEs), helps the business
analyst determine the types of changes to the organization.
6.4.6 Techniques
Balanced Scorecard: used to define the metrics that will be used to evaluate
the effectiveness of the change strategy.
Benchmarking and Market Analysis: used to make decisions about which
change strategy is appropriate.
Brainstorming: used to collaboratively come up with ideas for change
strategies.
Business Capability Analysis: used to prioritize capability gaps in relation to
value and risk.
Define Change Strategy Strategy Analysis
130
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Business Cases: used to capture information about the recommended change
strategy and other potential strategies that were assessed but not
recommended.
Business Model Canvas: used to define the changes needed in the current
infrastructure, customer base, and financial structure of the organization in
order to achieve the potential value.
Decision Analysis: used to compare different change strategies and choose
which is most appropriate.
Estimation: used to determine timelines for activities within the change
strategy.
Financial Analysis: used to understand the potential value associated with a
change strategy, and evaluate strategies against targets set for return on
investments.
Focus Groups: used to bring customers or end users together to solicit their
input on the solution and change strategy.
Functional Decomposition: used to break down the components of the
solution into parts when developing a change strategy.
Interviews: used to talk to stakeholders in order to fully describe the solution
scope and change scope, and to understand their suggestions for a change
strategy.
Lessons Learned: used to understand what went wrong in past changes in
order to improve this change strategy.
Mind Mapping: used to develop and explore ideas for change strategies.
Organizational Modelling: used to describe the roles, responsibilities, and
reporting structures that are necessary during the change and are part of the
solution scope.
Process Modelling: used to describe how work would occur in the solution
scope or during the change.
Scope Modelling: used to define the boundaries on the solution scope and
change scope descriptions.
SWOT Analysis: used to make decisions about which change strategy is
appropriate.
Vendor Assessment: used to determine whether any vendors are part of the
change strategy, either to implement the change or to be part of the solution.
Workshops: used in work with stakeholders to collaboratively develop change
strategies.
6.4.7 Stakeholders
• Customer: might be purchasing or consuming the solution that results from
the change. Customers can also be involved in a change as testers or focus
Strategy Analysis Define Change Strategy
131
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
group members, whose input is considered in the enterprise readiness
assessment.
• Domain Subject Matter Expert: have expertise in some aspect of the change.
• End User: uses a solution, is a component of the solution, or is a user
temporarily during the change. End users could be customers or people who
work within the enterprise experiencing a change. Users might be involved in a
change as testers or focus group members, whose input is considered in the
enterprise readiness assessment.
• Implementation Subject Matter Expert: have expertise in some aspect of
the change.
• Operational Support: directly involved in supporting the operations of the
enterprise, and provide information on their ability to support the operation of
a solution during and after a change.
• Project Manager: responsible for managing change and planning the detailed
activities to complete a change. In a project, the project manager is responsible
for the project scope, which covers all the work to be performed by the project
team.
• Regulator: ensures adherence to laws, regulations, or rules during and at the
completion of the change. The regulator might have unique input to the
enterprise readiness assessment, as there might be laws and regulations that
must be complied with prior to or as a result of a planned or completed change.
• Sponsor: authorizes and ensures funding for solution delivery, and champions
the change.
• Supplier: might help implement the change or be part of the solution once the
change is completed.
• Tester: responsible for ensuring that the change will function within acceptable
parameters, accomplish the desired result, and deliver solutions that meet an
appropriate level of quality. The tester is often involved in validation of
components of a solution for which the results will be included in an enterprise
readiness assessment.
6.4.8 Outputs
• Change Strategy: the approach that the organization will follow to guide
change.
• Solution Scope: the solution scope that will be achieved through execution of
the change strategy.
Define Change Strategy Strategy Analysis
132
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
133
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7
Requirements Analysis and Design
Definition
The Requirements Analysis and Design Definition knowledge area describes the
tasks that business analysts perform to structure and organize requirements
discovered during elicitation activities, specify and model requirements and
designs, validate and verify information, identify solution options that meet
business needs, and estimate the potential value that could be realized for each
solution option. This knowledge area covers the incremental and iterative
activities ranging from the initial concept and exploration of the need through the
transformation of those needs into a particular recommended solution.
For more
information, see
Requirements and
Designs (p. 19).
Both requirements and designs are important tools used by business analysts to
define and guide change. The main difference between requirements and designs
is in how they are used and by whom. One person’s designs may be another
person’s requirements. Requirements and designs may be either high-level or very
detailed based upon what is appropriate to those consuming the information.
The business analyst's role in modelling needs, requirements, designs, and
solutions is instrumental in conducting thorough analysis and communicating
with other stakeholders. The form, level of detail, and what is being modelled are
all dependent on the context, audience, and purpose.
Business analysts analyze the potential value of both requirements and designs. In
collaboration with implementation subject matter experts, business analysts
define solution options that can be evaluated in order to recommend the best
solution option that meets the need and brings the most value.
The following image illustrates the spectrum of value as business analysis
activities progress from delivering potential value to actual value.
Requirements Analysis and Design Definition
134
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 7.0.1: Business Analysis Value Spectrum
The Requirements Analysis and Design Definition knowledge area includes the
following tasks:
Specify and Model Requirements: describes a set of requirements or
designs in detail using analytical techniques.
Verify Requirements: ensures that a set of requirements or designs has
been developed in enough detail to be usable by a particular stakeholder, is
internally consistent, and is of high quality.
Validate Requirements: ensures that a set of requirements or designs
delivers business value and supports the organization's goals and
objectives.
Define Requirements Architecture: structures all requirements and
designs so that they support the overall business purpose for a change and
that they work effectively as a cohesive whole.
Define Solution Options: identifies, explores and describes different
possible ways of meeting the need.
Analyze Potential Value and Recommend Solution: assesses the
business value associated with a potential solution and compares different
options, including trade-offs, to identify and recommend the solution
option that delivers the greatest overall value.
The Core Concept Model in Requirements Analysis
and Design Definition
The Business Analysis Core Concept Model™ (BACCM™) describes the
relationships among the six core concepts. The following table describes the
usage and application of each of the core concepts within the context of
Requirements Analysis and Design Definition.
Solution Evaluation
Potential
Requirements Analysis
& Design Definition
Strategy Analysis
Need
Solution
Scope
Requirements Design
Proof of Concept/
Prototype
Pilot/Beta Operating
Actual
Requirements Analysis and Design Definition
135
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Table 7.0.1: The Core Concept Model in Requirements Analysis and Design
Definition
Core Concept During Requirements Analysis and Design
Definition, business analysts...
Change: the act of transformation
in response to a need.
transform elicitation results into
requirements and designs in order to
define the change.
Need: a problem or opportunity to
be addressed.
analyze the needs in order to recommend
a solution that meets the needs.
Solution: a specific way of
satisfying one or more needs
within a context.
define solution options and recommend
the one that is most likely to address the
need and has the most value.
Stakeholder: a group or
individual with a relationship to
the change, the need, or the
solution.
tailor the requirements and designs so
that they are understandable and usable
by each stakeholder group.
Value: the worth, importance, or
usefulness of something to a
stakeholder within a context.
analyze and quantify the potential value
of the solution options.
Context: the circumstances that
influence, are influenced by, and
provide understanding of the
change.
model and describe the context in formats
that are understandable and usable by all
stakeholders.
Specify and Model Requirements Requirements Analysis and Design Definition
136
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 7.0.2: Requirements Analysis and Design Definition Input/Output Diagram
7.1 Specify and Model Requirements
7.1.1 Purpose
The purpose of Specify and Model Requirements is to analyze, synthesize, and
refine elicitation results into requirements and designs.
7.1.2 Description
Specify and Model Requirements describes the practices for analyzing elicitation
Tasks
Output
7.3
Validate
Requirements
7.2
Verify
Requirements
7.1
Specify and Model
Requirements
7.4
Define
Requirements
Architecture
7.5
Define Design
Options
Requirements
(any state)
3.4
Information
Management
Approach
4.2, 4.3
Elicitation Results
(any state)
6.4
Change Strategy
6.4
Solution Scope
6.2
Potential Value
7.1
Requirements
(specified and
modelled)
7.2
Requirements
(verified)
7.3
Requirements
(validated)
7.5
Design Options
7.4
Requirements
Architecture
7.6
Analyze Potential
Value and
Recommend
Solution
7.6
Solution
Recommendation
Input
Requirements Analysis and Design Definition Specify and Model Requirements
137
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
results and creating representations of those results. When the focus of the
specifying and modelling activity is on understanding the need, the outputs are
referred to as requirements. When the focus of the specifying and modelling
activity is on a solution, the outputs are referred to as designs.
Important In many IT environments, the word 'design' is used specifically for technical
designs created by software developers, data architects, and other
implementation subject matter experts. All business deliverables are referred to as
'requirements'.
In addition to the models used to represent the requirements, this task also
includes capturing information about attributes or metadata about the
requirements. The specifying and modelling activities relate to all requirement
types.
7.1.3 Inputs
• Elicitation Results (any state): modelling can begin with any elicitation result
and may lead to the need for more elicitation to clarify or expand upon
requirements. Elicitation and modelling may occur sequentially, iteratively, or
concurrently.
Figure 7.1.1: Specify and Model Requirements Input/Output Diagram
Tasks Using This Output
Output
Modelling Notations/
Standards
7.1
Requirements
(specified and
modelled)
7.2
Verify
Requirements
4.2, 4.3
Elicitation Results
(any state)
Modelling Tools
Requirements Architecture
Requirements Life Cycle
Management Tools
Solution Scope
7.3
Validate
Requirements
Guidelines and Tools
7.1
Specify and Model
Requirements
Input
Specify and Model Requirements Requirements Analysis and Design Definition
138
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7.1.4 Elements
.1 Model Requirements
A model is a descriptive and visual way to convey information to a specific
audience in order to support analysis, communication, and understanding.
Models may also be used to confirm knowledge, identify information gaps that
the business analyst may have, and identify duplicate information.
Business analysts choose from one or more of the following modelling formats:
Matrices: a matrix is used when the business analyst is modelling a
requirement or set of requirements that have a complex but uniform
structure, which can be broken down into elements that apply to every
entry in the table. Matrices may be used for data dictionaries, requirements
traceability, or for gap analysis. Matrices are also used for prioritizing
requirements and recording other requirements attributes and metadata.
Diagrams: a diagram is a visual, often pictorial, representation of a
requirement or set of requirements. A diagram is especially useful to depict
complexity in a way that would be difficult to do with words. Diagrams can
also be used to define boundaries for business domains, to categorize and
create hierarchies of items, and to show components of objects such as
data and their relationships.
Using one or more of the model formats, business analysts determine specific
categories and specific models within categories to be used. Model categories can
include:
People and Roles: models represent organizations, groups of people,
roles, and their relationships within an enterprise and to a solution.
Techniques used to represent people and their roles include Organizational
Modelling, Roles and Permissions Matrix and Stakeholder List, Map, or
Personas.
Rationale: models represent the ‘why’ of a change. Techniques used to
represent the rationale include Decision Modelling, Scope Modelling,
Business Model Canvas, Root Cause Analysis, and Business Rules Analysis.
Activity Flow: models represent a sequence of actions, events, or a course
that may be taken. Techniques used to represent activity flows include
Process Modelling, Use Cases and Scenarios, and User Stories.
Capability: models focus on features or functions of an enterprise or a
solution. Techniques used to represent capabilities include Business
Capability Analysis, Functional Decomposition, and Prototyping.
Data and Information: models represent the characteristics and the
exchange of information within an enterprise or a solution. Techniques used
to represent data and information include Data Dictionary, Data Flow
Diagrams, Data Modelling, Glossary, State Modelling, and Interface
Analysis.
Requirements Analysis and Design Definition Specify and Model Requirements
139
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Business analysts should use any combination of models best suited to meet
stakeholder needs in a given context. Each modelling technique has strengths
and weaknesses and provides unique insights into the business domain.
.2 Analyze Requirements
Business analysis information is decomposed into components to further examine
for:
• anything that must change to meet the business need,
• anything that should stay the same to meet the business need,
• missing components,
• unnecessary components, and
• any constraints or assumptions that impact the components.
The level of decomposition required, and the level of detail to be specified, varies
depending on the knowledge and understanding of the stakeholders, the
potential for misunderstanding or miscommunication, organizational standards,
and contractual or regulatory obligations, among other factors.
Analysis provides a basis for discussion to reach a conclusion about solution
options.
.3 Represent Requirements and Attributes
Business analysts identify information for requirements and their attributes as part
of the elicitation results. Requirements should be explicitly represented and
should include enough detail such that they exhibit the characteristics of
requirements and designs quality (see Verify Requirements (p. 141)). Various
attributes can be specified for each requirement or set of requirements. These
attributes are selected when planning for information management (see Plan
Business Analysis Information Management (p. 42)).
As part of specifying requirements, they can also be categorized according to the
schema described in task Requirements Classification Schema (p. 16). Typically
elicitation results contain information of different types, so it is natural to expect
that different types of requirements might be specified at the same time.
Categorizing requirements can help ensure the requirements are fully
understood, a set of any type is complete, and that there is appropriate
traceability between the types.
.4 Implement the Appropriate Levels of Abstraction
The level of abstraction of a requirement varies based on the type of requirement
and audience for the requirement. Not all stakeholders require or find value in the
complete set of requirements and models. It may be appropriate to produce
different viewpoints of requirements to represent the same need for different
stakeholders. Business analysts take special care to maintain the meaning and
intent of the requirements over all representations.
The business analysis approach may also influence the level of abstraction and
choice of models used when defining requirements.
Specify and Model Requirements Requirements Analysis and Design Definition
140
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7.1.5 Guidelines and Tools
• Modelling Notations/Standards: 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.
• Modelling Tools: software products that facilitate drawing and storing
matrices and diagrams to represent requirements. This functionality may or may
not be part of requirements life cycle management tools.
• Requirements Architecture: the requirements and interrelationships among
them can be used to ensure models are complete and consistent.
• Requirements Life Cycle Management Tools: software products that
facilitate recording, organizing, storing, and sharing requirements and designs.
• Solution Scope: the boundaries of the solution provide the boundaries for the
requirements and designs models.
7.1.6 Techniques
Acceptance and Evaluation Criteria: used to represent the acceptance and
evaluation criteria attributes of requirements.
Business Capability Analysis: used to represent features or functions of an
enterprise.
Business Model Canvas: used to describe the rationale for requirements.
Business Rules Analysis: used to analyze business rules so that they can be
specified and modelled alongside requirements.
Concept Modelling: used to define terms and relationships relevant to the
change and the enterprise.
Data Dictionary: used to record details about the data involved in the change.
Details may include definitions, relationships with other data, origin, format,
and usage.
Data Flow Diagrams: used to visualize data flow requirements.
Data Modelling: used to model requirements to show how data will be used
to meet stakeholder information needs.
Decision Modelling: used to represent decisions in a model in order to show
the elements of decision making required.
Functional Decomposition: used to model requirements in order to identify
constituent parts of an overall complex business function.
Glossary: used to record the meaning of relevant business terms while
analyzing requirements.
Interface Analysis: used to model requirements in order to identify and
validate inputs and outputs of the solution they are modelling.
Non-Functional Requirements Analysis: used to define and analyze the
quality of service attributes.
Requirements Analysis and Design Definition Verify Requirements
141
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Organizational Modelling: used to allow business analysts to model the
roles, responsibilities, and communications within an organization.
Process Modelling: used to show the steps or activities that are performed in
the organization, or that must be performed to meet the desired change.
Prototyping: used to assist the stakeholders in visualizing the appearance and
capabilities of a planned solution.
Roles and Permissions Matrix: used to specify and model requirements
concerned with the separation of duties among users and external interfaces in
utilizing a solution.
Root Cause Analysis: used to model the root causes of a problem as part of
rationale.
Scope Modelling: used to visually show a scope boundary.
Sequence Diagrams: used to specify and model requirements to show how
processes operate and interact with one another, and in what order.
Stakeholder List, Map, or Personas: used to identify the stakeholders and
their characteristics.
State Modelling: used to specify the different states of a part of the solution
throughout a life cycle, in terms of the events that occur.
Use Cases and Scenarios: used to model the desired behaviour of a solution,
by showing user interactions with the solution, to achieve a specific goal or
accomplish a particular task.
User Stories: used to specify requirements as a brief statement about what
people do or need to do when using the solution.
7.1.7 Stakeholders
• Any stakeholder: business analysts may choose to perform this task
themselves and then separately package and communicate the requirements to
stakeholders for their review and approval, or they might choose to invite some
or all stakeholders to participate in this task.
7.1.8 Outputs
• Requirements (specified and modelled): any combination of requirements
and/or designs in the form of text, matrices, and diagrams.
7.2 Verify Requirements
7.2.1 Purpose
The purpose of Verify Requirements is to ensure that requirements and designs
specifications and models meet quality standards and are usable for the purpose
they serve.
Verify Requirements Requirements Analysis and Design Definition
142
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7.2.2 Description
Verifying requirements ensures that the requirements and designs have been
defined correctly. Requirements verification constitutes a check by the business
analyst and key stakeholders to determine that the requirements and designs are
ready for validation, and provides the information needed for further work to be
performed.
A high-quality specification is well written and easily understood by its intended
audience. A high-quality model follows the formal or informal notation standards
and effectively represents reality.
The most important characteristic of quality requirements and designs is fitness
for use. They must meet the needs of stakeholders who will use them for a
particular purpose. Quality is ultimately determined by stakeholders.
7.2.3 Inputs
• Requirements (specified and modelled): any requirement, design, or set of
those may be verified to ensure that text is well structured and that matrices
and modelling notation are used correctly.
Figure 7.2.1: Verify Requirements Input/Output Diagram
Input
Tasks Using This Output
Output
7.2
Requirements
(verified)
5.5
Approve
Requirements
7.1
Requirements
(specified and
modelled)
Requirements Life Cycle
Management Tools
Guidelines and Tools
7.2
Verify Requirements
Requirements Analysis and Design Definition Verify Requirements
143
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7.2.4 Elements
.1 Characteristics of Requirements and Designs Quality
While quality is ultimately determined by the needs of the stakeholders who will
use the requirements or the designs, acceptable quality requirements exhibit
many of the following characteristics:
Atomic: self-contained and capable of being understood independently of
other requirements or designs.
Complete: enough to guide further work and at the appropriate level of
detail for work to continue. The level of completeness required differs
based on perspective or methodology, as well as the point in the life cycle
where the requirement is being examined or represented.
Consistent: aligned with the identified needs of the stakeholders and not
conflicting with other requirements.
Concise: contains no extraneous and unnecessary content.
Feasible: reasonable and possible within the agreed-upon risk, schedule,
and budget, or considered feasible enough to investigate further through
experiments or prototypes.
Unambiguous: the requirement must be clearly stated in such a way to
make it clear whether a solution does or does not meet the associated
need.
Testable: able to verify that the requirement or design has been fulfilled.
Acceptable levels of verifying fulfillment depend on the level of abstraction
of the requirement or design.
Prioritized: ranked, grouped, or negotiated in terms of importance and
value against all other requirements.
Understandable: represented using common terminology of the audience.
.2 Verification Activities
Verification activities are typically performed iteratively throughout the
requirements analysis process.
Verification activities include:
• checking for compliance with organizational performance standards for
business analysis, such as using the right tools and methods,
• checking for correct use of modelling notation, templates, or forms,
• checking for completeness within each model,
• comparing each model against other relevant models, checking for
elements that are mentioned in one model but are missing in other models,
and verifying that the elements are referenced consistently,
• ensuring the terminology used in expressing the requirement is
understandable to stakeholders and consistent with the use of those terms
within the organization, and
Validate Requirements Requirements Analysis and Design Definition
144
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• adding examples where appropriate for clarification.
.3 Checklists
Checklists are used for quality control when verifying requirements and designs.
Checklists may include a standard set of quality elements that business analysts
use to verify the requirements, or they may be specifically developed to capture
issues of concern. The purpose of a checklist is to ensure that items determined to
be important are included in the final requirements deliverables, or that steps
required for the verification process are followed.
7.2.5 Guidelines and Tools
• Requirements Life Cycle Management Tools: some tools have functionality
to check for issues related to many of the characteristics, such as atomic,
unambiguous, and prioritized.
7.2.6 Techniques
Acceptance and Evaluation Criteria: used to ensure that requirements are
stated clearly enough to devise a set of tests that can prove that the
requirements have been met.
Item Tracking: used to ensure that any problems or issues identified during
verification are managed and resolved.
Metrics and Key Performance Indicators (KPIs): used to identify how to
evaluate the quality of the requirements.
Reviews: used to inspect requirements documentation to identify requirements
that are not of acceptable quality.
7.2.7 Stakeholders
• All stakeholders: the business analyst, in conjunction with the domain and
implementation subject matter experts, has the primary responsibility for
determining that this task has been completed. Other stakeholders may
discover problematic requirements during requirements communication.
Therefore, all stakeholders could be involved in this task.
7.2.8 Outputs
• Requirements (verified): a set of requirements or designs that is of sufficient
quality to be used as a basis for further work.
7.3 Validate Requirements
7.3.1 Purpose
The purpose of Validate Requirements is to ensure that all requirements and
Requirements Analysis and Design Definition Validate Requirements
145
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
designs align to the business requirements and support the delivery of needed
value.
7.3.2 Description
Requirements validation is an ongoing process to ensure that stakeholder,
solution, and transition requirements align to the business requirements and that
the designs satisfy the requirements.
Understanding what the desired future state looks like for stakeholders after their
needs have been met is valuable to business analysts when validating
requirements. The overall goal of implementing the requirements is to achieve the
stakeholders' desired future state. In many cases, stakeholders have different,
conflicting needs and expectations that may be exposed through the validation
process.
7.3.3 Inputs
• Requirements (specified and modelled): any types of requirements and
designs can be validated. Validation activities may begin before requirements
are completely verified. However, validation activities cannot be completed
before requirements are completely verified.
Figure 7.3.1: Validate Requirements Input/Output Diagram
Input
Tasks Using This Output
Output
7.3
Validate Requirements
Business Objectives
7.3
Requirements
(validated)
7.5
Define Design
Options
7.1
Requirements
(specified and
modelled)
Future State Description
Potential Value
Solution Scope
8.1
Measure Solution
Performance
Guidelines and Tools
Validate Requirements Requirements Analysis and Design Definition
146
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7.3.4 Elements
.1 Identify Assumptions
If an organization is launching an unprecedented product or service, it may be
necessary to make assumptions about customer or stakeholder response, as there
are no similar previous experiences on which to rely. In other cases, it may be
difficult or impossible to prove that a particular problem derives from an identified
root cause. Stakeholders may have assumed that certain benefits will result from
the implementation of a requirement. These assumptions are identified and
defined so that associated risks can be managed.
.2 Define Measurable Evaluation Criteria
While the expected benefits are defined as part of the future state, the specific
measurement criteria and evaluation process may not have been included.
Business analysts define the evaluation criteria that will be used to evaluate how
successful the change has been after the solution is implemented. Baseline
metrics might be established based on the current state. Target metrics can be
developed to reflect the achievement of the business objectives or some other
measurement of success.
.3 Evaluate Alignment with Solution Scope
A requirement can be of benefit to a stakeholder and still not be a desirable part
of a solution. A requirement that does not deliver benefit to a stakeholder is a
strong candidate for elimination. When requirements do not align, either the
future state must be re-evaluated and the solution scope changed, or the
requirement removed from the solution scope.
If a design cannot be validated to support a requirement, there might be a
missing or misunderstood requirement, or the design must change.
7.3.5 Guidelines and Tools
• Business Objectives: ensure the requirements deliver the desired business
benefits.
• Future State Description: helps to ensure the requirements that are part of
the solution scope do help achieve the desired future state.
• Potential Value: can be used as a benchmark against which the value
delivered by requirements can be assessed.
• Solution Scope: ensures the requirements that provide benefit are within the
scope of the desired solution.
7.3.6 Techniques
Acceptance and Evaluation Criteria: used to define the quality metrics that
must be met to achieve acceptance by a stakeholder.
Requirements Analysis and Design Definition Validate Requirements
147
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Document Analysis: used to identify previously documented business needs in
order to validate requirements.
Financial Analysis: used to define the financial benefits associated with
requirements.
Item Tracking: used to ensure that any problems or issues identified during
validation are managed and resolved.
Metrics and Key Performance Indicators (KPIs): used to select appropriate
performance measures for a solution, solution component, or requirement.
Reviews: used to confirm whether or not the stakeholder agrees that their
needs are met.
Risk Analysis and Management: used to identify possible scenarios that
would alter the benefit delivered by a requirement.
7.3.7 Stakeholders
• All stakeholders: the business analyst, in conjunction with the customer, end
users, and sponsors, has the primary responsibility for determining whether or
not requirements are validated. Other stakeholders may discover problematic
requirements during requirements communication. Therefore, virtually all
project stakeholders are involved in this task.
7.3.8 Outputs
• Requirements (validated): validated requirements and designs are those that
can be demonstrated to deliver benefit to stakeholders and align with the
business goals and objectives of the change. If a requirement or design cannot
be validated, it either does not benefit the organization, does not fall within the
solution scope, or both.
Define Requirements Architecture Requirements Analysis and Design Definition
148
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
7.4 Define Requirements Architecture
7.4.1 Purpose
The purpose of Define Requirements Architecture is to ensure that the
requirements collectively support one another to fully achieve the objectives.
7.4.2 Description
Requirements architecture is the structure of all of the requirements of a change.
A requirements architecture fits the individual models and specifications together
to ensure that all of the requirements form a single whole that supports the
overall business objectives and produces a useful outcome for stakeholders.
Business analysts use a requirements architecture to:
• understand which models are appropriate for the domain, solution scope,
and audience,
• organize requirements into structures relevant to different stakeholders,
• illustrate how requirements and models interact with and relate to each
other, and show how the parts fit together into a meaningful whole,
• ensure the requirements work together to achieve the overall objectives,
and
• make trade-off decisions about requirements while considering the overall
objectives.
Requirements architecture is not intended to demonstrate traceability, but rather
to show how elements work in harmony with one another to support the
business requirements, and to structure them in various ways to align the
viewpoints of different stakeholders. Traceability is often used as the mechanism
to represent and manage these relationships (see Trace Requirements (p. 79)).
Traceability proves that every requirement links back to an objective and shows
how an objective was met. Traceability does not prove the solution is a cohesive
whole that will work.
7.4.3 Inputs
• Information Management Approach: defines how the business analysis
information (including requirements and models) will be stored and accessed.
• Requirements (any state): every requirement should be stated once, and only
once, and incorporated into the requirements architecture so that the entire set
may be evaluated for completeness.
• Solution Scope: must be considered to ensure the requirements architecture is
aligned with the boundaries of the desired solution.
Requirements Analysis and Design Definition Define Requirements Architecture
149
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
Figure 7.4.1: Define Requirements Architecture Input/Output Diagram
7.4.4 Elements
.1 Requirements Viewpoints and Views
A viewpoint is a set of conventions that define how requirements will be
represented, how these representations will be organized, and how they will be
related. Viewpoints provide templates for addressing the concerns of particular
stakeholder groups.
Requirements viewpoints frequently include standards and guidelines for the:
• model types used for requirements,
• attributes that are included and consistently used in different models,
• model notations that are used, and
• analytical approaches used to identify and maintain relevant relationships
among models.
Tasks Using This Output
Output
7.4
Define Requirements
Architecture
Architecture Management
Software
7.4
Requirements
Architecture
5.3
Prioritize
Requirements
3.4
Information
Management
Approach
Requirements
(any state)
Legal/Regulatory
Information
Methodologies and
Framework
5.4
Assess
Requirements
Changes
7.1
Specify and Model
Requirements
7.5
Define Design
Options
6.4
Solution Scope
Input
Guidelines and Tools
Define Requirements Architecture Requirements Analysis and Design Definition
150
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
No single viewpoint alone can form an entire architecture. Each viewpoint is
stronger for some aspects of the requirements, and weaker for others, as
different groups of stakeholders have different concerns. Trying to put too much
information into any one viewpoint will make it too complex and degrade its
purpose. Examples of viewpoints include:
• Business process models,
• Data models and information,
• User interactions, including use cases and/or user experience,
• Audit and security, and
• Business models.
Each of those viewpoints has different model notations and techniques, and each
is important to ensure a cohesive final solution. The solution would likely not be a
success if the business analyst only looked at the business process viewpoint.
Similarly, trying to put conventions from many viewpoints in one single viewpoint
would make it overwhelming to analyze and contain information irrelevant to
particular stakeholder groups.
The actual requirements and designs for a particular solution from a chosen
viewpoint are referred to as a view. A collection of views makes up the
requirements architecture for a specific solution. Business analysts align,
coordinate, and structure requirements into meaningful views for the various
stakeholders. This set of coordinated, complementary views provides a basis for
assessing the completeness and coherence of the requirements.
In short, the viewpoints tell business analysts what information they should
provide for each stakeholder group to address their concerns, while views
describe the actual requirements and designs that are produced.
.2 Template Architectures
An architectural framework is a collection of viewpoints that is standard across an
industry, sector, or organization. Business analysts can treat frameworks as
predefined templates to start from in defining their architecture. Similarly, the
framework can be populated with domain-specific information to form a
collection of views that is an even more useful template to build architecture from
if it is accurate because the information is already populated in it.
.3 Completeness
An architecture helps ensure that a set of requirements is complete. The entire set
of requirements should be able to be understood by the audience in way that it
can be determined that the set is cohesive and tells a full story. No requirements
should be missing from the set, inconsistent with others, or contradictory to one
another. The requirements architecture should take into account any
dependencies between requirements that could keep the objectives from being
achieved.
Structuring requirements according to different viewpoints helps ensure this
Requirements Analysis and Design Definition Define Requirements Architecture
151
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
completeness. Iterations of elicitation, specification, and analysis activities can
help identify gaps.
.4 Relate and Verify Requirements Relationships
Requirements may be related to each other in several ways when defining the
requirements architecture. Business analysts examine and analyze the
requirements to define the relationships between them. The representation of
these relationships is provided by tracing requirements (see Trace Requirements
(p. 79)).
Business analysts examine each relationship to ensure that the relationships
satisfy the following quality criteria:
Defined: there is a relationship and the type of the relationship is
described.
Necessary: the relationship is necessary for understanding the
requirements holistically.
Correct: the elements do have the relationship described.
Unambiguous: there are no relationships that link elements in two
different and conflicting ways.
Consistent: relationships are described in the same way, using the same set
of standard descriptions as defined in the viewpoints.
.5 Business Analysis Information Architecture
The structure of the business analysis information is also an information
architecture. This type of architecture is defined as part of the task Plan Business
Analysis Information Management (p. 42). The information architecture is a
component of the requirements architecture because it describes how all of the
business analysis information for a change relates. It defines relationships for
types of information such as requirements, designs, types of models, and
elicitation results. Understanding this type of information structure helps to
ensure that the full set of requirements is complete by verifying the relationships
are complete. It is useful to start defining this architecture before setting up
infrastructure such as requirements life cycle management tools, architecture
management software, or document repositories.
7.4.5 Guidelines and Tools
• Architecture Management Software: modelling software can help to
manage the volume, complexity, and versions of the relationships within the
requirements architecture.
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed. They may impact the requirements architecture or its
outputs. Additionally, contractual or standards-based constraints may also need
to be considered.
Define Design Options Requirements Analysis and Design Definition
152
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
• Methodologies and Frameworks: a predetermined set of models, and
relationships between the models, to be used to represent different viewpoints.
7.4.6 Techniques
Data Modelling: used to describe the requirements structure as it relates to
data.
Functional Decomposition: used to break down an organizational unit,
product scope, or other elements into its component parts.
Interviews: used to define the requirements structure collaboratively.
Organizational Modelling: used to understand the various organizational
units, stakeholders, and their relationships which might help define relevant
viewpoints.
Scope Modelling: used to identify the elements and boundaries of the
requirements architecture.
Workshops: used to define the requirements structure collaboratively.
7.4.7 Stakeholders
• Domain Subject Matter Expert, Implementation Subject Matter Expert,
Project Manager, Sponsor, Tester: may assist in defining and confirming the
requirements architecture.
• Any stakeholder: may also use the requirements architecture to assess the
completeness of the requirements.
7.4.8 Outputs
• Requirements Architecture: the requirements and the interrelationships
among them, as well as any contextual information that is recorded.
7.5 Define Design Options
7.5.1 Purpose
The purpose of Define Design Options is to define the solution approach, identify
opportunities to improve the business, allocate requirements across solution
components, and represent design options that achieve the desired future state.
7.5.2 Description
When designing a solution, there may be one or more design options identified.
Each design option represents a way to satisfy a set of requirements. Design
options exist at a lower level than the change strategy, and are tactical rather than
strategic. As a solution is developed, tactical trade-offs may need to be made
Requirements Analysis and Design Definition Define Design Options
153
Complimentary IIBA
®
Member Copy. Not for Distribution or Resale.
among design alternatives. Business analysts must assess the effect these trade-
offs will have on the delivery of value to stakeholders. As initiatives progress and
requirements evolve, design options evolve as well.
7.5.3 Inputs
• Change Strategy: describes the approach that will be followed to transition to
the future state. This may have some impact on design decisions in terms of
what is feasible or possible.
• Requirements (validated, prioritized): only validated requirements are
considered in design options. Knowing the requirement priorities aids in the
suggestion of reasonable design options. Requirements with the highest
priorities might deserve more weight in choosing solution components to best
meet them as compared to lower priority requirements.
• Requirements Architecture: the full set of requirements and their
relationships is important for defining design options that can address the
holistic set of requirements.
Figure 7.5.1: Define Design Options Input/Output Diagram
Tasks Using This Output
Output
7.5
Define Design Options
Existing Solutions
7.5
Design Options
6.4
Define Change
Strategy
6.4
Change Strategy
5.3, 7.3
Requirements
(validated,
prioritized)
Future State Description
Requirements (traced)
7.6
Analyze Potential
Value and
Recommend