Presentation - CIBAP Exam Preparation

Business Analysis
CIBAP Exam Preparation

Expand capabilities, enhance value, and gain the edge through mastering the Business
Analysis tactics
and skills
Participant Introductio
s
Name
Current role
Education
Previous experience
Project management experience Analysis Training?
Business analysis experience
Agend
Morning
6
days
x8
a
09:00 am 11:20 amhoursSession
#
1 am 12:30 pm
11:20
Break
12:30 pm 02:30 pm
Session
#
2 pm 03:25 pm
02:30
Break
03:15 pm 05:00 pm
Session
#3
Looking for a volunteer to help me

executing
this agenda (time keeper)
Open
Discussion
Is this statement true?
What should we do to get

diferent
Where to start?
Who should lead this
initiative?
results?
What is the role of Business Analyst?
Discussion
How can you benefit from Business Analysis course at your work?
How can you
improve the Business Analyst role at your organization?
Business Analysis - CIBAP Exam Preparation, based on the
Open
s
e
r
t
e
Whatdoe th Sponso Expec from th Project

?
e
e
e
How Are th TeamRecogniz th Project

?
Whatwill th TeamDeliver?
e
reserved.
Challenges
Business
10
e
r
d
Whatth custome requeste
TAS1
<
11
e
s
t
d
Whatth busines analys understoo
TAS1
<
12
s
d
Whatsale describe
TAS1
<
13
e
t
m
d
Whatth projec tea delivere
TAS1
<
14
d
Whatwasdocumente
TAS1
<
15
e
r
Whatth custome paid for
TAS1
<
16
d
Whatwasimplemente
TAS1
<
17
t
d
Whatsuppor wasprovide
TAS1
<
18
A
B
B
h
e
t
o
n
e
d
s
ba
tion,
Pr
ep
ar
a
m
a
x
TAS1
<
OK
Whatth custome neede
Busines Analysis
IIBA
to
s
CIBAP
Main Concepts
Analyst
Role of the
Standardization and Adaptability

Business
Introduction
20
IIBA
non-profit professional association serving the field of business

analysis.
IIBA established October 2003 in Toronto, Canada, With 28 founding

members from 21 diferent organizations.
Certification of Competency in Business Analysis (CCBA)
Certified Business Analysis Professional (CIBAP) - 3,13

9
- 430
International Institute of Business Analysis (IIBA) is an independent
21
CIBAP - Exam
Each CIBAP applicant must meet
the following requirements to be
eligible to write the exam.
Minimum 7500 hours of BA work

experience aligned with the
Guide in the last 10 years

Minimum 900 hours in each of four
of the six knowledge areas
Minimum 21 hours of Professional
Development in the past four
years Two references from a
career manager, client or CIBAP
recipient
Signed Code of Conduct
Information
22
Exam
Blueprint
follows:
Guide is as
Knowledge Area
Percent of
Business Analysis Planning and Monitoring
Elicitation 19.33%
14%
Requirements Management
and Communication
Enterprise 16%
Analysis
Requirements15.33%
Analysis
19.33% and Validation
Solution Assessment
16%
Questions
The current
exam blueprint based on v2.0 of the
23
What is ?
generally accepted best

practices of the business
field
analysis
It describes the knowledge
area
of the business analysis,

perform
tasks
and to
activities
required the
skills
needed
of the business analysis
Guide contains the
24
PART 1
Introduction
Main concepts
PART 2: Knowledge
1. Business analysis planning and
Area
monitoring
2.
3.
Elicitation
Requirement management and
communication
4.
5
.
6.
Enterprise analysis
Requirement analysis
Solution assessment
and
validation
What is ?
25
1. Purpose
2
.
Descriptio
n
3. Elements
4. Inputs
5
.
Techniqu
e
6. Outputs
7. Stakeholder
Knowledge
Knowledge Area Tasks

Area
26
Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
Controlled
P@rlomm
1ca1
?roJ.a.ct
:er Sac: n
Work
Analysis Plarnnlng
End
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
Re q 1JJ1 u irements
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
~-li-ii-ll-l-ii-illl&iii-ll-------
Analysls
--~----iiiiiiiiil----~----iiiiiiiiiii----~---- II
iiiiiiiiiii----iiiiiiiiil----~----iiiiiiiiil---i
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
-------lliiiil--------~----iiliiiilil-------
------------------------------
and Valldatlora
I ---------------------------and Communication
Management
iiiiili--------lliiiill--J
Formally
----.--------
TAS1
<
Guide Knowledg Area - Interactio
27
Role of th BA Requirements
in Requirement
Documentatio
Planning
e
. V&S
Elicitation
Req
Plan
Enterprise
Requirements
Analysis
Analysis
An.
Mod
.
Requirements
Satisfaction assessment
documentation
and
Communication
BR
D Acc.
Cert
TAS1
<
Domain is the area undergoing

analysis.
It could be the whole organization

or part of it or certain business unit
or department.
Solution
Solution is a set of changes
that
made to the current state of the
organization which enable it to
achieve
itsof
strategic
goalsisand
The scope
the solution
working
as a basis for the project
objectives.
scope.
Main
Domain
Concepts
29
needed by a stakeholder to solve a problem or to reach certain objective.

capabilities
Requirement
s The formal definition of requirement is conditions or
30
Type of
Requirement
objectives, and needs of the
organization.
They describe and justify the high
level business functionality that is
needed in the resulting solution
Stakeholder
These requirements define the needs of

Requirements
stakeholders and how they will interact
with a solution.
Stakeholder requirements bridge
between the business requirements
and the more detailed solution
requirements
Business
Requirements
They define the high - level goals,
31
are the most detailed type of
Requirements
requirements.
They describe the solution
characteristics that will be
needed to meet the higher level business and
stakeholder requirements.
Transition
define the solution capabilities
Requirements
required to transition from the
current to the future state and
Type of
Solution
Requirements
are
no longer needed once the
32
In group of 3 to 5 members,
for a milk
The functional requirements
The non-functional requirements

Present your team result in a flip chart
pack define
:
Group Exercise
33
What Is Business
Business analysis is the set of tasks

and techniques used to work as a liaison
among stakeholders in order to understand the
structure,
policies, and operations of an organization, and
A Guide to the Business Analysis Body of Knowledge , (
Guide), Version 2.0, International Institute of Business Analysis, 2009, 223.
recommend solutions that enable the organization to

achieve its goals.1
Analysis?
34
The Busines Analys Role

t
Policie
Operation
Recommended
solutions to enable
Tasks
and
technique
s
Structur
the
organization to
achieve its goals
35
Vision and Scop

Vision and
Scopestate and
Current
desired state from
the
In-scope and out-ofbusiness
perspective
scope
solution
features
36
Busines Rules
Rules
Structural
Rules
You
Use
will
this
not
calculatio
Yo
n to
This
will
cann
be filed
ot
You
The
under
are
forbidde
security
setting
allowed
s
Normal hours
will
of
be
operation
to
are
n to
You
are
not
sOperative
37
Assumption and Constraint

s
Requirements
Assumptions
True but unable to
confirm
True but could change
during project
Constraints
Limits the solution
Policies, schedule, budget,
technology
38
solution components.
Basically, they constrain how the solution requirements

are to be
the solution itself
by
met
Nonfunctional requirements state

qualitie of behavio or quality
attribute that the stakeholders want
the
s
r
s
Non-Functional
Define the overall qualities or attributes of the resulting
solution or
Requirement
39
Requiremen
Reliability
Functional
Reliability focuses ont the solution s

availability when the stakeholders
need it.
Operability
Measures the extent to which your
stakeholders can recognize whether or
not a solution meets their needs. It
also evaluates the ease of learning
to
and how usable the solution actually
use the new solution, its capabilities,
is.
Security
This category looks at the solution s
ability to store information and protect
it from unauthorized use.
Maintainability
Focuses on how easy it will be to

change one solution component
Transferability
without affecting other components.
Determine whether the solution can be

migrated to, installed in, and
uninstalled from diferent
Efficiency
environments when needed.
Looks at the time it takes to perform

activities and the resource utilization
Usability
levels for the solution.
Availability
Compatibility
Non-
40
individual, group or
affect,
be affected
organization
whoby
perceive itself to be
or
may
affected by a decision,
activity, or outcome of a
project.
ISO 21500-2012 Guidance on project management,
Stakeholder
A stakeholder is an
s
Page 10
41
Project
Processes
across
lifecycle
Provided by
any group
or
individual
training
Available through many sources
Other units within the organization
Consultant
Customer, users and sponsors
Professional and technical
associations
Industry groups
Subject Matter Experts
with specialized knowledge or
Expert
Applied to any technical and management details during the
Judgment
42
Organizational Process
(OPA)
of
the organizations involved in

the project that can be used to
the project s success.
influence
Quality Management System (QMS)
Organizational standard (processes,
policies and procedures)

Standardized guidelines (proposal
evaluation criteria, closure , etc.)
Templates, communication
requirements, HR policies, Proc
policies, etc
Control procedures for (finance,
risk, staffing, change, etc.)
Corporate Knowledge Base
Process management databases
Project files (ex: scope, cost

,schedule, quality, performance
measurements baselines, etc.)
Lessons learned (ex: project

records and closure
documentation, etc.)
Financial databases (labor hours,
costs, budgets, etc.)
All related assets from any or all

Assets
43
Improve communication
Provide a repeatable methodology
Increase
efficiency
Facilitate
interaction
Enable adaptability
Allow compatibility
Standardization of
andVocabular
The goal of standardization is to:
Processes
y
44
BAs must be expert communicators
Business Analysis could include:

- System analysts
- Process analysts
- Product
- managers
- Enterprise
analysts
Business
architects
Management
The Business Analyst

BAs are the bridge between the business and IT stakeholders
Role
45
BA vs PM vs. SA
How much will
this phone
system cost?
handle
the higher volume of calls

when we roll it out
What date do we
to the new
need
branch?
Will we need to acquire

new
servers to handle the

expected call volume?
to roll
it out by?
Business
Project
manager
analyst
System
analyst
Will this system be able to
46
In group of 3 to 5 members, for a Car

Licensing Authority
Write down 2 business requirements
Write down up to 5 functional requirements
Write down up to 5 non-functional
requirements
Write down
2 transition requirements
Ofice
Group Exercise
47
1. Plan Business Analysis Approach
Monitoring
2
.
3
.
4
.
Conducting Stakeholder
Planning
Analysis Business Analysis Activities
Plannin Business Analysis Communication
g
the Requirements Management
Managing
Business Analysis Performance
Plannin Process
g
Business Analysis Planning and
48
Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
?roJ.a.ct
Work
Plarnnlng
End
P@rlomm
1ca1
:er Sac: n
Analysis
Controlled
I
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
Analysls
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
------------------------------
and Valldatlora
Management
Formally
----.--------
TAS1
<
49
defining, planning, and completing the business analysis work for a

project
The business analyst determine the:

required processes,
templates and
activities needed to perform the business analysis
This knowledge area govern and control

all
tasks
activitie performed on the

s
This knowledge area focuses on laying the groundwork for successfully

Monitoring
other knowledge areas

50
2
.
3
.
4
.
5
.
6
.
Conducting Stakeholder
Planning Business Analysis Activities
Analysis
Plannin Business Analysis Communication
g
the Requirements Management
Managing
Business Analysis Performance
Plannin Process
g
Elicitati
Analys
on
is
pla
pla
Documentati
Communication
on
plan
and
and risk
validation
management
1.
Plan Business Analysis Approach
Monitoring
51
1. Business Need
Analysis
2. Expert Judgment
3. Organizational Process
Assets
Approac
Proce
ss
Select the business
approach,
h the stakeholder who
define
will be involved in the
decision and illustrate how
and when the business
analysis activities will be
performed through out the
project, the tool and
techniques that will be used
Tools
and
Techniques
and
define
the
required
deliverables.
1. Decision Analysis
2. Process Modeling
3. Structured
Walkthrough
Outpu
t
1. Business analysis
approach
Plan Business
Inpu
52
BA adap their
for
Project
Project
importance
size
activities
Development
Project
approach
standards
Larg
Smal
Waterfa
Phase
Iterativ
Ne
Change
Clien
ll
Timing of business analysis

Formality and level of details
Change management
its
Communication with stakeholder formality

Requirement analysis and management
and
SCRU
Agil
Element
53
focus on ensuring that the solution is fully defined before its implementation
begins.
Change - driven approaches

are used on projects where many small iterations are defined and developed en
route to the final result
Element
driven approaches
s Plan
54
The
SDLC
Analysi
s
Desig
n
Developmen
t
Testin
g
Implementatio
n
Waterfall
Initiation
55
Typical Phased
Release
Initiation
Waterfall
Initiation
Initiation
3
Release 2
Analysi
Analysi
Analysi
Design
Design
Design
Developmen
Developmen
Developmen
Testin
Testin
Testin
Implementatio
Implementatio
Implementatio
Release 1
56
Typical Iterativ Life Cycle
an
Implementati
It
analysi
on
and
de
E
prioritizati
Detailed
Acceptance requirements
on
testing
Iteration
detail
developer
testing
testin
analysis
s
I eration
t 1
Deploymen
t
I eration
t 2
I eration
t 3
I eration
t 4
Project
completion
Implementation
Design an
d
Design
start
Project
valuation and
57
Proces Modeling
58
is used to validate the business analysis approach for a project with key
stakeholders and team members.
Desk
checking
Walkthrou
gh
Peer
review
Verification and Validation
Structured walkthrough
Techniques
59
1. Business Need
Stakeholder
2. Enterprise Architecture
Assets (OPAs)
Survey/Questionnaire
Analysis
Proce
ss
identify all stakeholder
who
may affect the execution
and/or affected by the result
of the project. It is ongoing
process, should start once
the business need is defined
and documented.
The role, attitude,
responsibility and authority of
be defined
and
each
stakeholder
should
Tools
and
Techniques
documented.
1.
Stakeholder Map
2.
3.
4.
5.
6.
7.
8.
9.
10
.
11
.
12
14.
.
Stakeholder Matrix
Organization
Modeling
RACI Matrix
Scope Modeling
Scenarios and Use
Cases
User Stories
Risk Analysis
Process
Modeling
Brainstorming
13.
Interviews
Acceptance & Evaluation Criteria Definition
Requirements
Outpu
t
1.
Stakeholder List, Roles
and
Responsibilities
Conducting
Inpu
60
list all the stakeholder and the expected impact of the proposed change on each
one of them
Complexity of the stakeholder groups

Stakeholder attitude
Business goal, objectives and solution
Business analysis work
Sponsor
Project team
Collaboration
Element
s Identification
61
individual, group or
affect,
be affected
organization
whoby
perceive itself to be
or
may
affected by a decision,
activity, or outcome of a
project.
ISO 21500-2012 Guidance on project management,
Stakeholder
A stakeholder is an
s
Page 10
62
Internal Stakeholders
Sales and
Marketing
Product
Engineering
Customer
Team
and contributors
Executive
Users
Sponsors
xternal
Customer
Government
Support staff
Internal/Process
External S
Stakeholders
Regulatory
Champion
Project Leader
Process Owner
Subject Expert
Business Analyst
SW Architect
Tester
Quality Manager
Suppliers
Competitors
TAS1
<
Categorie of Stakeholder
63
stakeholders and the solution
Stakeholder
Represent the relationship between the stakeholders and between the

Map
64
Stakeholde Matrix
65
Project
role
Job Title
Level of
Support
Area
GB Project team
member
Test Mgr
QC
Green Belt
Demand
Analyst
Project Team
member
Link to the Problem

area
Alex Bates (AB)
High
Testing Manager
FIN
Peter Goja (PG)
High
Process Owner
Finance
Business
partner
FIN
TBA
Master Black
Belt
Consultant
3 Party
Rob Owen (RO)
High
Mentor to the project team

greenbelts
Black Belt
QA
QA
Simon Cull (SC)
High
Co-ordinator for the 6 sigma

programme
Consultant
ProjectSponsor
CTO
IT
Jack Duly (JO)
High
Executive sponsor for the 6

sigma programme
Project
Champion
HO Testing
Services
IT
Nathan Crowe
(NC)
High
HO Testing Services
.
.
Responslble.ror IT Dev portfolio

forBcomm
; Programme
' Mgr -~ -
Release ~
Manager:.
CustomerCustomer
User
Customer
.~en Chower (BC)
RLt
Delivery Mgr
'
.
R!"1 ;
.
'AccountM ,. t
MIS
MIS
'
1Medlu'!1
'Medium ...
J
!-4oahGoo~frey
(NG)
-.
Suzie Naples(SN)
Paula Wltley
Solution
tan Howe (IHt)
Comments
Inform
.Meet
'I
..I .
r . --
I n v i te to
-:rWS
Low
Medium
High
SME & Business user I Customer

Ila Ison
System. u"ser
TBC
:
Interview
-.....
Change
manager
Actions
required
TAS1
<
A Stakeholder Registe
Name/contact
Accountable for delivery of

Business SI change
66
Stakeholde Profile
s
Speci
Role
and
Nam
Solutio
n
al
influence
nee
ds
and
responsibi
authorit
lities
Solutio
title
Socioecono
Numbe
mic
informati
on
Stakeholde
informatio
n
intere
st
attitud
and
ic
Demograph
Solutio
r
profile
Locatio
n
67
Organizatio Modeling
QUAD-H
Directors
Ima
Keypen
Veep
Book
VP Patient
Florence
Nightingale
John House
Dir
Services
Physician
Care
Raymon
d
Xavier
Dir Nursing
Dir
Ops
Radiology
Nursin
g
Physicians
Medical
Technician
Supervisor
Supervisor
Nurses
VP Admin
Clair
Pharma
E Murge
Ansi Dir
Dir Hospital
Pharmacy
Emergency
Medicine
Pharmacists
Medica
l
Technician
s
John Hipa Services

Manager
Patient
Record Mgmt
Administrati
ve
Clerks
IT
Sysrunnin
Mgr
Technology
Information
System
designers/
Programmer
s
Board of
Ask the customer for his

organization chart
68
RACI Chart
Activity
Define
Perso
n
AhCmareld
HossBaemn
AmArnn
os
A
I
R
IbraDhinim
EmEad d
1
a I
Des.ign
Develop
Iest
CR I
A o
Res~onsibie Accountable Cons.1.d - I m
TAS1
<
RACI Matrix
69
team the set of stakeholders

external to the solution scope
solution
who interact with the
used to
The main diagram
model the scope is
diagram
context
Scope
Show the business analysis
Modeling
70
describe how each ac

tor
(stakeholder) interact
the solution.
with
s
Use Case
This technique is used to

Diagram
71
functionalities of the solution

that are needed by the
stakeholders.
It describe in very few sentence

who sue the story,
the goal we need to

accomplish
and other information that is useful
to complete the task
the acceptance and

evaluation criteria
User
Short description of the
Story
72
Risk
Analysis
The degree , amount , or volume of
risk
that an organization
or individual
will withstand
or can accepted.
Communicate Risk to
stakeholders:
Communication management plan
Stakeholder register
Stakeholder management strategy
Risk management plan
Stakeholder tolerance: determine

up to what level a certain
can accept a risk.
stakeholder
Risk Averter
Not likely to take a risk that is
considered a high risk
Risk Seeker
Prefers an uncertain outcome and may

be willing to pay a penalty to take a
high risk.
Risk Neutral
Tolerance to risk is proportional to the

amount of money at stake
What is Risk tolerance?
73
In group of 3 to 5 members, for a Car Licensing

Authority Ofice
Prepare a stakeholder register
project stakeholders using

Identify, analyze, prioritize and
classify the
Develop Stakeholders Engagement Plan
Stakeholder Analysis Matrix
Group Exercise
74
1. Business Analysis Approach

Analysis
2. Business Analysis
Performance Assessment
3. Stakeholder List, Roles,
and
Responsibilities
4. (OPAs)
Activitie
Proce
ss
Business analysis
activities
s
must be planned. The
business analysis plans are
the road map for what
needs to be done, when it
needs to be done, who is
responsible for actually
doing it, what are the
expected deliverables and
develop estimates
Tools and Techniques
for the
business analysis
1. Risk Analysis
2. Function work.
decomposition
3. Estimation
Outpu
t
1. Business analysis Plan(s)

Plan Business
Inpu
75
Determine the needed business analysis work.

Create BA WBS
Element
Geographic distribution of the stakeholders
s
Type of project
76
Techniqu
en
Analogou
s
Parametri
c
Battom-u
p
Rolnng
estimatlo
n
estlrnatlo
n
estl
Use
s
Use
s
similar
as the basis top-dawn

for
projects
estimates
parameter an historic data
s
d al
matlon
wave
use hlstor as
s
v
basis
Expert
judrgment
Delphi estl
rnatlon
to bottom-up and top-down

r estlrnates
ComlJilnes expert
and
Judgm1ent
history
TAS1
<
Estimatio
77
Business Analysis
Define the scope of work
Plan
Generate a task list and task attributes
Develop the WBS
Develop acceptance criteria for tasks and
deliverables
Construct task dependencies and critical paths
Assess resource requirements
Integrate
project plan and schedule
Calculatewith
thethe
budget
78
Stakeholder
Customers
s
Domain SME
End users
Suppliers
Implementati SME
on
Project
Manager
Testers
Sponsors
79
AnalysisCommunicatio
Proce
Business
Approach
2. Business Analysis plans
and
4. Responsibilities
(OPAs)
ss who, how,
Used to decide,
n and what
and when
business analysis
information needs to be
communicated, who needs
to receive that information,
how the information will be
delivered, and when the
information will be
Toolsrequired.
and Techniques
1. Structured Walkthrough
Outpu
t
Communication
Plan
Planning
Inpu
80
Element
Geography
s
Culture
Project
Frequency
type
Communicati Formality
on
Communicatio
n
81
Information storage and retrieval
Business Analysis
Plan
Plan overview and project objectives
Communication
Key project stakeholders
Business analysis team
information
Business analysis reports
Meeting schedule
Business
communication
tools
Businessanalysis
analysis
team meeting
82
Stakeholde
Customers
r
Domain SME
End users
Suppliers
Implementati SME
on
Project
Manager
Testers
Sponsors
Operational Support
Regulator
83
Requirements
Approach
3. plans
(OPAs)
Managemen
Proces
Proce
define thess
process for
t
developing project
requirements, how they
will approach
requirements traceability,
requirements prioritization,
requirement approval and
changing requirements.
2. Problem
3. Tracking
Risk Analysis
s1.
Outpu
t
Requirement management
Plan
Planning
the
Inpu
84
White board
Word document
Software application
wikis
Requirement attribute
Author: consultant for clarification
Ownership: group or
individual that need the
requirement
Source of requirement:
consultant
for change or extra detailed
needed
Reference
Requirement prioritization
process
Change management
Traceability
management process
Urgency the requirement

Tailoring
Stability
Status
Element
s Repository
85
approach
projects
and process for developing and managing requirements.

It contains the following contents:
Traceability approach for the requirements
Selection of requirements attributes
Definition of the requirements prioritization process
Management of changing requirements, including how to request, analyze,

approve, and implement those changes
Requirement management
The requirements management plan describes the
Plan
86
Managing
requirements
activities includes at
least:
Planning activities such as:
Collecting
Planning activities
Specifies how
Plan
requirements
throughoutwill
the project.
activities
be
conducted
Collection
Analysis
Categories
Prioritizati
on
Document
ation
Managing
activities
Traceability
Structure
Tracking
Analyzing
Categorizing
Reportin
g
Prioritizing
Documenting
Validatio
n
Determining metrics
Defining the traceability
Configur
87
Requirements
When documenting requirements, it useful to group them by category.

Some common categories include:
Business requirements
Stakeholder requirements
Solution requirements (Functional and Nonfunctional)
Project requirements (Acceptance criteria, Impacts to other organization areas, Support and training requirements)
Quality requirements
It is
beneficial to document:
Transition requirements
dependencies
between requirements and
assumptions and constraints pertaining to requirements.
Requirements Documentation provides information to:
Scope Baseline
Quality Management Plan
Documentation
Procurement Management Plan

88
Requirements
Requirement
Validation Method
Documentation
Stakeholder
Category
Priority
Acceptance Criteria
ID
89
Requirement Attribute
Requirem
ent
Requirement 001
Feature in Scope Doc
Priori
ty
Sour
ce
Requirement 002
Query
07
Scheduling 14
Hig
h
Lo
w
Requirement 003
Relationship 02
Lo
w
Business strategy
document
Mediu
m
Business strategy
document
Requirement 004
Requirement 005
Requirement 006
Requirement 007
Requirement 008
Platform 12
Security Level 16
Name
01
Tag
16
Metadata 19
Hig
h
Hig
h
Mediu
m
Hig
h
Customer request
Customer request
Federal regulation
State
law
Customer request
Stakeholder
request
Requirements
Attributes
90
Stakeholde
Domain SME
r
End users
Tester
Implementati SME
on
Project
Manager
Operational Support
Sponsors
91
AnalysisPerformanc
Proce
Business
performance metrics
2. Business analysis plans
3. Requirement
management
4. plan
Organizational
performance standard
ss measuring
Monitoring and
e
business
analysis
performance against the
business analysis plans
ensures that the projects
business analysis effort
produces the desired
outcomes and that the
business analysis work is
Tools andefficiently.
Techniques
performed
1. Metrics and KPIs
2.
3.
4.
5.
6.
7.
Variance Analysis
Root
Cause Analysis
Problem Tracking
Process Modeling
Survey /
Questionnaire
8. Lessons Learned
Outpu
t
performance
2. assessment Business
analysis process
assets
ManageInpu
92
Actual vs. planed date
Number of changes per week/month/quarter

Performance reporting
Preventive and corrective actions
Element
measures
s Performance
93
problem.
Fishbone diagram
5 WHYs
Root Cause
The objective of this
technique is to determine the underlying source of
Analysis
94
Stakeholder
Domain SME
s
End users
Tester
Implementati SME
on
Project
Manager
Operational Support
Sponsors
95

Licensing Authority
Develop a requirement analysis plan, to describe:
Requirement Elicitation
Requirement Analysis Requirement

Documentation Requirement
Verification and Validation
Requirement Management &
Communication
Present
your team result in a flip chart
Ofice
Group Exercise
96
Elicitation Techniques
Elicitation
Selecting the Right Requirements
Technique
Tasks
Prepare for elicitation
Conduct elicitation activity
Elicitati
on
Requirements
Document elicitation results

Confirm elicitation results
97
Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
Controlled
P@rlomm
1ca1
?roJ.a.ct
:er Sac: n
Work
Analysis Plarnnlng
End
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
Analysls
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
------------------------------
and Valldatlora
Management
Formally
----.--------
TAS1
<
98
identify and gather requirements and understand their needs and
concerns
The Elicitation knowledge area focuses on:

Gathering the right information to develop project requirements
Elicitation techniques must be selected to gather as much relevant

quickly as information
Requirements elicitation is performed

for all types of requirements
possible
found
in the Guide:
Business,
Stakeholder,
Solution, and
Transition
as
Elicitatio
Elicitation defines how business analysts work with stakeholders to
n
99
'
Inp
uts
'!--1-11-11-11,_
,I
s
~~------
t~
,
,-----~-~:
Busine Busine
~ Organiz
-~-&--~.
,
,
3.,.
11
I
I
11
ss
Case
ss
Need
l~
r:,4,,
R~,qu~
rem ents
1
1
Manag1e
So~
utio
n
Sc
op
ational
Proms
Assets
ii
I .i .
. ..
1.
, ,
Stak e ,
1
holdler
.
i
List I
Roles,
and
I
Pre
pa
re
For
1
-3.,
l~licit
,3.
aUon
Docu
.i -, ment
Elicitati
~
q
,
..........--~
on !
Results
Tas
3.
,2
ks Cond
uct
,
,
I
~licitat
ion3
1
{
I
Acti
4
Confirm
v~t
Elicitation
y
Res
ults
~--~
It_,
Oiut
pu1t
s
I I
I----~-~---
I
I
ll_
. j""
. "~i
.
II
Elicit
ation
Sche
duled ,
Res
ults
Reso ,
urces
,I
'
I
I
!
I
I
,
1
I
I
I,
I Stake Supp i
,
\ holde orting
Mate ;
,1-11-Concer
Mals
r
ns--"
IJ-
i
Tasks
TAS1
<
and Output
Elicitation Inputs,
11-
100
1. Business Need n
for
2. Solution scope
3. Business case
and
Responsibilities
Proce
ss analyst
The business
prepare a detailed schedule
of the elicitation activities.
Ensure that all the
required
resources to conduct
theTechniques
Tools and
elicitation activities are
defined and available.
1. Interviews
2. Focus Groups
3. Requirements
Workshops
4. Brainstorming
5. Observation
6. Survey /
Questionnaire
7. Prototyping
Outpu
t
1. Scheduled Resources
2. Supporting
Documentation
PrepareInpuElicitatio
101
Element
Clarify the scope of each elicitation technique
s
Develop a schedule for all the needed
Communicate the schedule with the appropriate parties

resources
102
Interview when
you
Need
general
information
about
Want the
stakeholder
s to
explain
requirem
their
ents
needs
Need more
Have
conflicting
requirement
s
ininformation
on
depth
requiremen
t
Want the
a
stakehold
ers
unique
perspectiv
e
Intervie
103
Use a focus
group
when
you
Want to gauge attitudes and

preferences
Want
seegroup of people to elicit
A focus
group is a carefully planned interactive session
with ato
selected
ideaspeoples
attitudes} impressions}
preferences, and needs about a specific solution. Participants are free
responses
to talk to each other but interaction is guided by a moderator. Observers must record or monitor
tbe focus group.
TASl
<
Focu Group
104
Requirements Meeting
JAD Sessions
Brainstorming
Requirements
Three of the more common requirements workshops:

Workshop
105
Workshop: Requirements
Meeting
Use a
requirements
Need requirement
on
noncontrovers issue
consensus
ial
s
Wan to
workshop
when
t
generate
ideas
you
Want to
revie
w
the
requirements
Requirement
106
Requirements Workshop: JAD
Us a JAD when
e
Need
stakeholder
buyin
you
Have
Need to
multiple
differe
view
make
stakeholders
nt
s
controversi
with
al
decisio
ns
Sessions
107
Requirements Workshop:
ng
when
you
Wan creativ
innovati solutio
t
e,
ve
ns
Need
solutio option
many
n
s
Brainstorming
Use brainstormi session
108
Us observation
you
when
Need to learn
a user environme
about
s
nt
Need to
Need
understand
information
or
wont
workflo
that
the users
provide
cant
fully
Observatio
109
Surve
y
you
Have only a
short
tim
e
to
gather
a lot
of
informatio
n
Have a
majority
of remote
users
to
contact
Need to
provide a
way for users
to
respon
d
anonymous
ly
Have
statistical
and
survey
writing
abilities
Administer surveys when
110
Prototype the
product
when
Need
to
identify
missing
requiremen
ts
Gain advantage
Need to
with
identify
you
usability
issues
clear
representation
early
for
feedback
Prototyping
purpose
s
111
OtherElicitatio Technique
s
Document
Business rules
analysis
analysis
Black box
reverse
engineeri
ng
Product
trials
112
Document
Analyze documentation when

you
Need information on the
Cannot contact the SMEs
current
for the
solutio
existing
solution
Analysis
113
Analysis
Analyze
rule when
business
Need
to
underst
and
busines
s
directiv
es
Need
to
validate
against
business
policy
you
Need clarif
contradicto
to
y
ry
rule
s
Need to
clarify
whether a
rule
is not
relevant
Business Rules
114
Use reverse
engineering
when
Lack
documentation
about
the
existing
product
Want to
you
understand a
competitors
product
Need to
understand
why the
product
works the
way
it
does
Reverse Engineering
115
Perform product
trials
when
Thin a COT produc migh beth solutio
k
you
t
Product Trials
116
Analysis
Analyze
whe you
activities
Need to
know
how long
it
takes
to
perfor
m
Want
to
eliminat
e
wasted
time
Need
to
identif
y
unneces
sary
activiti
es
Need
to
prioriti
ze
activiti
es
Activity
a
task
117
identify the way they interact.
There are three types of

User interface
interfaces:
Interfaces to/from external application
Interfaces to/from external
hardware devices
Interface
Used to identify the interfaced between
the solution components and to
Analysis
118
Stakeholders
Requirement type
Geography of the solution
Selecting the Right

Elicitatio Techniqu
Always consider these three factors: n

Requirements
e
119
1. Business Need
Elicitation
2. Solution scope
3. Business case
and
5. Responsibilities
6. OPA
Requirement
7. management
8. plan
Scheduled resources
Supporting material
Activity
Proce
ss
the business analysis team

meet with the stakeholders
to elicit the needed
information and
requirements.
1. Interviews
2. Focus Groups
3. Requirements
Workshops
4. Brainstorming
5. Observation
6. Survey /
Questionnaire
7. Prototyping
8. Interface
Analysis
10.Data Dictionary
9. Document Analysis
Outpu
t
1. Elicitation result
ConductInpu
120
This is to trace the requirement back to the goal and objectives of the performing
organization, to protect the project from scope creep
Capturing requirement attribute

Metrics
Measure the performance of the meetings and the performance of the participants
Element
Requirement
s Tracing
121
Data Dictionary and

Glossary
Glossary
Data dictionary
includes the standard definition of each data element, its meaning and values
There are two types of data element

Primitive Data Element
Name
Aliases
Value /
meaning
Composite Data Element
Description
Name
Aliases
Value /
meaning
include the terms relevant to each domain and its unique definition
122
Stakeholder
Customers
s
Domain SME
End users
Suppliers
Implementati SME
on
Project
Manager
Testers
Sponsors
123
1. Business Need
Elicitation
2. Solution scope
3. Business case
and
5. Responsibilities
6. OPA
Requirement
7. management
8. plan
Scheduled resources
Supporting material
Result Proce
ss
The objective of this task

is to document the result
generated during the
conduct elicitation task.

1. Interviews
2. Focus Groups
3. Requirements
Workshops
4. Brainstorming
5. Observation
6. Survey /
Questionnaire
7. Prototyping
8. Interface
Analysis
10.Data Dictionary
Outpu
t
1. Elicitation result
Document
Inpu
124
Written document
Visual or audio recording
Whiteboard
Formal
Large, high profile, high-stakes projects
Documentation
Projects with high degree of
uncertainty
Important, expensive projects
Signoff of documentation is extremely
important
Informal
Small projects
Documentation
Products being developed using an iterative

life cycle Requirements written on flip charts
or whiteboards Signoff or approval, even
verbal, still extremely important
Element
the elicitation results using the following tools:

s Documents
125
t
Requiremen Statu
s
126
Stakeholder
s Business Analyst
127
1. Requirement [stated]
Elicitation
2. Stakeholder
concerns
Result
s
Proce
validate ss
the stated
requirement generated by
the stakeholders and
confirm that the business
analysis clearly understand
the stakeholder issues and
may affect the requirement
and and
the project.
Tools
Techniques
1. Interviews
2.
Observation
Outpu
t
1. Requirement [confirmed]
2. Stakeholder concerns
[confirmed]
ConfirmInpu
128
Tasks
Analysis
Prioritize Requirements
Organize Requirements
Specify and Model requirements
Define Assumptions and constraints
Verify Requirements
Requirement
129
Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
Controlled
P@rlomm
1ca1
?roJ.a.ct
:er Sac: n
Work
Analysis Plarnnlng
End
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
Analysls
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
------------------------------
and Valldatlora
Management
Formally
----.--------
TAS1
<
130
Analyzing what the stakeholders have told the business analyst and
Defining which capabilities need to be part of the resulting solution
The knowledge area is where we develop the stakeholder and solution

for the project.
requirements
Stakeholder requirements describe the capabilities of the solution that will meet
stakeholder needs.
the
Solution requirements are more detailed requirements, describing the behavior of
the solution components so that those components can actually be created
later
the project life cycle.
in
Requirement
Requirements Analysis focuses on:

Analysis
131
',.,,_.---r--
t
s
--~
---.. - .. ._-
Ths~
6,
Busines Bus! N
s Case ines ee
I
s
d
j
TAS1
<
Pi 11or
rtize
i
i i
Requ
Rueq,.. ui'r 1
,,emen t'5,
'
rement
6
s
1
3
I
I
Oirganiz Require Stake

I ationa I
ments holder
Process
iI Assets
Man~g Conc
ement erns,
l.
2
Pi
la
n
Orga
nize
Require
ments,
i A1s-m-u,
Requ'i
ptionsRequ'irem
and
St~uc mment
ents
s
Ccmstraii
ture
~--~I
~
~,
and
I
, . ~' ! nts
I'"' Specify ,
- --.
Con1traint
and
1..
I
s 4....,.....
i,,---I
i
Mode:!
I
16
I Requir
.......................
Valli
I
,S
===--I Require
i ements
i
I
d~te
.
~i
[Valid
I
r=..................... _d'I
....
5.
4
Stakeholder
Solution Srnpe
List Roles) and
!ImResponsilblliti
es
-----
"l ments
VerifyRequir
I'
1
~iiiiiiiiiiiiiiiiiiiiiiiiiiiiiid
ements
I
I
Requi1r
I
IDefineAs,
ements,
~umptions
~iiiiiiiiiiiiiiiiiiiiiiiiiiiiii
),
,
.,~
,.
[Priori
6J
tized]
:
Requir Stakeho
ements lderor '
Solu
[Verif
I
=. =,. _
Requ1rei
ate<!] --==-tion
ied]
,I
ments
=--=-=J
.IRequirement
~----- --llnp
-
urts
Analysis
132
1. Business Case
Elicitation
2. Business Need
3. Requirements (Any)
4. Requirements
Management
Plan
5. Stakeholder List, Roles
and
Responsibilities
Proce
ss
determine the relative
importance of the
requirements, based on
(Value, Risk, Easy
(difficulty) of
implementation)

1. MoSCoW Analysis
2. Timeboxing /
Budgeting
3. Voting
5. Risk Analysis
1.
Outpu
t
Requirements (Prioritized)
PrepareInpu
for
133
Challenge
Non- negotiable demand (all
the requirements are high)

Unrealistic tradeoffs
(overestimating effort
and complexity)
Element
s Basis of prioritization
134
MoSCoW Analysis
Must
These requirements are must
haves.
They must be part of the final

solution
Should
These requirements are also
high priority requirements. However,

there might be workarounds or
they
may not be as time critical.
Could
These desirable requirements
Timeboxing /
All in
Budgeting
All out
the
high priority
Selective:
add and remove bases
on
135
Requirement
Assets (OPAS)
2. Requirements
(Stated)
3. Solution
Proce
ss organize
structure and
individual requirements,
group those requirements,
and show the relationships
between them to ensure
that the requirement is
complete, comprehensive,
consistent, and
your
understandable
to
Tools
and Techniques
stakeholders.
1. Organization Modeling
2. Process Modeling
3. Scenarios and Use
Cases
4. Scope Modeling
5. Data Flow Diagrams
6. Data Modeling
7. Functional
Decomposition
Outpu
t
1. Requirements Structure
Organize
Inpu
136
A representation and simplification of reality developed to convey information to

a specific audience to
support analysis,
communication and understanding.1
A Guide to the Business Analysis Body of Knowledge, (
Defining a
Model
Model
Guide), Version 2.0, International Institute of Business Analysis, 2009, 228.
137
Models bring value to requirements analysis, By using models,
Modeling
1
More easily answer the questions:

1
the
BA
ca1111:
TAS1
<
Vlho?'
What?
When~,
"\Vhere
?
Why?'
Hov/l exactly a current state versus the future state

Demonstrate
Organize analysis information from high level to detail level
Continue to drive the discovery of critical requirements that would otherwise be missed
Verify and validate requirements
Value of
138
Organizatio Model
n
Board of
Directors
Ima
Keypen
Veep
Book
VP Patient
Florence
Nightingale
John House
Dir
Services
Physician
Care
Raymon
d
Xavier
Dir Nursing
Dir
Ops
Radiology
Nursin
g
Physicians
Medical
Technician
Supervisor
Supervisor
Nurses
Medica
l
Technician
s
VP Admin
Clair
Pharma
E Murge
Ansi Dir
Dir Hospital
Pharmacy
Emergency
Medicine
Pharmacists
John Hipa Services

Manager
Patient
Record Mgmt
Administrati
ve
Clerks
IT
Sysrunnin
Mgr
Technology
Information
System
designers/
Programmer
s
QUAD-H
139
Locatio Model
n
Wes
t
East
Campus
Primary
Care
Buildin
g
Clinical
Center
Off
Campus
Campu
s
Clinic
s
Veterans
Facility
Pharmacy
Pharmacy
Emergen
cy
Roo
m
Laboratory
Doctors
Offices
Doctors
Offices
Doctors
Homes
Private
Laboratorie
s
QUAD-H
140
Proces Model: Workflow

Task 1
Task 2
Decisio
n
Stop
Task 3
141
Determine
Amount
Owing
Bill
Authorize
Account info
Provide Patient
Account info
<uninsured>
Request
Payment
Patient
Company
Receive
Bill
Receive
Electronic Bill
Clerk
PRADA
Request
Patient
<insured>
Insurance
Billing
Proces Model: Swimming LaneDiagra
142
Busines Use Cas Diagra

e
Maintain and
View
Patient Medical
Data
Doctor
Patient
Maintain and
View
Administration
Laborator
Data
Bill
Patients
143
Syste Use Cas Diagra

Regular Patient
Request
Assessment
or Test
Doctor
Administrato
r
Authorize/
Refuse
Treatment
Add
Patient
Diagnosi
Nurse
Record
Assessment
or Test
Result
Billing
Manage
r
Mail Room
View
Patient
Demographic
Billing
Clerk
Change
Patient
Demographic
Insurer
144
Enter Bill
1. Clerk requests Billing page.
2 Billing page opens.

. Clerk enters patient identification.
3 System populates Bill and provides
identification for Bill.
. unique
4 Authorized Payer field activates.
. System offers Save, Correct, or Delete options.
Clerk enters authorized payer.
5
chooses Save.
. Clerk
System confirms Bill has been sent to authorized payer.
6
10.The use case
.
ends.
7
.
8
.
Use Case
Main Scenario for Bill Patient/Insurer:

Scenario
145
CRUD Matrix
Rol
e Billing
Informat
Access to Medical Data ion
Doctor
Clerk
Manage
Patient history
Access to Administrative Data
Nurse
Billin
g
Test result
R
U
R
Treatment result
Treatment
authorization
Patient demographics
Patient registration
CRU
CRUD
R
R
r
R
U
R
R
U
R
R
R
U
CRUD
Billing
Patient bill
CR
U
CRUD
Partial CRUD Analysis
146
State
[pay
Diagram
[register
patient]
Good
Standing
bill]
[determine >60
[determine >90
days
days
outstanding]
Overdu
outstanding]
In
Collection
[determine if 5 yr
[determine if
inactive]
uncollectable]
[close
Closed
account]
Written
Off
[archive account
data]
bill]
[pay
147
Busines RulesAnalysis
Business goal
Compliance with
government tax
legislature
Business policies
Charge tax to
customer
Business rules
Calculate the tax owed by

multiplying the
total cost of the product by the
tax rate as
determined by the state or
Functional
requirements: The
province
where
the sale is made
system shall
calculate and charge all state and
provincial
taxes where
applicable.
148
Data Flow
DFD
The DFD shows how

information is input,
processed, stored and
output from the system
(solution)
f
It is a visual presentation
how information moved
through the application.
Diagram
149
DOCTOR
PATIENT
treats
INTERVENTION
has
is for
is treated by
has
TREATMENT
is for
ERD
150
1. Requirements (Stated)
Model
2. Requirements
Structure
Diagrams
Requiremen
Proce
t
analyze thessstakeholder
and solution requirement
and the current state of
the organization, to
support the development
and implementation of the
solution, communication
with the stakeholder, and
team
training
Tools
and
Techniques
1.
Acceptance and Evaluation Criteria Definition
2.
3.
4.
5.
6.
7.
8.
9.
10
.
11
.
12
.
13
16.
.
Business Rules Analysis

Data Dictionary and Glossary
Data Flow Diagrams
Data Modeling
Functional Decomposition
Interface Analysis
Metrics and KPIs
Non-functional Requirements Analysis
Organization
Modeling
Process Modeling
Prototyping
Scenarios and Use Cases
Sequence
15. State Diagrams
User Stories
Outpu
t
1. Requirements [Analyzed]
Specify Inpu
and
151
Inpu
t
1. Stakeholder Concerns
Assumptions
and constraint
Proce
s
ss
Define and document the

project assumptions and
constraints (business and
Technical)

1. Problem Tracking
2. Risk Analysis
Outpu
t
1. Assumptions and
constraints
Define
152
Are factors that are correct but we dont have time and money to prove that it is
correct. We use it for the planning purpose.
Constraints
Are factors that limit our options.
Types of Constraints:
Business constraints limit the solution or the current organizational state. They
tend to be focused on the available time, money, and resources for your project
Technical constraints focus on architecture decisions that limit the

solution design. They tend to be inflexible and unchanging, and
they can impact your solution implementation
Element
s Assumptions
153
Inpu
t
1. Requirements (Any Except

Requirements
Stated)
Proce
ss
a quality check of the
analyzed requirements, to
make sure that the
requirements are correct
and complete, and that
they meet the quality
standards.
1. Acceptance and Evaluation
Criteria Definition
2. Checklists
3. Problem Tracking
4. Structured
Walkthrough
Outpu
t
1. Requirements (Verified)
Verify
154
Verifying and Validatin duringRequirement Analysis

s
Presentin
Elicitin
Modeling
Verificati
Organizin
on
Analyzin
g
An
d
Validatio
n
155
Verificatio and Validation

Techniques
Desk
checking
Walkthrou
gh
Peer
review
156
Characteristics of Requirement
Quality
Description
requirements are a set of requirements relating to one particular

Cohesive
process
thing, such as a business
Complete
. The goal is to produce a complete set of requirements defining what is
solution or a solution
needed for a
requirements do not contradict or conflict with one another
Consistent
component.
Correct
requirements
Feasible
Correctness must be determined and targeted across all steps of the

development
Feasibility of requirements relates to implementation

process
Modifiable
Requirements should be written and structured to allow easy changes
Unambiguous
the requirements should not be interpreted in more than one way
Testable
Characteristic
157
is the minimal set of requirement that must be met in order for a certain solution
to be worth implementing.
Evaluation criteria
is the set of requirement that will be used to choose between multiple solutions.
Acceptance & Evaluation Criteria
Acceptance criteria
Definition
158
1. Business Case
Requirements
2. Stakeholder,
Solution, or
Transition
3. Requirements
(Verified)
Proce
ss
a quality check of the
analyzed requirements, to
make sure that the
requirements are correct
and complete, and that
they meet the quality
standards.
Criteria Definition
2. Metrics and KPIs
3. Prototyping
4. Risk Analysis
5. Structured
Walkthrough
Outpu
t
1. Requirements (Validated)
ValidateInpu
159
business requirements and the business objectives for the project.
Valid requirements contribute directly or indirectly to the projects

business case.
Requirements validation is ongoing across the project life cycle; it

ensures that each level of detail added to the requirements aligns
with
Validate
requirement support the delivery of value to the business.
the big picture.
Validate
Validating requirements ensures that the requirements align to the
Requirements
160

Licensing Authority
Develop the following models:
Organization diagram
Swimming Lane for the Car License Renewal

process
Develop a Use Case Diagram and Use Case
Scenario
Develop
the
CRUD
diagram
Present
your
team
result
in a flip chart.
Plan for requirement verification and
validation
Ofice
Group Exercise
161
Solution Assessment and

1. Assess Proposed Solution
Validation
2
.
3
.
4
.
Allocate
Requirements
Assess Organization
Readiness
Define
Transition
Requirement
TAS1
<

Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
Controlled
P@rlomm
1ca1
?roJ.a.ct
:er Sac: n
Work
Analysis Plarnnlng
End
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
Analysls
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
------------------------------
and Valldatlora
Management
Formally
----.--------
163
Solution Assessment and

This knowledge area focuses on ensuring the solution can be
Validation
successfully implemented within the organization in order to meet the
business need driving your project.
The Solution Assessment and Validation focuses on assessing and

validating proposed, in progress, and implemented solutions
during, and
the project life cycle.
before,
after
164
Four diferent
Proposed Solution or Solutions Assessment

assessments
assesses the value delivered by each proposed solution and recommends the best
solution
Solution Validation Assessment

assesses the solutions ability to meet the business need at an acceptable level
of
quality
Organizational
Readiness
assesses the stakeholder readiness to accept the change associated with a
solution
and theirPerformance
ability to use the
solution effectively
Solution
Assessment
assesses how the operational solution is performing relative to business goals and
objectives
Solution
andValidatio
~!!"""""""l!!!""""""''!!-'!'!""""""'!'~!-111-!~'!l!""""""'!'-!!'l"""""""I,
Inpu
ts
Assessment
,A
1
I
I
,,----,
[Cons
.truct
ed,.
Solu
tlon
OpU
on(sl
Soluti
on
~erfo:r
,JJ ma
Deplo 5.4
,
yed,
nee
or SolurUon Scope
De.siStakeholder Met~
](S,
gned
Conc
~
erns
7,
1
,--
7,
Soluti
3
on
Ass
11
~. dll a
--- - -
-===---j
,.,_
,
Tas
ks -----..,
"
es.s
e
I -~- Org1
,.,,
Ass ess
Proposed
I
Solu
tlon
,.-,.,-,.,-.,,_,.
Ii
I,-----0 utp,u
ts
1
Assumpti Enter Requllr

ons and prise ements
Cons.t Archit
ralnts ecture,
TAS1
<
'\
Solutio
n
As~ess Identi
ment of fied
'7f
2
IProp
o~ed
Alloc
ate
~-- -===-~
Requi
7f
remen
4
ts.
Define
~
--Tramrnlo
----1 ~
n
R1equlr
Evaluate
nments.
~
5
Solution
s
Pe rfo:r
Valldat
i '!--------,----------~mance,
.7.
nes.
------
,,.
,-
'
II
I
j
Det
ects
7.
5
Mltlga
1Un
AcU
g
ons
Solu
7,
tion
3
Orga
Requl Trans
n i~atlon
rem
Readi
ition
ents Requir
a ness
I
1
[Alloc ements
ated]
Assess
nient
7.
6
Solut
ion
P erfo:
\,-oe~!'-'!!!_!'_-1!-!'-'!'_!l'_-~I'
rm a1n
1
Ge
1,
5
Solut
ion
Valld
atlon
Assess
Inpu
t
1. Assumptions and
Proposed
Constraints
2. Requirements
(Prioritized
and
Approved)
3. Solution Option(s)
Solutio
n
Proce
ss
assess all the proposed

solutions in order to
determine how closely they
meet the stakeholder
requirements and solution
requirements

Criteria
Definition
3. Vendor Assessment
Outpu
t
1. Assessment of Proposed
Solution
PMP Exam Preparation, based on the PMBOK Guide 5th edition
Assess
167
Element
s Ranking of solution options
Identification of additional potential capabilities
AllocateInpu
t
1. Requirements (Prioritized
Requirements
and Approved)
2. Solution (Designed)
3. Solution Scope
Proce
ss
allocate the stakeholder
and the solution
requirements to the
solution components and
release
Criteria Definition
2. Business Rules
Analysis
4. Functional
Decomposition
5. Process Modeling
6. Scenarios and Use
Outpu
t
1. Requirements (Allocated)
Element
Solution components
s
Release planning
Business Rules
Organizations business policies
Analysis
are directives that support business
Business goal
Compliance with
government tax
legislature
Business policies
Charge tax to
customer
Business rules
Calculate the tax owed by

multiplying
the total cost of the product
by the tax
rate as determined by the
Functional requirements: The
state or
system
province where
the sale is
made
shall calculate and charge all
state and
provincial taxes where
goals.
Business rules, by contrast,
are actionable and testable
directives that support the

business policies. Complex
business rules are often
represented as a decision tree
or table.
Business rules are
independent of their
implementation within the
organization
Assess
Inpu
t
Organizational
3. Solution Scope
4. Stakeholder
Concerns
Readines
Proce
ss
involves communicating
sthe impacts that a new
solution will have on the
business.
This allows everyone to be
prepared for the upcoming
changes versus being
surprised by them.
1. Acceptance and Evaluation Criteria
Definition
3. Focus Groups
4. Force Field Analysis
5. Interviews
6. Organization
7. Modeling
8. Problem Tracking
9. Process Models
Analysis
10. Risk
Survey/Questionnaire
11. SWOT
Analysis
Outpu
t
1. Organizational Readiness
Assessment
Element
s Culture assessment
Operational or technical
analysis
Stakehold impact
assessment
er
Forc Field Analysis

e
6
17
13
Define
Inpu
t
Requiremen
Proce
1. Organizational Readiness t
Transition
Assessment
2. Requirements
(Stated)
3. Solution (Deployed)
define whatssneeds to be
done to transition from
the existing solution to
the new solution. The
capabilities defined in the
transition requirements
target
making a smooth
transition
from
the old
Tools and
Techniques
solution to the new
1. Businesssolution.
Rules Analysis
3. Data Modeling
4. Organization
Modeling
5. Process Modeling
Outpu
t
1. Transition Requirements
Element
Data
s
Ongoing
work
change
Organization
al
ValidateInpu
t
1. Requirements (Prioritized
Solution
and Approved)
2. Solution
(Constructed)
Proce
ss
validate that the
constructed solution (the
new solution) will meet the
required business need
and to find the most
suitable way to solve the
identified problem.
Criteria
Definition
2. Problem Tracking
3. Root Cause Analysis
Outpu
t
1. Identified Defects
2. Mitigating
Actions
3. Solution
Validation
Assessment
Element
s Investigate Defective Solution Outputs
Assess Defects and Issues
Evaluate
Inpu
t
Performanc
Proce
1. Business Requirements
Solution
e
2. Identified Defects
3. Solution (Deployed)
4. Solution
Performance
Metrics
ss
is performed after the
actual implementation of
the new solution, to
understand the real value
delivered by the new
implemented solution.
2. Focus Groups
3. Observation
4. Survey /
Questionnaire
Outpu
t
1. Solution Performance
Assessment
Element
Understanding the Value Delivered by the Solution
s
Validating the Solution Metrics
Considering Solution Replacement or Elimination

Ongoing Cost versus Initial Investment
Opportunity Cost
Necessity
Sunk Cost
for a Car
Licensin Authority Ofice

g
Proposed Solution Assessment plan
Requirement Validation plan

Up to 3 Transition
Requirements
Present your team result in a flip chart.
Group Exercise
180

1. Manage Solution Scope & Requirements
Communication
2
.
3
.
4
.
Manage Requirements Traceability

Maintain Requirements for ReUsability
Prepare Requirements Package
Communicate Requirements
TAS1
<

Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
Controlled
P@rlomm
1ca1
?roJ.a.ct
:er Sac: n
Work
Analysis Plarnnlng
End
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
Analysls
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
------------------------------
and Valldatlora
Management
Formally
----.--------
182

This knowledge area focuses on managing and sharing the solution
Communication
scope and the project requirements with the project stakeholders.
The objective of this knowledge area is to have a common

understanding among all the stakeholders.
Requirement Management & Communication

2,
4
B
A
Com
munl
catl!
2.
on5
-,
.r- -- --- -- -- ---- ----
Process
Assets
I
4,.
4.
'
2,
1
ks,
I
Manage,
Managre
Re,q ts . I
Solution
Trac,e
r:----~
Scope
I
4.
ablllty
4,.
and
~u~
3
Req ts
4
Maint
ain
P'repa
R.eq't
4.
s for
re ~
5
Reuse Commueq Its
nicate
Pack
Requ I age,
List
Rolles,
and
4 ,1J
Req
u[Alpp
llremen
1
tsmved]
Requ
llrem ent
[Commu
nicated]
------
11
Stak,e
hollder
urts
C'
111~
Requir Sollu Sco

emernt ements tlon pe
s
Struc
ture
Manag
ement
4,.
1
Tas
Or1ganl Requir
zatlonal ements
Pll
an
Requllr
Pll
an
Out,p
--------~
Inp
uts
... _li_liii_'i_ili_ili_li_ll_ill_ili_li_li_li~
reme
nts,
Requ 11
u llr eme1 rem ent
1ts
s
[Maintai
Req
1
ned & 4. [Trac

Reus 4
ed]
able]
Requir
ements
P,ac
kage
,
TAS1
<
ManageInpu
Solution
& Requirement
Proce
1. Requirements Management
Scope
2.
3.
4.
Plan
Solution Scope
Stakeholder List, Roles, and
ss
secure the approval of

requirements from
stakeholders who have
the appropriate authority.
Outpu
t
1. Requirement [Approved]
responsibilities
Stakeholder, Solution, or
Transition Requirements
(Communicated or Traced
1.
Problem Tracking
2.
Baselining
3.
Signoff
185
Element
Solution scope management
s
Conflict and issue
Presenting
requirement for review
management
Approval
s
Solution
Identifies the new capabilities to be implemented and the methods to

Scope
deliver those capabilities, and it identifies the part(s) of the organization

that will be impacted by the new capabilities.
Baselinin
A baseline is a view of the reviewed and agreed
upon requirements at
g
a specific point in time.
Baselined requirements are considered to be
basis for future project
the
work.
Any changes to the baselined requirements must go through a formal
change control process.
Stakeholder
Domain SME
s
Implementation
SME
Project Manager
Sponsor
ManageInpu
t
1. Requirements Management
Requirements
2.
Plan
Requirements (all)
Traceabilit
Proce
The ability toss
identify and
y
document the lineage of
each requirement,
backward traceability
(derivation) or forward
traceability (allocation):
Outpu
t
1. Requirement [Traced]
project requirements
work products
solution components
1. Coverage Matrix
190
Element
s Impact Analysis
Configuration Management System
Relation
Requirements Traceability
A Requirements Traceability Matrix is a table used to track the various attributes of
requirements throughout the project life cycle.
It uses information from the Requirements Documentation and traces how those
requirements are addressed through other aspects of the project.
It provides information to:

Product Acceptance
Change Requests
Matrix
192
Requirement Information
Traceability
Requirement
Priority
Category
Matrix
ID
Relationship
Source
Objective
WBS
Deliver
able
Metric
Validation
Requirements Traceability
193
Stakeholder
s Implementation SME
Project Manager
Tester
ManageInpu
t
1. OPA
Requirements
2. Requirements
for Re-Use
Proce
ss
Requirements that may be
reused on other projects
must be named, defined,
and easily available to
other business analysts in
the organization.
1.
Outpu
t
Requirements (Maintained
and Reusable

NON
195
Element
requirement
s Ongoing
SLA
Quality standard
Business process
Stakeholder
Implementation SME
s
Domain SME
Business Analyst
PrepareInpu
t
Requirement
2.
Communication Plan
Organizational Process
3.
4.
Assets (OPAs)
Requirements (Any)
Requirements Structure
PackagProce
e
ss
a set of requirements that

you are getting ready for
an important projects
stakeholder to review, this
information should be
communicated clearly and
unambiguously.
Outpu
t
1. Requirements
Package
1. Requirements
Documentation
2. Requirements for
Vendor Selection
198
Element
objectives are:
s The
Formal presentation of requirements for reviews and approvals

Proof of conformance with contractual and regulatory obligations
Producing Work Products

MoM
Issue Log
Status
reports
Presentatio
Deliverables
n
Notes
Format
Stakeholder
Domain SMEs
s
End Users
Implementati SMEs
on
Project
Manager
Regulators
Tester
Communicate
Inpu
Proce
Have ass
common
Requirement
2.
3.
Communication Plan
Requirements (Any)
Requirements Package
understanding among
stakeholders, via iterative
and ongoing formal or
informal communication,
including conversations,
notes, documents,
presentations, and
discussions. usually done
in parallel
withTechniques
most of the
Tools and
other business analysis
tasks.Workshops
1. Requirements
2.
Outpu
t
1.Requirements
[communicated
Structured Walkthrough
201
Element
s General Communication
Presentation
Formal
Informal
In group of 3 to 5 members, for a Car Authority Ofice

Licensing
Requirement Approval plan
Requirement Traceability Matrix

Requirement Communication Plan
Requirement Configuration
Management
Group Exercise
203
Enterprise
1. Define Business Need
Analysis
2
.
3
.
4
.
Assess Capability Gap

Determine Solution
Approach
Define Solution Scope
Define Business Case
TAS1
<

Business
I
I
Conrtr 0. I ledl
1
Start
I
I
~rfmm Pir.a-
PlcJect
A.ctlv
@S
work
Business
Controlled
P@rlomm
1ca1
?roJ.a.ct
:er Sac: n
Work
Analysis Plarnnlng
End
Tiiams o n
Sc11.1t10t1 to
-
if'Kli"I
Stage
I
I
Ccntrcl Pr~oct
ProJ@Cii: a nel
asna
Work
Contfolled
Mlddle
Mon110 r .and
lnltJam
Pia
Analysls
Con
Close tlhe
0 going
Oper.atJOiilS
and Monitoring
Ov~all
I
[:::~~:::~~:
~ ---------~--------::~~:::~
I
~---------~--------I
I
I
~------
I~ -
'
Soll.W11orn
Requ I rem e
. . ..-------~---~~---~l-liii-ill---
I
Analysls
Ellcltatlon
N@;,;:t
St:ag
nts
Assessment
----I
------------------------------
and Valldatlora
Management
Formally
----.--------
205
Enterprise
This knowledge area focuses on defining and documenting the business
Analysis
requirements for a project to justify, why a particular project should be
initiated to address a particular business need.

It define the problem or the opportunity and the solution that meet the
requirement of the stakeholder
Enterprise
r
Inp
Analysis
uts
Assumpti Busines
ons and s Goa lls
1
Constr
aints
Organiz
ational
roc ess
Assets,
IP
and
Objectiv
es,
Require
ments
[Stat
ed]
Stalke
holder
~
,B~l~IIJ~lll~'l~l~l~l!l~lll~l~l'~ll'~'lll~'I
Conc
erns
( ,-
i -
' -
'
_, ; '\
I
Outp
Enter
prise
ArcMt
ecture
,
J uts
"""===="'
5,.
5.
.
4
i ...j
3
Defin
,
Appr
.,.I
Determi
1.. oach
I,
e
_ ine
I
---~-----1Solut
So!
lutio
n
P
@rfor
ma
nee
1
Solutio
n
As5e~
~rnenr }
t
I
ion
Sco
pe
S
J
.r
I
I"
~
I
'
'
'
Busi C Busi Ne I
nes: as nes: ed
s
e sI
I .
!J
..
Requ
ired
Ca1pa
biliti
@s
Solu
Uon
Appr
oach
Soli Scutiio ope

----n
---
TAS1
<
Define
Inpu
t
1. Business Goals and

Business
2.
Objectives
Requirements (Stated)
Need
Proce
ss
why the organization
need to make a change
to its current status.
To define the problem
and/or the opportunity
that the business analyst
need to develop a solution
for it.
Outpu
t
1. Business Need
1. Benchmarking
2. Brainstorming
3. Business Rules Analysis
4. Focus Groups
5. Functional Decomposition
6. Root Cause Analysis
208
Element
Business goals and objectives
s
Business problem and
opportunity
Increase customer satisfaction
Desired
outcome
Increase employee
Improve safety
satisfaction
Improve revenue
and sales
Assess
Inpu
t
1. Business Need
Capability
3. Solution Performance
Assessment
Gaps
Proce
ss
Assess capability gaps

define the new
capabilities required in
order to meet that
business need and
deliver the desired
outcomes or business
Toolsbenefits.
and Techniques
Outpu
t
1. Required capabilities
2. SOWT Analysis
210
Element
s Current capability analysis
New capability assessment

Business process
Software
application Service
to be delivered
product
Assumptions
SWOT Analysis
SWOT analysis is a strategic
planning method used to evaluate
the Strengths, Weaknesses,
Opportunities, and Threats involved
in
a projectby
or in
a business
venture.
Originated
Albert
S Humphrey
in
the 1960s.
SWOT Matrix is sometimes called an

IE Matrix.
Determine
Inpu
t
1. Business Need
Solution
2. OPA
ApproacProce
how you will ss
create or
hacquire the required
capabilities (the solution) in
order to meet the business
need, could be:
Partnering or outsourcing
Making organizational changes
Changing business processes
Adding business resources
Update existing software and/or
Outpu
t
1. Solution Approach
hardware
Tools
and Techniques
capabilities
1.
Benchmarking
Purchasing or
2. Brainstorming
leasing
software
and/or
3. Decision
Analysis
hardware
4. Estimation
5. SWOT Analysis
213
Element
Alternative generation
s
Assumption and
Ranking and selection of approaches

constrains
Feasibility
Feasibility analysis focuses on
Analysis
When assessing possible solution
identifying and analyzing potential
approaches, the
solution options to determine the
be considered:
Operational
Economic
Technical
Schedule
based
Organizational
Cultural
viable solution.
most
Feasibility study, the output of
Feasibility analysis, presents a
preliminary analysis of solution
option will deliver the desired
alternatives, evaluating how each
benefits) and meet
outcome (business
the business need.
Legal
Marketing
following factors to
Define
Inpu
t
1. Business Need
Solution
2. Solution Approach
4. Assumptions
Scop
e
Proce
ss
defines the set of
capabilities a solution
must deliver in order to
meet the business
need.
It is derived from the
business need, the desired
outcome (business benefits),
and the required capabilities
including the major
functions,
Tools
and features,
Techniques
options.
Outpu
t
1. Solution Scope
1. Functional Decomposition
2. Interface Analysis
3. Scope Modeling
4. User Stories
5. Problem or Vision
216
Element
Solution scope definition
s
Implementation
approach
Dependencies
Problem or Vision
Problem or Vision Statement describes the positive impact that meeting
Statement
a business need will have on key project stakeholders.
The recommended contents for a problem or vision statement include:

A description of the problem or vision
List of affected stakeholders
on each listed stakeholder

Impacts
the
problem
or
vision
will
have
Key benefits of a successful solution
Define
Inpu
t
1. Business Need
Business
2. Solution Scope
3. Stakeholder Concerns
4. Assumptions &
Cas
e
Proce
ss
Business case is used to
justify the costs of doing a
project in terms of the value
the project adds to the
business and the associated
business benefits.
A business case must look
at both sides of the
equation, comparing both
the costs and benefits of a
proposed solution.
Outpu
t
1. Business Case
2. Estimation
3. Metrics and Key
4.
Performance Indicators
5.
Risk Analysis
6.
219
Element
Benefits
s
Cost
Risk
Result Measurement
Assessment
for a Car
Licensin Authority Ofice

g
Identify the Business Need
Develop Vision & Scope

statement
Develop Business Case
Group Exercise
221
Underlying Competencies are the behaviors,

characteristics,
1. Analytical thinking and Problem solving
qualities.
2.
Behavioral characteristics
3.
Business knowledge
4.
Software knowledge
5.
Interaction skills
knowledge, and personal
Underlying Competencies
222
1. Creative Thinking
Thinking
2
.
3
.
4
.
Decision
Making
Learning
Problem
Solving
Systems
and Proble
m
Solving
Analytical
223
and
alternative solutions when solving business problems.

The business analyst also need to ask questions and
assumptions in order to foster creative thinking in his other team
challenge
members and stakeholders.
1- Creative
Creative thinkers are able to generate new ideas, concepts,
Thinking
224
good decision and be able to help other project team

members
stakeholders make good decisions.

The decision making should include:
Gathering and breaking down relevant information
Making comparisons and evaluating tradeofs between options
Identifying the option that is most desirable
and
2- Decision
The business analyst must understand what is involved in making a

Making
225
The business analyst should absorb new business information so that he

can translate
information into the project requirements and
their
resulting solution.
these
3
Learning is to know something new.
Learning
226
make sure that the problem or business need being addressed is clearly defined
and understood by stakeholders
Alternatives Identification
suggest more than one way to address the problem
Decision Making
Tradeoff decision making may be required to select the best solution to the
problem or need
4- Problem
Problem Definition
Solving
227
put all of the pieces together and

understand the properties, behaviors, and
across people, processes, and technology.
characteristics of the system as a whole
5- Systems
Looks at your ability to:

Thinking
228
1. Ethics
Characteristics
2 Trustworthiness
. Personal
3 Organization
.
Behavioral
229
are sure to clearly articulate the basis of their decisions so everyone
understands.
Any conflicts of interest should be promptly and fully disclosed.
1
Consider the interests of all stakeholders when making decisions and
Ethics
230
time on the project and to keep their interests front and center in the
decision - making process during the project and business analysis
work.
2 Stakeholders trust the business analyst to do the right thing at the right
Trustworthiness
231
impact on how the business analysis team members and other

stakeholders perceive the business analyst.
3- Personal
Ability to effectively managing his time, tasks, and information has an

Organization
232
1. Business Principles and Practices
Knowledge
2 Industry Knowledge
. Organization knowledge
3 Solution Knowledge
.
4
.
Business
233
organizations of similar purpose and structure, such as:

human resources,
finance, and
information technology functions.
In contrast, business practices or processes vary based on what an

organization does and the size of that organization.
1- Business Principles and
Business principles are defined as the characteristics common

Practices
234
major competitors,
partners, and
customer
segments.
The business analyst knowledge should also encompass the

organizations common products and product types.
2- Industry
The business analyst should be aware of:

Knowledge
235
business models,
organizational structure,
business unit relationships,
and
the key project stakeholders,
Includes recognizing the informal lines of communication, authority,

and internal politics that are in play relative to your project.
3- Organization
Includes the entire business architecture:

knowledge
236
capabilities within the organization, this allows them to effectively

identify, assess and implement changes to those solutions.
,
4- Solution
Business analysts are familiar with existing solutions and their

Knowledge
237
1. General purpose Software Applications

Applications
2 Specialized Software Applications
Software
238
information such as:

Word processing
Spreadsheets
Presentation software
tools
Document repositories
Wikis
Email and instant messaging

Discussion forums
1- General purpose Software

Ofice productivity tools used
to store, capture, and distribute
Applications
239
implement formal models, and build/manage requirements

documentation.
Diagramming tools
Modeling tools
Requirements
management
Change control
Configuration management
Traceability
tools
2- Specialized Software
Requirements development tools used to develop, validate, and

Applications
240
Communication
1. Communication Model
Skills
2 Communicatio Type
. n
s
3 Teaching
.
Activ
Communicatio
listeni
ng
skills
Teachi
Verb
al
Writte
ng
241
1-Communicatio Model
Effective
means transferring the intended ideas

information to the target
communication
or
242
2-Interperson Communicatio
Types
Formal
Oral
Presentations, speeches
Meetings, conversations
Written
Complex problems, pm plans,

Memos,
emails, notes charter, communicating over long
distance, formal letters, contract, CR
NonVerbal
body
In formal use, like Aerospace,
individual likes
language
factories, etc.
The extent to which an

another and is interested in his or
her
Meaning of
physical distance words
views
The
relati
facial expression and
Verbal
al
Informal
243
communicated to and understood by the stakeholders.
Types of learners:
Visual learners who learn best by seeing something done
Auditory learners who learn best by hearing or reading things
Kinesthetic (tactile) learners are those who learn best by doing something for
themselves
3 Use teaching to ensure that the ideas and information effectively

Teaching
244
Skills
Facilitatio
Negotiatio
Leadershi
Influencin
Motivating
Interaction
245
such as resolving disagreements regarding the priority and nature of

requirements.
Moderate any number of group discussions and meetings.
1- Facilitation and
Facilitating many diferent types of interactions between stakeholders,

Negotiation
246
Developing a vision & strategy
Establishing direction
Motivating
and inspiring
Aligning people
Directing
telling people what to do
Coaching
giving needed instructions
Facilitating
coordinating input of others
Supporting
giving assistance along the way
Consultative
Inviting ideas from others
Team Building
helping the group to work
interdependently & achieve good
teamwork
laissez Faire
2- Leadership and
Leadership is about:
Influencing
247
t
3 - Conflict Managemen Technique

s
248
4 - DouglasMcGregor(Theor X & Y)
y
249
Mohamed
AbuSen
PM,
ITSM
BPM
MBA, MSc,
BScand
Engineering,
Coach
PM Diploma, PMI-PMP , PMI-RMP, Prince 2 Practitioner, Prince 2
Agile,
Project Management Governance Manager ISO 21500,
ITIL Expert, IT Governance Manager ISO 38500,
Disaster Recovery Manager ISO 24762,

6 Sigma-BB, CIBAP and TQM
Mohamed AbuSen, All

Rights
reserved, 2015.
mohamed.abusen@gmail.com
mohamed.abusen
Thank you
+201006439499
250

Presentation - CIBAP Exam Preparation

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Presentation - CIBAP Exam Preparation

Hochgeladen von

Copyright:

Verfügbare Formate

Business Analysis

CIBAP Exam Preparation

Looking for a volunteer to help me

this agenda (time keeper)

Is this statement true?

What should we do to get

What is the role of Business Analyst?

How can you

improve the Business Analyst role at your organization?

Business Analysis - CIBAP Exam Preparation, based on the

Whatdoe th Sponso Expec from th Project

How Are th TeamRecogniz th Project

Business Analysis - CIBAP Exam Preparation, based on the

Whatth custome requeste

Whatth busines analys understoo

Whatth projec tea delivere

Whatth custome paid for

Whatth custome neede

Standardization and Adaptability

Business Analysis - CIBAP Exam Preparation, based on the

non-profit professional association serving the field of business

IIBA established October 2003 in Toronto, Canada, With 28 founding

Certification of Competency in Business Analysis (CCBA)

Certified Business Analysis Professional (CIBAP) - 3,13

Business Analysis - CIBAP Exam Preparation, based on the

International Institute of Business Analysis (IIBA) is an independent

Minimum 7500 hours of BA work

Guide in the last 10 years

Business Analysis - CIBAP Exam Preparation, based on the

Business Analysis - CIBAP Exam Preparation, based on the

generally accepted best

of the business analysis,

Business Analysis - CIBAP Exam Preparation, based on the

Guide contains the

Business Analysis - CIBAP Exam Preparation, based on the

Business Analysis - CIBAP Exam Preparation, based on the

Knowledge Area Tasks

Business Analysis - CIBAP Exam Preparation, based on the

Guide Knowledg Area - Interactio

Domain is the area undergoing

It could be the whole organization

Business Analysis - CIBAP Exam Preparation, based on the

needed by a stakeholder to solve a problem or to reach certain objective.

Business Analysis - CIBAP Exam Preparation, based on the

s The formal definition of requirement is conditions or

objectives, and needs of the

These requirements define the needs of

Business Analysis - CIBAP Exam Preparation, based on the

They define the high - level goals,

are the most detailed type of

current to the future state and

Business Analysis - CIBAP Exam Preparation, based on the

The non-functional requirements

Business Analysis - CIBAP Exam Preparation, based on the

Business analysis is the set of tasks

A Guide to the Business Analysis Body of Knowledge , (

Guide), Version 2.0, International Institute of Business Analysis, 2009, 223.

recommend solutions that enable the organization to

Business Analysis - CIBAP Exam Preparation, based on the

The Busines Analys Role

Business Analysis - CIBAP Exam Preparation, based on the

Vision and Scop

In-scope and out-ofbusiness