PMI-PBA Course Manual (Printing)

Delivered especially
Delivered to:
Especially to:
PMI Professional in Business Analysis ( PMI-PBA )

Participant Manual Certification Preparation
Venture International FZC Business Consulting & Training
Needs Assessment
Planning
Analysis
Traceability & Monitoring
Evaluation
PBA is a registered certification service mark of the Project Management Institute, Inc
Copyright, Use, and Resale Prohibitions
All content in this book is copyrighted and VENTURE INTERNATIONAL

owns the copyright and the book itself. Other than as stated in the
Single Use License Agreement, you may not copy, print, modify,
remove, delete, augment, add to, publish, transmit, sell, resell, create
derivative work from, or in any way exploit any of the book’s content,
in whole or in part, and you may not aid or permit other to do so. The
unauthorized use of distribution of copyrighted or other proprietary
content is illegal and could subject the violator to substantial money
damages.
Violator will be liable for any damage resulting from any violation of
this License Agreement, including any infringement of copyright of
proprietary rights.
PMP, PMI-RMP, PMI-SP, PgMP, CAPM, PBA, PMBOK,and PMI
are registered marks of the Project Management Institute, Inc.
Venture International – Business Consulting & Training
Author: Maher Alkhadra BS, MBA %#"D
PfMP¥, PgMP®, PMP®, PRINCE2® Practitioner, PMI-RMP®,
PMI-SP®, PMI-PBA¥, PMOC, CMQ/OE, CQE, CQA, CSCM,
CDDP, IC3PM, CSE®, SixSigmaBB
All rights reserved
Copyright © 201 , by Venture International
https://www.facebook.com/VentureInternational www.venture-consult.com
https://www.linkedin.com/company/venture-llc
Delivered Especially to:

Delivered especially to:
Contents
PMI-PBA Credential Overview ........................................................................................ 1
Introduction to Business Analysis ................................................................................... 15
Exam Domain 1: Needs Assessment ............................................................................ 41
Exam Domain 2: Business Analysis Planning ................................................................ 85
Exam Domain 3: Requirements Elicitation and Analysis ......................................... 155
Exam Domain 4: Traceability and Monitoring .......................................................... 223
Exam Domain 5: Evaluation ........................................................................................ 247
Soft Skills .......................................................................................................................... 271
© Venture International FZC PMI-PBASM Certification Preparation

PMI-PBA
Credential
Overview

Page 1 of 301
Objectives
• Describe the background of the PMI® and their
introduction of the PMI-PBA® credential
• List the elements of the PMI-PBA application and
content for the examination

Page 2 of 301
PMI Background
• Founded in 1969
• Not-for-profit member based organization
• Over 400,000+ member worldwide, in 170+ countries
• Certification
• Global Standards
• Chapters & Communities of Practice
• Training & Education
• Research

Page 3 of 301
PMI-PBA®
• Project Management Institute Professional in
Business Analysis
• PMI Reasons for Credential
• Increased demand for professionals experienced
in business analysis
• Improve the practice of requirements
management for more successful projects
• PMI-PBA has a greater focus on requirements
for projects and programs.

Page 4 of 301
PMBOK® Guide
• A Guide to the Project Management Body

of Knowledge (PMBOK® Guide) – Fifth
Edition
• Documents generally recognized "good
practice" that enhance the chances of
project success.
4. Project Integration Management

4.1 Develop project charter
4.3 Perform integrated change control
5. Project Scope Management (All)
6. Project Time Management
6.2 Define activities
6.3 Sequence activities
6.4 Estimate activity resources
6.5 Estimate activity durations
8. Project Quality Management (All)
10. Project Communications Management
10.1 Plan communications management
10.2 Manage communications
10.3 Control communications
11. Project Risk Management
11.1 Plan risk management
11.2 Identify risks
11.5 Plan risk responses
11.6 Control risks
13. Project Stakeholder Management (All)

Page 5 of 301
Application Qualifications
Educational Business Analysis Experience General Project Experience PM
Background Education
4,500 hours
Bachelor’s (5 years) *2,000 working
**35 contact
Degree or Global working as a on a project
hours
Equivalent practitioner of Experience team Experience
business analysis must be must be
High School 7,500 hours within the within the
Diploma or (3 years) past 8 years *2,000 working past 8 years
**35 contact
Associate’s working as a on a project
hours
Degree or Global practitioner of team
Equivalent business analysis
*These can be inclusive of the hours of business analysis experience listed.

** Hours must be in business analysis practices

Page 6 of 301
Credential Overview
Application Process
Application Schedule and CCR

Completeness Take Exam • (Earn 60 PDUs in 3
Application Review years)
Submission • Re-Take up to 2 Certified PMI-
• Possible times per calendar PBA
(Online) Application Audit year

Page 7 of 301
Exam Overview
• 4 hours; 200 multiple-choice questions
• Mutually exclusive answers
• Includes 25 "pre-test" questions which do not
count toward your final result
• You will be able to mark questions and move
forward and backward through questions.
• A clock will run on your screen showing how
much time you have left.
# 1 Challenge
Often, you will see two correct answers and two obviously wrong answers. You must choose the
"most likely" or "best" answer!

Page 8 of 301
Exam Blueprint (Question Distribution)
Evaluation Needs
10% Assessment
Traceability 18%
and
Monitoring
15%
Planning
22%
Analysis
35%
Needs Assessment: Activities related to understanding a business problem or opportunity and

evaluating various inputs to help develop an effective solution.
Planning: The preparation required to effectively manage the business analysis activities that will
occur within the project.
Analysis: Focuses on requirements management activities including elicitation, analysis,

decomposition, acceptance, approval, and validation of requirements.
Traceability and Monitoring: Activities related to managing the lifecycle of requirements including
continuous monitoring and communication of requirements status to stakeholders.
Evaluation: Related to the assessment of how well the delivered solution fulfills the requirements
and meets the business need.

Page 9 of 301
General Tricks & Tips
• The business analyst is responsible for
requirements and solution recommendation
• The project manager is responsible for project
processes
• Stakeholder engagement is key, Integrated
Change Control is essential
• Requirements traceability matrix is key to
documenting and tracking requirements
These first two might be tricky for those with a project management background. The thing to
keep in mind is that the PMI-PBA® exam is the result of a role delineation study. PMI, through this
study, has determined that the business analyst is responsible for the domains and activities of the
PMI-PBA® exam. This may be contrary to how you have thought about project management or
the PMBOK® Guide's processes and activities in the past. Assume the project has both a project
manager and a business analyst. In real life, even when these roles are shared by one person,
there are still project management tasks and business analysis tasks.
Communication and engagement with the stakeholders is a very important theme to keep in
mind. The BA, PM, and project team do not do anything that would impact the overall solution or
project baselines without involving key stakeholders. Information is candid and timely.
Stakeholders are never surprised.
No changes are made without formal approval. Ever! Integrated change control is very important.
The exam will focus on how to plan for integrated change control as well as following the plans
documented.
Expect to see a lot of questions regarding traceability. These will range for how to plan for
traceability to when to update the traceability matrix. Hint: attributes of the requirements should
be updated as they happen. Change to the actual requirements must go through formal change
control and be re-baselined when changed. PMBOK Guide 5.2.3.2.

Page 10 of 301
Testing Tips
• Get plenty of rest!
• Read the question carefully
• Read the question thoroughly
• Do not panic
• Do not leave any question unanswered
• Respect your test-taking style
• Your first answer is your best.
Read the question carefully

 Watch words like never or always to tip you off to a wrong selection.
 Double check qualifiers such as least or most.
Read the question thoroughly to understand what it is that they are testing. Many questions will
be situational and include context that may or may not have any bearing on the correct answer.
Diagrams shown may or may not be needed to answer the question.
Do not panic if the first few questions throw you or you don't feel 100% confident about your
answer.
Do not leave any question unanswered; guess if you have to. (No credit for no answer!)
Respect your test-taking style. 4 hours will be enough time. You will need to keep moving, but you
shouldn't have to rush.
Remember: In general, your first answer is your best. Unless you have misread the question or you
have a compelling reason to change your answer, leave it.

Page 11 of 301
Post Test
Submit
Test
Respond
to Survey
Get
Results
Provided
Print Out
In addition to providing information whether you passed or failed, the exam report includes a
picture of your overall strengths and weaknesses within each domain. This is a diagnostic
representation of your proficiency level per domain for the credential tested. Each domain or
chapter reports your level of proficiency as either:
Proficient- indicates performance is above the average level of knowledge in this domain
Moderately Proficient- indicates performance that is at the average level of knowledge in
this domain
Below Proficient- indicates performance is below the average level of knowledge in this
domain
PMI applies global best practices in examination administration by reporting your proficiency
levels. The proficiency levels serve as an aid in measuring your knowledge in specific areas of study
and practice. For example, if your result is Below Proficient in one of the domains/chapters, then
you know what you need to study to improve. There are not a minimum or maximum number of
domains or chapters in which you need to demonstrate proficiency in order to pass the exam.
Your pass/fail score is based on your overall performance, not on how many questions you
answered right or wrong in a particular domain or chapter.
Each of the domains or chapters has a different number of questions within them that are relative
to each other but not equal to each other. That means it is possible to score Below Proficiency in
one of the domains and yet still pass the examination. It all depends on how many items were
present in the domains that were failed.*
*PMI Customer Care automated response to exam scoring inquiry

Page 12 of 301
Exercise
Sample Question:
Jane will be taking her PMI-PBA® exam in the morning. She has been
studying consistently for 3 months and is getting 85% on average in
exam simulations. Her weakest domain is Evaluation. Jane has just
finished having dinner with her family. What should she do next?
A. Re-study materials on Evaluation

B. Take another practice test
C.Relax and get to bed early
D. Cram all night

Page 13 of 301
Page 14 of 301
Introduction to
Business
Analysis

Page 15 of 301
Objective
• Discuss foundational knowledge related to

requirements and project approaches
needed to support the domains and tasks
of the PMI-PBA

Page 16 of 301
What is Business Analysis?
• Business analysis is the set of activities

performance to identify business needs and
recommend relevant solutions; and to elicit,
document and manage requirements
Business analysis is the application of knowledge, skills, tools and techniques to:
• Determine problems and identify business needs,
• Identify and recommend viable solution for meeting those needs,
• Elicit, document, and management stakeholder requirements in order to meet business and
project objectives,
• Facilitate the successful implementation of the product, service, or result of the program or
project
Source: Business Analysis for Practitioners – A Practice Guide

Page 17 of 301
What is Business Analysis?
• Liaise with
Stakeholders
Relationship
building
Learning
the
business
• Structure, policies and
operations
• Organization need
• Solution to
enable goal
achievement

Page 18 of 301
Business Analysis and Project Management?
Business Analysis
• Identifies, analyzes, and manages requirements
Project management
• To project requirements.
Project objectives
• Intended output
Organization goals
• Benefit
• Strategy

Page 19 of 301
Who is a Business Analyst?
• A business analyst is, "Any person who

performs business analysis activities, no
matter what their job title or organizational
role may be."

Page 20 of 301
Requirement
• Requirements are things that are wanted tor

needed by stakeholders to solve a problem
or achieve an objective.
• Almost every task in business analysis involves
requirements.
“A condition or capability that is required to be present in a product, service, or result to satisfy a

contract or other formally imposed condition.”
Source: PMBOK® Guide Glossary; 5th edition

Page 21 of 301
Types of Requirements
Business requirements
Stakeholder requirements
Solution requirements
• Functional
• Non-functional
Transition requirements
Project requirements
Quality requirements

Page 22 of 301
Business Requirements
• Describes the higher level needs of the
organization
• Business objectives (problem or opportunity)
• Independent from the technical descriptions
Currently, customer are unable to manage their accounts

without calling customer service, resulting in:
• Increased customer complaints
• Unnecessary calls to customer service

Page 23 of 301
Stakeholder Requirements
• Describes the need of a stakeholder or

stakeholder group.
• May be thought of as raw or unrefined
As a <role>, I need to retrieve a

forgotten user ID and/or password
so that I can access email and
document repositories

Page 24 of 301
Solution Requirements
• Describe the solution to be built.
• Diagrams, blueprints, models, and descriptions.
• Functional
• Non-functional

Page 25 of 301
Solution: Functional Requirements
• Describes the behaviors of the product
The system shall provide a tool that

allows users to retrieve their login ID
The system shall provide a tool that

allows users to reset their password
in the event they have forgotten

Page 26 of 301
Solution: Non-Functional Requirements
• Describe the quality of service

characteristics of the solution
• Required level of performance
• Portability
• Security The system shall send an email response
• Etc. with forgotten user ID or password reset
instructions within 2 minutes of the user
selecting the option.

Page 27 of 301
Transition Requirements
• Describe what needs to happen before the
business can implement the solution:
• Training needs
• Procedure change
The system shall convert
• Rollout plans user IDs and passwords to
• conversion rules the new system without
• Communication plans interruption of service to
end-users.

Page 28 of 301
Project Requirement
• Describes actions, processes, or other

conditions the project needs to meet
A focus group will be used to

conduct user acceptance
testing and for formal signoff
prior to release.

Page 29 of 301
Quality Requirement
• Captures conditions or criteria needed to

validate the successful completion of a
project deliverable
The solution must be free

of all Critical Level 1
defects prior to release.

Page 30 of 301
Project Approaches

Page 31 of 301
Project Lifecycle Approaches
Waterfall Agile
(Predictive) (Adaptive)
• Usually sequential phases (requirements • Focuses on collaboration
and then design) • Can be SCRUM with daily stand up
• Documentation and approvals tend to meetings
be more formal • Prioritize features
• Can be done incrementally • Can document with user stories
• Often used on global projects or with • Best with co-located teams
geographically dispersed teams • Iterative (evolve and improve)
• Often used on complex projects with • Does not mean no documentation!
complex interfaces
Incremental / Iterative
• Increments are like small releases • Time-boxed
• Both Waterfall and Agile can be • Multiple phases
incremental • Incremental development may or may
• Add features with each increment not be iterative (including rework)
The project approach often determines the business analyst's approach.
For example, if an organization uses a predictive approach to managing a project, the waterfall
approach is usually preferred. However, there may be certain projects for which a business analyst
approach may deviate from a project approach because of the particular solution being
developed. For example, if a project is adaptive, but part of the solution has a small, self-
contained feature, then an agile approach (change-driven) might be chosen.
There are two basic approaches according to PMI: predictive and adaptive. However, waterfall
may also be incremental or iterative. By its nature, agile is both incremental and iterative.

Page 32 of 301
Waterfall Approach (Predictive)
BA Plan for
Requirements Baseline
Identify Requirements
Stakeholders
Define Analyze Design Build Test Deploy
• Analyze Problem, • Elicit, Model,

Understand Document &
Business & Project Review
Background Requirements
Manage &
Communicate
Requirements
A predictive or Waterfall approach is more formal than an adaptive approach. The activities are
usually more detailed and planned. A predictive approach implies that each project phase is
completed, documented, and approved before the next project phase is started. With a
predictive approach, most of the business analysis work occurs during the "analysis" project phase,
at the beginning of the project.
When using a formal waterfall approach, all requirements are usually gathered before design
begins. Most of the requirements effort (elicitation, modeling, and documentation) is spent at the
beginning of the project, with traceability and change management happening throughout the
rest of the project. Alternatively, Waterfall can also be used in conjunction with incremental
development by chunking the project out into smaller "mini-waterfall" projects.
Key Features
• The business analyst endeavors to capture all the requirements at the beginning of the project.
• Additional requirements found later in the life cycle are managed through change control
processes.
• The Waterfall approach is a one-directional phased approach (As each phase is completed,
the requirements work is then handed off).
• Most of the business analysis effort occurs at the beginning of the project.
*A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fourth Edition.

Page 33 of 301
Incremental Approach
BA Plan for
Identify Requirements
Stakeholders
Detailed Build &

Define Analyze Design
Analysis Test
• Analyze Problem, • Elicit, Model, • Elicit, Model,
Understand Document & Document &
Business & Review High Review Detailed
Project Level Requirements
Background Requirements Manage &
Communicate
Requirements
An incremental approach divides the product deliverable into smaller components or increments.
Each increment produces a small deliverable component of the entire solution. Thus, after a very
short period of time, you have a working deliverable, even though the final product is not
complete.
Mini reviews are set after each increment has been completed. Dividing a project into
incremental components must take into consideration the strategy of designing, constructing,
testing and deploying the deliverable. Increments can be divided by functionality or be time-
boxed, delivering the functionality that will fit into that time box.
In incremental methodologies, requirements planning must be done at two levels. The first level is
the overall requirements plan, which estimates the overall requirements process and breaks the
requirements efforts into separate increments. It is important to capture all the high level
requirements at the beginning of the project, prioritize them by business value and assign them to
an increment. Alternatively, increments can be time-boxed, with the functionality assigned that
will fit into that time box in terms of work effort. Often, incremental planning takes the riskiest
requirements and applies them to the first increment for proof of concept.
The second level of planning is done at the incremental level. An increment typically lasts from
one week to several months, depending on the methodology used, the project size, and
complexity. Each increment should provide useful functionality that provides value to the business
and is fully deployable.

Page 34 of 301
Iterative Approach
Iteration 1 Iteration 2 Iteration 3:
•Requirements •Review •Review

Analysis Iteration 1 & Iteration 1 &
•Design Enhance Enhance
•Code •Analysis •Analysis
•Test •Design •Design
•Code •Code
•Test •Test
As opposed to the classic Waterfall approach where development activities occur in a "waterfall"
manner, iterative development develops limited results in short timeframes. Only a fraction of the
project is developed in any one iteration. Rather than the stepped approach of Waterfall, iterative
development occurs in a circular manner. In iterative development, the overall life cycle is
composed of several iterations in sequence. Each iteration is a self-contained mini-project
composed of activities such as requirements analysis, design, development, and test.
Iterative development is often confused with incremental development. Iterative development is

about planned rework. You create something, review it, and then improve upon it based on the
feedback. Each iteration (should be) better than the one you had before, even if you don't add
features. This requires you have the courage to review what you did before and to make the
application better. The iterations are planned rework, while incremental development only
develops new functionality in each iteration.
Key Features
• A life cycle is composed of several iterations.
• Each iteration is a self contained mini-project (requirements analysis, design, programming, and
test).
• Planning includes rework based on review of the past work and make enhancements.
• Each iteration may be implemented.

Page 35 of 301
Agile (Adaptive)
A Scrum Framework
Since Serum is currently the most widely used agile methodology, we will use it as a reference
method in this course, although we will also refer to other agile methods.
Serum in a nutshell: The Product Backlog contains a prioritized list of the features and functions
desired for the product being built in the form of user stories. It also contains defect fixes from
previous sprints. Based on priority, some of these user stories are chosen by the Product Owner for
development and presented in the Sprint Planning Meeting. During the meeting, the user stories
are broken down into the tasks that need to be completed to build the functionality. The Sprint is
1-4 weeks long. The goal of the Sprint is to produce a potentially shippable product increment.
During the Sprint, the team meets on a daily basis during a Daily Serum meeting during which they
update their progress. At the end of the Sprint, the product increment is shown to stakeholders at
the Sprint review meeting to get their feedback, which may change the content or priority of
items on the Product Backlog. The team then engages in a Sprint Retrospective where lessons
learned from the previous sprint can be immediately implemented in the following sprint.
Serum history: In the early 1990s, Ken Schwaber used an approach that led to Serum at his
company, Advanced Development Methods. At the same time, Jeff Sutherland developed a
similar approach at Easel Corporation and was the first to call it Serum. In 1995 Sutherland and
Schwaber jointly presented a paper describing Serum at OOPSLA '95 in Austin, Texas. Schwaber
and Sutherland collaborated during the following years to merge the above writings, their
experiences, and industry best practices into what is now known as Serum.

Page 36 of 301
Discussion
• What type of approach do your projects
typically use?
• Waterfall
• Waterfall Incremental
• Iterative
• Agile

Page 37 of 301
Practice Questions
1. Which is a true statement regarding the role of a business analyst?

A. The business analyst is the team member responsible for documenting requirements.
B. The business analyst selects the projects that meet the organization’s strategic initiatives.
C. The role of the business analyst can be performed by anyone doing the work of the
business analysis.
D. The role of the business analyst can only be fulfilled by a single person who is dedicated
full-time to the work of business analysis
2. Business analysis is?

A. A subplan of the project management plan that defines the business analysis
approached.
B. The set of activities performed to identify business needs; recommend relevant solutions;
and elicit, document, and manage requirements.
C. A collection of pre-project or early project activities and approaches for capturing the
necessary view of the business to provide context to requirements and function design
work for a given initiative and/or for long term planning.
D. A set of stakeholder needs that are analyzed, structure, and specific for use in the design
or implementation of a solution.
3. What are the different types of requirements?

A. Business, stakeholder, functional, non-functional and transition.
B. Business, stakeholder, solution requirements, transition, project, and quality.
C. Optional, important, critical.
D. Sponsor, stakeholder, functional, non-functional, transition, project, and quality.
4. Who completes the business case?

A. Project manager.
B. Project sponsor.
C. Business analyst.
D. The person who requests the project.
5. Most solutions:
A. Are systems of interacting solution components, each of which are potentially solution in
their own right.
B. Contain only one solution component.
C. Contain software and a process component.
D. Are systems of interacting business applications, each one of which is unique.
6. The following is what type of requirement? "All data that is less than 3 years old should be
migrated to the new system"
A. Solution.
B. Functional.
C. Non-functional.
D. Transition.

Page 38 of 301
7. Requirements are defined:
A. From a high- to low-level of detail.
B. To the lowest possible level of detail.
C. To the level dictated by the sponsor.
D. To whatever detail is needed to achieve action and understanding
8. Business analysis is performed:

A. Sequentially and in order.
B. According to logical relationships (dependencies).
C. Iteratively or simultaneously
D. Iteratively after Enterprise Analysis is complete
9. Which of the following is a stakeholder requirement?

A. Company policy states that all transactions be posted real-time.
B. I need to be able to see all transactions in the ledger as they occur.
C. The system shall post all transactions within0.5 seconds of a user save.
D. The system shall have all transactions from the past year available with the original
date/time posted.
10. Which statement about techniques is most correct?

A. They are required for all tasks
B. They are prescribed by the PMBOK® Guide
C. They describe different ways a task can be performed.
D. They provide supplemental information about one and only one task.

Page 39 of 301
Page 40 of 301
Exam Domain 1:
Needs
Assessment

Page 41 of 301
Objectives
• Discuss key concepts and terms related to

Needs Assessment
• Identify and understand tasks and
processes within Needs Assessment
• Explain the tools and techniques utilized in
Needs Assessment
At the end of this chapter you will be able to
Analyze and explain the tasks included in Needs Assessment, including their inputs, tools and
techniques, and outputs.
Describe how to determine and articulate business requirements, project goals, and project
objectives.
Describe various valuation tools used to understand the value proposition of projects.
Discuss how to determine and document product I solution scope
Identify and analyze stakeholders in order to achieve a level of support needed for project
success.

Page 42 of 301
Exam Tasks
• Define or review a business problem or opportunity using problem and opportunity
Task 1 analysis techniques in order to develop a solution scope statement and/or to provide
input to create a business case.
Task 2 • Collect and analyze information from a variety of sources using valuation tools and
techniques to contribute to determining the value proposition of the initiative.
• Collaborate in the development of project goals and objectives by providing

Task 3 clarification of business needs and solution scope in order to align the product with the
organization’s goals and objectives.
Task 4 • Identify stakeholders by reviewing goals, objectives, and requirements in order that the
appropriate parties are represented, informed and involved.
Task 5 • Determine stakeholder values regarding the product, using elicitation techniques in
order to provide a baseline for prioritizing requirements.

Page 43 of 301
Need Assessment – Process View
Identify
Organizational Recommend Assemble the
Problem or
Assessment Action Business Case
Opportunity
• Identify stakeholders • Assess goals and • High-level approach

objectives
• Investigate • Provide alternative
• SWOT Analysis options
• Gather data and
evaluate the • Relevant Criteria • Identify constraints,
situation assumptions and risks
• Root-cause analysis
• Situation statement • Assess feasibility
• Identify capabilities
• Obtain approval gaps • Recommend best
option

Page 44 of 301
Identify Problem or Opportunity
Gather data
Identify and Situation Obtain
Investigate
stakeholders evaluate statement approval
the situation

Page 45 of 301
Identify Stakeholders
• We need to assess which stakeholders are
impacted by the area of business under
analysis.
Vendors, Partners, Customer
SMEs, Sponsors, Execs, Support
End Users
Project Team
There are a variety of stakeholders to consider from project team members, to end users, to others
who are oftentimes once removed from using the solution such as SMEs (Subject Matter Experts),
project sponsor, organization executives, and support personnel. Also don't forget any vendors,
partners, and customers who may be impacted by the solution.

Page 46 of 301
• The identified stakeholder can be categorized
using a responsibility assignment matrix (RAM) –
e.g. RACI model
• R- Responsible (does the work)
• A- Accountable/Approval (ultimate responsibility)
• C- Consult (has input)
• I- Inform (is informed)
There are a variety of stakeholders to consider from project team members, to end users, to others
who are oftentimes once removed from using the solution such as SMEs (Subject Matter Experts),
project sponsor, organization executives, and support personnel. Also don't forget any vendors,
partners, and customers who may be impacted by the solution.

Page 47 of 301
Collaboration Point—Both project managers and business analysts have an interest in stakeholder
identification and RACI analysis. While the project manager is concerned about analyzing the
roles across the project, business analysts may perform their analysis to a lower level of detail or
may focus on one specific area such as a needs assessment or requirements elicitation. Each may
lend support to the other and work together to perform this work. It is important to ensure efforts
are not duplicated.

Page 48 of 301
Investigate
• Learn enough to understand the situation
• Don’t conduct a complete requirements
analysis.
• Interviews
• Documentation reviews
• Process modeling
• Observation
More details will be discussed in Requirements Elicitation and Analysis

Page 49 of 301
Gather Data and Evaluate the Situation
• “Size up” the situation
• Use Benchmarking when internal data is not
available.
• Use Pareto and Trend analysis to analyze
and structure the data.
More details will be discussed in Requirements Elicitation and Analysis

Page 50 of 301
Situation Statement
• Problem: Describes a situation that is hindering a business
from achieving maximum value
• Example Problem Statement:

• We do not have a central listing of customers available
for CSR use. Each time a query regarding our customer
base is made, excessive staff time is spent researching
the request and validating the information from various
sources. It is estimated that this costs us $250,000 per year
in staff time and missed revenue opportunities.

Page 51 of 301
Situation Statement
• Opportunity: Describes a situation that will add value to
the business
• Example Opportunity Statement

• The company has invested in a new Enterprise System
that includes a customer management system (CRM)
module. We can leverage this module to improve our
customer information and reporting capabilities saving
staff time to respond to inquiries and investigations.

Page 52 of 301
Obtain Approval
• May be formal or informal
• Ensures common understanding of the
situation

Page 53 of 301
Organizational Assessment
Assess Identify
SWOT Relevant Root-cause
goals and capabilities
Analysis Criteria analysis
objectives gaps

Page 54 of 301
Assess Goals and Objectives

Page 55 of 301
• GOAL: An observable and measurable end
result having one or more objectives to be
achieved within a more or less fixed timeframe.
“Stabilize our workforce as a solid foundation for

growth”
Source:
• http:/ /www.businessdictionary.com/definition/goal.html#ixzz38FGDv3t3

Page 56 of 301
• OBJECTIVE: Something to which work is to be
directed, a strategic position to be attained, a
purpose to be achieved, a result to be
obtained, a product to be produced, or a
service to be performed.
To reduce yearly unwanted turnover among

employees by 80% over the next 12 months
Source:
• http:/ /www.businessdictionary.com/definition/goal.html#ixzz38FGDv3t3

Page 57 of 301
• S.M.A.R.T
• S: Specific
• Has an observable outcome
• M: Measurable
• For tracking the outcome of an objective
• A: Achievable
• Whether the objective is feasible and achievable.
• R: Relevant
• The objective is aligned with organizational goal
• T: Time Bounded
• The objective can be achieved in a timeframe that is consistent with the need.

Page 58 of 301
SWOT Analysis
In the absence of formal plans, the business analyst may use SWOT analysis to help assess
organization strategy, goals, and objectives.
SWOT Analysis- Analysis of strengths, weaknesses, opportunities, and threats of an organization,

project, or option.
SWOT analysis is a widely used tool to help understand high-level views surrounding a business
need.

Page 59 of 301
Relevant Criterial
How goals and objectives are cascaded into a solution:
• Foundation at the Strategic/Business Level
• Definition at the System/Operations/Department Level
• Focus at the Process Level
• Tactical Execution and Management

Page 60 of 301
Root-Cause Analysis
Opportunity analysis:
• Determine the viability of
successfully launching a new
product or service
Root-Case analysis:
• Used to discover the underlying
cause of a problem.
• Cause-and-effect diagram
• Five Whys
• Interrelationship diagram
• Process flows

Page 61 of 301
Root-Cause Analysis
• Cause-and-effect diagram
• A snapshot of the current situation and high-level
potential causes of why the situation (unwanted
effect) is occurring.
Fishbone Diagrams
Fishbone Diagrams are also called Cause-and Effect Diagrams, or Ishikawa Diagrams, named
after their Japanese originator. They are a snapshot of the current situation and high-level
potential causes of why the unwanted effect is occurring. We could also use these to explore
major aspects of an opportunity.
The diagram is not the important thing, but getting to the root cause is. We use these along with
the Five "Whys" technique to help get to the root cause(s) of a situation. They also help us look for
system problems, rather than looking for individual staff problems.
The focus of a Fishbone Diagram is on potential causes of problems, not their symptoms. The
Situation statement is the place to discover and document symptoms. They can also expose areas
where the team lacks knowledge and/or data, and can suggest where further study is needed.
(This is one aspect of "analyzing the analysis").

Page 62 of 301
Root-Cause Analysis
• Five Whys
• A guideline for getting to the potential root
cause
Why
• Five "whys" is part of other analysis tools Why
• Ask "why" up to five times Why
• Be diplomatic as you ask! Why
Why
Five Whys
So, how can we quickly get to the root cause? The "Five Whys" technique is one way to begin
analysis and is more a guideline than a true technique. It is an integral part of other analysis tools
like the Fish bone Diagram. It reminds us that in order to get to the root cause of a problem, we
need to ask "why is the problem occurring" up to five times to get to the root cause. Be sure to ask
"why“ diplomatically, such as "Help me understand why this problem is occurring?" or "Tell me more
why that happens.?"
Example
As an example, the Jefferson Memorial in Washington, DC, had a problem. The paint was wearing
out much more often than it should and needed frequent repainting. Root-cause analysis
revealed the need for repainting was caused by frequent power-washing of the monument. Why
was so much power washing needed? Well, because of bug droppings, of all things, and
consequently the monument was getting unsightly in the summer. By delving deeper, the reason
the bugs were so prevalent was caused by lighting of the monument at dusk. The bugs were
attracted to the light at dusk, but not before or afterwards.
By getting down to the root cause, a practical and effective solution was found: turn on the lights
later, after dusk, when the bugs were not active. By delaying the lighting of the monument a short
time, the bugs stopped swarming it, they left far fewer droppings, and the paint did not deteriorate
from over-frequent washings. By determining the root cause and solving it, the team saved
countless future dollars in labor, paint and energy by not re-painting as frequently.

Page 63 of 301
Root-Cause Analysis
• Interrelationship
Diagram
• Shows cause–
and–effect
relationships.

Page 64 of 301
Root-Cause Analysis
• Process Flows
• Graphically depict how the process flows from
beginning to end to illuminate how
components of the system are related.
Flowcharting also helps to analyze how
problems occur and highlights inefficiencies.
Root-Cause Analysis
• Process Flows

Page 65 of 301
Identify Capabilities Gaps
• Capability table
Determine required • Affinity diagram
capabilities • Benchmarking
• Process flows
Assess current • Enterprise and business architecture
capabilities • Capability frameworks
Identify gaps • Between the current and needed states

Page 66 of 301
Identify Capabilities Gaps
HR Function Current System Capabilities New Capabilities
Ability to accept applications We need this ability

None
from candidates via internet **This is a GAP**
This is partially automated but We would like this to be totally

Ability to process payroll for
requires lots of manual automated
workers in different countries
processes **This is a GAP**
Ability to remotely administer

Already exists
annual performance reviews

Page 67 of 301
Recommend Action
Identify
Provide
High-level constraints, Assess Recommend
alternative
approach assumptions feasibility best option
options
and risks

Page 68 of 301
Recommend Action
High-level approach
• General direction or description of the solution.
• How to address the gaps
• Example:
• The CRM solution will deliver functionality to support
a central repository of customer information that
can be shared across company functions. This will
include 2 years of prior purchase information and
filed complaints.

Page 69 of 301
Recommend Action
Provide Alternative Options
• There are often multiple approaches for
adding new capabilities.
• Make vs. Buy
• Vendor selections
• Etc.

Page 70 of 301
Recommend Action
Identify Constraints, Assumptions & Risks
Assumptions
• Considered
true!
Constraints Risks
• Limitations • Uncertain
events that
affect
objectives
Identify

Page 71 of 301
Recommend Action
Assess Feasibility
Feasibility Factors
Technology/ Cost-
Operational Time
system effectiveness
Technology Do benefits Can it be

Does it fit
exists / outweigh delivered on
the need?
acquirable? costs? time?

Page 72 of 301
Recommend Action
Other Valuation Techniques
• Force Field Analysis
• Kano Model
• Net Promoter Score
• Purpose Alignment Model
• SWOT Analysis
• Value Stream Map

Page 73 of 301
Force Field Analysis
• Analyze the forces
for and against a
change, to help
form a decision and
communicate the
reasoning behind
the decision.
Source:
• http:/ /www.mindtools.com/pages/article/newTED_06.htm

Page 74 of 301
Kano Model
• A model used to
describe what it
takes to positively
impact customer
satisfaction.
• Expected
• Normal
• Exciting
Source:
• http://asq.org/learn-about-quality/qfd-quality-function-
deployment/overview/kanomodel.html

Page 75 of 301
Net Promoter Score
• The Net Promoter Score, or NPS®, is based on the
fundamental perspective that every company's
customers can be divided into three categories:
Promoters, Passive, and Detractors.
Source:
• http:/ /www.netpromoter.com/why-net-promoter/know/

Page 76 of 301
Purpose Alignment Model
•A method for aligning
business decisions, processes,
and feature designs around
purpose.
Focus business decisions on those that will best support both the organization's purpose and
mission and make the organization stand out in the market.
Source:
http:/ /www.beyondrequirements.com/purpose-based-alignment-model/

Page 77 of 301
Value Stream Mapping
• Value stream mapping is a lean-management
method for analyzing the current state and
designing a future state for the series of events that
take a product or service from its beginning through
to the customer.
1. Map “as is”

2. Map “to be”
Sources:
• http:/ /en.wikipedia.org/wiki/Value_stream_mapping
• http://www2.emersonprocess.com/enus/
brands/processautomation/datamanagementservices/datamanagementconsulting/pages/
datamanagementconsulting.aspx

Page 78 of 301
Recommend Action
Recommend Best Options
• Weighted-Ranking Matrix

Page 79 of 301
Recommend Action
Recommend Best Options
Cost-Benefit Analysis
Internal Net
Payback Return on
Rate of Present
Period Investment
Return Value
(PBP) (ROI)
(IRR) (NPV)
The Payback Model

This method is based on the notion that an opportunity that pays back the initial investment
quickest is the best opportunity.
Return on Investment (ROI)

Percentage return on an initial project investment. Calculated by dividing forecasted net benefits
by the initial project cost. Organizations accept investment when its ROI exceeds a certain
“hurdle” rate. The problem with this metric is that it does not consider ongoing costs, only the initial
investment.
Internal Rate of Return (IRR)

Projected annual yield of a project investment – including initial and ongoing costs. To make things
easier, think of IRR as the Growth Rate. Thus, when comparing two project investments, chose the
project with the highest IRR.
The Net Present Value (NPV) model

The future value of expected project benefits expressed in the value of those benefits have at the
time of investment.
NPV = PV(benefits) – PV (costs) = PV (benefits – costs)
When making an investment decision, take the alternative with the highest NPV. Projects with
Negative NPV are losing projects, they shall be rejected outright.

Page 80 of 301
Assemble the Business Case
• A business case is a documented

justification for a project or initiative.
• A living document that constantly referenced
throughout the project.
• Review and update the business case based
on what is discovered as the project
progresses.
Table of Contents for a Formal Business Case
Introduction and Recommendation Overview

Current Environment and Problem
As-Is Workflow Diagrams
Description of the Problem
Detailed Description of the Proposal
To-Be Workflow Diagrams
Description of Proposed Development Plan
Description of Proposed Implementation Plan
Cost-Benefit Analysis Tables
Tangible Costs and Benefits with ROI and Payback Period
Intangible Costs and Benefits
Risk Assessment
Summary

Page 81 of 301
Practice Questions
1. Determining business value is not needed for the following type of project:
A. A database of donors for a non-profit organization.
B. Large retail chain point of sale upgrade.
C. Government project.
D. It is always needed.
2. Ideally, when is a business analyst assigned to a project?

A. During project initiation.
B. Prior to project initiation.
C. During project planning.
D. As soon as the charter is signed.
3. In dealing with the customer, the business analyst should:

A. Be honest to the extent that the project organization is protected from litigation.
B. Strive to develop a friendly honest and open relationship.
C. Try to maximize profits by encouraging scope creep.
D. Do whatever it takes to satisfy the customer.
4. Which of the following statements is the best example of the business problem statement?
A. We need to speed up the query search time in the problem database.
B. To increase productivity in the Help Desk, we need to speed up the query search time in
the Problem database.
C. Speeding up the problem database search time will save the company approximately
$300,000 per year and prevent increases in staff.
D. Help Desk staff wait an average of 30 seconds per query, resulting in an average of 10%
longer calls than the industry average.
5. As the BA you are called upon to participate in a Feasibility Study prior to launching a project
initiative. Which of the following statements is the MOST true?
A. The BA is expected to possess all of the skills required to plan and execute the study.
B. The BA will facilitate this study, but does not have the decision-making authority.
C. The BA must enlist a team of experts including: research and information analysis skills,
technical writing skills, leadership and organization skills, change management skills.
D. The Executive Team is responsible for the Feasibility Study in the Enterprise Analysis phase.
The BA is responsible for feasibility only after the project is in the Requirement Elicitation
phase.
6. Which type of requirements best state the needs of a particular stakeholder or class of
stakeholder, and how that stakeholder will interact with a solution?
A. Business Requirements.
B. Stakeholder Requirements.
C. Functions Requirements.
D. User Requirements.

Page 82 of 301
7. You are in a meeting with key executives from around the company discussing long term,
ongoing conditions the organization is striving to achieve. What is being discussed at this
meeting?
A. Strategic plan.
B. Business synergy.
C. Business values.
D. Business measurements.
8. Joseph is working on a small project and it seems that the requirements and subsequent
solution could be obvious. However, Joseph really wants to challenge his stakeholders to
ensure that the current business thinking and processes are in line with the requirements and
subsequent solution. What is Joseph trying to do?
A. Decision analysis.
B. Problem analysis.
C. Solution scope analysis.
D. Root cause analysis.
9. The quantifiable criterial established early in the project and upon which the project is
measured are the project:
A. Benefits.
B. Objectives.
C. Justification.
D. Goals.
10. The CFO has asked you to lead the requirements efforts for a new project to implement SAP
to support the organization’s accounting functions. What question should you ask the sponsor
first?
A. Who is the project manager?
B. When does the project need to be done?
C. What is the statement of work?
D. What business problem are you trying to solve?

Page 83 of 301
Page 84 of 301
Exam Domain 2:
Business
Analysis
Planning

Page 85 of 301
Objectives

Business Analysis Planning
processes within Business Analysis Planning
Business Analysis Planning
At the end of this chapter, you will be able to
Describe stakeholder identification and analysis
Identify business analysis activities and deliverables
Discuss requirements management and traceability
Plan for change control using principles and processes to support change control planning efforts
Determine acceptance criteria to plan for determining project results

Page 86 of 301
Tasks
• Review the business case, and the project goals and objectives, in
Task 1: order to provide context for business analysis activities.
• Define strategy for requirements traceability using traceability tools

Task 2 and techniques in order to establish the level of traceability
necessary to monitor and validate the requirements.
• Develop requirements management plan by identifying

stakeholders, roles and responsibilities, communication protocols,
Task 3 and methods for eliciting, analyzing, documenting, managing, and
approving requirements in order to establish a roadmap for
delivering the expected solution.
Tasks (cont’d)
• Select methods for requirements change control by identifying
channels for communicating requests and processes for managing
Task 4 changes in order to establish standard protocols for incorporation into
the change management plan.
• Select methods for document control by using documentation

Task 5 management tools and techniques in order to establish a standard
for requirements traceability and versioning.
• Define business metrics and acceptance criteria by collaborating

Task 6 with stakeholders for use in evaluating when the solution meets the
requirements.

Page 87 of 301
Business Analysis Planning – Process View
Conduct/Refine
Create the Business Plan the Business
Stakeholder
Analysis Plan Analysis Work
Analysis
• Identify Stakeholders • Understand Project Contexts • Determine Who Plans the

• Understand Project Life Cycle Business Analysis Effort
• Determine Stakeholder • Ensure the Team is Trained
• Build the Business Analysis
Characteristics • Leverage Past Experiences
Work Plan
• Plan for Elicitation
• Group/Analyze • Plan for Analysis • Assemble the Business
Stakeholders • Define Requirements Analysis Work Plan
Prioritization
• Document the Rationale for
• Assemble Analysis Results • Define Traceability
the Business Analysis
• Define Communication
Approach
• Define Decision-making
• Define Requirements • Review the Plan with Key
Verification/Validation Stakeholders
• Define Change Process
• Obtain Approval
• Define Solution Evaluation

Page 88 of 301
Why Business Analysis Planning
Success of
project
Estimate the
amount and
Understanding level of
the scope of business
work and
Business stakeholder’s
analysis
analysis expectations required
planning
Business analysis planning achieves the following:

• Sets expectations as to the business analysis activities that will be performed;
• Ensures that roles are identified, understood, and communicated to everyone involved;
• Achieves buy-in and support before work begins;
• Provides context to support estimation; and
• Produces a more efficiently run business analysis process.
Planning work should be performed with discretion to ensure the process is not too formal for the
needs of the project.
When using a predictive life cycle, planning is performed up-front prior to elicitation. In adaptive
life cycles, some planning is performed up-front and plans are adapted or evolve over the course
of the program or project.

Page 89 of 301
Business Analysis vs. Project Management
Project
Management
Activities
Business
Analysis
Activities
It is a best practice to have the project manager and business analyst working closely together
while the business analysis approach and plan is formulated.
Business analysts will develop a work plan to cover the activities they are responsible for
performing; however, the work plan should be integrated into the overall project management
plan managed by the project manager.

Page 90 of 301
Conduct/Refine Stakeholder Analysis
Determine
Identify Group/Analyze Assemble
Stakeholder
Stakeholders Stakeholders Analysis Results
Characteristics

Page 91 of 301
• Performed to understand the impacts and
influences of stakeholders.
• Performed iteratively.

Page 92 of 301
Determine Stakeholder Characteristics
Attitude
Complexity
Culture
Experience
Level of influence
Location and availability
Attitude:
Supportive vs. Unsupportive
Complexity:
• Large vs. small number of stakeholders
• Varying vs. similar needs
• Large vs. small number of business processes impacted
• Uniformed vs. ununiformed business process
• Large vs. small number of interfaces
• Internal vs. external systems
Culture:
Mind the diversity among stakeholders
Experience:
Experienced stakeholders make requirements elicitation more efficient.
Level of influence:
Understand the power a stakeholder possesses
Location and availability:

Physically available vs. virtual team

Page 93 of 301
Stakeholder Grouping and Analysis Techniques
Organizational Persona Process Stakeholder

Job analysis Risk analysis
modeling analysis modeling maps
• Grouping stakeholders allows for easier management of the information.

• Can be structured by many qualities.
• Can use “Primary” and “Secondary”

Page 94 of 301
• Job Analysis
Job
Skills, knowledge,
position attitude
Job Role & responsibility

description
Education,
experience and
Job Worth competencies

Page 95 of 301
• Persona analysis
• Persona: An archetype representing a group of users who have
common goals
• Provides more information than a Role name
• A Role can be associated with more than one Persona
• “Nancy Nin is a Marketing Analyst who is not comfortable with computers…”
• “Ted Turbo is a Marketing Analyst who builds custom computer gaming systems
as a hobby…”
• Marketing Analyst Ted Turbo uses keyboard shortcuts to select a
city so that he can analyze buyer habits for the city
• Marketing Analyst Nancy Nin uses the wizard view to select a city
so that she can analyze buyer habits for the city

Page 96 of 301
• Stakeholder maps
Power
Interest

Page 97 of 301
Assemble Analysis Results
• Stakeholder information may be
documented so that it can be shared.
• Information may sensitive in nature.
• Sharing information should serve better
understanding of stakeholders
Sample Stakeholder Register

Page 98 of 301
Create the Business Analysis Plan
Understand Define Define
Project Contexts Traceability Communication
Define
Understand Define Decision-
Requirements
Project Life Cycle making
Prioritization
Define
Ensure the Team Requirements
Plan for Analysis
is Trained Verification/Valid
ation
Leverage Past Define Change Define Solution

Plan for Elicitation
Experiences Process Evaluation

Page 99 of 301
Understand Project Context and Life Cycle
• Why understand project context:
• Provides a setting in which requirements can be
clearly understood
• Helps us make better decisions by having the
entire picture
• Assists us in understanding the background of the
stakeholder and their situation
• Provides the boundaries within which the
requirements must exist
Project context and Life cycle provide us with a way to understand the meaning of information. It
provides a setting in which requirements can be fully understood and assessed. Anytime we take
in new information the brain immediately files and sorts the information into the context of the
information already retained. In order to ensure accurate understanding we need to gather all
the pertinent information around us and possible override any past information that no longer
serves us in this context.
Project context and Life cycle provides us information about the project, why the project exists, its
benefits, what problem it solves or what opportunity we are taking advantage of, and the scope
of the project. All requirements will then be understood within the context of that project and
aligned to project objectives.

Page 100 of 301
Understand Project Context
Strategic Tactical
• Long-term • Shorter term
• Overall aims and interest • In support of strategy
• The "What" • The "How"

Page 101 of 301
Understand Project Life Cycle
Predictive Adaptive
• Waterfall • Agile
• Traditional requirements • User Stories with
acceptance criteria

Page 102 of 301
Leverage Past Experiences
Lessons Learned Retrospectives
• Knowledge gained • Reflection on what went
during a project well and what didn’t
• Mainly in adaptive life
cycle projects
The biggest differences between lessons learned and retrospectives are in the timing and speed
by which issues raised are addressed and the formality around documenting the learnings.
Because adaptive life cycles offer more opportunity, retrospectives occur regularly and
frequently.

Page 103 of 301
Plan for Elicitation and Analysis
• How and when to elicit and analyze
requirements
• Techniques to use
• Sequence of elicitation and analysis activities
Mind the time, cost, and hence, resources consumed during elicitation and analysis

Page 104 of 301
Define Requirements Prioritization
• How will requirements be prioritized?
• Who will be involved?
• What techniques will be used?
• Who has final say in prioritization?
• Are there special tools or logistical needs to
accomplish prioritization?

Page 105 of 301
• Requirements are based on:
• Value
• Cost
• Difficulty
• Regulatory
• Risk

Page 106 of 301
• Prioritization Techniques:
• MoSCoW (must, should, could, won't)
• Time boxing
• Voting
• High, Medium, Low
• Essential, Conditional, Optional
• 1-5
• Play money

Page 107 of 301
Define Traceability
• A technique to identify and document the linkage of each
requirement and to make connections within and between
requirements and other project elements.
• Benefits
• Ensures all requirements add value to the business by linking to
business objectives
• Ensures all approved and only the approved requirements are
delivered
• Helps keep the requirements effort focused
• Helps with impact analysis for change requests
• Assists in managing & organizing requirements
Traceability is making connections between requirements, and between the requirements and
other project elements in order to ensure the project is doing all the right things and only the right
things.
Traceability is the ability to track requirements throughout the development lifecycle and is a key
component in scope management. It assists the business analyst in ensuring all the requirements
are in the solution, no additional requirements have filtered into the project without going through
change control, and the requirements have been traced back up to the business value and down
to the test case(s) and perhaps even the release/deployment component.

Page 108 of 301
Define Traceability
• Requirements Traceability Matrix
• A grid that links product requirements from their origin
to the deliverables that satisfy them
• Business needs, opportunities, goals, objectives
• Project objectives
• Project scope/WBS deliverables
• Product design
• Product development
• Test strategy and scenarios
• High-level requirements to more detailed requirements
Sources:
• PMBOK® Guide v 5, Glossary (p. 558)
• PMBOK® Guide v 5, Section 5.2.3.2 (p. 118-119)

Page 109 of 301
Define Traceability
• What tool will you use to create your
traceability matrix?
• Where will the traceability matrix be stored?
• Who will have access to the traceability
matrix? What permissions are required?
• What information will you collect about each
requirement?
• How will you classify the requirements?

Page 110 of 301
Define Traceability
Traceability Management
Attributes
Components Components
• Related requirements • Absolute • Requirement type
(dependencies) Reference/ID • Logical sequence
• External interfaces • Author • Version/release
• Business Rules • Complexity • Approval
• Business objective • Ownership • Date completed
• Design reference • Priority • Comments
• Test reference • Risks • Process
• Source • Functions
• Stability • Use Cases
• Status • Other?
• Urgency
Traceability Components: Includes any related requirements, external interfaces, business rules,
the business objective the requirements satisfies, where it can be found in the design document,
and the related test reference numbers.
Attributes: Each requirement should be uniquely identified and will have supporting "attributes" or
information about itself.
Management Components: Includes elements that can help the business analyst manage the
requirement. E.g., what version or release the requirement will be implemented in, who approved
the requirement, the date it was implemented into the system, and a comments section (allows
you to capture why the requirement was deleted or rejected, by whom, and when). The business
analyst may also add additional categories that will help them manage and organize the
requirements such as tracing requirements to processes, functions, or use cases, etc.
The traceability matrix may be captured in a word table, spreadsheet, database, or management
tracking tool which allows the business analyst to sort by any of the organizational components.

Page 111 of 301
Define Traceability
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fifth Edition, Project
Management Institute, Inc., 2013, Page 119.
This is a sample traceability matrix, abbreviated for an example. Your matrix may look different
depending on what tool is used and what traceability components, attributes, and management
components are used to manage the requirements.

Page 112 of 301
Define Communication
• Communication plan is a plan that describes how,
when, and by whom information will be administered
and disseminated.
• Business analysts will often have a large contribution to this
plan as it relates to the product scope and requirements.

Page 113 of 301
• Common considerations:
• Stakeholder communication requirements
• Information to be communicated
• Time frame and frequency of communication
• Person responsible for communicating
• Person or groups who will receive information
• Methods used to convey information
• More ...

Page 114 of 301

Page 115 of 301
Define Decision Making
Unanimity:
Every one
agrees
Dictatorship: Group Majority: >

One man’s Decision 50% of
decision Making voters
Plurality:
Most votes

Page 116 of 301
Define Requirements Verification/Validation
Verification: Validation:
•Conducted by •Conducted by the
engineering customer (end-user)
•Objective: Meet design •Objective: Meet needs
Verification is confirmation by examination and evaluation of objective evidence that a specific

design specification has been met.
Validation is confirmation by examination and evaluation of objective evidence that a specific

intention has been met.
The difference between these two activities entails who does them and the nature of the
acceptance criterion.

Page 117 of 301
Define Requirements Change Process
• A process whereby modifications to
documents, deliverables, or baselines
associated with the project are identified,
documented, approved, or rejected
Source:
• PMBOK® Guide v. 5, Glossary (p. 530)

Page 118 of 301
Approve Change
• Change Control
Board / Sponsor
Analyze Impact
• Business Analyst /
Project Team
Updated requirements
Make baseline
Recommendation • Business Analyst
• Business Analyst /
Project Manager
Request Change
• Requester
Change Control Process
Request Change: A formal change request is needed before change can be considered. How
will requests be made and tracked for this project? Is there a specific form? Who completes the
form?
Analyze Impact: Once a change has been received the project team will need to analyze the
impact. The business analyst leads the analysis on the impact to the solution. The requirements
traceability matrix will help the business analyst to identify impacted requirements. The project
team will provide additional analysis on the project impacts to the project manager. Who is
responsible for impact analysis of which aspects? How will these impacts be tracked?
Make Recommendation: The business analyst will develop a recommendation on the change
request by determining the cost-benefit or value added to the solution if the change is approved.
The recommendation gets routed to the approvers of change requests. Typically this will be the
project sponsor and/or a change control board. In some cases, changes within a certain threshold
of impact may be left to the discretion of the project team. Who will be involved in developing
recommendations? Is there a predetermined format for recording the recommendation?
Approve Change: The project sponsor or change control board will need to make a decision to
approve or reject the change request based in part upon the recommendation of the business
analyst and project manager and considering the overall impact to the project and solution. Who
has the authority to approve what type of change requests?
Update requirements baseline: An approved change to requirements must be reflected in a new

requirements baseline. The business analyst will manage the requirements baseline. How often are
requirements re-baselined? After every change or are changes botched? How will the new
baseline be communicated to the project team and stakeholders? How will we version and track
changes to the requirements baseline? (Covered in more detail in task 5.)
Communicate Changes: Requirements that have been rebaselined will also need to be
communicated to stakeholders. How are stakeholders notified of rebaselined requirements?

Page 119 of 301
Change Request Form Example
ABC Project Change Request CR #:
Prepared by: Date Submitted:
Title: Enter a brief, descriptive name for this change request.
Priority: Use a 1-2 word description of the change request priority (e.g., Top, High, Medium or low).
Change Request Details:
Description: Describe the change being requested. Include a description of impacts to existing objectives and deliverables as
well as any new objectives and deliverables.
Justification: Provide a business case for the change being requested.
Impact if not implemented: Describe the impact if the requested change is not implemented as requested. Discuss any issues of
timing of implementation.
Change Request Impact Analysis:
Scope& Requirements: Describe the impacts on project requirements including whether this is in or out of scope of the project as
required.
Project Risk: Describe risks associated with this change or overall impacts of change on project risks.
Change Request Form Example

ABC Project Change Request CR #:
Prepared by: Date Submitted:
Change Request Impact Analysis (cont.):
Schedule: Describe potential impacts of change on project schedule. Include description of proposed implementation schedule
associated with this change.
Budget: Include information about impacts on project budget. Provide specific details on costs associated with the change.
Project Management: Describe any impacts to the project management plan or project organization.
Alternatives: Describe alternatives to the proposed change.
Recommendation:
Resolution Description: Include information about what is to happen with this change request (e.g., approved, denied, on hold,
etc.), the date this decision was made, who was involved in the decision and the rationale for the decision.
Request Implementation Activities: Describe specific follow-on activities required by the resolution, assigned resource, timeline and
other details. Include references to modifications to the project schedule and project or project management deliverables as
appropriate

Page 120 of 301
• For an Adaptive (Agile) Project
• User stories and additional activities are continuously
reprioritized within the product backlog
• Highest priority user stories/activities are selected for each
iteration
• No changes are allowed once the iteration starts

Page 121 of 301
Define Solution Evaluation Process
• Acceptance Criteria:
• A set of conditions that is required to be met before
deliverables are accepted
Source

Page 122 of 301
• Acceptance Criteria Considerations:
• Written from the perspective of the end-user or
customer
• Are not technical requirements
• (test cases are written from acceptance criteria)
• S.M.A.R.T.
• Owned by the project sponsor
• (product owner in Agile)
SMART
• Specific
• Measurable
• Achievable
• Relevant
• Time Bound (or upon implementation)
Source:
• http:/ /www.brighthubpm.com/project-planning/109950-building-winning-projectacceptanee-
criteria/

Page 123 of 301
• Given-When-Then
• Given (some context)
• When (some action is carried out)
• Then (a particular set of observable
consequences should obtain)
Source:
• http:/ /guide.agilealliance.org/guide/gwt.html

Page 124 of 301
Given-When-Then Example
• Given my bank account is in credit, and I

made no withdrawals recently
• When I attempt to withdraw an amount less
than my card's limit
• Then the withdrawal should complete
without errors or warnings
Source:
• http:/ /guide.agilealliance.org/guide/gwt.html

Page 125 of 301
Discussion
• How do you define "acceptance criteria“

related to solution quality?

Page 126 of 301
Grade vs. Quality
Grade Quality
• Category or rank used to • The degree to which a set of
distinguish items that have inherent characteristics fulfills
the same functional use but requirements
do not share the same
quality requirements
Source
• PMBOK® Guide v. 5, Section 8 (p. 228)

Page 127 of 301
Precision vs. Accuracy
Precision Accuracy
• Measure of exactness • Assessment of correctness
Sources:

Page 128 of 301
Cost of Quality
• Costs incurred over the life of the product
Project Management Institute, A Guide to the Project Management Body of Knowledge,

(PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc., 2013, Page 236.

Page 129 of 301
Seven Basic Quality Tools
• Cause and effect diagrams
• Flowcharts
• Checksheets
• Pareto diagrams
• Histograms
• Control charts
• Scatter diagrams

Page 130 of 301
Cause and Effect Diagram
(Fishbone or Ishikawa)
Cause and Effect (Ishikawa or Fishbone) Diagram

A type of flowchart that helps organize thinking about a problem and diagnoses cause and effect
to discover root cause. Can be used in conjunction with the "5 Whys" tool.
The problem under consideration is at the head of the "fish." Then the rib bones are drawn to
represent the categories of potential causes of the problem. Any categories can be used, but
typical categories used are below.
The 8 Ms (used in manufacturing)

Machine (technology) Method (process}
Material {Inc. Raw Material, Consumables, Info.) Measurement (Inspection}
Man Power (physical work}/Mind Power (brain work) Management/Money Power
Milieu/Mother Nature (Environment) Maintenance
The 8 Ps (used in service industry)

Product=Service Price
Place Promotion/Entertainment
People(key person) Process
Physical Evidence Productivity & Quality
The 4 Ss (used in service industry)

Surroundings Suppliers
Systems Skills

Page 131 of 301
Flowcharts
Flowcharts
Graphically depict how the process flows from beginning to end to illuminate how components
of the system are related. Flowcharting also helps to analyze how problems occur and highlights
inefficiencies.

Page 132 of 301
Checksheets
Checksheets often are used to collect sampling results information about defects which then may
be further analyzed using a Pareto chart

Page 133 of 301
Pareto Chart
Pareto Analysis
In 1906, Vilfredo Pareto inspired the 80/20 Principle, which states that 80% of problems are due to
20% of the causes.
The Pareto Chart shows how many results were generated by types or category of identified
cause. It identifies the "vital few" causes of most quality problems. If those few problems are
eliminated, about 75%-80% of the problems will be eliminated. For example, if most of the problems
in the Call Center are due to network issues, resolving those issues will eliminate most of the calls.
Common Pareto Terminology

• Before and After Measures-New Pareto bars can be drawn side by side with the original Pareto
showing the effect of the change.
• Breakpoint-This is where the Pareto principle visibly takes effect on the chart.
• Categories of Contributors-These are the groups or clusters of problem categories.
• Cumulative Percentage-This is the ongoing total percentage of contribution each problem
contributes when added together.
• Magnitude of Contribution-This is how much each individual problem contributes to the total
sum of all the problems added together.
• Major Cause Breakdown-This is the tallest bar on the graph.
• Trivial Many-These are other contributors to the problem that could be studied at a later time.
• Vital Few-These are the contributors that make up most of the problem.

Page 134 of 301
Histogram
Histograms
Histograms are bar charts showing how often something occurs. The height of each column
represents the frequency of the data. Histograms help identify the cause of problems by the shape
and width of the distribution. The columns of data may be unordered as shown above, or ordered
as shown in the Pareto chart.
Histograms typically don't include the element of time and how variation occurs over time,
although a Run Chart can be utilized to show frequency over time.

Page 135 of 301
Control Chart
Control Chart Analysis

A control chart's purpose is to determine whether or not a process is stable or has predictable
performance (typically) over time by measuring output variables representing repetitive activities.
Control charts can be used for both project and product life cycle processes.
Key Concepts
• The middle line represents the mean or average of the data.
• The upper and lower control limits are usually set at+/- 3 sigma (11voice of the data"). Data
points are plotted and then analyzed to determine if the process is "out of control" (unstable)
or "in control" (stable). There are eight rules for "out of control" or special cause conditions- the
• test will focus on the following four:
• One point more than 3 sigma from the center line (outside of control limits).
• Seven points in a row on same side of the center line (Rule of 7).
• Six points in a row, all increasing or decreasing. (trend)
• Fourteen points in a row, alternating up and down.
• "Normal" variation (data points falling within control limits that do not follow the above-stated
rules) is also called common or random cause variation.
• The upper and lower specification limits (USL, LSL) represent the "voice of the customer"; in other
words, what is acceptable to the customer. The USL and LSL may be inside or outside of the
UCLs and LCLs.

Page 136 of 301
Scatter Diagram
Scatter Diagrams
Shows relationship or correlation between independent ("X" axis) and dependent ("Y" axis)
variables. Independent variables are also known as "inputs" or "potential causes"; dependent
variables are also known as "outputs" or "effects."
While scatter diagrams do show correlation, they DO NOT show cause and effect (further analysis
is needed}.
The closer the points are to a diagonal line, the more closely they are positively (I) or negatively
(\) correlated.

Page 137 of 301
Design of Experiments (DOE)
Let's try this ...
What if we use expert-level
skills, and moderate quality
materials, and shorten the
testing phase, and ... For this widget we're building,
let's see what happens if we use
a higher temperature for
molding, a shorter cooling
cycle, and the highest grade
paint, and ...
Design of Experiments (DOE)

DOE uses statistical "what-if" scenarios to determine which combination of variables produce the
best or desired quality outcome. DOE, unlike other quality techniques, provides a tool for
modifying multiple factors at the same time rather than just one at a time. It is more typically used
on the product of the project, rather than the project itself.

Page 138 of 301
Why Sampling
Statistical Sampling
• Attribute Sampling
• The sample conforms or not
• Example: The bottle has a label on it or it doesn't.
• Variable Sampling
• The degree to which the sample conforms
• Example: How close is the water in the bottle to
the correct fill line. (It is 90% full, or 75% full, et,c,.)
Statistical Sampling
Most often, it is not cost effective to inspect EVERY product. Therefore, a sample of the product is
inspected to determine quality. Statistics provides formulas for determining correct sample sizes.
There are two types of sampling:
• Attribute sampling: The result is rated by if the product conforms or it does not.
• Variable sampling: The result is rated by the degree of conformity.

Page 139 of 301
Plan the Business Analysis Work
Document
Determine
Build the Assemble the Review the
Who Plans
Business the Business Rationale for Plan with Obtain
the Business
Analysis Analysis the Business Key Approval
Analysis
Work Plan Work Plan Analysis Stakeholders
Effort
Approach

Page 140 of 301
Build the Business Analysis Work Plan
CRM Business
Analysis
BA Plan Requirements Analysis Signoff
Decomposed /
Communication Elicited Requirements
WBS
Elaborated
Plan Requirements package
Requirements
Requirements
Documented Prioritized Requirement
Management
Requirements Requirements walk through
Plan
Issues
Management
Confirmed What will the BA create and
Requirements
Plan deliver to support the project?
This is a simplified WBS for typical business analysis activities on a software development project.
Each deliverable that the business analyst is responsible for is identified and then progressively
elaborated into sub-deliverables.

Page 141 of 301
• The business analyst is responsible for
developing estimates for BA activities that
feed into the overall project schedule.
Estimate Estimate
Define Sequence
activity activity
activities activities
resources durations
Source:
• PMBOK® Guide v. 5, Chapter 6

Page 142 of 301
• For each deliverable in the WBS
• What tasks (or activities) to you need to
perform to deliver the item?
• What tasks (or activities) will others need to do
to support delivering the item?

Page 143 of 301
• Identify and document relationships among
the business analysis activities to indicate a
logical sequence for the work.
Source:
• PMBOK® Guide v. 5, Section 6.3 (p. 153}

Page 144 of 301
• Precedence Diagramming Method (PDM)
• Used to construct a schedule model
• Activities are represented by nodes
Source

Page 145 of 301
1. Estimate the types of quantities of resources
needed to perform each activity.
2. Estimate the durations needed to complete
the individual activities with estimated
resources.
3. Estimate the costs needed to complete the
individual activities with estimated resources
and durations.
Source:
• PMBOK® Guide v. 5, Section 6.4 (p. 160 & 165)

Page 146 of 301
Build Business Analysis Work Plan
(Estimation Techniques)
Analogous
Parametric
Delphi
Rolling Wave
3-Point
Bottom
up
Analogous
Also called "top down". Uses similar past projects to forecast a new one, usually at a high ROM
(Rough Order of Magnitude) level.
Example: Based upon a similar project she completed a year ago, Jane estimates it will take 3
months to complete requirements.
Parametric
Using parameters of work times their number to arrive at a total estimate.
Example: John knows from experience that it takes about two weeks to define requirements for
each interface. There are 6 interfaces for requirements definition. John estimates 12 weeks for
requirements for all interfaces to be completed.
Delphi
An interactive estimating method which relies on a panel of experts. The experts independently
answer questionnaires in two or more rounds and note their assumptions. After each round, a
facilitator distributes an anonymous summary of the experts' forecasts from the previous round as
well as the reasons they provided for their estimates. The process continues until consensus is
reached.

Page 147 of 301
Build Business Analysis Work Plan
(Estimation Techniques)
Analogous
Parametric
Delphi
Rolling Wave
3-Point
Bottom
up
Rolling Wave
Progressive refinement of estimates as project phases/iterations begin.
Example: Sarah has provided an order of magnitude estimate of 12 weeks to complete the
requirements package. She is refining her schedule for the next set of features. After reviewing the
deliverables and activities needed to complete the deliverables, she estimates this set of
requirements will take 20 hours to complete.
3-Point Estimation A formula using averages to estimate based on most likely, pessimistic, and
optimistic estimates (O+P+ML}/3
Tom thinks it will take 3 weeks to complete the requirements. If things go exceedingly well it could
be as little as two weeks. Worst case scenario is 6 weeks.
(2+6+4)/3 = 4 weeks
PERT is a variation of 3-Point Estimating using a weighted average, giving more weight to the most
likely estimate (O+P+(ML *4))/6. Given the scenario above
(2+6+(3*4))/6
(2+6+12)/6 = 3.3 weeks
Bottom Up
Estimation based upon detailed individual tasks and activities.
Example: Lucy has fully defined all of her deliverables and activities to complete the deliverables.
She has estimated the time needed to complete each activity and concluded it will take six weeks
to complete all of the deliverables.

Page 148 of 301
Assemble the Business Analysis Work Plan

Page 149 of 301
Rationalize the Business Analysis Approach
Provides
assurance
Helps in
supporting
Reduces
and
uncertainty
managing the
work
Why
rationalize
the
approach?

Page 150 of 301
Review the BA Plan with Key Stakeholders
• Reduces risk of stakeholders failing to
support
• Be ware of role
• Commit time
• Understand how decision are handled
• Buy-in

Page 151 of 301
Obtain Approval of the BA Plan
• May be formal and require a signature
• May be informal and only require verbal
acceptance

Page 152 of 301
Practice Questions
1. What should be included in the requirements management plan?

A. Requirements analysis activities, configuration management process, requirements
prioritization process, traceability structure.
B. Requirements analysis activities, project schedule, project team RACI.
C. A requirements management plan is not needed.
D. How activities will be planned, tracked, and reported.
2. What are valid elements to include in the Requirements Traceability Matrix?

A. Priority, status, owner, complexity
B. Business needs, project scope, product development, test scenarios
C. Project team progress
D. Changes to requirements
3. Which of the following provides information on the process to document changes to

requirements?
A. Configuration management plan
B. Project plan
C. Requirements management plan
D. Change management plan
4. Which of the following can be said about a configuration management system?

A. It includes the configuration control system, which is focused on the specification of the
requirements, as well as the change control system,, which is focused on identifying,
documenting, and controlling changes to the stakeholder’ needs.
B. It includes the configuration control system, which is focused on the delivery mechanism
for the products, as well as the change control system, which is focused on identifying,
documenting, and controlling changes to the project and product baselines.
C. It includes the configuration control system, which is focused on the specification of both
the deliverables and the processes, as well as the change control system, which is focused
on identifying, documenting and controlling changes to the project and product
baselines.
D. It includes the traceability management system which is focused on the specification of
both the deliverables and the processes, as well as the change control system which is
focused on identifying, documenting and controlling changes to requirements.
5. You are making a case for using a traceability matrix. Which of the following is included in your
presentation?
A. It provides metrics for quantifying the business value of each requirement.
B. It provides a method for confirming cross-functional value of project and product
requirements.
C. It provides the method for communicating requirements to stakeholders to manage
product expectations.
D. It helps validate the business value of each requirement.

Page 153 of 301
6. Organizations may have informal and formal standards for business analysis work, including
how they fit into a project. Which of the following statements is the most correct?
A. The approach should be tailored to the needs of the specific initiative.
B. A standard approach must be followed exactly for every project.
C. Review the organization standards and dictate to the stakeholders the best approach.
D. Organizations don’t really have standards and it’s always best to follow what all other
projects are doing.
7. Which statement best describes how to plan business analysis activities?

A. Determine the activities that must be performed, the deliverables that must produce, and
estimate the effort required to perform that work.
B. Determine the activities that must be performed to ensure compliance with stakeholder
expectations.
C. Identify management tools required to measure the progress of business analysis work.
D. Build the requirements estimates.
8. Which of the following is an important tool in defining the scope of work and in developing
estimates.
A. WBS
B. RBS
C. OBS
D. TBS
9. Lydia is planning her business analysis communications with stakeholder on a major new
project. Which stakeholder type would she spend the most time within creating the plan?
A. Domain SME/End user
B. Others on the BA team
C. Sponsor
D. Project manager
10. Which of the following approaches is most likely to use a formal requirements change
management system?
A. Agile
B. Scrum
C. Waterfall
D. Extreme programming

Page 154 of 301
Exam Domain 3:
Requirements
Elicitation and
Analysis

Page 155 of 301
Objectives

Analysis
processes within Analysis
Analysis
Describe tools and techniques for eliciting requirements.
Apply analysis tools and techniques to requirements in order to decompose and verify complete
requirements suitable for development.
Discuss evaluating options using decision-making and valuation techniques to prioritize and
allocate requirements
Use techniques to get stakeholder buy-in to attain signoff of the project requirements.
Create acceptance criteria for determining project results.

Page 156 of 301
Tasks
• Elicit or identify requirements, using individual and group elicitation techniques in
Task 1 order to discover and capture requirements with supporting details (e.g., origin
and rationale).
• Analyze, decompose, and elaborate requirements using techniques such as

Task 2 dependency analysis, interface analysis, and data and process modeling in order
to collaboratively uncover and clarify product options and capabilities.
• Evaluate product options and capabilities by using decision-making and valuation

Task 3 techniques in order to determine which requirements are accepted, deferred, or
rejected.
• Allocate accepted or deferred requirements by balancing scope schedule,

budget, and resource constraints with the value proposition using prioritization,
Task 4 dependency analysis, and decision-making tools and techniques in order to
create a requirements baseline.

Page 157 of 301
Tasks
• Obtain sign-off on requirements baseline using decision-making techniques in order
Task 5 to facilitate stakeholder consensus and achieve stakeholder approval.
• Write requirements specifications using process (such as use cases, user stories),
Task 6 data, and interface details in order to communicate requirements that are
measurable and actionable (that is, suitable for development).
• Validate requirements using tools and techniques such as documentation review,

Task 7 prototypes, demos, and other validation methods in order to ensure requirements
are complete, accurate and aligned with goals, objectives, and value proposition.
• Elaborate and specify detailed metrics and acceptance criteria using

Task 8 measurement tools and techniques for use in evaluating whether the solution
meets requirements.

Page 158 of 301
Elicit
• To draw forth or bring out
• Requirements elicitation is the activity of

drawing out information from stakeholders
and other sources.
Source:
• http:/ /www.merriam-webster.com/dictionary/elicit

Page 159 of 301
Requirements Elicitation
Conduct Document
Plan for Prepare for Complete
Elicitation Outputs from
Elicitation Elicitation Elicitation
Activities Elicitation
• Develop plan • Determine the • Introduction

objective • Body
• Determine the • Close
Participants • Follow-Up
• Determine the
Questions for the
• Elicitation
Session
Techniques

Page 160 of 301
Plan for Elicitation
Develop Elicitation Plan
• Elements in an elicitation plan include:
• What information to elicit.
• Where to find that information.
• How to obtain the information.
• Sequencing the Elicitation Activities.
Elements in an elicitation plan include:

• What information to elicit. What does the business analyst need to know in order to define the
problem, solve the problem, or answer the question?
• Where to find that information. Where is that information located: in what document, from
what source, in whose mind? Identify who has the information or where it is located.
• How to obtain the information. What method will be used to acquire the information from the
source?
• Sequencing the Elicitation Activities. In what order should the elicitation activities be
sequenced to acquire the needed information?

Page 161 of 301
Prepare for Elicitation
Determine Determine
Determine
the the Questions
the objective
Participants for the Session

Page 162 of 301
Prepare for Elicitation

Page 163 of 301
Conduct Elicitation Activities
Body Close
• Open-end • Any questions?
Introduction • Close-end • Anything else? Follow-Up
• Contextual • Anyone else?
• Context-free
• Introduction. The introduction sets the stage, sets the pace, and establishes the overall
purpose for the elicitation session.
• Body. The body is where the questions are asked and the answers are given.
• Close. The close provides a graceful termination to the particular session.
• Follow-Up. The follow-up is where the information is consolidated and confirmed with the
participants.

Page 164 of 301
Elicitation Techniques
• Brainstorming
• Document Analysis
• Facilitated workshops
• Focus Groups
• Interviewing
• Observation
• Prototypes
• Questionnaires and Surveys
Source
• PMI-PBA® Examination Content Outline

Page 165 of 301
Brainstorming
• Generate and collect multiple ideas related to

the project and product requirements.
• Advantages • Challenges
• Elicits many ideas in short • Dependent on participants~
period creativity and engagement in
• Encourages creative thinking the
• Can reduce tension during • process
requirements workshops • Temptation to debate ideas
(participants should agree not
to)
Brainstorming
A technique that promotes divergent thinking. Divergent refers to those team activities that
produce a broad or diverse set of options. It uses the creative powers of a group to generate
many ideas quickly to help solve a problem or resolve an issue. By contrast, convergent thinking
narrows down possibilities to select the best idea or option.
Brainstorming is used extensively in requirements activities, ranging from analyzing root causes of
business problems to initial product concept to recommended solutions. A skilled facilitator is
needed to guide the group through the technique, to avoid a chaotic free-for-all of ideas.
Source:
• PMBOK® Guide v. 5, Section 5.2.2.4 (p. 115)

Page 166 of 301
Document Analysis
• Collects requirements for an existing ("As Is") system by

studying and summarizing available business and system
documentation.
• Provides a useful starting point • Limited to ”As Is"
for analysis • Existing documentation may
• Gives a way to cross-check be outdated or limited
other elicitation results (e .g., • Can be time-consuming and
interviews) tedious to perform
• Leverages existing
documentation to
discover/confirm requirements
Document Analysis
A technique that collects requirements for an existing ("As Is") system by studying and summarizing
available documentation. It gathers details of a current system, such as process flows, data
entities/attributes, business rules, reports, etc., This technique can compensate for a lack of
qualified Subject Matter experts (SMEs), assuming the documentation is current.
Document analysis is only useful for an existing system and when current, accurate
documentation exists for it.
Source:

Page 167 of 301
Facilitated Workshops
• A focused session to quickly bring key stakeholders
together to define product requirements.
• Can elicit detailed requirements • Availability of participants and
quickly; immediate feedback scheduling can be challenging
• Promotes collaboration and aids • Success highly dependent on skill
consensus through immediate of facilitator, and knowledge of
feedback and seeing others‘ the participants
viewpoints • Having the wrong number and mix
• Often less expensive than multiple of participants can impede
interviews progress and/or requirements
Facilitated Workshop
Useful for several requirements-related purposes Well-run workshops are one of the most effective
ways to discover and define high quality requirements quickly. This general goal is also central to
specific elicitation methodologies such as Joint Application Design, or JAD for short. The PMBOK
refers to JAD sessions synonymously with Facilitated Workshops.
The need for a skilled and neutral facilitator is critical to a productive workshop. The facilitator
keeps the group focused on the session objectives, and enforces discipline if need be. Agendas
are especially important to rely on when meetings become emotional. The scribe role is critical to
capturing the requirements generated.
Facilitator Responsibilities
• Establish a professional and objective tone for the meeting.
• Enforce discipline, structure and ground rules for the meeting.
• Introduce the goals and agenda for the meeting.
• Manage the meeting and keep the team on track.
• Facilitate decision-making/build consensus, but avoid discussing content.
• Ensure that all stakeholders participate and have their input heard.
• Ask the right questions, analyze the information being provided at the session by the
stakeholders, and follow-up with probing questions, if necessary.
Scribe Responsibilities
Document the requirements discovered in the format agreed to before the workshop.
Source:

Page 168 of 301
Focus Groups
• Bring together prequalified stakeholders to learn about their
expectations and attitudes about a proposed product,
service, or result. Homogeneous, Heterogeneous
• Elicit many ideas in single session • Trust may be an issue if topics are
vs. separate interviews sensitive
• Learn about people's attitudes • Data reported may not be
and desires consistent with actual behavior
• Active discussion to explore • Lack of group diversity may mean
personal views and be able to incomplete requirements
ask questions of other participants • Skilled moderator needed
• Scheduling may be difficult
Focus Group
A focus group is used to gather qualitative input about a problem, opportunity, product, system,
etc. It can be useful when many ideas need to be generated quickly, especially concerning
attitudes and beliefs about a product.
The findings are subjective conclusions about a particular situation, often reported as themes or
patterns vs. numeric results. Used more with marketing and new product creation, focus groups
can aid requirements elicitation by discovering stakeholders' attitudes and perceptions. This
discovery can uncover hidden expectations about a product or solution, which can then be
elaborated into more detailed requirements.
Homogeneous- The group has similar characteristics. (e.g., the group represented all CRS in the
Puget Sound area)
Heterogeneous- The group has differing characteristics (e.g., the group represented customer
service, fulfillment, and sales staff)
Source:

Page 169 of 301
Interviews
• Formal or informal approach to elicit information from stakeholders
by talking to them directly. Structured, Unstructured.
• Encourages participation, builds • Not ideal for reaching consensus
rapport with a wide range of stakeholders
• Allows full discussions, enabling • Requires considerable time
observations of non-verbal commitment by participants
• Allows for follow-up questions and • Training and experience required
maintains focus for a good interviewer
• Allows for private discussions of
sensitive issues
Interview
This is arguably the most common and understood elicitation technique. It involves questioning
stakeholders to learn about their problems, root causes of them, and the stakeholders‘
requirements. Interviews may be formal or informal, structured or unstructured (see below}, and
by individual or by group.
There are several factors that lead to successful interviews, such as the knowledge and
preparation of the interviewer and their skill. Plus, the willingness of the interviewee is a factor, as
is the interviewee's ability to understand their own requirements and what the business wants from
a new system.
Structured- Questions have been predefined

Unstructured- No predefined questions, an open discussion
Interviewing may be a mix of structured and unstructured (e.g., 5 structured questions followed by
an open discussion)
Source:

Page 170 of 301
Observation
• Observe individuals in their environment and how they perform
their jobs or tasks and carry out processes.
• Passive I invisible, Active I visible
• Realistic and practical insight into • Not viable for new processes
the business processes performed • Might be time-consuming and
• Elicits informal details and actual disruptive to observees
practices that may not be • May not observe all needed
captured in more formal sessions exceptions Not effective for
processes with a great deal of
cognitive activity or other
unobservable work
Observation
Observation is a common elicitation technique that is used to watch people in there natural work
environment. This technique is sometimes called 11job shadowing" and is useful as an adjunct to
other elicitation methods. For instance, it is a frequent way to help fill in gaps in processes and
related requirements based on what people describe verbally in interviews and requirements
workshops.
It is also valuable when stakeholders are unwilling or unable to articulate their work or their
processes. A Business Analyst may need to do observation to conduct basic discovery work when
more routine methods prove fruitless.
Depending on the situation, it may be helpful to actively participate in the job being observed.
This is sometimes referred to as 11participant observation.“
Passive /Invisible -The observer observes silently. They may document questions to follow up.
Active I Visible - The observer interacts with the observe and may ask questions as they work.
Source:

Page 171 of 301
Prototypes
• You gather preliminary requirements that you use to build an initial version of the
solution — a prototype.
• You show this to the client, who then gives you additional requirements.
• You change the application and cycle around with the client again.
• This repetitive process continues until the product meets the critical mass of
business needs or for an agreed number of iterations.
• Provides a real feel of the • May cause “selling” the
solution. solution instead of eliciting
requirements
Prototypes
Prototypes allow us to immediately see some aspects of the solution. Showing users a simple
prototype can provoke them into giving good requirements information or changing their mind
about existing requirements. The techniques described here help you gather ideas for
requirements. Prototypes and models are an excellent way of presenting ideas to users. They can
illustrate how an approach might work, or give users a glimpse of what they might be able to do.
More requirements are likely to emerge when users see what you are suggesting.
A presentation can use a sequence of slides, storyboard, an artist's impression, or even an

animation to give users a vision of the possibilities. When prototyping software, make a mock-up
of the user interface screens, emphasizing that there is no code and that the system has not been
designed or even specified yet (fair warning: there are dangers here for the unwary).
This prototyping aims to get users to express (missing) requirements. You are not trying to sell users
an idea or product, you are finding out what they actually want. Seeing a prototype, which
invariably is wrong in some ways and right in others, is a powerful stimulus to users to start saying
what they want. They may point out plenty of problems with the prototype! This is
excellent, because each problem leads to a new requirement.

Page 172 of 301
Questionnaires and Surveys
• Written sets of questions designed to quickly accumulate
information from a large number of respondents.
• Closed-ended, Open-ended
• Effective for quantitative, and • Open-ended questions may need
possible qualitative, data more analysis by a BA
• Helpful in reaching stakeholders in • May require follow-up, if answers
multiple geographic areas incomplete or inconclusive
• Quick and relatively inexpensive to • Not well suited to gathering
get large numbers of responses information on actual behaviors
• Response rates may be low
Survey /Questionnaire
A survey allows collecting a large amount of both qualitative and quantitative information from
people, in a fairly short amount of time. Surveys or questionnaires (terms used synonymously) are
best used when a large number of responses to a limited set of questions are needed
quickly.
The project team determines the data that needs collecting, formulates the questions, then
collects and analyzes the responses. A key part of the process is determining the sample
population to be surveyed, and finding a representative group of respondents to measure.
There are two types of survey questions, which are similar to interview questions:
• Closed-Ended- Limited choice of answers, including "Yes/No." Because possible answers are
known and limited, limited choice questions are easier to quantify and analyze than open-
ended ones.
• Open-Ended- Respondents are able to answer in any way or degree they wish. Open-ended
answers can provide more substance than closed-ended ones, but are more difficult and time-
consuming to analyze.
Source:

Page 173 of 301
Additional Group Creativity
Techniques
• Nominal group technique
• Idea/mind mapping
• Affinity diagram
• Multi-criteria decision analysis
Nominal group technique: This technique enhances brainstorming with a voting process used to
rank the most useful ideas for further brainstorming or prioritization.
Idea/mind mapping: Ideas created through individual brainstorming sessions are consolidated
into a single map to reflect commonality and differences in understanding, and generate new
ideas.
Affinity diagram: Allows large numbers of ideas to be classified into groups for review and analysis.
Multi-criteria decision analysis: Utilizes a decision matrix to provide a systematic analytical

approach for establishing criteria, such as risk levels uncertainty, and valuation, to evaluate and
rank many idea.
Source:

Page 174 of 301
Document Output from Elicitation
Type Description Examples
Written Describe outcomes from Interview notes. Notes from
Documents the elicitation. observations. Findings from
document analysis
Recordings Visual or audio recordings Video of observation session.
of elicitation events. Audio recordings from
interviews
Whiteboards Whether tangible or virtual, Sticky notes and drawings of
they contain notes that will a business process. Notes
eventually be transferred from a virtual meeting with
to another medium, such changes to a prototype.
as written documents
• Can be formal or informal.

• Notes comprised of wealth of information for performing other BA tasks.

Page 175 of 301
Complete Elicitation
• When to consider elicitation activities

complete?
• Progressively elaborated process.
For the predictive approach, the iterative process of elicitation and analysis continues until the
analysis produces no further questions, or when the risk of problems due to incomplete information
is determined to be acceptable.
For the adaptive approach, elicitation ana analysis occur throughout the project as part of initial
backlog definition, grooming the backlog, and then analyzing the details for each iteration.

Page 176 of 301
Challenges in Elicitation
Stakeholders
No access to are having
the right difficulty
stakeholders. defining their
requirements.
Stakeholders No sufficient
do not know detail to
what they develop the
want. solution.
• The business analyst cannot gain access to the right stakeholders. Focus on the information
not the individual.
• Stakeholders do not know what they want. Use techniques such as prototyping or storyboards.
• Stakeholders are having difficulty defining their requirements. Ask the business stakeholders
for help in understanding the problem domain and focus their attention on the problem or
opportunity they wish to address. After clarifying the situation, the discussion should be
focused on the high-level requirements.
• Stakeholders are not providing sufficient detail to develop the solution. Try to elicit
requirements through visual modeling techniques.

Page 177 of 301
Requirements Analysis
Requirements
Analyze
Requirements (Analyzed)
(decompose
(elicited) • Requirements
and elaborate)
models
Requirements that have been elicited are far from being ready for implementation by the project
team. This is where analysis begins! It is through this analysis that stakeholder statements of
requirement begin to take form to provide a complete list of product requirements that are
suitable for development.
The business analyst will be doing a significant amount of work to analyze, elaborate and
decompose the elicited requirements which will result in more requirements that contribute to a
more complete picture of the final solution The business analyst will also be creating models and
other artifacts that support and provide additional context to the requirements.

Page 178 of 301
Requirements Models
Rule
models
Process Data
models models
Scope Models Interface

models categories models
• Scope models: Models that structure and organize the features, functions, and boundaries of
the business domain being analyzed
• Process models: Models that describe business processes and ways in which stakeholders
interact with those processes
• Rule models: Models of concepts and behaviors that define or constrain aspects of a business
in order to enforce established business policies
• Data models: Models that document the data used in a process or system and its life cycle
• Interface models: Models that assist in understanding specific systems and their relationships
within a solution
Models use standard symbols to represent actions, decisions, hierarchies, and components, as
well as their relationships. They may need a key to help interpret them. Specific modeling
languages have been developed to provide continuity in model development interpretation
throughout common industries. Unified Modeling Language (UML) is a common standard. Other
languages include:
• Business Process Modeling Notation (BPMN)
• Requirements Modeling Language (RML)
• System Modeling Language (SysML)

Page 179 of 301
Requirements Models – Scope Models
Goal/Business Objective Model:
Goal/Business Objective Model:

The Goal/Business Objectives Model is a model that illustrates the value that a project will bring to
the customer. Utilizing the Business Objectives Model guides the identification of appropriate
business objectives and the process of selecting in-scope features.

Page 180 of 301
Ecosystem Map:
Ecosystem Map:
An ecosystem map is a diagram that shows all the relevant systems, the relationships between
them, and optionally, any data objects passed between them.

Page 181 of 301
Context Diagram
Context Diagram:
The Context Diagram shows the system under consideration as a single high-level process and
then shows the relationship that the system has with other external entities (systems, organizational
groups, external data stores, etc.).

Page 182 of 301
Feature Model:
Feature Model:
Feature Models are an established, graphical notation that use a hierarchical tree structure to
present features and their child features as well as their cardinality.

Page 183 of 301
Use Case
Use Case Diagram:

The Use Case Diagram provides information on solution scope by showing the "actors“ that will
use the resulting solution and the processes ("use cases") that will be included in the solution scope.
Components:
• Boundary box
• Actors
• Use cases
• Interfaces
Instructions:
• Draw a boundary box and label with the solution I project name.
• Draw stick figures on the left side of the boundary box and label with the types of solution users
(should be role of system use, not job title)- these are people actors
• Draw stick figures (or optionally computer icon) on the right side of the boundary box and
label with the systems or components that will interact with the solution- these are system
actors.
• Determine the primary goals of each actor and state in a short verb noun combination.
• Each goal represents a process
• Each goal/process becomes a use case
• Draw an oval for each use case and label with the use case name.
• Draw a line from the actor to the use case for each primary goal.
• Draw lines for other actor I use case interaction.

Page 184 of 301
Requirements Models – Process Models
Process Flow
Process Flow Diagram:

A.K.A swimlane diagram is a type of flowchart. It visualizes a process from start to finish, but it also
divides these steps into categories to help distinguish which departments or employees are
responsible for each set of actions.

Page 185 of 301
Requirements Models – Process Models
User Story
As a Customer Service Rep, I need to see the complete

history of customers calls so that I can answer their
questions more quickly
User Story:
A written story, one or two sentences, that begin the conversations of desired functionality.
As an <actor>, I want to be able to <function>, so that I can <business reason>

Page 186 of 301
Page 187 of 301
Requirements Models – Rule Models
Business Rules Catalog
Business Rules Catalog:

A document containing a complete list of business rules. The list may include the rule decription,
examples, related rules, references, notes, and assumptions for each.

Page 188 of 301
Decision Tree/Table
Decision Tree/Table:
Decision trees and decision tables depict a series of decisions and the outcomes they lead to.
• Decision trees work best with binary choices (i.e., yes or no),
• Decision tables can be used when more choices exist and the analysis is becoming complex.

Page 189 of 301
Decision Tree/Table
Decision Tree/Table:
Decision trees and decision tables depict a series of decisions and the outcomes they lead to.
• Decision trees work best with binary choices (i.e., yes or no),
• Decision tables can be used when more choices exist and the analysis is becoming complex.

Page 190 of 301
Requirements Models – Data Models
Entity Relationship Diagram
Entity Relationship Diagram:

The Entity-Relationship Diagram uses "craw's feet" to signify a "many" relationship. There is no way
to limit the maximum number of the many, unlike a Class Diagram. In practice, however, this is not
a significant problem.

Page 191 of 301
Data Flow Diagrams
Entity Relationship Diagram:

Data Flow Diagrams provide a data-centric view of a system, showing the information that is input,
output, processed, and stored within the system.
Elements:
• External Entities are people or other systems that interact with the system. Shown on a DFD as
a square.
• Data Stores show where and when the information is stored in the system. Shown as open
rectangles with labels.
• Data Process or the processes within the system. Shown as circles or rounded rectangles.
• Data Flows that show data flowing into and out of the Processes. Shown by single lines with
arrows indicating direction of the flow.

Page 192 of 301
Data Dictionary
Data Dictionary:
Key terminology and definitions used by the organization. Defines data used by an organization:
high-level and detailed data definitions. The purpose is to get stakeholder consensus about data
needed and terminology used.
• Glossary
• Terms and formal definitions for them, plus any synonyms or aliases.
• e.g., Customer= A person or business who inquires about our products or makes a
purchase. Alias: Client.
• Data Dictionary
• Formal definitions of individual data items and groups. Includes meanings and ranges
of permissible values (i.e., constraints).

Page 193 of 301
State Table/Diagram
Initial State Event/Transition New State Activities
Recruit Accept job New Hire Candidate Hire,
Add Employee
Recruit Rejects offer Non-Hire
New Hire Begins work Employee Intake new
employee
Employee Terminates Former Employee Terminate
Employee, Achieve
Employee
Employee Retires Retiree Employee
retirements
State Table/Diagram:
A table or a diagram that depicts the various "states" that an entity/class goes through during its
lifetime. Transitions move an entity from state to state based on events or other triggers. In other
words, shows how status changes over time.
Elements:
• States. Discreet conditions or statuses that an entity/object of a class can occupy, one at a
time. States are defined by the business and sources for requirements and rules for entering
and leaving the various states.
• Example: A Customer may have states of New, Provisional, Regular, Preferred,
Delinquent, and Former. What makes a regular customer a preferred one is dictated
by a business rule.
• Transitions. An event or other trigger that causes an entity to move from one state to another,
dictated by business rules.
• Events. These are the triggers that cause an entity to change state. It could be an internal or
external event.
• Activities. These are actions that represent things the business want to occur when an entity
enters or leaves a given state.

Page 194 of 301
State Table/Diagram
State Table/Diagram:
A table or a diagram that depicts the various "states" that an entity/class goes through during its
lifetime. Transitions move an entity from state to state based on events or other triggers. In other
words, shows how status changes over time.
Elements:
• States. Discreet conditions or statuses that an entity/object of a class can occupy, one at a
time. States are defined by the business and sources for requirements and rules for entering
and leaving the various states.
• Example: A Customer may have states of New, Provisional, Regular, Preferred,
Delinquent, and Former. What makes a regular customer a preferred one is dictated
by a business rule.
• Transitions. An event or other trigger that causes an entity to move from one state to another,
dictated by business rules.
• Events. These are the triggers that cause an entity to change state. It could be an internal or
external event.
• Activities. These are actions that represent things the business want to occur when an entity
enters or leaves a given state.

Page 195 of 301
Requirements Models – Interface Models
• Report Table:
• A report table is a model that captures the
detailed level requirements for a single report.
• It adds context for the textual information in
the report table.
See page 111 – Business Analysis for Practitioners: A Practice Guide

Page 196 of 301
System Interface Table
State Interface Table:

The System Interface Table is an RML systems model that details the communication between two
systems from a business stakeholder’s point of view. Instead of a technical point of view, where
message formats, character encoding or information about how a transaction occurs is included,
the System Interface Table describes what information has to be transferred, how often, and how
much.

Page 197 of 301
User Interface Flow
User Interface Flow:

A graphical representation of pages or screens that map user navigation of the screens based on
various triggers.
A user interface flow specifies pages or screens within a functional design and plats out how to
navigate the screens according to various triggers. The boxes in the diagram are the main screens
in the user interface. The lines show the flow allowed between screens
In this example, there are two main observations::

• At a first glance we can see that the analytics features (in orange) are segregated from the
main application (green and blue). The analytics section of the app is a behind the scenes
feature and is only accessible by an admin who will know how to specifically reach the login
page, but not accessible by the average user.
• Although it is slightly harder to spot, we can also see that within the main application (blue
and green) we can reach the calculation screen, valve screen, and info screen from any
other page. These three pages are linked to on the navigation bar at the top of the screen.

Page 198 of 301
Wireframes and Display-Action-Response
Wireframes and Display-Action-Response:

The display-action-response model is used in conjunction with wireframes or screen mockups to
identify page elements in the functions. The display-action-response model details displays and
interactions in a single user interface element based on wireframes using a tabular format, and
may include:
• ID
• Description
• Display conditions (upon screen entry, upon entering information, upon saving information)
• Behaviors (upon entry, upon exit)

Page 199 of 301
Acceptance Criteria
• I know this is done when…
1. I receive a daily email with open service tickets by

number. title, and status.
2. I can click on the service ticket number to view the
entire ticket within the system.

Page 200 of 301
Requirements Documentation
Requirements Requirements
(Analyzed) (Documented)
• Requirements models Document • Business Requirements
• Solution
Documentation

Page 201 of 301
• Goals,
objectives
• Functions,
and high-level
features and
Business organizational Solution
characteristics
Requirements needs. Documentation
• Blueprint for
• Often
development
grouped by
category
The solution documentation may be rendered in any number of forms. Some common forms
include:
• Requirements document, which may be a business requirements document and/or a
functional requirements specification and/or a system or software requirements specification,
etc.;
• Deck of user stories written;
• Set of use cases with accompanying nonfunctional requirements; or
• List of items on a product backlog.
The format of the solution documentation is defined in business analysis planning.

Page 202 of 301
Note!
Product: Project:
e.g. length and e.g. number lf
width of the laborers,
sidewalk in front qualifications,
of a building equipment, etc.
Responsibility of Responsibility of
the business the project
analyst manager
Don’t confuse product and project requirements.

Page 203 of 301
Categorization
Requirements
filters
Scope Functional Prioritization Testability
• Scope filter. Determine whether a requirement or information is in scope, out of scope, or

unknown. Unknown refers to requirements that are possibly invalid and need to be revised or
omitted.
• Functional filter. Once the functional categories have been determined, any defined
functional requirement not fitting into one of the categories can be filtered out, revised, or
discarded.
• Prioritization filter. An arbitrary level of priority (e.g., needs, wants, and desires), is defined and
used as a filter to determine which requirements stay or are removed.
• Testability filter. All requirements need to be testable, and all requirements should be
examined to determine if they are testable. Any requirements that are not testable are
filtered out and need to be revised.

Page 204 of 301
Documenting Assumptions and Constraints
Assumptions Constraints
Assumed, but
Limitation of
not proven,
options
to be true.
• Assumption: Something that is assumed, but not proven, to be true, usually during the life of
the solution
• Example: Employees will have access to the HR website from wherever they work.
• Business Constraint: A limitation on the business need/solution design.
• Example: Contract workers should only be able to access the equipment tracking
portion of the system.
• Technical Constraint: A limitation or boundary beyond which the technology or technology
budget cannot treat. The team must design a solution that works within the technical
constraints.
• Example: The system must work on all the Internet browsers supported by the
company.
• Project Constraint: A limitation on the project. Project managers use the term constraint when
referring to the project budget and time limitations.

Page 205 of 301
Guidelines
Correct Complete
Consistent Measureable
Precise Feasible
Requirements
Unambiguous Testable
shall be:
• Unambiguous. When two individuals disagree on the meaning of a requirement, then the
requirement is ambiguous.
• Precise. As a whole, the solution document states precisely what the solution to the business
problem is—no more, no less.
• Consistent. Avoid contradiction and redundancy.
• Correct. (Not absolute.) Each requirement should accurately describe the functionality to be
built.
• Complete. (Not absolute.) The requirements can be made more complete with more
information.
• Measurable. Each requirement needs to be independently measurable.
• Feasible. Doable
• Traceable. Can be mapped back to the source of the requirement and mapped forward to
a test case that proves that the requirement was successfully satisfied.
• Testable. Requirements should be written in a way that allows them to be tested.

Page 206 of 301
• Prioritization scheme to be used must be

fully defined in the business analysis plan.
• Basis for Prioritization • Techniques
• Compliance • MoSCoW (must, should,
• Business value could, won't)
• Risk (business or technical)
• Multi-voting
• Implementation
• Time boxing
• Likelihood of success
• Urgency
• Weighted ranking
• Dependencies • Others?
All requirements are not created equal. Therefore the business analyst, with the assistance of the
project manager and project sponsor, should determine the criteria by which each requirement
will be reviewed in relationship to its value to the business and its importance to the stakeholder.
Keep in mind that the selection criteria used should align with the goals and strategies of the
organization. Some organizations have a fully developed prioritization process that the business
analyst must use in their prioritization efforts with the stakeholders. The resulting priority is often
captured in a traceability matrix.

Page 207 of 301
Schemes
• MoSCoW. establishes a set of prioritization rules
which are:
• Must haves (fundamental to project success),
• Should haves (important, but the project success
does not rely on them),
• Could haves (can easily be left out without
impacting the project), and
• Won’t haves (not delivered this time around).

Page 208 of 301
Schemes
• Multi-voting
• Each participant is given a specific number of
votes to apply to the requirements.
• Optionally, the facilitator may allow
participants to apply many votes to one
requirement to provide added weight.

Page 209 of 301
Schemes
• Time-boxing:
•A technique for delivering prioritized
requirements based on the work the project
team can deliver within a set period.
Before conducting a prioritization workshops, implementation SMEs estimate the time and cost to
complete each requirement. With this information, a time-boxing approach starts with a
specification implementation timeframe or budget. The team must choose which requirements
can and should be included, given time and cost constraints. Used in many of the change-driven
software development approaches, this techniques causes the stakeholders to pick the most
important requirements, effectively marking them as the highest priority.

Page 210 of 301
Schemes
• Weighted Ranking:
• BA should facilitate a decision regarding
which criteria the decisions will be based on
• (During planning)
• The criteria are ranked with a score.

• The highest score is assigned to the criterion
considered to be the most important.
See Needs Assessment

Page 211 of 301
Requirements Reviews
• Common Roles • Outcomes
• Author • List of errors and omissions
• Presenter • List of participants
• Facilitator • List of corrections
• Reviews • Deliverable status
• Standards Rep • Identification of further
• Scribe review
• Approvals/sign-off
There are a number of roles that may be found in a review session. A business analyst may play
one or more of these roles or get additional support for fulfilling the roles. The key outcome of a
review is a list of errors and omissions, a list of who participated, a list of corrections, deliverable
status, identification of any additional reviews that may be needed, and ultimately approval or
sign-off of the requirements package.
Common Roles:
Author: creator of the deliverable to be reviewed . The business analyst will be the author of the
requirements lists and requirements package.
Presenter: (often the author) develops the agenda for the walkthrough and presents the
deliverable being reviewed.
Facilitator: facilitates the session.
Reviewer: reviews and evaluates the requirements.
Standards Rep: checks to ensure deliverable meets organizational standards.
Scribe: records the error, issues, suggestions, and other comments.

Page 212 of 301
Review Approaches
• Participant Driven • Document Driven
• Reviewers ask questions and • Author steps through the
bring up concerns based on document (top to bottom
items they noticed prior to explaining each section)
the review
• Reviewers bring up items they
• Author explains each item for
noticed prior to the meeting
clarification purposes
as the author addresses that
• Whole document may not be
section of the document
reviewed (determined by
questions asked) • Typically more thorough
When would you want to do each?

Page 213 of 301
Why Conduct Peer Review?
• Provides a venue for validation and verification
efforts
• Detects errors and omissions in the requirements
• Confirms requirements are accurate
• Identifies inconsistencies between documentation
and stakeholder needs
• Determines whether cost and time is sufficient to
build product and achieve the project objectives
Formal reviews are also called walkthroughs. They support the verification and validation efforts in
the project.
The purpose of reviews or walkthroughs is to catch errors, oversights, and incorrect assumptions
early in the project. The costs of capturing the errors and oversights are much lower at the
beginning of the project than toward the end of the project. The first reviews are often informal
and conducted with the key stakeholders. Peer reviews are conducted with other project team
members or other business analysts. The requirements and models (requirements package) are
then subjected to a more formal and final review.
The key concept in walkthroughs or review is that people can't always edit their own work and
see their own mistakes. If the business analyst is conducting a formal review during a stage gate
process, then they may work with the project manager and technologists to determine whether
the cost and time is sufficient to build the product and achieve the project objectives. The project
manager will then ask for approval to move the project forward.

Page 214 of 301
Effective Requirements Review Tips
• Be prepared • Celebrate when defect are
• Use a facilitator for larger found!
groups • Document decisions and
• Review the document – not assignments
the person  • Obtain sign-off (when
• Keep focused on the appropriate)
quality of the content
• Listen openly
Giving and receiving feedback is not always easy. When giving feedback it is important to focus
on constructive, concrete suggestions about the document. When receiving feedback it is
important to really listen without being defensive. Remember that discovering ways to improve
the quality of a document is cause to celebrate, since achieving a higher quality is the ultimate
goal of doing reviews.
As with all meetings, it is important to document results, decisions, and action items.

Page 215 of 301
Requirements Approval
• "Baseline" is the approved version of a work
product that can be changed only through
formal change control and is used as the
basis for comparison.
Source:

Page 216 of 301
Discussion
• Are the requirements ready to baseline?

Why or why not?

Page 217 of 301
Requirements Approval
Group Decision Making Techniques
• Unanimity
• Majority
• Plurality
• Dictatorship
Unanimity: Everyone agrees on a single course of action.
Majority: More than 50% of the members agree to a course of action.
Plurality: The course of action that gets the highest percentage of votes. This is typically used when
there are more than two options.
Dictatorship: One individual makes the decision

Source:

Page 218 of 301
Resolving Requirements-Related
Conflict
Multi-
voting
Weighted
Delphi
Ranking
How to
resolve
conflict?

Page 219 of 301
Practice Questions
1. What are the different types of requirements?

A. Business, stakeholder, functional, non-functional and transition
B. Business, stakeholder, solution requirements, transition, project, and quality
C. Optional, important, critical
D. Sponsor, stakeholder, functional, non-functional, transition, project, and quality
2. Considerations when collecting requirements include which of the following?

A. Project charter and stakeholder register
B. Project charter and WBS
C. Stakeholder register and scope statement
D. Scope statement and WBS
3. Which of the following statements about conflict is most true?

A. Conflict should be avoided as higher performing teams are collaborative in nature
B. The project manager should stay out of conflict between team members and let them
work it out
C. Conflict can lead to increased creativity and better decision-making
D. The project manager should first try “smoothing” as a conflict resolution strategy.
4. The ability to influence others is a critical interpersonal skill required of business analysts and
includes which of the following:
A. The ability to get others to see the inconsistencies in their perspectives.
B. A relentless passion and unyielding commitment to one’s perspectives.
C. The ability to understand various stakeholders’ perspectives.
D. The willingness to subordinate your goals to others’ goals.
5. A requirement is best defined as:

A. A need or want of the business to solve a problem or achieve an objective.
B. A condition or capability that is required to be present in a product, service, or result to
satisfy a contract or other formally imposed specification.
C. A condition or capability of a product or solution that documents a problem or objective
of the business.
D. A need or necessary feature of a system that could be sensed from a position anywhere
within the system.
6. The BA serving as facilitator encounters a situation such as this during a requirements workshop
with a client: A “scribe’ is assigned to keep track of important discussion points and action
items. Several times during the morning session, issues are deferred to a ‘Parking lot.’ The scribe
makes no visible gesture that the issue has been noted. What should the facilitator do?
A. Mention to the scribe’s supervisor that the scribe should be excluded from future
workshops.
B. Indicate to the scribe during the meting that “Parking lot’ issues should be acknowledged,
and suggest writing them on a white board or flip chart.
C. Wait until after the workshop has ended for the day, and out of the client’s presence to
provide coaching to the scribe with respect to meeting procedures and artifacts.
D. Start tracking “Parking lot’ issues independently so that they are not lost.

Page 220 of 301
7. Which of the following best describes what is needed in order to prioritize requirements?
A. Assessment of the proposed solution.
B. Allocated requirements.
C. Validated solution
D. Requirements Management Plan
8. How are transition requirements defined?

A. Communication with technical operational teams
B. The same way all requirements are defined
C. Through a transition decision matrix
D. Through requirement validation
9. Eliana is a business analyst working on the requirements for a new marketing system. When she
mentions to her manager that the stakeholders already have a commercial software
package in mind, her manager tells her that they should plan to build custom software. She
explains something that puts their mind at rest. What does Eliana explain to them?
A. That the decision will not be made until the requirements are captured and understood.
At that time she will recommend the purchase of the commercial software to the project
manager and sponsor.
B. That the decision will not be made until the requirements are captured and understood.
At that time she will compare multiple proposed solutions to see which best meets the
requirements.
C. That she will ensure the vendor discusses the situation with her manager to emphasize the
benefits of buying a package and the disadvantage of custom solutions.
D. That she will ensure that the vendor discusses the situation with the sponsor to emphasize
the benefits of buying a package and the disadvantages of custom solutions.
10. As the lead BA you are analyzing requirements collected by another BA on a big project. You
run across a requirement that states “The system shall be easy for new team members to
learn.” What should you suggest to the BA regarding this requirements.
A. Ask the BA to work with the stakeholder to prioritize the requirement.
B. Tell the BA “good job”
C. Suggest that the BA discuss the requirement with the stakeholder to get specific criteria on
what is “easy to learn”
D. Ask the BA to restate the requirement with specific criteria on what is “easy to learn”.
11. What prioritization method is typically used on an agile project?

A. Multi-voting
B. High, medium, low
C. MosCoW
D. Stack ranked
12. A prototype that is continuously modified and updated is known as what?

A. Exploratory prototype
B. Evolutionary prototype
C. A mockup
D. Horizontal prototype

Page 221 of 301
13. You are starting to recruit your participants for your focus group. You are looking for a very
diverse group of people. The participants you are looking for would be categorized as what?
A. Homogeneous
B. Heterogeneous
C. Esoteric
D. Homogenized
14. You are in the middle of doing an unstructured interview. You ask the questions “How many
days are counted for the member’s activity in the program per month?” Your stakeholder
replies “I don’t know”. This is an example of what type of question?
A. Open-ended
B. Calculation
C. Closed-ended
D. Unstructured
15. You are in the process of selection people to participate in a particular requirements elicitation
event. Among your considerations are whether the type of question will be open-ended or
closed-ended. You are also considering the best mode of distribution. What techniques are
you likely to be planning?
A. Survey/Questionnaire
B. Focus group
C. JAD workshop
D. Interview
16. The following process step in NOT recommended in the interviewing process:
A. Contact potential interviewees and explain why their assistance is needed.
B. Organize questions in a logical order or an order of significance based on the interviewee’s
knowledge or subject of the interview.
C. Use a standard set of interview questions for all interviewees in order to facilitate scoring
each question.
D. Send summary notes of the interview to the interviewee to review
17. You are walking your stakeholders through a diagram that shows the lifecycle of a class. What
type of diagram are you using?
A. Context level data flow diagram
B. Sequence diagram
C. State diagram
D. Functional decomposition diagram
18. Business value, implementation difficulty, and urgency are all basis for:
A. Requirements allocation
B. Requirements prioritization
C. Requirements planning
D. Requirement s status
19. Which of the following tools would be used in the Collect Requirements process?
A. Facilitated workshop and focus groups
B. Facilitated workshops and variance analysis
C. Focus groups and inspection
D. Decomposition and prototypes

Page 222 of 301
Exam Domain 4:
Traceability and
Monitoring

Page 223 of 301
Objectives

Traceability and Monitoring
processes within Traceability and Monitoring
Traceability and Monitoring
Describe tools and techniques for tracing and monitoring requirements.
Develop and use a traceability matrix to relate requirements to goals and objectives, and to other
requirements.
Use requirements attributes to manage, monitor and communicate requirements throughout the
project.
Manage changes to requirements using formal change control methods and traceability.

Page 224 of 301
Tasks
• Track requirements using a traceability artifact or tools, capturing the requirements'
Task 1 status, sources and relationships (including dependencies), in order to provide
evidence that the requirements are delivered as stated.
• Monitor requirements throughout their lifecycles using a traceability artifact or tool in

order to ensure the appropriate supporting requirements artifacts (such as models,
Task 2 documentation, and test cases) are produced, reviewed and approved at each
point in the lifecycle.
• Update a requirement’s status as it moves through its lifecycle states by

Task 3 communicating with appropriate stakeholders and recording changes in the
traceability artifact or tool in order to track requirements towards closure.
• Communicate requirements status to project manager and other stakeholders using

Task 4 communication methods in order to keep them informed of requirements issues,
conflicts, changes, risks, and overall status.
• Manage changes to requirements by assessing impacts, dependencies, and risks in

accordance with the change control plan, and comparing to the requirements
Task 5 baseline in order to maintain the integrity of the requirements and associated
artifacts.

Page 225 of 301
Traceability
• The ability to track product requirements

from their origin to the deliverables that
satisfy them.
• How the traceability process will be
conducted is set during business analysis
planning.
Benefits of Tracing Requirements:

• Helps to ensure that each requirement adds business value.
• Helps to meet customer expectations.
• Helps to manage scope

Page 226 of 301
Traceability
Product Project
Scope Scope
Work to be
Features and
carried out to
characteristics
build the
of the solution
product
Managed by Managed by
the Business the Project
Analyst Manager

Page 227 of 301
The Traceability Matrix

Page 228 of 301
Requirements Dependency
Implementation
Dependency
Benefit or Value
Subset
Dependency
Types of
dependencies
Requirements Dependencies:
• Subset: A requirement may be a subset of another requirement.
• Implementation Dependency: Some requirements are dependent on the implementation of
other requirements before they can be implemented.
• Benefit or Value Dependency: Sometimes the benefit of a requirement is unable to be
realized unless another requirement is implemented first.

Page 229 of 301
Requirements Approval Levels
Approval
Rejection of
authority vs.
requirements.
accountability.
Change
Control Board
Reviewer vs.
(CCB) and
approver.
approval of
changes.
Expert
Approval vs. Approval judgment and
signoff.
Levels the approval
process.

Page 230 of 301
Requirements Lifecycle

Page 231 of 301
Requirements Status
• Active • The PMBOK® Guide
• Cancelled does not provide a
standard framework for
• Deferred status.
• Added
• Approved 1. Plan
• Assigned 2. Define
• Completed 3. Use Consistently
Source:

Page 232 of 301
Change Management
Updated
requirements
Approve Change baseline
•Change Control Board •Business Analyst
/ Sponsor
Make
Recommendation
•Business Analyst /
Project Manager
Analyze Impact
•Business Analyst /
Project Team
Request
Change
•Requester
Request Change: A formal change request is needed before change can be considered. How
will requests be made and tracked for this project? Is there a specific form? Who completes the
form?
Analyze Impact: Once a change has been received the project team will need to analyze the
impact. The business analyst leads the analysis on the impact to the solution. The requirements
traceability matrix will help the business analyst to identify impacted requirements. The project
team will provide additional analysis on the project impacts to the project manager. Who is
responsible for impact analysis of which aspects? How will these impacts be tracked?
Make Recommendation: The business analyst will develop a recommendation on the change
request by determining the cost-benefit or value added to the solution if the change is approved.
The recommendation gets routed to the approvers of change requests. Typically this will be the
project sponsor and/or a change control board. In some cases, changes within a certain threshold
of impact may be left to the discretion of the project team. Who will be involved in developing
recommendations? Is there a predetermined format for recording the recommendation?
Approve Change: The project sponsor or change control board will need to make a decision to
approve or reject the change request based in part upon the recommendation of the business
analyst and project manager and considering the overall impact to the project and solution. Who
has the authority to approve what type of change requests?
Update requirements baseline: An approved change to requirements must be reflected in a new

requirements baseline. The business analyst will manage the requirements baseline. How often are
requirements re-baselined? After every change or are changes botched? How will the new
baseline be communicated to the project team and stakeholders? How will we version and track
changes to the requirements baseline? (Covered in more detail in task 5.)
Communicate Changes: Requirements that have been rebaselined will also need to be
communicated to stakeholders. How are stakeholders notified of rebaselined requirements?

Page 233 of 301
Types of Change Requests
Add a new requirement

• Adding/removing a requirement requires a change request
Change in the process

• Modifying an approved procedure, preventively or correctively, requires a
change request
Repair a defect
• Fixing a defective output request a change request

Page 234 of 301
Change Request Impact Assessment
Baseline
Other requirements
Business Analysis
Project Management

Page 235 of 301
Change Control RACI
CCB PM BA Dev/ Test
Design
Verify Business Value/Scope I C R I I
Determine impact to requirements I C R I I
Determine impact to design/dev I A C R I
Estimate level of effort to address I A C R R
Identify project impacts (Cost/Schedule) I A,R C I I
Prepare recommendation for CCB I A,C R I I
Approve or Reject Change A,R C C I I
Rebaseline project plan I A,R I I I
Rebaseline requirements I A R C C
Update tech documents I A C R R
Change Control Board (CCB): Reviews impact analysis from the project team including
recommendation based on cost-benefit provided by the business analyst; approves or rejects the
change.
Project Manager (PM): Ensures the change control process is followed, facilitates information
gathering and analysis from team, determines overall project impacts for consideration along with
the benefit(s) of the change, updates project plans as necessary if approved.
Business Analyst (BA): Determines the business impact and value of the change, determines cost-
benefit (or overall value) of the change to the project, identifies additional impacted
requirements, provides information to aid in team identification of additional impacts, prepares
recommendation, updates requirements baseline if approved.
Technical Team (Dev/Design & Test): Analyzes impacts to their work, develops cost and time
estimates to support the change, updates necessary documents if change is approved,
implements the change

Page 236 of 301
Configuration Management
What constitutes
the product at
any point in What changes have
time? been made to the
product?

Page 237 of 301
Configuration Management
Configuration Configuration
control accounting
Configuration Configuration
identification audits
Basic
components
1. Configuration identification
 The starting point for a configuration is called the baseline.
2. Configuration control
 Once the product baseline has been approved, changes to the design will fall under
configuration control. The changes will proceed to the configuration board with
representatives from various departments and will review all proposed changes.
3. Configuration accounting
 Configuration accounting is the tracking of all proposed changes and the
implementation status of every approved change.
 The details of every change is recorded and reviewed for existing and future
compatibility.
4. Configuration audits
 Configuration audits review the documentation system for completeness and
accuracy, and/or the product to verify engineering specification accuracy.

Page 238 of 301
Page 239 of 301
Version Control Tools
• Share Point
• OneDrive
• Team Foundation Server
• Google Drive Version Author Description Date/Time
• Version Table 1.0 Maher Initial Draft 24/7/2014

1.1 Bassam Feedback 26/7/2014
1.2 Maher Updates 27/7/2014
2.0 Maher Final for print 4/8/2014

Page 240 of 301
Requirements Management Tools
• A tool developed to support collecting,
analyzing, managing, and communication
requirements
• Common features include:
• Create & customize your own fields
• Easy to relate requirements to each other, to
use cases, or more
• Rich reporting features including customization
and export
• Wireframe and diagramming capability
See article at http://makingofsoftware.com/resources/list-of-rm-tools for more information

Page 241 of 301
What and How to Communicate
To Be Communicated Ways to Communicate
• Scope In person
• Requirements • Group meeting
• Use Cases • One on one meeting
• Models • Phone
• Wireframes • Virtual
• Issues / Risks
• Decisions / Changes Push Communications (provided to recipient)
• Status • Email
• Plans • Distributed report
• Product Backlog • Formal letter
Pull Communication 9recipient finds)

• Public Website
• Team Collaboration Website
• Shred Drive

Page 242 of 301
Requirements Communication
Considerations
• Business analysis approach
• Components included
• Optimal format(s) & venue(s)
• Stakeholder presentation preferences
• Formality
• Permanence/Retention
• Organization Standards
Some approaches, such as agile or some iterative methodologies, a requirements package is not
created. Instead, an informal work product may be created. The BA should work in close
connection with the project manager for any format, template or organization standards. In
addition, the BA must select the optimal format which communicates the information to the
specific audience and which meets the technology constraints by reviewers. To this end, the BA
will identify stakeholder presentation preferences such as the level of detail, language and
formality that is appropriate for each type of stakeholder. They must also determine what
information is important to communicate. Always remember that the primary goal of a
requirements package it to convey information clearly and in an understandable manner so it
can be reviewed and approved.

Page 243 of 301
Communication Channels
Project Quality
Manager Assurance
•Requirements •Detailed functional
package & non-functional
requirements
Technologists Business
•Detailed functional Stakeholders
and non-functional •Detailed
requirements requirements in
business language
Executive Project Sponsor

Management
•High-level Summary
Business •Business
requirements
Analyst
The business analyst is responsible for disseminating requirements information to all key
stakeholders. Each stakeholder group may need different information. For example:
Executive Management and Executive Sponsors: These stakeholders will probably want to see a
requirements summary and high level requirements. Their purpose is to understand the
requirements in regards to their business plans.
Project Sponsor: The type of communication the sponsor needs often depends on the
organizational level of the sponsor. A sponsor who is more hands on may want more detailed
information. A sponsor who is at a higher level in the organization or a sponsor who has a more
hands off approach may only want a summary or high level version of the information.
Business Stakeholders: Stakeholders who represent the customer and business normally like to see
detailed requirements presented in their business language.
Quality Assurance: QA analysts will need to understand the detailed functional and nonfunctional
requirements to make sure they understand what each requirement will deliver so they can
develop test cases and test scripts.
Project Manager: Although the project manager usually will not need a separate requirements
package, they will still want to see the requirements. It is best to work with the project manger to
determine what requirements documentation they will need on the project.
Technologists: Technologists could include developers, architects, database administrators, web

designers, capacity planners, etc. Most technologists will need the detailed functional,
nonfunctional and technical requirements so they can develop their design plans and the
solution.

Page 244 of 301
Practice Questions
1. You have received an approved change request from the project manager and have
updated the baseline requirements with the changes and published a new version of the
document. This is an example of:
A. Change control.
B. Configuration management.
C. Re-baselining.
D. Requirements management.
2. The following statements demonstrate how requirements traceability benefits scope

management EXCEPT for:
A. A stakeholder requirement must be traced to solution requirements to prevent a gap on
fulfilling customer needs.
B. A high priority requirements must be traced to a test condition or test case.
C. A design function must be traced to a functional requirement to prevent scope creep.
D. A functional requirement must be traced to a business requirement to ensure all
requirements belong within the scope of the project.
3. Which of the following can help guard against scope creep?

A. A strong stakeholder leader
B. Brainstorming
C. Problem management
D. Requirements traceability
4. Requirements must be _______________ to be managed, as stakeholders cannot consent to

requirements they are not aware of.
A. Defined
B. Elicited
C. Documented
D. Communicated
5. Traceability of requirements means:

A. Requirements can be traced forward through design and to the finished product and are
tested to ensure they work.
B. Requirements can be traced back to the business or project objectives, and who provided
them, to validate they will solve the problem being addressed.
C. Requirements can be traced back to the business or project objectives to validate they
will solve the problem being addressed, and forward through design and to the finished
product.
D. Requirements adhere to an organization template to ensure they help support strategic
direction of the organization.

Page 245 of 301
6. When communicating requirements, which of the following roles typically want to have high-
level summaries to help them understand the impact of the requirements?
A. SME
B. Regulator
C. Sponsor
D. Tester
7. Which of the following examples demonstrates the “effort” relationship:

A. For an online mortgage application, the online application is not wanted without
adequate login functionality.
B. Once the login is implemented, it makes it easy to add other secure features like accessing
loan information after the loan is created.
C. The login requirement includes the user ID, password, and password reminder
requirements.
D. The ‘password reminder’ requirement increases in desirability when the login functionality
is implemented.
8. Quint was assigned as a BA/QA for his next project. After requirements were completed
several months later, management learned that there were over 2,000 requirements for the
project. The requirements were completed on time but Quint’s estimates for traceability,
quality assurance, and defect resolution due to the large number of requirements made it
clear that the project deadline would need to be delayed if they wanted the project to move
forward. In order to speed things up in the future, Quint likely recommended which of the
following:
A. Mercury automated testing tool
B. Configuration management system
C. Requirements management tool
D. Outsource the effort
9. Which statement about conflict is true:

A. Conflicts that affect the requirements must be resolved before formal approval is given.
B. Sign-off can occur provisionally if the parties agree that not resolving the conflict does ot
present a risk to the business analysis effort.
C. Conflicts do not need to be resolved when using a change-driven approach and no
formal approval is required.
D. When conflicts occur that jeopardize the effort, the business domain subject matter expert
will resolve the conflict.
10. It is the role of the BA to analyze change request by performing each of the following tasks
EXCEPT for which one:
A. Ensure that each change request is traceable back to the source.
B. Determine the timeline in order to achieve the appropriate design solution for the problem
to be solved.
C. Ensure that the request is understood by key stakeholders.
D. Determine the impact of executing the change on external processes, people or systems.

Page 246 of 301
Exam Domain 5:
Evaluation

Page 247 of 301
Objectives

Evaluation
processes within Evaluation
Evaluation
Describe tools and techniques for Evaluation.
Validate a solution to assess if requirements are satisfied.
Communicate gaps and discrepancies between solution scope, requirements and developed
solution.
Determine how effective a solution was in meeting the goals and objectives of the project after
its implementation.

Page 248 of 301
Tasks
• Validate the solution's test results, reports, and other test evidence
Task 1 against the requirements acceptance criteria in order to determine
whether the solution satisfies the requirements.
• Analyze and communicate the solution's identified gaps and deltas

using quality assurance tools and methods in order to enable
Task 2 stakeholders to resolve discrepancies between solution scope,
requirements, and developed solution.
• Obtain stakeholder sign-off on the developed solution using

Task 3 decision-making techniques in order to proceed with deployment.
• Evaluate the deployed solution using valuation techniques in order

Task 4 to determine how well the solution meets the business case and
value proposition.

Page 249 of 301
Task 1
• Validate the solution's test results, reports,

and other test evidence against the
requirements acceptance criteria in order
to determine whether the solution satisfies
the requirements.

Page 250 of 301
Validate Results
• Validate
• Test Results
• Reports
• Other Evidence
This tasks is specific to "validating the test results, reports, and other evidence of the solution.“
"Testing" is not a business analysis activity.

Page 251 of 301
• Cause and effect diagram
• Flowcharts
• Checksheets
• Pareto diagrams
• Histograms
• Control charts
• Scatter diagram
These are described in detail in the Planning chapter.

Page 252 of 301
More Quality Tools
• Statistical Sampling
• Choosing part of a population of interest for inspection
• Inspection
• Examine or measure to verify whether an activity, component,
product, result or service conforms to the specific requirements
• Desk Checking
• Author/coder reviews own work prior to handing over to quality
assurance
• Walk Through or Peer Review
• See Peer Review Chapter 4.
Sources:
• PMBOK® Guide v. 5, Section 8.3.2 (p. 252)

Page 253 of 301
Control Quality
• Outputs
• Quality Control Measurements
• Validated Changes
• Verified Deliverables
• Work Performance Information
• Change Requests
Quality Control Measurements

These are the documented results of quality control activities.
Validated Changes
Anything that has been repaired or changed is inspected and then a decision is made as to
whether or not the repair or change is accepted. If it is not, then rework may be required.
Verified Deliverables
The goal of quality control is to determine the correctness of the deliverables. The results of this
process are verified deliverables, which are inputs into the Validate Scope process, where they
may be accepted or rejected.
Change Requests
Any preventive or corrective actions or a defect repair that changes an element of the Project
Management Plan requires a change request to be run through Perform Integrated Change
Control.
Organizational Process Assets Updates

Notably, completed checklists and lessons learned documentation.

Page 254 of 301
Task 2
• Analyze and communicate the solution's
identified gaps and deltas using quality
assurance tools and methods in order to enable
stakeholders to resolve discrepancies between
solution scope, requirements, and developed
solution.

Page 255 of 301
Discussion
• Does every requirement need to be fulfilled

before the product can accepted?
• When might a requirement not need to be

fulfilled?

Page 256 of 301
Requirements Levels
Requirement Level Strategy

Business requirement Must be met
Stakeholder Must be met or change order approved
requirements
Functional requirement Must be met if stakeholder requirement cannot be met
May be logged as a defect yet accepted for release to
be fixed later
Non-functional Depends on source and priority
requirement
Transition requirements Must be met or change order approved
Project requirements Must be met or change order approved
Quality requirements Must be met or change order approved

Page 257 of 301
Analysis of Defects
• How likely is a user to experience the defect?
• What is the behavior of the system if experienced?
• Can the user proceed with their work if experienced?
• Is there a workaround to avoid the defect or otherwise
complete the action?

Page 258 of 301
Prioritizing Defects
Impact of Defect
Likelihood of Low Medium High
Occurrence Low Level 4 Level 3 Level 2
Medium Level 3 Level 2 Level 1
High Level 2 Level 1 Critical
The solution must be fee of all

Critical and Level 1 Defects prior to
release

Page 259 of 301
Task 3
• Obtain stakeholder sign-off on the developed
solution using decision-making techniques in
order to proceed with deployment.

Page 260 of 301
Organization Readiness
• Determining whether stakeholders are prepared to
accept the change associated with the solution
and will be able to use if effectively.
• Allows the project team to adjust • Stakeholders may not
plans and deliverables (through
understand the need and
change control) to better support
the end users
advantages and resist to
• Increases the likelihood of the time and effort
project achieving the expected
outcomes
Source:
• BABOK® Guide v. 2, Glossary (p. 229)

Page 261 of 301
Accepted Deliverables
• Deliverables that meet the acceptance criteria
are formally signed off and approved by the
customer or sponsor.
• Requirements documentation
• Requirement traceability matrix
• Verified deliverables
• Work performance data
• List of defects
Source:
• PMBOK® Guide v. 5, Section 5.5.3 (p.135)

Page 262 of 301
Task 4
• Evaluate the deployed solution using

valuation techniques in order to determine
how well the solution meets the business
case and value proposition.

Page 263 of 301
Did the project meets its goals?
•Review the business case

•Review agreements
•Review "expected outcomes"
Deployed Solution
The extent to which a project or project deliverable met its objectives cannot be measured until
the end users have been using the solution for a sufficient amount of time. "Deployed solution“
may be on the PMI-PBA® examination.

Page 264 of 301
Lessons Learned
• An event to gain knowledge of how project events
were addressed or should be addressed in the
future. These can happen anytime, but typically
occur when the project closes.
• Provides insights for future • Can be difficult to get stakeholder
projects buy in on purpose and benefit
• Information is only available to
• Provides an opportunity for all
future projects when easily
stakeholders to contribute available
Source:

Page 265 of 301
Retrospectives
• A review at the end of each iteration to determine
what processes are working well, what can be
improved, and should be discontinued. Used
commonly in Agile projects.
• Keeps improvement discussions • May be hard to get buy-in on
close to when the processes meeting every iteration
happened
• Sometimes requires a skilled
• Involves all who were involved in the
facilitator to keep discussion
processes
focused and moving
• Can lead to immediate
improvement to the current project
Source:

Page 266 of 301
Exercise
• Evaluate Solution
Objective
Practice in evaluating if a solution met the project objectives.
Objective:
Implement a CRM system that will enable CSRs across all units of the organization to share
information and collaborate across departments in order provide seamless service to customers
by June 1, 20XX.
Scenario:
It has been 6-months since the CRM system was implemented. You have sent out a survey to the
user community asking how things are going with the system. Below are some of the comments
received.
Susan: It's nice having access to all of our customers' information with purchase and service history,
but I sure wish I could get some different reports.
Megan: Recording comments on service calls suck. 220 characters. WTH? It's like trying to
compose a tweet to get any information in there.
Allen: This system saved me so much time in research. I had a particularly difficult service call the
other day. Being able to see the service call history made it easy to get in touch with Thomas, who
helped this guy before, and together we were able to resolve his problem. He sent us a note after
the fact stating that the collaboration between Thomas and myself made it an A+ interaction and
he's recommending us to all of his friends.
• What questions would you want to see on the survey?

• Based on the information provided, did the system meet the project's objective? Yes I No

Page 267 of 301
Practice Questions
1. You want to ensure that the solution will provide business value. Which technique will be LEAST
useful?
A. Metrics and key performance indicators
B. Prototypes
C. Variance analysis
D. Risk analysis
2. What are the validation tools and techniques you can use in evaluation?
A. DITL testing, UAE, exploratory testing
B. Inspection, peer review, desk checking
C. Control charts, scatter diagram, histogram
D. Force field analysis, net promoter score, planguage.
3. How do business analysts typically participate in testing of a solution?

A. Perform testing if there is no formal testing group to do it.
B. Ensure requirements are testable.
C. Execute the test plan.
D. Track defects and problems.
4. During a team meeting, you suggest using a Pareto chart. What might be the problem you
are trying to address.
A. Team members need to know whether or not a process is in control
B. Team members need to know which type of defects are causing the most problems and
on which they should focus
C. Team members need to know whether or not a process has improved since making
changes
D. Team members have identified two key variables and want to know if there is any cause
and effect relationship between them.
5. What type of analysis is used to ensure the underlying reason for a defect has been identified?
A. Problem tracking
B. Defect tracking
C. Root cause analysis
D. Business analyst performance metrics
6. Which of the following can be said about statistical sampling?

A. It is rarely used for highly complex, heterogeneous populations.
B. It requires identification of the key sub-populations and then choosing equal numbers from
each.
C. Various techniques can be used to ensure that the sample selected is representative of
the population.
D. Any method for randomization in the selection process works equally well for any
population.

Page 268 of 301
7. Sunk cost is:
A. A recommendation on whether the developed solution is ready for implementation.
B. Cost already invested in a project or solution.
C. An evaluation of the costs of a deployed solution.
D. Cost needed to replace or phase out a solution.
8. When validating a solution and its potential defects, an identified defect is best described as:
A. Known problem with a requirement.
B. Known problem with the project.
C. Known problem with a requirements approach.
D. Known problem that exists in a solution.
9. The business analyst should conduct a post-implementation assessment to evaluate the

performance of the solution. Which of the following items is not an input to this process:
A. Technical design
B. Business requirements
C. Identified defects
D. Solution performance metrics
10. The solution was delivered a month prior when you receive a phone call from a stakeholder
who showed little interest in the project. She states that the product is of poor quality as a
number of features she was expecting were not included. You review the scope and baseline
requirements and find that her requirements were determined to be out of scope. What is her
real complaint.
A. The project delivered a lot quality product
B. Poor communication and stakeholder engagement throughout the project.
C. You have an unreasonable stakeholder.
D. The project meets quality requirements. Her issue is with the grade of the product based
on the approved scope.

Page 269 of 301
Page 270 of 301
Soft Skills

Page 271 of 301
Soft Skills

Page 272 of 301
Objectives

Soft Skills for business analysis
• Explain the tools and techniques utilized for
Soft Skills
Describe the skills and competencies needed by business analysts
Utilized team and communication models to better understand and support the team

Page 273 of 301
Soft Skills
Communication Conflict Negotiation

Collaboration
Management
Leadership Political / Systems

Facilitation Thinking
Skills Cultural
Collaboration: Business analysts collaborate with the business team to elicit requirements, get buy
in and sign off to the final product. The business analyst collaborates with the project team to
ensure the requirements can and will be met.
Communication: Business analyst must be able to communicate well in order to share the vision
of the project and elicit requirements from others.
Conflict Management: Often conflicts arise on projects regarding requirements. The business
analysts leads conflict resolution through a number of techniques to ensure the conflict gets
resolved and the solution meets the project objectives.
Negotiation Skills: The business analyst may be involved in negotiation either with the project team
regarding project processes or with stakeholders to facilitate negotiation of solution scope and
requirements.
Facilitation Tools: Facilitation is an important skill for business analysts as it is central to coordinate
group activities that enable us to elicit requirements and get the buy in and signoff needed to
support the project.
Leadership: The business analysts must be able to demonstrate leadership. The business analysts
role is a leadership due to its "change agent" nature, regardless of whether anyone reports to the
business analyst or not.
Political and Cultural Awareness: Being a business analysts has its challenges. The better equipped
we are to understand the environment both politically and culturally, the better we will be able to
respond to the organization and stakeholder needs.
Systems Thinking: Systems refer to the overall systems that involved the people, processes, and
tools make things happen. A business analyst must see past t he tools and be able to understand
and articulate the system to ensure solution requirements bring the greatest benefit to the
organization.

Page 274 of 301
Collaboration
• Working together toward a common goal
• Working in teams is customary for BAs, and effective teams contribute to project success.
• Team development models describe how teams develop and perform at various stages.
• Rules for teamwork can improve communication and trust.
• Conflicts that are resolved effectively can benefit the team.
• Cognitive vs. emotional conflicts can both arise.
• Fostering a collaborative working environment.
• Effective resolution of conflict.
• Developing trust among team members.
• Support among the team for shared high standards of achievement.
• Team members have a shared sense of ownership of the team goals.

Page 275 of 301
Stages of Team Development
Storm
Norm
Form
Adjourn
Perform
Each change to the team makeup means going
back to FORM
Form: Team members meet and learn about the project and their roles and responsibilities.
Storm: The team begins to address the project work, technical decisions, and the project
management approach. The work environment may be counterproductive as team members
learn each other styles and perspectives.
Norm: Team members begin to work together and adjust their work habits and behaviors to
support the team.
Perform: Teams function as a well-organized unit. There are interdependent and work through
issues smoothly and effectively.
Adjourn: The team completes the works on moves on from the project.
Sources:
• PMBOK® Guide v. 5, Section 9.3.2.3

Page 276 of 301
Communication
• Two-way process of reaching mutual

understanding
• Information
• News
• Ideas
• Feelings
Source:
• http://www.businessdictionary.com/definition/communication.html

Page 277 of 301
Techniques and Considerations
• Sender-receiver models
• Choice of media
• Writing style
• Meeting management techniques
• Presentation techniques
• Facilitation techniques
• Listening techniques
Source:
• PMBOK® Guide v. 5, Section 10.2 (p. 2968-299)

Page 278 of 301
Types of Communication
• Internal / External
• Formal / Informal
• Vertical / Horizontal
• Official / Unofficial
• Written / Oral
• Verbal / Non-Verbal
Source:

Page 279 of 301
Communication Skills
• Listening • Persuasion
• Questioning / probing • Motivating
• Educating • Coaching
• Fact-finding • Negotiating
• Managing • Resolving conflict
expectations • Summarizing
Source:

Page 280 of 301
Communication Technology
• Factors for technology choice
• Urgency of message
• Availability of technology
• Ease of use
• Project environment
• Sensitivity and confidentiality of the
information
Source:
• PMBOK® Guide v. 5, Section 10.1.2.2 {p. 292)

Page 281 of 301
Communication Model
Encode: Thoughts or ideas are translated (encoded) by the sender
Transmit Message: Information is sent using chosen communication channel (medium). "Noise“
may compromise the message.
Decode: The receiver translates the message into meaningful thoughts or ideas.
Acknowledge: The receiver acknowledges receipt of the message, although does not necessarily
agree.
Feedback I Response: The receiver encodes thoughts and ideas and transmits the response back
to the original sender.
"Noise"
• Distance
• Unfamiliar technology
• Inadequate infrastructure
• Cultural difference
• Lack of background information I context
Sources:
PMBOK® Guide v. 5, Section (p. 294)

Page 282 of 301
Communication Methods
• Interactive communication
• Two or more people exchanging information (meetings, phone
calls, instant messaging, video conferencing)
• Push communication
• Sent to specific recipients who need the information (letters,
memos, reports, emails, faxes, voice mails, blogs, press releases)
• Pull
• Recipients must access the communication content at their own
discretion (Intranet site, e-learning, database, knowledge
repository)
Source:
• PMBOK® Guide v. 5, Section 10.1.2.4 (p. 294-295)

Page 283 of 301
Communication Complexity
Communications Complexity
The more people who are involved on a project increases the communication complexity. The
number of communication channels increases dramatically with each new person involved. The
formula for the number of communication channels is n (n -1) I 2.
Each time a resource is added, the communications complexity increases exponentially. For
example if there are 3 people involved, there are 3 channels: 3 {3-1) I 2 = 3. Increasing a project
to four people expands the number of channels to six: 4 {4-1) I 2 = 6. The increase in complexity
means that it will take longer to collect, distribute, share and update information, which will add
time to the requirements process and may even delay the end date of a project.

Page 284 of 301
Conflict Management
• Recognizing and dealing with disputes in a

rational, balanced, and effective way.
Source:
• http:/ /www.businessdictionary.com/definition/conflict-management.html

Page 285 of 301
Conflict Management is…
• Being able to understand the root-cause of

the conflict
• Being able to draw out and understand
differing points of view
• Staying focused on what is in the best
interest of the project

Page 286 of 301
Conflict Management Techniques
• Withdraw / Avoid
• Smooth / Accommodate
• Compromise / Reconcile
• Force / Direct
• Collaborate / Problem Solve
Withdraw I Avoid: Retreat from the conflict, postpone issue to be better prepared or to be resolved
by others.
Smooth I Accommodate: Emphasize areas of agreement, concede position to the needs of others
to maintain harmony and relationships.
Compromise I Reconcile: Search for solutions that bring a degree of satisfaction to all parties.
Force I Direct: Push one's viewpoint at the expense of others.
Collaborate I Problem Solve: Incorporate many viewpoints and insights with a cooperative
attitude and open dialog to find consensus and commitment.
Sources:
• PMBOK® Guide v. 5, Section 9.4.2.3 (p. 282-283)

Page 287 of 301
Discussion
• When is each conflict management
technique is most appropriate to use
• Withdraw / Avoid
• Smooth / Accommodate
• Compromise / Reconcile
• Force / Direct
• Collaborate / Problem Solve

Page 288 of 301
Negotiation
• The process and activities to resolving

disputes through consultations between
involved parties.
Many resources combine negotiation with conflict management and/or facilitation skills. We are
calling out only the definition of negotiation separately.
Source:

Page 289 of 301
Facilitation
• Moderate and guide discussions to enable

participants to adequately voice their
opinions and be receptive to the opinions of
others

Page 290 of 301
Facilitation Includes
• Brainstorming
• Conflict resolution
• Problem solving
• Meeting management
Source:

Page 291 of 301
Leadership
• The power or ability to lead people
Source:
• http://www.merriam-webster.com/dictionary/leadership

Page 292 of 301
Leadership Success Factors
Understanding
Motivation Needs
Shared Vision Engagement
• Developing a vision of a positive future state that will engage people to want to reach it.
• Motivating others to act cooperatively to achieve a shared goal and objectives.
• Understanding individual needs and abilities of team members and channeling them to reach
the needed goal.
• Reducing resistance to necessary changes.
• Team members and stakeholders demonstrating a willingness to set aside personal objectives
when necessary.
• Articulating a clear and inspiring vision of a desired future state.

Page 293 of 301
Motivation
Self
Actualization
Esteem
Love/Belonging
Safety/Security
Physiological
Maslow’s Hierarchy of Needs

Page 294 of 301
Political / Cultural Awareness
• Understanding the organization, the

people, and what it takes to get things
done

Page 295 of 301
Discussion
• What are some examples of political or

cultural differences in your experience or
organization?

Page 296 of 301
Systems Thinking
• Understanding the overall systems that

involved the people, processes, and tools
make things happen

Page 297 of 301
Systems Thinking Is Knowing ...
• A system is greater than the sum of its parts
• Systems are broader than just IT systems
• Systems include people, their interactions,
external factors, etc.
• How changing a component affects systems as
a whole
• How systems adapt to external pressures and
changes

Page 298 of 301
Practice Questions
1. What is legitimate power?

A. The ability to force a decision among team members.
B. Power predicated on fear, due to position in the organization.
C. Another term for personal power.
D. Ability to influence others due to position in the organization.
2. Which method of conflict management brings some degree of satisfaction to all parties?
A. Compromising.
B. Smoothing.
C. Withdrawing.
D. Confronting.
3. Team members come to you with a disagreement about a technical problem. One person
wants to modify the software but not the hardware except under specific circumstances
pending the software changes; the other person wants to upgrade the hardware but not
make changes to the software except under specific circumstances pending the hardware
upgrade. You facilitate a meeting in which all the alternatives are explored for solving the
problem and a solution is developed. What technique have your used?
A. Forcing.
B. Compromising.
C. Confronting.
D. Smoothing.
4. The ability to influence others is a critical interpersonal skill required of business analysts and
includes which of the following?
A. The ability to get others to see the inconsistencies in their perspectives.
B. A relentless passion and unyielding commitment to one's perspectives.
C. The ability to understand various stakeholders' perspectives.
D. The willingness to subordinate your goals to others' goals.
5. Some of your project stakeholders disagree about which requirements to include in the
project. Your project manager asks you to negotiate. He is asking you to:
A. Consistently produce key results expected by stakeholders.
B. Confer with the stakeholders to come to terms.
C. Influence behavior to get the stakeholders to do what they would not otherwise do.
D. Just solve the problem.

Page 299 of 301
6. Veronica recently put into her status report that all requirements have been communicated
and signed off on. She has held several workshops and walkthroughs of her requirements but
she still has the claims department asking questions and wanting to change requirements
even though they had previously been signed off on. What seems to be the issue here?
A. Stakeholder analysis is suspect. Veronica does not have the right people.
B. Requirements have not been communicated appropriately.
C. Nothing. Veronica cannot control the quality of the SMEs she receives on a project and
has only limited time to elicit and sign off on requirements.
D. Veronica had too many workshops and not enough formal walkthroughs.
7. Yolanda has started on at a new company as a consultant. She bas noticed that traceability
is something that is not being done at this company. Yolanda has recommended to
management that traceability is important and that she will be pilot it on some of the projects
she is working on to show them the value of it. Since Yolanda is only doing it on some projects,
what is the best way to show people which ones she is and which ones she is not?
A. Requirements communication plan.
B. Risk plan.
C. Requirements management plan.
D. Project plan.
8. 8. Which of the following is a valid consideration for presenting requirements to stakeholders:

A. Executive sponsors and management want high-level requirements, so include executive
summaries.
B. Many business SMEs will not be available to review requirements, so there is little need to
write in the language they can understand.
C. There is virtually little difference in the time needed to prepare formal or informal
requirements reviews. The difference lies in the organizational level of the audience being
presented to.
D. A requirement may be presented informally in an e-mail message, a note, or verbally.
9. When stakeholders are in disagreement about a requirements to resolve a problem on a

project, which method of conflict management will be most effective in that it will likely lead
to consensus and commitment?
A. Compromising.
B. Collaborating.
C. Smoothing.
D. Withdrawing.

Page 300 of 301
10. Anika is getting pressure from her management about the proposed solution for her project.
The business requirements have been signed off on and the solution has been chosen. Anika
met with her director to educate him on why it is inappropriate at this time to review the
solution since she has not finished her technical requirements specification. Once she has the
document completed she will review it with the management team. What approach should
Anika preferably take?
A. Inform her manager of the pressure she is receiving so that they can address any potential
issues.
B. Inform her project manager of the pressure she is receiving so that they can address any
potential issues.
C. Create a presentation of the high-level functionality delivered by the solution and present
to management.
D. Nothing. Anika is correct in her approach.

Page 301 of 301

PMI-PBA Course Manual (Printing)

Enviado por

Dados do documento

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

PMI-PBA Course Manual (Printing)

Enviado por

Direitos autorais:

Delivered especially

PMI Professional in Business Analysis ( PMI-PBA )

All content in this book is copyrighted and VENTURE INTERNATIONAL

Delivered Especially to:

Introduction to Business Analysis ................................................................................... 15

Exam Domain 1: Needs Assessment ............................................................................ 41

Exam Domain 2: Business Analysis Planning ................................................................ 85

Exam Domain 3: Requirements Elicitation and Analysis ......................................... 155

Exam Domain 4: Traceability and Monitoring .......................................................... 223

Exam Domain 5: Evaluation ........................................................................................ 247

Soft Skills .......................................................................................................................... 271

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

• A Guide to the Project Management Body

4. Project Integration Management

© Venture International FZC PMI-PBASM Certification Preparation

*These can be inclusive of the hours of business analysis experience listed.

© Venture International FZC PMI-PBASM Certification Preparation

Application Schedule and CCR

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

Needs Assessment: Activities related to understanding a business problem or opportunity and

Analysis: Focuses on requirements management activities including elicitation, analysis,

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

Read the question carefully

© Venture International FZC PMI-PBASM Certification Preparation

*PMI Customer Care automated response to exam scoring inquiry

© Venture International FZC PMI-PBASM Certification Preparation

A. Re-study materials on Evaluation

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

• Discuss foundational knowledge related to

© Venture International FZC PMI-PBASM Certification Preparation

• Business analysis is the set of activities

• Determine problems and identify business needs,

• Identify and recommend viable solution for meeting those needs,

Source: Business Analysis for Practitioners – A Practice Guide

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

• A business analyst is, "Any person who

© Venture International FZC PMI-PBASM Certification Preparation

• Requirements are things that are wanted tor

“A condition or capability that is required to be present in a product, service, or result to satisfy a

Source: PMBOK® Guide Glossary; 5th edition

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

Currently, customer are unable to manage their accounts

© Venture International FZC PMI-PBASM Certification Preparation

• Describes the need of a stakeholder or

As a <role>, I need to retrieve a

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

• Describes the behaviors of the product

The system shall provide a tool that

The system shall provide a tool that

© Venture International FZC PMI-PBASM Certification Preparation

• Describe the quality of service

© Venture International FZC PMI-PBASM Certification Preparation

© Venture International FZC PMI-PBASM Certification Preparation

• Describes actions, processes, or other

A focus group will be used to

© Venture International FZC PMI-PBASM Certification Preparation