Business Analysis (p160-199)

Business Analysis Knowledge Areas 141
• Item Tracking
• Lessons Learned
• Organizational Modelling
• Process Modelling
• Reviews
• Survey or Questionnaire
• Workshops
Stakeholders Involved during Business Analysis Governance
Planning
• Domain Subject Matter Expert
• Project Manager
• Regulator
• Sponsor
Output
Governance Approach – according to the Business Analysis Book of
Knowledge, the governance approach identifies the stakeholders who will
have the responsibility and the authority to make decisions about business
analysis work. This will also include identifying who will be responsible
for setting priorities. They will also be responsible and authorized to
approve changes to the business analysis information. It also defines the
process that will be used to monitor and manage requirement and design
changes across the initiative.
Plan Business Analysis Information Management

Plan Business Analysis Information, as described in the Business
Analysis Book of Knowledge, aims to develop an approach for how
the business analysis information will be stored and accessed. Business
analysis information is composed of all the information a business
analyst stimulates, creates, compiles, and distributes in the course of
performing business analysis. Information management aids in ensuring
that business analysis information is organized in a functional and useful
manner is easily accessible to appropriate and authorized personnel and
is stored for the necessary length of time. Information management
involves identifying the following:
142 Business Analysis
• The approach in organizing information,

• The level of detail at which information should be captured
(e.g. process and sub-processes)
• Any relationships and trends between the information
• How information may be used across multiple initiatives and
throughout the organization
• How information should be accessed, retrieved, and stored
• Characteristics or metadata about the information that must be
maintained
Inputs
Business Analysis Approach – the overall business analysis approach
should be incorporated into the information management approach to
ensure the uniformity across different approaches
Governance Approach – the government approach will define 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 the
communication and collaboration needs of the stakeholders involved is
useful in properly determining specific information management needs.
Business analysts determine the best way to structure and organize
business analysis information when an initiative has been started. This
involves considering the type and amount of information to be collected,
the stakeholder’s access and usage needs, and the size and complexity
of the change. The business analyst also needs to define the relationship
among the types of information to assist in managing any effect of new
or changed information in the future.
The business analyst also needs to identify the depth of information
to be provided as needed by the stakeholders requiring the information.
Representations may range from high-level concepts or summarized
information to very detailed kind of information.
Business analysts also need to plan for requirements reuse. Reusing
requirements can later save an organization’s effort, time, and cost.
Requirements must be clearly named, defined, and stored in a repository
in order to be effectively reused.

Organizational standards and tool availability influence storage
and access to information. Aside from the information concerning the
requirements and design, the repository must also be able to indicate the
status of any stored information and allow alterations of that information
over time.
Some commonly used requirements attribute includes:
• Absolute reference
• Author
• Complexity
• Ownership
• Priority
• Risks
• Source
• Stability
• Status
• Urgency
There are different guidelines and tools a business analyst can utilize
during the business analysis information management planning.
Table 13: Guidelines and Tools for Planning Information Management

(BABOK v3, 2015)
Guidelines and Tools Description

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 regula-
tions, contracts, agreements, warranties,
certifications, or other legal obligations
Information Management Tools Each organization uses some tools to store,
retrieve, and share business analysis informa-
tion. 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 man-
aged
Techniques for Planning Information Management

• Brainstorming
• Interviews
• Item Tracking
• Lessons Learned
• Mind Mapping
• Workshops
Stakeholders Involved during Business Analysis Governance
Planning
• Regulator
• Sponsor
Output
Information Management Approach – the information management
approach includes the identified approach on how business analysis
information will be stored, accessed, and used during and after a change
is completed
Identify Business Analysis Performance Improvements

Identification of Business Analysis Performance Improvements, as
described in the Business Analysis Book of Knowledge, aims to assess
business analysis work and to plan areas where process improvements
are required. It is essential to establish the performance measures,
conduct performance analysis, report on the results of the analysis, and
identify any necessary preventive, correct, or developmental actions.
Performance analysis should be iterative throughout an initiative as areas
of performance improvements become guidelines for the next time a task
is executed. Measuring performance is important in management as the
famous quotation of Peter Drucker says “Whatever gets measured, gets

managed”.
Inputs
Business Analysis Approach – all business analysis deliverables to be
produced as well as the activities involved, and the techniques to be used
will be identified
Performance Objectives (external) – describes the desired
performance outcomes the business is aiming to achieve
Reports on the performance of business analysis can be formal and
with documentation or it can be informal and verbal. The reports are
designed depending on the needs of the reviewers or recipients of the
report.
Some of the possible assessment measures as defined in BABOK v3
are:
• Accuracy and Completeness
• Knowledge
• Effectiveness
• Organizational Support
• Significance
• Strategic
• Timeliness
The business analysis processes and deliverables are then compared
against the identified sets of measures and once the performance analysis
has been completed, the authorized stakeholders recommend actions
which may be preventive, corrective, or generally an improvement in
nature.
Below is a guideline and tool during the identification of business
analysis process improvement.
Table 14: Guideline and Tool for Identification of Performance Improvement

(BABOK v3, 2015)

Organizational Performance Standards may include performance metrics, key
performance indicators, or expectations for
business analysis work mandated by the
organization
Techniques for the Identification of Business Analysis Performance

Improvement
• Brainstorming
• Interviews
• Item Tracking
• Lessons Learned
• Metrics and Key Performance Indicators (KPIs)
• Observation
• Process Analysis
• Reviews
• Risk Analysis and Management
• Root Cause Analysis
• Workshops
Stakeholders Involved during Business Analysis Performance
Improvement
• Project Manager
• Sponsor
Output
Business Analysis Performance Assessment – the business analysis
performance assessment is a comparison of the planned versus actual
performance of the business analysis processes. It identifies the root cause
of variances between the expected and actual and proposes approaches to
narrow the variance.
REQUIREMENTS GATHERING AND

COLLABORATION
The Requirements Gathering (Elicitation) and Collaboration knowledge
area consist of the tasks that the business analysts perform to gather
information from stakeholders and verify the results. According to the
Business Analysis Body of Knowledge v3, Elicitation is the process
of gathering of data 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 cooperating and working
together towards a common goal. The Elicitation and Collaboration
knowledge area describes how business analysts identify and reach a
settlement until they come with an 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.”
Below table summarizes the Business Analysis Elicitation and
Collaboration knowledge area tasks and their corresponding description:
Table 15: Business Analysis Elicitation and Collaboration Tasks. BABOK v3

Guide 2015
Tasks Description
Prepare for Requirements involves making sure that the stakeholders have the
Gathering information they need to provide and that they understand
the types of 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 prepare to hold an experiment to see
if a process change actually results in an improvement
Conduct Requirements Gath- describes the work performed to understand stakeholder
ering needs and identify potential solutions that may meet those
needs. This may involve direct interaction with stakehold-
ers, doing research, or running experiments
Confirm Elicitation Results involves ensuring that stakeholders have a shared under-
standing of the outcomes of elicitation, that elicited in-
formation is recorded appropriately, and that the business
analyst has the information sought from an elicitation
activity. This task also involves comparing the informa-
tion received with other information to look for inconsis-
tencies or gaps
Communicate Business provides stakeholders with the information they need

Analysis Information in a timely manner that they need it. The information is
presented in a useful form, using the right jargon and
concepts
Manage Stakeholder Collabo- describes working with stakeholders to engage them in
ration the overall business analysis process and to ensure that
the business analyst can deliver the expected outcomes
The table below which was based from Business Analysis Body of
Knowledge (BABOK) Guide v3 describes the usage and application
of each of the BACCM core concepts within the context of Business
Analysis Requirements Gathering and Collaboration.
Table 16: Usage of BACCM in Business Analysis Requirements Gathering and

Collaboration
Core Concept During Business Analysis Requirements Gathering and

Collaboration, business analysts...
Change: the act of trans- …use a variety of requirements techniques to fully identify
formation in response to the characteristics of the change including concerns that
a need stakeholders have about the change. The change itself may
determine the appropriate types and extent of elicitation and
collaboration
Need: a problem or oppor- …gather requirements, confirm, and communicate needs and
tunity to be addressed supporting business analysis information. As requirements
gathering is iterative and incremental, the understanding of
needs may evolve over time
Solution: a specific way of gather requirements, confirm and communicate necessary or
desired characteristics of proposed solutions
satisfying one or more
needs in a context
Stakeholder: a group or …manage the collaboration with the stakeholders who
participate in the business analysis work. All stakeholders
individual with a relation- are expected to participate in different roles and at different
ship to the change, the times during a change
need, or the solution
Value: the worth, impor- …work together with stakeholders to assess the relative
tance, or usefulness of value of information provided through elicitation, and apply
something to a stakeholder a variety of techniques to confirm and communicate that
within a context. value
Context: the circumstances …apply a variety of requirements gathering techniques to
that influence, are influ- identify business analysis information about the context that
enced by, and provide un- may affect the change
derstanding of the change
Figure 5: Requirements Gathering and Collaboration Input/ Output Diagram,

BABOK v3 2015.
As previously discussed, there are five tasks related to Business
Analysis Elicitation and Collaboration. These are: Prepare for Elicitation,
Conduct Elicitation, Confirm Elicitation Results, Communicate Business

Analysis Information, and Manage Stakeholder Collaboration.
Prepare for Requirements Gathering

Preparation for Requirements Gathering or Elicitation, as described in
the Business Analysis Book of Knowledge, aims to understand the scope
of the elicitation activity, select the appropriate techniques, and plan
for appropriate supporting materials and resources. Business analysts
prepare for elicitation by determining the desired outcomes of the activity,
considering the stakeholders involved and the goals of the initiative.
Inputs
Needs – requirements gathering 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 fully been understood
Stakeholder Engagement Approach – understanding the different
communication and collaboration needs of the stakeholders are needed to
plan and prepare appropriate and effective elicitation events
Business analysts should understand the scope of elicitation so that
he or she may respond appropriately in case an activity strays from the
initially defined scope. According to the BABOK Guide, the following
items must be considered by the business analysts to determine the type
of business analysis information to be discovered:
• 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
• Strategy or solution approach
• Scope of future solution
The business analyst should also inform the stakeholders involved,
if any, on how the elicitation technique works and what information is
truly needed. Doing so will help them understand the validity and the
importance of the information being elicited. Some initiatives, however,
require the business analyst to do research and exploration which no

longer needs the preparation of the business analyst.
Below are the guidelines and tools during the preparation for
requirements gathering.
Table 17: Guidelines and Tools for Preparing for Requirements Gathering
(BABOK v3, 2015)

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 elicita-
tion 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 elici-
tation events and to develop supporting materials
Existing Business Analysis may provide a better understanding
Information
of the goals of the elicitation activity, and aid in prepar-
ing for elicitation
Potential Value describes the value to be realized by implementing the
proposed future state, and can be used to shape elicita-
tion events
Techniques for the Preparation for Requirements Gathering

• Brainstorming
• Data Mining
• Document Analysis
• Estimation
• Interviews
• Mind Mapping
• Stakeholder List, Map, or Personas
Stakeholders Involved during Preparation for Requirements
Gathering
• Project Manager
• Sponsor
Output
Elicitation Activity Plan – the elicitation activity plan will be used for
each requirement gathering activity. The plan includes logistics, scope of
the requirements gathering activity, selected techniques, and supporting
materials
Conduct Requirements Gathering

Conducting Requirements Gathering or Elicitation, as described in the
Business Analysis Book of Knowledge, aims to draw out, explore, and
identify information which is relevant to the change. The BABOK Guide
lists down three common types of elicitation:
• Collaborative – involves direct interaction with stakeholder
and relies heavily on their expertise, experience, and judgment
• Research – involves the systematical way of discovering and
studying information from materials which are indirectly
known by the stakeholders involved in the change. Research
can involve data analysis of historical data to identify trends
and patterns from the past results.
• Experiments – experiments can be done to identify information
which could not be known without some sort of controlled
test. Experiments can include observational studies, proofs of
concept, and prototypes
Inputs
Elicitation Activity Plan: According to the Business Analysis Body of
Knowledge, this lists the planned elicitation activities and techniques;
activity logistics such as date, time location, resources and agenda;
scope of the elicitation activity, and the available sources of background
information
Capturing Elicitation Outcomes is frequently iterative and happens in
a series of sessions, whether in parallel or in sequence, according to the
scope of the elicitation activity.
Below are the guidelines and tools when conducting requirements
gathering.
Table 18: Guidelines and Tools for Conducting a Requirements Gathering

(BABOK v3, 2015)

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 stakehold-
ers
Stakeholder Engagement Approach provides collaboration and communica-
tion approaches that might be effective
during elicitation
Supporting Material 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
Techniques when Conducting Requirements Gathering

• Benchmarking and Market Analysis
• Brainstorming
• Business Rules Analysis
• Collaborative Games
• Concept Modelling
• Data Mining
• Data Modelling
• Focus Groups
• Interface Analysis
• Interviews
• Mind Mapping
• Observation
• Process Analysis
• Prototyping
• Workshops
Stakeholders Involved when Conducting Requirements Gathering
• Customer
• End User
• Implementation Subject Matter Expert
• Sponsor
• Other Stakeholders who could have relevant knowledge to
participate in the elicitation activities
Output
Elicitation Results (unconfirmed) – the unconfirmed elicitation results
are captured in a format which is specific to the elicitation activity
Confirm Elicitation Results

Confirming the Elicitation Results, as described in the Business Analysis
Book of Knowledge, aims to check and verify the information gathered
during requirements gathering session for accuracy and consistency
with other information. Elicited information is confirmed to identify any
issues such as errors, omissions, conflicts, and ambiguity and resolve
them even before resources commit in utilizing the information.
Inputs
Elicitation Results (unconfirmed) – formats of the captured information
vary depending on the elicitation activity.
As described in the Business Analysis Book of Knowledge, the task
of Conducting Elicitation describes the sources from which elicitation
results may be derived, including documents and stakeholder knowledge.
Business analysts should compare results collected through multiple
elicitation activities to check and confirm whether the information is
consistent and accurately represented. Business analysts should develop
specifications and models in order to uncover any inconsistencies in
elicitation results. These models may be developed during an elicitation
activity to improve collaboration.
Below are the guidelines and tools when confirming elicitation

results.
Table 19: Guidelines and Tools for Confirmation of Elicitation Results (BABOK
v3, 2015)

Elicitation Activity Plan used to guide which alternative sources
and which elicitation results are to be
compared
Existing Business Analysis Infor- can be used to confirm the results of
mation elicitation activities or to develop addi-
tional questions to draw out more detailed
information
Techniques for the Confirmation of Elicitation Results
• Interviews
• Reviews
• Workshops
Stakeholders Involved when Confirming Elicitation Results
• Domain Subject Matter Experts
• Other stakeholders who may need to participate in confirming
elicitation results
Output
Elicitation Results (confirmed): as defined in the BABOK v3, the
confirmed elicitation result is the 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.
Communicate Business Analysis Information

Communicating Business Analysis Information, as described by the
Business Analysis Book of Knowledge, aims to make sure that the
stakeholders have a shared understanding of business analysis information.
Business analysts must be able to deliver the appropriate information
to the stakeholders at the right time and in the formats that meet their
needs. Some of the things to be considered in expressing the information
are the language, tone, body language, and style that is appropriate to
the audience. Communication of business analysis information is two-
way and iterative. It does not simply involve pushing the information out
and assuming the information was received and understood as intended.
Engagement of stakeholders to gain agreement and ensure understanding
must be done and any disagreements must be acted upon by the business
analyst.
Inputs
Business Analysis Information – As defined in the BABOK Guide, a
business analysis information is 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.
Various kinds of packages could be used to communicate analysis
information. It can be in Formal Documentation which is more
preferred to use when a long-term record of information is given. It also
usually based on templates of text, matrices or diagrams. However, some
prefer to use Informal Documentation which includes text, diagrams
or matrices that are used during a change but are not necessarily part
of a formal business process. Lastly, some people prefer the last form
of package for an effective business analysis information and this is
through Presentations. In addition, this method is preferred to use when
delivering high-level overview information.
Functions of solutions or information to support decision-making
relevant to a change is used to understand goals of a change. In fact,
various platforms can also be seen to be used in communicating business
analysis information and these platforms that are commonly used are
Group Collaboration which allows immediate discussion about
the information and any related issues of the business; Individual
Collaboration which can be used when group setting is not feasible or
if it is deemed necessary to yield the best results and lastly; Email or
other non-verbal methods which are used when no verbal explanation
is needed to support the level of information presented. Below are the
guidelines and tools when communicating business analysis information.
Table 20: Guidelines and Tools for Communicating Business Analysis Infor-
mation (BABOK v3, 2015)

Business Analysis Approach This approach describes how the various types
of information will be spread rather than what
will be disseminated. Moreover, it describes the
level of detail and formality required, frequency
of the communications, and how communica-
tions could be affected by the number and
geographic dispersion of
stakeholders
Information Management Ap- This helps determine how business analysis
proach
information will be packaged and communi-
cated to stakeholders
Techniques for Communicating Business Analysis Information
• Interviews
• Reviews
• Workshops
Stakeholders Involved when Communicating Business Analysis
Information
• End User
• Customer
• Tester
• Other stakeholder who will likely need to be communicated
with at some point during the change initiative
Output
Business Analysis Information (communicated) – business analysis
information, as described by BABOK v3, is considered as communicated
when the target stakeholders have reached an understanding of its content
and implications.
Manage Stakeholder Collaboration

Managing the Stakeholder Collaboration, as described in the Business
Analysis Book of Knowledge, aims to encourage stakeholders to work
towards a common goal. This collaboration is an ongoing activity. The
more significant an impact of a change is, or the higher the visibility of
the change is within the organization, the more attention is directed to
managing stakeholder collaboration. Business analysts should manage
the stakeholder collaboration to capitalize on positive reactions and
mitigate or avoid negative reactions. If the poor relationship with the
stakeholders is established then there might be negative effects on the
business analysis activities. Some detrimental effects of having poor
stakeholder relationships as listed in the BABOK v3 are the following:
• 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
Inputs
Stakeholder Engagement Approach – the stakeholder engagement
approach describes the types of expected engagement with stakeholders
and how might they need to be managed
Business Analysis Performance Assessment – the assessment will
provide key information about the effectiveness of business analysis
tasks.
According to BABOK Guide v3, Business Analysts need to monitor
the participation and performance of stakeholders to ensure that the right
subject matter experts 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. Stakeholders are more likely to support change if business
analysts collaborate with them and encourage the free flow of information,
ideas, and innovations. Collaborative relationships help maintain the free
flow of information when obstacles and setbacks occur.
Below are the guidelines and tools when managing stakeholder

collaboration.
Table 21: Guidelines and Tools for Managing Stakeholder Collaboration

(BABOK v3, 2015)

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 stake-
holders 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 stake-
holders 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 suc-
cessful
Techniques for Managing Stakeholder Collaboration

• Collaborative Games
• Lessons Learned
• Stakeholder List, Map, or Personas
Stakeholders Involved when Managing Stakeholder Collaboration
• All stakeholders
Output
Stakeholder Engagement – as defined by BABOK Guide, stakeholder
engagement is the willingness from stakeholders to engage in business
analysis activities and interact with the business analyst as necessary
REQUIREMENTS LIFE CYCLE

MANAGEMENT
The Requirements Life Cycle Management knowledge area, as described
in the Business Analysis Body of Knowledge, describes the tasks that

business analysts perform in order to manage and maintain requirements
and design information from inception to retirement. The purpose of
this knowledge area is to ensure that business stakeholder, and solution
requirements and designs are aligned to one another and that the
solution implements them. The requirements life cycle begins with the
representation of 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.
Figure 6: Requirements Life Cycle Management (BABOK v3, 2015).

Below table summarizes the Business Analysis Requirements Life
Cycle Management knowledge area tasks and their corresponding
description:
Table 22: Business Analysis Requirements Life Cycle Management Tasks.
BABOK v3 Guide 2015
Tasks Description
Trace Requirements analyzes and maintains the relationships be-
tween requirements, designs, solution compo-
nents, 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 en-
sure 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 gover-
nance process to reach approval and agreement
on requirements and designs
Analysis Requirements Life Cycle Management.
Table 23: Usage of BACCM in Business Analysis Requirements Life Cycle

Management
Core Concept During Business Analysis Requirements Life Cycle Man-

agement business analysts...
Change: the act of …manage how proposed changes to requirements and designs
transformation in are evaluated during an initiative.
response to a need
Need: a problem or …trace, prioritize and maintain requirements to ensure that the
opportunity to be ad- need is met
dressed
Solution: a specific …trace requirements and designs to solution components to
way of ensure that the solution satisfies the need
satisfying one or more
needs in a context
Stakeholder: a group …work closely with key stakeholders to maintain understand-
or ing, agreement, and approval of requirements and designs
individual with a
relationship to the
change, the need, or the
solution
Value: the worth, …maintain requirements for reuse to extend value beyond the
importance, or useful- current initiative
ness of something to
a stakeholder within a
context.
Context: the circum- …analyze the context to support tracing and prioritization
stances that influence, activities.
are influenced by, and
provide understanding
of the change
Figure 7: Requirements Life Cycle Management Input/ Output Diagram.

As previously discussed, there are five tasks related to Business

Analysis Requirements Life Cycle Management. These are: Trace
Requirements, Maintain Requirements, Prioritize Requirements, Assess
Requirements Changes, and Approve Requirements.
Trace Requirements
Tracing requirements, as described by the Business Analysis Book of
Knowledge (BABOK) v3 aims to ensure that requirements and designs
at different levels are aligned to one another, and to manage the effects of
the change to one level on related requirements. 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. Traceability enables faster and
simpler impact analysis, the 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.
Figure 8: Process and Software Requirements Traceability Inputs.

Requirements – requirements may be traced to other requirements,
solution components, visuals, business rules, and other work products
Designs – designs may be traced to other requirements, solution
components, and other work products
The effort to trace requirements in proportional to the number of
requirements and the level of formality. According to BABOK, there
are several types of relationships that a business analyst should consider
when determining the traceability approach:
• Derive – relationship between two requirements; used when a
requirement is derived from another requirement
• Depends – relationship between two requirements; used when
a requirement depends on another requirement, can either be a
Necessity or Effort
• Satisfy – relationship between an implementation element and
the requirements it is satisfying
• Validate – relationship between a requirement and a test case
or other element that can determine whether a solution fulfills
the requirement
Requirements traceability is documented in accordance with the
methods identified by the business analysis approach. Some organizations
develop a requirements traceability matrix which can be used for any
business analysis initiative.
Below are the guidelines and tools when tracing requirements.
Table 24: Guidelines and Tools for Tracing Requirements (BABOK v3, 2015)

Business Area Knowledge knowledge of and expertise in the business area
needed to support traceability
Information Management Approach provides decisions from planning activities con-
cerning the traceability approach
Legal/ Regulatory Information describes governmental rules or regulations that
must be followed. These may need to be considered
when determining traceability rules
Requirements Management Tools/ used to store and manage business analysis infor-
Repository mation. The tool may be as simple as a text docu-
ment or as complex as a dedicated requirements
management tool.
Table 24: Guidelines and Tools for Tracing Requirements (BABOK v3, 2015)
Techniques for Tracing Requirements
• Functional Decomposition
• Scope Modelling
Stakeholders Involved when Tracing Requirements
• Customers
• End User
• Operational Support
• Project Manager
• Sponsor
• Suppliers
• Tester
Outputs
Requirements (traced) – as defined by BABOK, requirements
with clearly defined relationships with other requirements, solution
components, or releases, phases, or iterations, within a solution scope

such that coverage and the effects of the change are clearly identifiable
Designs (traced) – as defined by BABOK, designs with clearly
defined relationships with other requirements, solution components, or
releases, phases, or iterations, within a solution scope such that coverage
and the effects of the change are clearly identifiable
Maintain Requirements
Maintaining Requirements, as defined by the Business Analysis Book
of Knowledge (BABOK) v3, aims to retain requirement accuracy
and consistency throughout and beyond the change during the entire
requirements lifecycle and to support reuse of requirements in other
solutions. Requirements which represent ongoing needs should be
maintained to ensure that it remains valid over time.
Inputs
Requirements: as defined in BABOK v3, requirements include goals,
objectives, business requirements, stakeholder requirements, solution
requirements, and transition requirements. These should be maintained
throughout their life cycle
Designs: designs can also be maintained to ensure validity over time
Business analysts should maintain requirements to ensure that they
remain correct and current after an approved change. It is important that
the level of accuracy of the requirements is retained. Information such
as the source, priority, and complexity of the requirement should be
managed throughout the life cycle. If an organization succeeds in clearly
identifying, naming, and storing their requirements in a manner that
makes them easily retrievable, then those requirements are candidates
for long-term use.
Below are the guidelines and tools when maintaining requirements.
Table 25: Guidelines and Tools for Maintaining Requirements (BABOK v3,
2015)

Information Management Approach indicates how requirements will
be
managed for reuse
Techniques for Maintaining Requirements
• Data Flow Diagrams
• Data Modelling
• Functional Decomposition
• Use Cases and Scenarios
• User Stories
Stakeholders Involved when Maintaining Requirements
• Regulator
• Tester
Outputs
Requirements (maintained) – maintained requirements are defined
once they become available for long-term usage by the organization.
Designs (maintained) – maintained designs become reusable when
defined
Prioritize Requirements
Prioritizing Requirements, as described by the Business Analysis Book
of Knowledge (BABOK) v3, aims to rank a number of requirements
in the order of relative importance. When a requirement is prioritized,
it is given either a greater or a lesser priority. Identifying any inter-
dependencies between requirements may be used as the basis for

prioritization. Prioritization is a critical activity that ensures maximum
value is achieved.
Inputs
Requirements – any requirements in the form of text, matrix, or
diagrams which are ready to be prioritized
Designs – any designs in the form of text, prototypes, or diagrams
that are ready to be prioritized.
The basis of prioritization is agreed with by relevant stakeholders as
defined in the Business Analysis Planning and Monitoring knowledge
area. According to BABOK v3, below are the typical factors that influence
prioritization:
• Benefit
• Penalty
• Cost
• Risk
• Dependencies
• Time Sensitivity
• Stability
• Regulatory or Policy Compliance
Since prioritization is an assessment of relative value and each
stakeholder may value things differently, conflicts may occur among the
stakeholders. Sometimes there may be a need for stakeholders to make
trade-offs in the prioritization process.
Below are the guidelines and tools when prioritizing requirements.
Table 26: Guidelines and Tools for Prioritizing Requirements (BABOK v3,
2015)

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 the
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
Requirements Management including a requirements attribute for prioritiza-
Tools/ Repository tion can help the business analyst to sort and
access requirements by priority.
Solution Scope considered when prioritizing requirements to
ensure scope is
managed
Techniques for Prioritizing Requirements
• Backlog Management
• Business Cases
• Decision Analysis
• Estimation
• Financial Analysis
• Interviews
• Item Tracking
• Prioritization
• Workshops
Stakeholders Involved when Prioritizing Requirements
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
Outputs
Requirements (prioritized) – ranked or prioritized requirements when
available ensure the highest valued requirements are addressed first
Designs (prioritized) – ranked or prioritized designs ensure that the

highest valued designs are addressed first
Assess Requirements Changes

Assessing Requirements Changes, as defined in the Business Analysis
Book of Knowledge, aims to evaluate the implications of proposed
changes to requirements and designs. Assessing Requirements Changes
is a task performed as new needs or possible solutions are identified.
Business analysts should assess the potential effect of the change and
whether any of the proposed changes introduce conflicts with other
requirements or will increase the level of risk. Business analysts should
ensure that each proposed change can be traced back to a need.
Inputs
Proposed Change – proposed changes can be identified at any time and
may impact any aspect of business analysis work
Requirements – requirements may need to be assessed to identify
the impact of a proposed change
Designs – designs may need to be assessed to identify the impact of
a proposed change
According to BABOK v3, when considering changes or additions
to existing requirements, business analysts assess the impact of the
proposed change by considering:
• Benefit
• Cost
• Impact
• Schedule
• Urgency
Below are the guidelines and tools when assessing requirements
changes.
Table 27: Guidelines and Tools for Assessing Requirements Changes (BABOK
v3, 2015)

Change Strategy describes the purpose and direction for changes, es-
tablishes the context for the change, and identifies the
critical components of 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, there-
fore the business analyst examines and analyzes the
requirement
relationships to determine which requirements will be
impacted by a requested requirement change
Solution Scope must be considered when assessing changes to fully
understand the impact of a proposed change
Techniques for Assessing Requirements Changes

• Business Cases
• Estimation
• Financial Analysis
• Interviews
• Item Tracking
• Workshops
Stakeholders Involved when Assessing Requirements Changes
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
• Tester
Outputs
Requirements Change Assessment – this contains the recommendation
to approve, modify, or deny a proposed change to requirements
Designs Change Assessment – this contains the recommendation
to approve, modify, or deny a proposed change to one or more design
components
Approve Requirements
The Approval of Requirements, as defined by the Business Analysis Book
of Knowledge (BABOK) v3, aims to obtain agreement on and approval
of requirements and designs for business analysis work to continue and/
or solution construction to proceed. Business analysts should ensure
clear communication of requirements, designs, and other business
analysis information to the key stakeholders responsible for approving
that information.
Inputs
Requirements (verified) – as defined by BABOK, 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 – as defined by BABOK, a set of designs that have been
determined as ready to be used for further specification and development.
Business analysts should obtain stakeholder approvals and understand
who holds the decision-making responsibility and the authority to sign-
off requirements and design for the initiative. The consensus among
stakeholders is usually sought prior to requesting approval to maintain
stakeholder support for the solution. Stakeholder groups frequently have
varying points and clashing priorities. Conflicts may arise with their
various interpretations of requirements and design. This is where the
business analyst should come in and facilitate 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 will commonly occur while the business analyst reviews the
requirements and designs and while aiming to secure the stakeholders’
sign-off.
Business analysts are responsible for recording approval decisions
through requirements maintenance and tracking tools. An audit history
of changes on requirements and design containing what was changed,
who made the change, the reason for the change, when It was made will
greatly help in requirements and design maintenance.
Below are the guidelines and tools when approving requirements.
Table 28: Guidelines and Tools for Approving Requirements (BABOK v3,
2015)

Change Strategy provides information which assists in managing
stakeholder consensus regarding the needs of all
stakeholders
Governance Approach identifies the stakeholders who have the author-
ity and responsibility to approve business analysis
information, and explains when such approvals will
take place and how they will align with organiza-
tional 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/ tool to record requirements approvals
Repository
Solution Scope must be considered when approving requirements to
accurately assess alignment and completeness
Techniques for Approving Requirements

• Acceptance and Evaluation Criteria
• Item Tracking
• Reviews
• Workshops
Stakeholders Involved when Approving Requirements

• Customer
• Domain Subject Expert
• End User
• Project Manager
• Regulator
• Sponsor
• Tester
Outputs
Requirements (approved) – according to BABOK, approved
requirements are requirements which are agreed to by stakeholders and
are ready for use in the subsequent business analysis activities
Designs (approved) – according to BABOK, approved designs are
designs which are agreed to by stakeholders and are ready for use in
subsequent business analysis and solution development activities
STRATEGY ANALYSIS
The Strategy Analysis knowledge area, as described in the Business
Analysis Body of Knowledge, 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 provides
context to requirements analysis and design definition for a given change.
Strategy analysis should be performed as a business need is identified to
allow stakeholders to make a decision whether to address that need or
not. The image below illustrates the business analysis value spectrum as
the business analysis activities progress from delivering potential value
to actual value.
Figure 9: Business Analysis Strategy Analysis Value Spectrum (BABOK v3,

2015).
Below table summarizes the Business Analysis Strategy Analysis
knowledge area tasks and their corresponding description:
Table 29: Business Analysis Strategy Analysis. BABOK v3 Guide 2015
Tasks Description
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 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
the 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
Analysis Strategy Analysis.
Table 30: Usage of BACCM in Business Analysis Strategy Analysis
Core Concept During Business Analysis Strategy Analysis

business analysts...
Change: the act of transfor- …define the future state and develop a change
mation in response to a need strategy to achieve the future state.
Need: a problem or opportu- …identify needs within the current state and
nity to be addressed prioritize needs to determine the desired future
state
Solution: a specific way of …define the scope of a solution as part of devel-

oping a change strategy.
satisfying one or more needs
in a context
Stakeholder: a group or …collaborate with stakeholders to understand

the business need and to develop a change strat-
individual with a relationship egy and future state that will meet those needs
to the change, the need, or the
solution
Value: the worth, importance, …examine the potential value of the solution to
or usefulness of something to determine if a change is justified
a stakeholder within a context.
Context: the circumstances …consider the context of the enterprise in devel-

that influence, are influenced oping a change strategy
by, and provide understanding
of the change
Figure 10: Business Analysis Strategy Analysis Input/ Output Diagram,

BABOK v3 2015.
As previously discussed, there are four tasks related to Business

Analysis Strategy Analysis. These are: Analyze Current State, Define
Future State, Assess Risks, Define Change Strategy.
Analyze Current State

According to the Business Analysis Book of Knowledge (BABOK) v3.
Analyzing Current State (or the As-is as described by some business
analysis practitioners) aims 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. Any change starts with
understanding why the change is needed. Problems or opportunities that
cannot be addressed without altering the current state are the triggers of
a potential change. Business analysts work to help stakeholders enable
change by exploring and articulating the business needs that drive the
desire to change, the Current state can be described on different levels,
ranging from the entire enterprise to small components of a solution.
Models of the current state, when created, usually requires collaboration
throughout or outside the enterprise. The current state of an enterprise
is rarely static during the development and implementation of a change.
Both internal and external influencers and even organizational changes
can affect the current state in ways that force alterations in the desired
future state or to-be state, change strategy, or requirements and designs.
Inputs
Elicitation Results – the data gathering results are used to define and
understand the current state
Needs – problems and opportunities faced by an enterprise or
organization triggers business analysis work to further understand the
business needs
According to BABOK v3, a business need may be identified at many
different levels of an enterprise:
• From the top-down
• From the bottom-up
• From the middle management
• From external drivers
The elements involved when determining the current state are the
following:
1. Business Needs
Determining business needs is usually the most critical step in any
business analysis effort. The same way that Charles Kettering said that
“A problem well stated is a problem half solved”, business needs have
to be well defined to ensure that the solution to be provided would truly
address a business need. Business needs should always be expressed from
the perspective of the enterprise, and not of any particular stakeholder.
Business needs drive the overall analysis of the current state and the
business analyst should identify the assumptions and constraints to ensure
that the correct problem is being solved and the range of alternative
solutions are considered.
2. Organizational Structure and Culture

As defined in BABOK v3, business analyst should perform cultural
assessment to identify if cultural changes are required to better achieve
goals, 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

A business analyst can either use a capability-centric view or a process-
centric view. A capability-centric view is used when looking for
innovative solutions that combine existing capabilities to produce a new
outcome while a process-centric view is used when looking for ways to
improve the performance of the current activities being performed in the
organization.
4. Technology and Infrastructure

Technology and infrastructure used by an enterprise support people
in executing processes. Infrastructure can include components like
computer hardware and logistics.
5. Policies
Policies are used to define the scope of decision-making at different
levels of an enterprise. They address concerns involving routine
operations rather than strategic change by providing guidance to staff on
the permitted and appropriate behavior and actions.
6. Business Architecture
Business analysts should understand how all of the elements of the
current state fit together and support one another so that changes can be
effectively recommended.
7. Internal Assets
Internal assets used in the current state should be identified whether these
resources are tangible or intangible.
8. External Influencers
The external influencers do not necessarily participate in a change but
might present constraints, dependencies, or drivers on the current state.
Some of the external influencers as defined in BABOK v3 include:
• Industry Structure
• Competitors
• Customers
• Suppliers
• Political and Regulatory Environment
• Technology
• Macroeconomic Factors
Below are the guidelines and tools when analyzing the current state.
Table 31: Guidelines and Tools for Assessing Current State (BABOK v3, 2015)

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

Business Analysis (p160-199)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysis (p160-199)

Uploaded by

Copyright:

Available Formats

Business Analysis Knowledge Areas 141

Plan Business Analysis Information Management

• The approach in organizing information,

in order to be effectively reused.

Table 13: Guidelines and Tools for Planning Information Management

Guidelines and Tools Description

Legal/ Regulatory Information describes legislative rules or regulations that

Techniques for Planning Information Management

Identify Business Analysis Performance Improvements

famous quotation of Peter Drucker says “Whatever gets measured, gets

Table 14: Guideline and Tool for Identification of Performance Improvement

Guidelines and Tools Description

Techniques for the Identification of Business Analysis Performance

REQUIREMENTS GATHERING AND

Table 15: Business Analysis Elicitation and Collaboration Tasks. BABOK v3

Communicate Business provides stakeholders with the information they need

Table 16: Usage of BACCM in Business Analysis Requirements Gathering and

Core Concept During Business Analysis Requirements Gathering and

Figure 5: Requirements Gathering and Collaboration Input/ Output Diagram,

Conduct Elicitation, Confirm Elicitation Results, Communicate Business

Prepare for Requirements Gathering

require the business analyst to do research and exploration which no

Guidelines and Tools Description

Techniques for the Preparation for Requirements Gathering

Conduct Requirements Gathering

Table 18: Guidelines and Tools for Conducting a Requirements Gathering

Guidelines and Tools Description

Techniques when Conducting Requirements Gathering

Confirm Elicitation Results

Below are the guidelines and tools when confirming elicitation

Guidelines and Tools Description

Communicate Business Analysis Information

Guidelines and Tools Description

Manage Stakeholder Collaboration

Below are the guidelines and tools when managing stakeholder

Table 21: Guidelines and Tools for Managing Stakeholder Collaboration

Guidelines and Tools Description

Techniques for Managing Stakeholder Collaboration

REQUIREMENTS LIFE CYCLE

in the Business Analysis Body of Knowledge, describes the tasks that

Figure 6: Requirements Life Cycle Management (BABOK v3, 2015).

Prioritize Requirements assesses the value, urgency, and risks associated

Table 23: Usage of BACCM in Business Analysis Requirements Life Cycle

Core Concept During Business Analysis Requirements Life Cycle Man-

Figure 7: Requirements Life Cycle Management Input/ Output Diagram.

As previously discussed, there are five tasks related to Business

Figure 8: Process and Software Requirements Traceability Inputs.

Below are the guidelines and tools when tracing requirements.

Guidelines and Tools Description

components, or releases, phases, or iterations, within a solution scope

Guidelines and Tools Description

dependencies between requirements may be used as the basis for

Guidelines and Tools Description

Domain Knowledge knowledge and expertise of the business domain

Designs (prioritized) – ranked or prioritized designs ensure that the

Assess Requirements Changes

Guidelines and Tools Description

Techniques for Assessing Requirements Changes

business analyst should come in and facilitate communication between

Guidelines and Tools Description

Techniques for Approving Requirements

Stakeholders Involved when Approving Requirements