PMI-PBA® (PMI Professional in Business Analysis)

Course Structure
• Module 1 – Introduc/on to PMI-PBA
• Module 2 – Introduc/on to Business Analysis
• Module 3 – Defining and Aligning Process Group
• Module 4 – Ini/a/ng Process Group
• Module 5 – Planning Process Group
• Module 6 – Execu/ng Process Group
• Module 7 – Monitoring and Controlling Process Group
• Module 8 – Releasing Process Group
• Module 9 – Prac/ce Guide for Business Analysis Prac//oner

2
Module 6

Execu<ng Process Group

3
Business Analysis Knowledge Area and Process Groups

Process Group Defining and Ini<a<ng Planning Execu<ng Monitoring and Releasing
& Knowledge Aligning Process Process Process Controlling Process
Area Process Group Group Group Group Process Group Group
Needs
6 1 7
Assessment
Stakeholder
1 3 1 2 7
Engagement
Elicita<on 1 3 4
Analysis 1 8 9
Traceability
and 1 2 1 4
Monitoring
Solu<on
1 1 1 1 4
Evalua<on

8 1 7 15 3 1 35

4
Execu<ng Process Group - Knowledge Area and Processes

Knowledge Needs Stakeholder Elicita<on (3) Analysis (8) Traceability Solu<on

Area Assessment Engagement and Monitoring Evalua<on (1)
(0) (1) (2)
Execu<ng Prepare for Prepare for Create and Analyze Models Establish Evaluate
Process Group Transi/on to Elicita/on Rela/onship and Acceptance
Future State Define and Elaborate Dependencies Results and
(15) Conduct Requirements Address Defects
Elicita/on Select and
Define Acceptance Criteria Approve
Confirm Requirements
Verify Requirements
Elicita/on
Results Validate requirements

Priori/ze Requirements and

Other Product Informa/on
Iden/fy and Analyze
Product Risks

Assess Product Design

Op/ons

5
Exec<ng processes in Stakeholder Engagement

Stakeholder Engagement

6
Prepare for Transi<on to Future State

Inputs Tools and Techniques Outputs

Business Case Elicita/on techniques Readiness assessment
Current state assessment Group decision making techniques Transi/on plan
Job analysis
Product risk analysis
Priori/za/on schemes
Product scope
Process flows
Requirements and other product SWOT analysis
informa/on
User story
Solu/on design
Stakeholder engagement and
communica/on approach

7
Prepare for Transi<on to Future State

Readiness assessment
• Readiness is the ability and the interest of an organiza/on to transi/on to future state or use capability
• Iden/fy any gaps in readiness considered as risks
• May use readiness checklist
• Report that provides readiness assessment
Transi<on plan
• Based on readiness and transi/on strategy
• Includes ac/onable and testable transi/on requirements

8
Exec<ng processes in Elicita<on

Elicita<on

9
What elicita<on means

• Elicita<on – Bringing forth

• Elicita<on Is More than Requirements Collec<on or Gathering
• Requirements are not ready and wai/ng in the stakeholders’ minds or in documents within the
business community
• Some stakeholders may not even know their needs
• Importance of Elici<ng Informa<on
• Support execu/ve decision making
• Apply influence successfully.
• Assist in nego/a/on or media/on
• Resolve conflict
• Define problems

10
Prepare for Elicita<on

Inputs Tools and Techniques Outputs

Product Scope Document analysis Elicita/on prepara/on materials
Situa/on Statement Interviews

Elicita/on approach
Requirements and other product
informa/on
Stakeholder engagement and
communica/on approach

11
Plan for elicita<on

Develop the Elicita<on Plan

• What informa/on to elicit?
• What does the business analyst need to know in order to define the problem, solve the problem, or
answer the ques/on?
• Where to find that informa/on.?
• Where is that informa/on located: in what document, from what source, in whose mind? Iden/fy who
has the informa/on or where it is located.
• How to obtain the informa/on?
• What method will be used to acquire the informa/on from the source?
• Sequencing the Elicita/on Ac/vi/es.
• In what order should the elicita/on ac/vi/es be sequenced to acquire the needed informa/on?
Finding Informa<on
• Individuals in the elicita/on plan should be iden/fied by role rather than name
• Good prac/ce to try to iden/fy at least two sources for each topic or ques/on
12
Elicita<on Plan

13
Conduct Elicita<on

Inputs Tools and Techniques Outputs

Product Scope Brainstorming Unconfirmed elicita/on results
Situa/on Statement Collabora/ve games
Document analysis
Elicita/on prepara/on materials
Facilitated workshops
Focus groups
Interviews
Observa/on
Prototyping
Ques/onnaires and Surveys

14
 Voice of customer

• VOC is a technique borrowed from the six sigma methodology

• VOC stands for what the customer says and helps us
understand what the customer meant.
• VOC is facilitated through a table as shown below:
•
Sl # Customer voice Who What When Where Why How
1
2

3-15
 Voice of customer
• Who – Who uses it
• What – What it actually means
• When – When is it needed
• Where – Where is it needed
• Why – Why is it needed
• How – How is it used?
•

Sl # Customer voice Who What When Where Why How

1 Ability to reserve Traveller, Online 24 x 7 x 365 Through web Ease Card
booking agent reserva/on site payment
system
2

3-16
 Voice of customer – assessment administra/on

• Who – Who uses it

• What – What it actually means
• When – When is it needed
• Where – Where is it needed
• Why – Why is it needed
• How – How is it used?
•

Sl # Customer voice Who What When Where Why How

1 Administer An eligible - Online Based on Examina/on Authen/c and Online
exam registered - Mul/ple appointmen centres credible
student choice t mechanism
objec/ve
type
2
3-17
 Exercise

• Create a VOC table for any one requirement of the MB case

study

3-18
 What if analysis

• When a customer requirement is to provide a capability or

meet a condi/on, the WhatIf analysis involves asking nega/ve
ques/ons as to what if that condi/on is not met.

• This ques/oning helps in understanding the business logic

behind the requirement and helps uncover implicit or
unconscious requirements

• The what if analysis can go up to mul/ple levels

3-19
 Exercise on “WhatIf” Technique

Descrip/on:
• The state of requirement from the customer is as given below.
“The payroll applica/on shall send out the pay-slips at the
end of each month to employees. The pay-slips will be sent
to their respec/ve e-mail ids as well their mobile phones”.

Exercise:
• Elicit requirements wri/ng ques/ons that will discover the unconscious
or implicit requirements in the above statement.

3-20
 Some possible what if ques/ons

• Q1: What if the pay-roll applica/on is not working at the end of

the month? Do employees get some alert regarding the
breakdown?
• Q2: What if the end of the month happens to be a Holiday?
• Q3: Is the pay-slip sent on 30th of every month? How about
leap year?
• Q4: What if the mobile phone of the employee is out of order?

3-21
 Exercises

Discussion –
• Hollywood videos is a video store chain with outlets across the US having a turn over of USD 10 B.
They were consolida/ng their opera/ons and were building a single global IT plaform that would
support all their opera/ons. While elici/ng requirements, the vendor encountered a contradic/on:
• The IS manager who was championing this global applica/on and was the primary contact for the
vendor team was recommending that replenishment of stock should be done centrally. But, a
business manager was insis/ng that the replenishment should be handled locally. And they were not
converging easily. How would you resolve this situa/on?

3-22
 Interviewing
– The most simple and direct method of
iden/fying requirements
– Prepare for the interview
– The interview
• Users
• Customers
– Work toward bias-free interviews
• Solu/on free ques/ons

3-23
 How to Handle

• Resistant interviewees
– Leverage organiza/on structure and stakeholder analysis

3-24
 Mind maps – crea/ng informal visual model

• Another alterna/ve to prototype is other types of visual

models such as mind maps
• A mind map is a simple diagrams that relates various en//es
discussed in a graphical way
• It is an informal technique and uses no conven/on, but is very
useful

3-25
 Brainstorming

– Encourages par/cipa/on by all stakeholders

– Allows group to build synergy
– All ideas are captured in wrihen form
– Encourages out-of-the-box thinking
– Involves:
• Idea genera/on
• Idea reduc/on

3-26
 Rules for Brainstorming

– Don’t allow cri/cism or

debate
– Let your imagina/on soar
– Generate as many ideas as
possible
– Mutate and combine ideas

Managing Software Requirements, p. 114

3-27
 Idea Genera/on – Idea Reduc/on

– Idea Genera/on – Idea Reduc/on

• All gather in one room • Pruning
• Supplies • Grouping ideas
• Facilitator • Feature defini/on
• Objec/ves • Priori/za/on
• Ideas
• Collect
• Post

Managing Software Requirements, pp. 116-119

3-28
 Use case workshops

– One or more users are invited into the workshop

– Users narrate the sequence of steps performed in a given scenario
– Analyst team either writes a use case or a process flow diagram
based on the inputs
– When users concur on the usecase / process flow wrihen by the
analyst team, that requirement is frozen.

3-29
 Suitability of elicita/on techniques
Conscious Unconscious Undreamed
VOC
WhatIf analysis
Interviews
Brainstorming
Prototyping
Use case workshops
Kano model
Appren/ceship

Legend:
1 – Low suitability
2 – Average suitability
3 – High suitability
3-30
 Suitability of elicita/on techniques
Conscious Unconscious Undreamed
VOC 2 3 1
WhatIf analysis 2 3 2
Interviews 3 2 1
Brainstorming 1 2 3
Prototyping 2 3 2
Use case workshops 2 3 2
Kano model 3 3 3
Appren/ceship 1 3 2

Legend:
1 – Low suitability
2 – Average suitability
3 – High suitability
3-31
 Suggest a suitable elicita/on technique

1. What is the procedure to select vendor?

2. Can the policies of MB compe/tors towards their own employees
influence a change in MB’s policies towards its own employees to
maintain its “Preferred Employer” ranking?
3. We need details of vendor administering the benefit such as region,
method of access, benefits administered etc.
4. What benefits are ex-employees eligible for?
5. What if a vendor fails in servicing a benefit?

3-32
 Suggest a suitable elicita/on technique

1. What is the procedure to select vendor? – Usecase workshop

2. Can the policies of MB compe/tors towards their own employees
influence a change in MB’s policies towards its own employees to
maintain its “Preferred Employer” ranking? - Brainstorming
3. We need details of vendor administering the benefit such as region,
method of access, benefits administered etc. - VOC
4. What benefits are ex-employees eligible for? - Interview
5. What if a vendor fails in servicing a benefit? - WhatIf

3-33
Elicita<on Techniques

A skilled business analyst uses a combina/on of requirements elicita/on techniques to help him
understanding the current business situa/on and uncover the real requirements
The primary elicita/on techniques we all use are interviews and workshops. Some addi/onal techniques may
be used.
We can divide elicita/on techniques into two categories:
Qualita<ve elicita<on techniques. They help to discover the widest possible range of facts about an issue at
hand.
Techniques: Interviews, workshops, observa/ons, prototyping, focus groups etc.
Quan<ta<ve elicita<on techniques. These techniques provide further insights into the issue at hand and are
concerned with volumes and frequencies (e.g. how many orders are taken, how long does it take to process
them).
Techniques: Ques/onnaires, document analysis, /mesheet etc.

34
Conduct Elicita<on

• Introduc<on
• Sets the stage, sets the pace, and establishes the overall purpose for the elicita/on session
• Body
• Where the ques/ons are asked and the answers are given.
• Close
• Provides a graceful termina/on to the par/cular session.
• Follow-Up
• Where the informa/on is consolidated and confirmed with the par/cipants.

35
 Conduct Elicita<on

Types of Ques<ons - sets the stage, sets the pace, and establishes the overall purpose for
the elicita/on session
• Open-ended ques/on - answer in any way they desire
• Closed-ended ques/on – yes or no, number
• Contextual ques/on- the subject at hand
• Context-free ques/on - may be asked in any situa/on

Listening - Ac/ve listening is the act of listening completely with all senses

36
Brainstorming

To produce numerous new ideas, and derive from them themes for further analysis

Ability to elicit many ideas in a short /me period

Non-judgmental environment enables crea/ve thinking
Can be useful during a workshop to reduce tension between par/cipants

Dependent on par/cipants’ crea/vity and willingness to par/cipate

Organiza/onal and interpersonal poli/cs may also limit par/cipa/on
Group par/cipants must agree to avoid deba/ng the ideas raised during
brainstorming

37
 Brainstorming

Descrip<on
• Brainstorming is an excellent way to foster crea/ve thinking about a problem. The aim of
brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis.

• Brainstorming is a technique intended to produce a broad or diverse set of op/ons

Elements
• Prepara/on
• Session
• Wrap-up
Prepara<on Session Wrap-up
• Define area of interest • Share Ideas • Discuss and evaluate
• Determine /me limit • Record Ideas • Create list
• Iden/fy par/cipants • Build on each other ideas • Rate ldeas
• Establish evalua/on criteria • Elicit as many ideas as possible • Distribute final list

38
Document Analysis

It is used to elicit business analysis informa/on, including contextual

understanding and requirements, by examining available materials that
describe either the business environment or exis/ng organiza/onal assets.

Exis/ng source material may be used as a basis for analysis

Results can be used to validate against the results of other requirements
elicita/on techniques

Exis/ng documenta/on may be out of date or invalid.

Authors may not be available for ques/ons.

39
Document Analysis

Descrip<on
• Document Analysis may be used to gather business informa/on in order to understand the context of a
business need, or it may include researching exis/ng solu/ons to validate how those solu/ons are
currently implemented.

Elements
• Prepara/on
• Document Review and Analysis
• Record Findings

40
Collabor<ve Games

It encourages par/cipants in an elicita/on ac/vity to collaborate in building a joint

understanding of a problem or a solu/on.

May reveal hidden assump/ons or differences in opinion

Encourages crea/ve thinking by s/mula/ng alterna/ve mental processes.

The playful nature of the games may be perceived as silly and make par/cipants with
reserved personali/es uncomfortable.
Games can be /me-consuming and may be perceived as unproduc/ve if the
objec/ves or outcomes are not clear.

41
Collabor<ve Games

Descrip<on
• Collabora/ve games refer to several structured techniques inspired by game play and are designed to
facilitate collabora/on
• The games are used to help the par/cipants share their knowledge and experience on a given topic,
iden/fy hidden assump/ons, and explore that knowledge in ways that may not occur during the course
of normal interac/ons.
Elements
• Game Purpose
• Process
• Outcome
• Examples of Collabora/ve Games
• Product Vision box
• Feature Tree
• Sail Boat

42
Focus Groups

It is a means to elicit ideas and opinions about a specific product, service, or

opportunity in an interac/ve group environment.

Focus Groups saves both /me and costs as compared to conduc/ng individual
interviews.
Effec/ve for learning people’s aotudes, experiences, and desires

Par/cipants may be concerned about issues of trust or may be unwillingly to

discuss sensi/ve or personal topics.
It may be difficult to schedule the group for the same date and /me.

43
Focus Groups

Descrip<on
• Focus Group is a means to elicit ideas and opinions about a specific product, service or opportunity in
an interac/ve group environment.
• Form of qualita/ve research
Elements
• Focus Group Objec/ve
• Focus Group Plan – Purpose, Loca/on, Logis/cs, Par/cipants, Budget, Timelines and Outcome
• Par/cipants
• Discussion Guide
• Assign a Moderator and Recorder
• Conduct the Focus Group
• Aqer the Focus Group

44
Interviews

It is a systema/c approach designed to elicit business analysis informa/on

from a person or group of people by talking to the interviewees, asking
relevant ques/ons and documen/ng the responses.

Encourages par/cipa/on by and establishes rapport with stakeholders

Enables observa/on of non-verbal behaviour
The interviewer can ask follow up and probing ques/ons to confirm their
own understanding

Significant /me is required to plan for and conduct interviews

Training is required to conduct effec/ve interviews

45
Interviews

Descrip<on
The interview is a common technique for elici/ng requirements.
It involves direct communica/on with individuals or groups of people who are part of an ini/a/ve.

Elements
• Interview Goal
• Poten/al Interviewees
• Interview Ques/ons
• Interview Logis/cs
• Interview Flow
• Interview Follow Up

Interview Type
• Structured
• Unstructured

46
Interviews

Step 1: Select stakeholders to interview

Step 2: Prepare for the interview
• Decide specifically whom to interview.
• Define objec/ves of the interview.
• Determine what informa/on you need.
• Set a /me limit for the interview (oqen 60 min.).
• Decide on (and some/mes write down) the interview ques/ons and develop an interview guide.
• Schedule the interview and inform your interviewees about the objec/ves of the interview.
• Choose an appropriate loca/on where you will not be disturbed and where you both feel comfortable.

47
Interviews

Step 3: Conduct the interview

• Allocate enough /me and ensure that there are no interrup/ons.
• Explain why you are conduc/ng the interview. Provide context and create a buy-in.
• Know what you expect to get out of the interview but be flexible enough to follow interes/ng tangents.
• Take notes.
• Explain to the stakeholder what will happen with his input and write down any ac/ons points you both
discussed
Step 4: Follow-up
• If ac/on points were defined, make sure you close them as soon as possible in order to keep the
stakeholder ac/vely involved and get his support for the case.

48
Interviews

Advantages Disadvantages
• Allows to establish rapport with the stakeholder. • An interviewer can be biased by the stakeholder
• Provide opportunity to explore topics in depth • You get only one side of the story (the stakeholder
• Allows to experience the effec/ve as well as you interview)
cogni/ve aspects of responses • Interviews can be very /me-consuming: seong up,
• Allows to collect samples of documents interviewing, analysing, feedback, repor/ng and
therefore costly
• Allow interviewer to explain or help clarify
ques/ons, what increases the likelihood of useful • Effec/veness depends on the interviewer
responses experience in conduc/ng interview and
interviewees knowledge.

49
Workshops

It brings stakeholders together in order to collaborate on achieving a

predefined goal.

Can be a means to achieve agreement in a rela/vely short period of /me.

Costs are oqen lower than the cost of performing mul/ple interviews.

Stakeholder availability may make it difficult to schedule the workshop.

The success of the workshop is highly dependant on the exper/se of the
facilitator and knowledge of the par/cipants

50
Workshops

Descrip<on
• A workshop is a focused event ahended by key stakeholders and subject maher experts (SMEs) for a
concentrated period of /me.
Elements
• Prepare for the Workshop • Conduct the Workshop
• Iden/fy cri/cal stakeholders • Elicit, analyze and document requirements
• Define agenda, Schedule and send out info • Obtain consensus
• Schedule pre workshop interview • Validate elicita/on ac/vity with goals
• Workshop Roles – Sponsor, Facilitator, • Post Workshop Wrap-up
Scribe, Time Keeper, Par/cipants • Follow up on ac/on items
• Complete documenta/on

51
Observa<on

It is used to elicit informa/on by viewing and understanding ac/vi/es and their

context.

Observers can gain realis/c and prac/cal insights about the ac/vi/es and their
tasks within an overall process
Recommenda/ons for improvement are supported by objec/ve and
quan/ta/ve evidence.

Can be threatening and intrusive to the person being observer

Significant /me is required to plan for and conduct observa/ons

52
Observa<on

Descrip<on
• Observa/on of ac/vi/es also known as job shadowing involves examining a work ac/vity first hand as it
is performed.
• There are 2 basic approaches for observa/on:-
• Ac/ve/No/ceable
• Passive/Unno/ceable
Elements
• Observa/on Objec/ves
• Prepare for Observa/on
• Conduct the Observa/on Session
• Confirm and Present Observa/on Results

53
Prototyping

It is used to elicit and validate stakeholder needs through an itera/ve process

that creates a model or design of requirements

It provides a visual representa/on for the future state.

Allows for stakeholders to provide input and feedback early in the design
process

Underlying technology may need to be understood or assumed in order to

ini/ate prototyping
If the prototype is deeply elaborate and detailed, stakeholders may develop
unrealis/c expecta/ons for the final solu/on.

54
Prototyping

Descrip<on
• Prototyping is a proven method for product design. It works by providing an early model of the final
result.
Elements
• Prototyping Approach • Prototyping Methods
• Throw-away • Storyboarding
• Simula/on
• Evolu/onary or Func/onal
• Paper Prototyping
• Prototyping Examples • Workflow Modelling
• Proof of Concept – Validate the design of a system
• Func/onal Prototype – Test soqware func/onality
• Usability Prototype – Test how the end user interacts with the system
• Visual Prototype – Test the visual aspects of the solu/on
• Form Study Prototype – Basic, Size, Look and Feel of the product.

55
Survey or Ques<onnaire

It is used to elicit business analysis informa/on including informa/on about

customers, products, work prac/ces and aotudes from a group of people in a
structured way and in a rela/vely short period of /me.

Quick and rela/vely inexpensive to administer.

Easier to collect informa/on from a large audience than other techniques
such as interviews

The response rates may be too low for sta/s/cal significance.

Use of open ended ques/ons requires more analysis.

56
Survey or Ques<onnaire

Descrip<on
• A survey or ques/onnaire presents a set of ques/ons to stakeholders and subject maher experts
whose responses are then collected and analysed in order to formulate knowledge about the
subject maher of interest.
• Two types of ques/ons used in a survey or ques/onnaire. Closed-ended and Open-ended.
Elements
• Prepare
• Distribute the Survey or Ques/onnaire
• Document the Results

57
Survey or Ques<onnaire

Step 1: Determine what informa/on you would like to obtain.

Step 2: Decide who is the audience for your ques/onnaire
Step 3: Decide on data collec/on method (electronic, phone, postal)
Step 4: Decide on types of ques/ons
Step 5: Pilot the ques/onnaire on a sample of poten/al respondents and revise ques/ons if necessary
Step 6: Distribute the ques/onnaire
Step 7: Chase non-respondents
Step 8: Analyse the responses
Step 9: Present and use the findings

58
Survey or Ques<onnaire

Advantages Disadvantages

• The responses are gathered in a standardised way. • There is no way to check how truthful a respondent
• Informa/on can be collected in short period of /me is
from a large number of people. • It is quite difficult to create unambiguous ques/ons.
• Inexpensive to reach a large number of people. Ques/ons may be misinterpreted and as
consequence incorrectly completed. You shall test
• Standard ques/onnaire providers quan/fiable
your ques/onnaire on a small group of respondents
answers to a research.
first to ensure it works as you designed it, before
• Ques/onnaires allow respondents to take /me to sending it around.
consider their responses carefully without
• Low response rate, if not administered.
interferences from others, e.g. interviewer.
• Ques/onnaires are not suitable to inves/gate long,
• They permit anonymity.
complex issues.

59
Elicita<on Techniques overview

Elicita<on techniques Individual / Group Scenario Benefits

Brainstorming Individual / Group Genera/ng ideas Generate ideas in short /me.
Document Analysis Individual Current state Save /me of stakeholder, Build trust
Facilitated Workshops
Elabora/on of cross-func/onal Build trust, foster rela/onship and
(Requirements Group
requirements improve communica/on
Workshops)
Learn expecta/ons and aotude towards Get sufficient level of feedback in
Focus Group Group
Product, or service short /me.
Sensi/ve informa/on. Informa/on from
Having undivided ahen/on of the
Interviews 1:1, Small Group upper level manager.
interviewee
types - structured, Unstructured
As-Is process. Four Types -passive, ac/ve, Greater amount of unbiased,
Observa<on Individual
par/cipatory, simula/on objec/ve, real informa/on
Early feedback on working model. Opportunity to iden/fy issues, clarify
Prototyping Group
Two types: Low-fidelity, High-fidelity ques/ons early.
Collect large amount of informa/on from
Survey / Ques<onnaires Large Group Less expensive.
large group in short /me.

60
Document outputs from elicita<on ac<vi<es

You choose the means Just capture it!

• Either formally or informally

• When the elicita/on results are analyzed, the
results are documented into the deliverables

61
Elicita<on Issues and challenges

1. Stakeholders don’t say what they want

2. Conflic/ng viewpoints
3. Conflic/ng informa/on
4. Unstated or assumed stakeholder informa/on
5. No stakeholder focus
6. Stakeholders who are resistant to change
7. No stakeholder /me for elicita/on

62
Confirm Elicita<on Results

Inputs Tools and Techniques Outputs

Elicita/on prepara/on materials Document analysis Confirm elicita/on results
Unconfirmed elicita/on results Glossary
Interviews
Observa/on
Walkthroughs

63
Glossary

Descrip<on
Glossaries are used to provide a common understanding of terms that are used by stakeholders

Elements
A glossary is a list of terms in par/cular domain with defini/ons for those terms and their common
synonyms

• A term is included in the glossary when

• The term is unique to a domain
• There are mul/ple defini/ons for the term
• The defini/on implied is outside of the term’s common use.
• There is a reasonable chance of misunderstanding

64
Complete elicita<on

When you are done?

• Stakeholder Approval
• Model completed
• Successful dry run
• Objec/ve reached
• Solu/on iden/fied

65
Exec<ng processes in Analysis

Analysis

66
Analyze Requirements

• Analysis Defined - process of examining, breaking down, and synthesizing informa/on to further
understand it, complete it, and improve it.
• Thinking Ahead about Analysis
• Determining which types of models would be most beneficial
• Which techniques to choose from?
• Any exis/ng models that can be used?
• What to Analyze?
• Conduct analysis on the outputs of elicita/on ac/vi/es
• Analysis spurns on more elicita/on

67
Create and Analyze Models

Inputs Tools and Techniques Outputs

Analysis approach Context diagram Modeling elabora/on Analysis
Data dic/onary Organiza/on chart models
Confirmed
elicita/on results Data flow diagram Process flow
Requirements and Decision tree and decision table Prototype: Wireframes, Display-Ac/on-
other product Ecosystem map Response table,
informa/on En/ty rela/onship diagram Report table
Event list State table and State Diagram
Feature model Story mapping
Goal model and business System Interface table
objec/ve model Use Case Diagram
User Interface Flow

68
Model and Refine Requirements

• Descrip<on of Models - a structured representa/on of informa/on

• Purpose of Models – A picture is like a 1000 words
• Types of Models

Data models - used in a process or a system Interface models - understanding specific systems

En/ty rela/onship diagram Report table

Data flow diagram System interface table
Data dic/onary User interface flow
State table Wireframes
State diagram Display-ac/on-response

69
 Fundamentals - Why Model Requirements?

• Project Review Findings

– Are you familiar with these scenarios in your project?
• In the design phase, your team is asking the customer many questions that pertain to
requirements.

• There is significant difference between the design and code in the same release

• Coding takes more than 20% of the life cycle time

• The alternating test cycle and fix cycle in system testing crashes into one test-fix cycle

• What do you think are the root causes?

70
Fundamentals – Why Model Requirements?

• Facts:

– Software requirements are intangible – primarily a mind game!

– Business users find expressing their requirements to developer community very
challenging
– It is a dire need of the Developer and the User Community to be on the same page
before implementation
– Developer Community ought to help Stakeholders understand what developers
have understood about the problem space
– Requirements need to be of high quality – clear and complete – for project success
– Seeking clarifications during the implementation is a cause for requirement volatility

71
 Fundamentals – Why Model Requirements?

• Modeling Comes to Rescue:

– Helps developers comprehend the problem space as in the stakeholder minds
– Abstraction is a key technique to get arms around the problem space – several
techniques are used to abstract the problem
– Analysts need to be productive while engaging stakeholders to elicit the depth and
breadth of responses - various techniques help in problem analysis leading to right
questions
– Models provide multiple views of the problem space - multiple views help in:
• Eliminating inconsistencies in requirements
• Spot early the missing requirements
• Achieve Clarity on the requirements gathered
• Stakeholders understand what developers have understood

72
 Main purpose of requirement modeling
• To achieve a 3-party synch on requirements
• The stakeholders who provide requirements, the requirement elicitation team and the development team are the 3
parties involved in requirements
• All the 3 have to be on the same page as far as understanding of the requirement goes.
– Lack of this 3-party synch results in untold hours of going around in loops wasting very valuable time.
– Lack of the 3-party synch can also result in rework
• Role of project manager crucial in achieving synch
– Aware of multiple modeling techniques, need not be an expert
– Understands the level of detail required to achieve synch
– Does not go blindly by the standards and guidelines, but tailors them according to the project based on his
judgment

73
Model and Refine Requirements

Scope models - structure and organize the Process models

features, func<ons, and boundaries
Process flow
Goal and business objec/ves model
Ecosystem map Use case
Context diagram User story
Feature model
Organiza/onal chart
Use case diagram Rule models - enforces policies
Decomposi/on model Business rules catalog
Fishbone diagram
Decision tree
Interrela/onship diagram
Decision table
SWOT

74
Model and Refine Requirements

Selec<on of Models
• Methodology – Formality and depth required
• Type of Project – Processes, soqware, etc.
• Project life cycle <ming
• Categories of models needed
• Levels of abstrac<on – How much detail required?

75
Model and Refine Requirements

76
Model and Refine Requirements

Modeling Languages

77
Scope Models – Goal Model and Business Objec<ve Model

• Cover goals, business problems,

business objec/ves, success metrics,
and high-level features
• Show where the project value comes
from
• Can be created at any /me during the
project
• Provide a structure to specify business
requirements

78
Scope Models – Ecosystem Map

• Diagram that shows all the

relevant systems
• Boxes for systems and lines for
rela/onships
• Used to understand all of the
systems
• Does not contain specific
requirements about these
interfaces

79
Scope Models – Context Diagram

• Shows all of the direct system and human

interfaces to systems within a solu/on
• Shows the system under development in the
center as a circle
• Used to specify the scope of the project
• Summarizes the product scope and related
informa/on

80
 Context diagram for a cafeteria ordering system

4-81
 Context Diagram Example

Vendor AD Agency

Order
Customer IRS
AJAX Corporation
Shipment

Response

FDA Inquiry
Customer
Banks

4-82
 Examples of scope creep

• Just one more SMS to be sent to the passenger with the

details of the specific bus and driver phone number.

Make reservation Passenger

Confirm status
Confirm status
Reservation system

Email SMS

4-83
Scope Models – Context Diagram

• Level 0 Data Flow Diagram is known as context

diagram

• Nota/on used for data flow diagram

• Gane-Sarson

• Yourdon

84
Scope Models – Feature Model

• A visual representa/on of all of the features of a

solu/on .
• Can be horizontal or ver/cal.
• Level 1 (L1) features, followed by Level 2 (L2)
features
• Helpful to show how features are grouped
together
• Show sets of requirements

85
Use Cases and Scenarios

It describe how a person or system interacts with the solu/on being modelled
to achieve a goal.

Use Case Diagrams can clarify scope and provide a high-level understanding of
requirements.
Use Case descrip/ons are easily understood by stakeholders due to their
narra/ve flow.

Decisions and the business rules should not be recorded directly in use cases,
but managed separately and linked from the appropriate step.
The flexible format of use cases may result in capturing inappropriate or
unnecessary detail in the ahempt to show every step or interac/on.

86
Use Cases and Scenarios

Descrip<on
• Use Cases describe the interac/ons between the primary actor, the solu/on and any secondary actors
needed to achieve the primary actor’s goal.
Elements

• Use Case Diagram • Use Case Descrip<on

• Rela/onship • Name
• Extend – Allows inser/on of addi/onal • Goal
behavior into a use case. Used to • Actors
show alternate flow.
• Pre Condi/ons
• Include – Allows for the use case to
• Trigger
make use of func/onality present in
another use case. • Flow of Events
• Post Condi/ons

87
Use Case Diagram

88
Use Case

Use Case Element Descrip<on

Use Case Number ID to represent your use case
Applica<on What system or applica/on does this pertain to
Use Case Name The name of your use case, keep it short and sweet
Use Case Descrip<on Elaborate more on the name, in paragraph form.
Primary Actor Who is the main actor that this use case represents
Precondi<on What precondi/ons must be met before this use case can start
Trigger What event triggers this use case
The basic flow should be the events of the use case when everything is perfect; there are no
Basic Flow errors, no excep/ons. This is the "happy day scenario". The excep/ons will be handled in the
"Alternate Flows" sec/on.
Post condi<ons Condi/ons aqer execu/on of use case steps
Alternate Flows The most significant alterna/ves and excep/ons

89
Exercise – List requirements for a Vada Pav vending
machine
 Defini/ons - Actor
• Actor
– someone or something outside the system that interacts with the system”
• Can be a human, machine or other system
• Can be ac/ve or passive
• To iden/fy Actors, ask the following ques/ons:
– Which user groups require help from the system to perform their tasks?
– Which user groups are needed to execute the system's most obvious main
func/ons?
– Which user groups are required to perform secondary func/ons, such as system Actor
maintenance and administra/on?
– Will the system interact with any external hardware or soqware system?

91
 Defini/ons – Use case
• Use Case:
– A sequence of ac/ons a system performs that yields an observable result of value to a par/cular actor

– Is depicted as an oval in use case diagrams

• To iden/fy use cases, ask the following ques/ons:

– What are the primary tasks the actor wants the system to perform?
– Will the actor create, store, change, remove, or read data in the system?
– Will the actor need to inform the system about sudden, external changes?
– Does the actor need to be informed about certain occurrences in the system?
– Will the actor perform a system start-up or shutdown?

92
 Use case iden/ty
• Name proper/es:
• reflect the actor’s goal from the actor’s perspec/ve
• describe a valuable transac/on
• be general enough to cover related scenarios
• Form: ac/ve verb + object
• “Generate Usage Report”, not “Usage Report Genera/on”
• use strong verbs and specific nouns

Good Examples: Poor Examples:

• Reserve Rental Car • Enter PIN
• Print Invoice • Submit Form 37
• Register for Payroll Deduction • Process Deposit
• Check Flight Status • Manage Menus

4-93
Actors and use cases - nota/ons

Log on to website

Select items

Add to cart
Buyer

Make purchase
 Where to use usecases

• Use cases work well for:

• end-user applica/ons
• web sites
• devices with which users must interact
• services provided by one system to another
• Use cases aren’t as valuable for:
• batch processes
• computa/onally-intensive systems
• data warehousing projects
 Use cases – Traps to avoid

• Use cases that users don’t understand.

• “Use cases” that aren’t about user goals.
• Too many use cases.
• Highly complex use cases.
• Describing specific user interface elements and ac/ons.
• Failing to consider alterna/ve flows and excep/ons.
• Prematurely detailing low-priority use cases.
• Undefined or inconsistent system boundary.
• Not using other requirements models
Process Models – Process Flow

• Also called swimlane diagrams, process maps,

process diagrams, or process flow charts

• Visually depict the tasks that people perform

in their jobs

• Par/cularly useful for facilita/ng conversa/ons

during elicita/on

• Can be traced back to the process flow steps

to see if there are requirements missing

97
Rule Model – Business Rules Catalogue

Descrip<on
• Business policies and rules guide the day to day opera/on of the business and its processes, and shape
opera/onal business decisions.
• A business policy is a direc/ve concerned with broadly controlling, influencing or regula/ng the ac/ons of
an enterprise and the people in it.
• A business rule is specific testable direc/ve that serves as a criterion for guiding behaviour, shaping
judgements or making decisions.
• A business rules are wrihen in declara/ve format and separated from the processes they support.
• Complex Business rules are expressed in decision tree, decision table.

• Opera<ve Rules guides the ac/ons of people who work.

• Structural Rules determines when something is true or not.

98
Business Rules Analysis

Elements
• Defini<onal Rules
• Describes how informa/on may be derived, inferred or calculated based on informa/on available.
• Behavioural Rules
• Governs day to day ac/vi/es
• Enforced as a maher of policy
• Strictly enforced (No viola/on)
• Override by authorized person
• Override with explana/on
• No ac/ve enforcement (Guidelines)

99
Rule Models – Business Rules Catalog

• Table of business rules and related ahributes

• Are not processes or procedures but behavioral constraints
• Should be maintained in a repository
• Could lead to necessary func/onal requirements

100
Rule Models – Decision Tree

• Decision points where each branch

represents a different choice
• The far right denotes the outcome
• Used to model complex branching
logic
• Used to iden/fy and represent
business rules

101
Rule Models – Decision Table

• Tabular format where the upper

rows in the table represent the
decision points and the bohom
rows in the table represent the
outcomes
• Each outcome row is marked to
indicate which choice
combina/on is valid
• Each column of the table is a
business rule

102
 Decision tables

4-103
 Decision trees

4-104
 CRUDL matrix

4-105
Data Models – En<ty Rela<onship Diagram (ERD)

• Also called a business data diagram

• Displays the cardinality rela/onship
• Cornerstone model for a project that
has a data management component
• Traced to data flow diagrams,
ecosystem maps, data dic/onaries,
and state transi/on models

106
Data Models – En<ty Rela<onship Diagram (ERD)

• Cardinality Nota/ons
• Chen’s Database Nota/on
• Crow’s Foot Database
Nota/on
• IDEF1x Database Nota/on
• UML Database Nota/on

107
Data Models – En<ty Rela<onship Diagram (ERD)

• Cardinality Nota/ons
• Crow’s Foot Database Nota/on

108
En<ty Rela<onship (ER) Diagram

ER Diagram Symbols and Nota/ons ER Diagram with basic objects ER Diagram with en/ty having ahribute

Mul/valued Ahribute ER Diagram with composite ahribute Cardinality

Weak En/ty

109
 En<ty Rela<onship (ER) Diagram

https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning

https://www.smartdraw.com/entity-relationship-diagram/

http://www.conceptdraw.com/solution-park/diagramming-ERD

http://creately.com/blog/diagrams/er-diagrams-tutorial/

110
Data Models – Data Flow Diagrams (DFD)

• Illustrates the rela/onships between

systems, actors and data.
• Data stores show where informa/on is
conceptually stored
• Can be used to describe the
movement of data between actors and
systems
• Relate to requirements through the
business data objects and processes.

111
Data Models – Data Flow Diagrams (DFD)

• Data flow diagram uses only FOUR symbols and strict

rules for diagramming to ensure consistency and
completeness.
• A process is shown inside a circle. Process is an ac/vity
that transforms the data
• Par<es are shown as rectangles.
• Data flows through arrow
• Data stores shown as par<al rectangles. Informa/on
wai/ng to be used.
• Rule 1: Inputs (data) must either come directly from an
outside party or to be created by another process.
• Rule 2: Every process must have at least one input and
one output
• Rule 3: Every output must flow to another process,
external party or data store.
112
Data Models – Data Dic<onary

• Shows data fields and ahributes of those fields

• Common ahributes include name, descrip/on, size, and valida/on rules
• Used to specify very detailed aspects of data
• Captures very detailed requirements and their business rules

113
 Data Dic<onary

Descrip<on
• A data dic/onary is used to document standard defini/ons of data elements, their meanings and allowable values.
• A data dic/onary contains defini/ons of each data element and indicates how those elements combine into composite data
elements.
Elements
• Data Elements
• Data Dic/onary describes data elements characteris/cs in the form of defini/ons.
• Primi<ve Data Elements
• Informa/on recorded for each data element.
• Each data element has a unique name.
• The data element may also have aliases in addi/on to its unique name.
• Every data element needs to state the acceptable values for that data element.
• Composite Elements
• Built using data elements, may include sequences, repe//ons, and op/onal elements.
• Sequencing primi/ve data elements specifies that they must always occur in the same order.
• Repea/ng primi/ve data elements has them occurring more than one /me in the composite element.
• Op/onal elements are primi/ve data elements that may or may not occur as part of a composite data element.
114
Data Dic<onary

• A data dic/onary is composed of data dic/onary elements (DDEs).

• Data elements are used to integrate back-end data as input for use in a IT and business correspondence.
• A data dic/onary is an independent representa/on of metadata that describes underlying data structures and their
associated ahributes.
• A data dic/onary is created using business vocabulary. It can be mapped to one or more underlying data models.
• The data dic/onary is made up of elements of three types: Simple, Composite, and Collec/on elements.
• The ahributes of a logical data dic/onary are unlikely to change unless there are significant business changes, the
physical ahributes can change much more frequently.
• There may be different physical data dic/onaries that include the same logical data en/ty, because the data element
could be stored in mul/ple databases with different physical structures.
• Most business analysts will be crea/ng the logical data dic/onary as part of their requirements work, which would
then be converted to physical data dic/onary as part of the solu/on defini/on and design phases of an effort.

115
Data Models – State Modelling

Descrip<on
A state model describes a set of possible states for an en/ty, and the sequence of states that the en/ty can
be in and how an en/ty changes from one state to another.
• State – An en/ty has a finit number of states. It can have more than one state at a /me.
• State Transi<on – How the en/ty changes or transi/ons from one state to another state could be
determined by the steps of a process, by business rules or by informa/on content.
• State Diagram – Shows the life cycle of one en/ty, beginning when the en/ty first comes into existence
and moving through different state un/l it is discarded and no longer in use.
• State Tables – is a two dimensional matrix showing states and the transi/on between them. Each row
shows a star/ng state, the transi/on and the end state. There will be separate row for each transi/on.
End state in one row could be a start state in another row.

116
Data Models – State Table and State Diagram

• Model the valid states of an

object
• Allows for transi/ons
between states
• Help business analysts specify
the life cycle of an object in
the solu/on
• Models that stand alone and
do not require addi/onal
requirements

117
Basic State Diagram Symbols and Nota<ons

118
Interface Models – Report Table

119
Interface Models – Report Table

• Model that captures the detailed

level requirements for a single
report
• Ahributes should be specified
alongside a prototype
• Helpful to provide addi/onal
details
• Represents the actual report
requirements

120
Interface Models – System Interface Table

• Model of ahributes that

captures all of the detailed
level requirements for a
single system interface
• Includes ahributes such as
source system, target system,
volume of data passed,
security or other rules
• Detailed enough to represent
the actual interface
requirements

121
Interface Models – User Interface Flow

• Displays specific pages or screens

within a func/onal design
• Used in the solu/on defini/on stage of
a project
• Help track all of the screens that need
to be further defined
• Does not reflect individual
requirements statements

122
Interface Models – Wireframes

• Used with screen mockups

• Broken down into user interface
elements
• Helpful when there is a user interface
for a solu/on
• Contain user interface requirements
and do not need further specifica/on

123
Interface Models: Display-Ac<on-Response (DAR)

• Compa/bility. Minimize informa/on

necessary
• Consistency. Assists with human
computer interfaces
• Memory. Minimize short-term
memory
• Structure. Displays the structure of
the system
• Assists with feedback and user
workload

124
Interface Analysis

Descrip<on
An interface is a connec/on between two components or solu/ons.
Most solu/ons require one or more interfaces to exchange informa/on with other solu/on components,
organiza/onal units or business processes.

Elements
• Preparing for Iden/fica/on
• Conduct Interface Iden/fica/on needed in the future state for each stakeholder or system that interacts
with the system.
• Define Interfaces – Coverage of the interface, exchange method, message format and exchange
frequencies.

125
Reference links for visual models

• hhps://www.smartdraw.com/
• hhps://www.edrawsoq.com/flowchart/
• hhp://www.sparxsystems.com/products/index.html#desk
• hhps://www.visual-paradigm.com/whats-new/
• hhp://www.tracemodeler.com/index.html
• hhps://www.lucidchart.com/pages/tour
• hhp://www.visualusecase.com/
• hhps://www.gliffy.com/
• hhps://www.draw.io/
• hhps://products.office.com/en-us/visio/flowchart-soqware
• hhps://creately.com/diagram-products#online
• hhps://www.genmymodel.com/flowchart-soqware
• hhp://www.bridging-the-gap.com/22-visual-models-used-by-business-analysts/

126
Document the Solu<on Requirements

• Why Documenta/on is Important?

Baseline to validate the stakeholder needs Baseline defini/on of the solu/on

Primary input to the design team Basis for user manuals
Suppor/ng detail for contractual Star/ng point for the evolu/on of the
agreements solu/on

Founda/on for reusability Baseline for an audit

• Business Requirements Document

• Goals, objec/ves, and higher-level needs of the organiza/on
• Provides the ra/onale for a new project

127
Document the Solu<on Requirements

• The Solu<on Documenta<on – Various forms can be used

• Deck of user stories
• Set of use cases
• List of items on a product backlog
• Func/onal requirements specifica/on
• system or soqware requirements specifica/on

Just to name a few……

128
Document the Solu<on Requirements

• Requirements – Wrihen at different levels of detail and are associated with different requirement types

• Categoriza<on - Used to help group and structure requirements within the documenta/on
• Scope filter – in scope/out of scope/un known
• Func/onal filter - Elements not fiong into defined func/onal category are discarded
• Priori/za/on filter - which requirements stay or are removed
• Testability filter - Requirements that are not testable are filtered out.

129
Document the Solu<on Requirements

• Requirements Specifica<on – Needs to specify all circumstances, condi/ons, ac/ons, reac/ons, results,
and error condi/ons that could possibly occur in the defined solu/on
• Documen<ng Assump<ons
• Defini/on: a factor that is considered to be true, real, or certain, without proof or demonstra/on. The
business analyst iden/fies a con/ngency for each documented assump/on so there is a course of
ac/on should that assump/on turn out to be false.
• Documen<ng Constraints
• Defini/on: A limi/ng factor that affects the execu/on of a project .
• Two types: Solu/on constraints & Project constraints

130
Document the Solu<on Requirements

• Guidelines for Wri<ng

Requirements
• Condi/on
• Subject
• Impera/ve
• Ac/ve verb
• Object
• Business rule & Outcome
(op/onal)

131
Characteris<cs of High Quality Requirements

Unambiguous, Precise, Consistent, Correct, Complete, Measurable Feasible, Traceable, Testable

• Unambigous – Clarity is the key. Same interpreta/ons of the requirements by all stakeholder
• Precise – No more, No less.
• Consistent – Document one requirement only once. Consistent language.
• Correct – Accurately describe the func/onality. Two basic rule to ensure correct requirements.
• Only the product stakeholder can confirm that a requirement is correct.
• Any requirements should be confirmed by a second source.
• Complete – Include all the informa/on necessary for the solu/on team to design, build and test the
solu/on component. TBD.
• Measurable – Requirements that is not measurable cannot be tested.
• Feasible – Opera/onal, Technology, Cost effec/veness and Time feasibility
• Traceable – Requirements should be mapped back and forward.
• Testable - Requirements should be testable.
132
 Problema/c and correct requirements - 1

“The Background Task Manager should provide

status messages at regular intervals not less than
every 60 seconds.”
-Incomplete
- what status messages should be displayed?
- Ambiguous
- what does “provide” mean?
- desired /ming interval is phrased very ambiguously
- Not verifiable because of these other problems.
- Try rewri/ng this requirement.
 Beher requirements -1

“1.The Background Task Manager (BTM) shall display status

messages in a designated area of the user interface.
1.1. The BTM shall update the messages every 60 plus or
minus 10 seconds aqer background task processing
begins and shall remain visible con/nuously.
1.2. Whenever communica/on with the background task
processing is possible, the BTM shall display the
percent completed of the background task.
1.3. The BTM shall display a “done” message when the
background task is completed.
1.4. The BTM shall display an error message if the
background task has stalled.”
 How is this requirement? (2)

• “The XML editor shall switch between displaying and

• hiding non-prin/ng characters instantaneously.”
Problems?

5-135
 Problems with the requirement (2)

• “The XML editor shall switch between displaying and

• hiding non-prin/ng characters instantaneously.”
• “Instantaneously” is not feasible.
• Ambiguity: what are “non-prin/ng characters”?
• Incompleteness:
• what triggers the display change -- user or system?
• what is the scope of the display change? en/re document?
• selected text?
• Not verifiable because of the ambigui/es.
• Try rewri/ng this requirement.

5-136
 A beher requirement (2)

• “The user shall be able to toggle between displaying and hiding

all XML tags in the document being edited with the ac/va/on
of a specific triggering condi/on. The display shall change in
0.1 second or less.”

5-137
 How is this requirement? (3)

• “The XML Parser shall produce a markup error report which

allows quick resolu/on of errors when used by XML novices.”
• Problems?

5-138
 Problems with the requirement (3)
• “The XML Parser shall produce a markup error
• report which allows quick resolu/on of errors when
• used by XML novices.”
• What is an “XML novice”?
• How does the system recognize an XML novice?
• “Quick resolu/on” refers to a manual process, not a system
• opera/on.
• What goes into the markup error report?
• Try rewri/ng this requirement.

5-139
 A beher requirement (3)

“1. Aqer the XML Parser has completely parsed a file, it shall
produce an error report that contains the linenumber and text of
any XML errors found in the parsedfile and a descrip/on of each
error found.
2. If no errors are found, the parser shall not produce anerror
report.”

5-140
Define and Elaborate Requirements

Inputs Tools and Techniques Outputs

Analysis approach Business rule catalog Requirements and other product
Defini/on of ready informa/on
Analysis models
Glossary
Confirmed elicita/on results
Product backlog
Rela/onship and dependencies
Requirements management tool
Stakeholder engagement and Story elabora/on
communica/on approach
Story slicing
Use case
User Story

141
User Stories

It represents a small concise statement of func/onality or quality needed to

deliver value to a specific stakeholder

It is easily understandable by stakeholders

Can be developed through a variety of elicita/on techniques
Focuses on value to stakeholders

This conversa/onal approach can challenge the team since they do not have
all the answers and detailed specifica/on upfront
May not provide enough documenta/on to meet the need of governance, a
baseline for future work, or stakeholder expecta/ons.

142
User Stories

Descrip<on
• User Stories capture the needs of a specific stakeholder and enable teams to define features of value to a
stakeholder using short, simple documenta/on.
Elements
• Card
• Title(op/onal)
• Statement of Value
• Who (user role or persona)
• What (ac/on, behaviour or feature)
• Why (Benefit or value)
• As a <who>, I need to <what>, so that <why>
• Conversa/on
• Confirma/on (Acceptance Criteria) – Defines boundaries of a user story.

143
Principles Of User Stories – The 3 C’s

Card

User Story informa/on is lightweight. It fits onto a single index card.

Conversa<on

When the story is selected for a Sprint, further details are finalized in
conversa/ons with the Product Owner

Confirma<on

Acceptance criteria are added to the User Story, to confirm the feature
was implemented properly

144
User Story and INVEST

A user story is a tool used in Agile soqware development to capture a descrip/on of a soqware feature
from an end-user perspec/ve.
INVEST principle is applied
I = Independent,
N = Nego/able,
V = Valuable,
E = Es/mable,
S = Small,
T = Testable
INVEST

Independent:
As much as possible avoid introducing dependencies between stories (priori/za/on and planning
problems)
If dependencies can not be sorted out:
Combine dependent ones to a larger story
Find a different way to spilt the story
Nego<able:
Stories are nego/able, Not wrihen contracts that the soqware must implement
Details determined through “Conversa/on” become tests and noted on back of the Story
Valuable:
Valuable to the Users, as well as Purchasers
Best way to be Valuable – Customer writes the stories!
INVEST

Es<mable:
Developer should be able to es/mate the size of the story or amount of /me to be taken into working
code
Stories not Es/mable – Due to Lack of Domain Knowledge, Technical Knowledge or Too Big size
Small:
Stories should be small, but not too big or too small
Epics should be broken down. Smaller ones are combined.
Testable:
Passing a test means story successfully developed.
Non-testable stories show up as Non-Func/onal Requirements
Define Acceptance Criteria

Inputs Tools and Techniques Outputs

Analysis approach Behavior Driven Development Acceptance criteria
(BDD)
Analysis models
Defini/on of Done
Requirements and other product
Story elabora/on
informa/on
Solu/on evalua/on approach

148
Behavior Driven Development (BDD)

• Team begin with understanding how the use will use a product (behavior) and write tests for that
behavior.
• Construct solu/on aqer wri/ng tests
• Includes examples of real life scenarios
• Syntax to write acceptance criteria for user story, the given-when-then
• Given-when-then format ensures that the business stakeholders should consider the precondi/ons of the
user in the product, trigger, and how product should react in these condi/ons.
• Given <the precondi/on>
• when <the user does something within the product>
• then <the product reac/on>

149
Defini<on of Done (DoD)

• Series of condi/ons that the team agrees to complete before an item is considered sufficiently developed
to be accepted by the business stakeholders.
• DoD for a user story or itera/on
• DoD are wrihen early in a porfolio, program or project.
• The DoD for any user story, itera/on, release, or solu/on is usually similar across the product or porfolio
of products.
• DoD can evolve over /me.
• Examples
• Acceptance criteria are met
• Development, test completed
• Defects fixed
• Non func/onal and usability requirements are met

150
Verify Requirements

Inputs Tools and Techniques Outputs

Analysis approach INVEST Verified requirements and other
Peer review product informa/on
Business analysis organiza/onal
standards
Compliance or regulatory
standards
Requirements and other product
informa/on

151
Verify Requirements

• Verifica<on
• Verifica/on is the process of reviewing the requirements for errors and quality
• Peer desk check
• a formal or informal review of the requirements by the peers of the BA
• Purpose is to ensure compliance with organiza/onal standards
• Inspec<on
• In a predic/ve environment, this takes place prior to final approval
• The inspec/on is performed by peers who par/cipated in the crea/on and documenta/on of the
requirements
• Walkthrough
• Workshop conducted for review
• Feedback typically given during the session

152
Validate Requirements

• The Concept of Con<nual Confirma<on

• Not an ac/vity that is performed once at the end of the requirements process
• Confirma/on is not approval

• Helpful to demonstrate parts of the solu/on as it is being completed

• Break the exercise into small, self-contained units
• Requirements Walkthrough
• Intended to receive confirma/on that the requirements as stated are valid
• Think about the stated solu/on ahead of /me, beher preparing their feedback
• Keep it non-emo/onal
• Discuss with the stakeholders to ensure it’s representa/ve

153
Validate Requirements

Inputs Tools and Techniques Outputs

Acceptance criteria Delphi Validated requirements and other
Goal models and objec/ve model product informa/on
Analysis approach
Traceability matrix
Business goals and objec/ves
Walkthroughs
Requirements and other product
informa/on

154
Priori<ze Requirements and Other Product Informa<on

Inputs Tools and Techniques Outputs

Analysis approach Backlog Management Priori/zed requirements and
Goal models and objec/ve model other product informa/on
Business goals and objec/ves
Itera/on planning
Change Requests
Kanban board
Rela/onship and dependencies
Priori/ze schemes
Requirements and other product Story mapping
informa/on
Traceability matrix

155
Priori<za<on Schemes

• Simple Scheme
• Labeling of items as “Priority 1”, “Priority 2”, “Priority 3” and so on or “High”, “Medium”, “Low”
• Drawback: Business execu/ves want everything to be P1 or High priority types!
• MoSCoW:
• Popularized technique from DSDM
• Must Have: Are fundamental to system and without them system will not work
• Should Have: Features are important by defini/on and we should have them for the system to work
properly
• Could Have: Useful net addi/ons that add tangible value
• Wont Have (In this release, but Would Like): Nice to have ones
Priori<za<on Schemes

• Minimum Viable Product (MVP)

• Priori/za/on technique used to define the scope of the first release of a solu/on to customer by
iden/fying minimum set of requirements, which delivers value to the customer.
• This is used to accelerate /me to market
• Weighted Shortest Job First (WSJF)
• Formula used to calculate WSJF for each user story
• [Business Value + Time Cri/cality + (Risk Reduc/on/Opportunity Enablement)] / Effort
• Buy a Feature
• Features are priori/zed based on the money received across feature from the par/cipants
• Delphi
• Consensus building technique by taking anonymous inputs from SMEs
Priori<za<on Schemes

• Rela<ve Weigh<ng: (by Carl Weigers)

• A simple model where priori/za/on is done based upon all the factors men/oned before.
• Major factors considered: Value of a feature and Nega/ve impact that might be caused by the
absence of the feature
• Based on expert judgment made by PO & supported by team
• Ranking the score – in a scale of 1 to 9
• Benefit from having the feature,
• Penalty for not having the feature,
• Cost of producing the feature,
• Risk incurred in producing the feature
• The priority and rank determina/on formula:
(Benefit score + Penalty score) / (Cost score + Risk score)
Iden<fy and Analyze Product Risks

Inputs Tools and Techniques Outputs

Analysis approach Context diagram Product Risks Analysis
Business goals and objec/ves Ecosystem map
Elicita/on techniques
Enterprise environmental factors
Es/ma/on techniques
Product scope
Organiza/onal chart
Requirements and other product Process flow
informa/on
Product backlog
Risk burndown chart
Risk register
Root cause and opportunity
analysis
SWOT analysis

159
 Iden<fy and Analyze Product Risks

Ac<vi<es • Strategies for nega<ve risks

• Iden/fying product risks • Avoid
• Perform qualita/ve risk analysis • Transfer
• Perform quan/ta/ve risk analysis • Mi/gate
• Planning risk responses • Accept
• Implemen/ng risk responses • Strategies for posi<ve risks
• Monitoring risks • Exploit
• Enhance
• Share
• Accept
 Risk Management Steps

• Risk Iden/fica/on
Risk
iden/fica/on

• Risk Priori/za/on

• Risk response planning

Risk
monitoring
Risk Risk
and control management priori/za/on

• Risk Tracking

• Risk Control
Risk response
plan

161
 Responses – a simplis/c example
• A forest officer gets an offer of pos/ng in a /ger infested jungle with a
promo/on ahached to it
– Opportunity: Promo/on
– Risk: Tiger ahack
– Risk impact: Damage to the body because of /ger ahack
– Does not take up the pos/ng (Avoidance: no risk and opportunity is lost in this
case)
– Takes up pos/ng, but appoints personal security guard (Transference: Risk is
transferred, but benefits are also shared in the form of salary to security
guard)
– Acquires caged vehicles and gun (Mi/ga/on: reduces the probability of /ger
ahack)
– Builds medical facility inside the jungle (Acceptance: If /ger ahack happens, a
quick medical care can reduce the impact on body )
162
 Response planning – IT example
• In a fixed price systems integra/on project that requires a special equipment for
tes/ng, delay in test set up can delay the project and increase project cost
– Risk triggers: (1) Delay in procurement of test equipment (2) Delay in set up due to
configura/on mismatch issues
– Risk: Delay in test set up
– Risk impact: Schedule overrun, Cost overrun, Customer dissa/sfac/on
• Response types
– Avoidance: Keep tes/ng out of project scope; create a separate Time and Material contract
for SI tes/ng. Risk is avoided, but customer can possibly outsource tes/ng to another vendor.
– Transference: Sub-contract tes/ng with transference of reward and penal/es as well.
– Mi/ga/on: Carry out due diligence with the equipment supplier and carry out a small pilot
project ahead of actual tes/ng to ensure compa/bility of equipment and flawless test
environment setup.
– Acceptance (with Con/ngency): Keep a separate ramp up and ramp down plan for the tes/ng
phase by ramping up freshers and ramping down seniors. Implement this, just in case test set
up gets delayed. This way the impact is minimized (cost escala/on is reduced).
 Risk Burndown Chart

• Burndown charts are used to communicate

progress over /me
• Risk burndown chart is used to show risk
exposure across itera/ons
• Sum of exposure (Probability X Impact) for all
product risks is mapped for each itera/on
• Generally risk exposure decreases as itera/ons
progress.
 Risk Register

• Risk ID
• Risk descrip/on
• Date logged
• Risk owner
• Status
• Updates
• Impact
• Probability
• Risk exposure
• Trigger
• Risk response
• Risk response owner
• Workaround
 Product Risk Analysis

• Iden/fies product risks

• List of poten/al responses
• Rela/ve ranking or priority list of risks
• Symptoms and warning signs
• Risk requiring responses in the near term
• Risk requiring addi/onal analysis
• Trends in qualita/ve risk analysis results
• Total risk exposure
• Watch list of low priority risks
Assess Product Design Op<ons

Inputs Tools and Techniques Outputs

Business goals and objec/ves Affinity diagram Viable product design op/ons
Enterprise environmental factors Brainstorming
Compe//ve analysis
Priori/zed Requirements and
other product informa/on Focus groups
Product backlog
Real op/ons
Vendor assessment

167
Vendor Assessment

Descrip<on
• A vendor assessment is conducted to ensure the vendor is reliable and that the product and service
meet the organiza/ons expecta/ons and requirements.

Elements
• Knowledge and Exper/se
• Licensing and Pricing Models
• Vendor Marker Posi/on
• Terms and Condi/ons
• Vendor Experience, Reputa/on and Stability

168
Exec<ng processes in Traceability and Monitoring

Traceability and Monitoring

169
Establish Rela<onships and Dependencies

Inputs Tools and Techniques Outputs

Product Scope Feature Model Rela/onships and Dependencies
Requirements and other product Requirements Management Tool
informa/on Story Mapping
Traceability and Monitoring Story Slicing
approach Traceability Matrix

170
Rela<onships and Dependencies

• Subsets
• A requirement may be a subset of another requirement.
• Implementa<on Dependency

• Some requirements are dependent on the implementa/on of other requirements before they can be
implemented.
• Benefit or Value Dependency
• Some/mes the benefit of a requirement is unable to be realized unless another requirement is
implemented first

171
 Requirement traceability - 1

6-172
 Requirement traceability - 2

6-173
Select and Approve Requirements

Inputs Tools and Techniques Outputs

Product Scope Backlog Management Approved Requirements
Rela/onships and dependencies Collabora/ve Games
Defini/on of Ready
Stakeholder Engagement and
Communica/on Approach Delphi
Facilitated workshops
Validated requirements and other
product informa/on Force Field Analysis
Group Decision-making techniques
Itera/on planning
Priori/za/on Schemes
Requirements management tool
Story mapping

174
Force Field Analysis

175
Group Decision Making Techniques

• Autocra/c
• Delphi
• Force field analysis
• Majority
• Plurality
• Unanimity

176
Approve Requirements

• Work Authoriza<on System

• Defines the process of authorizing work.
• Include process steps, documents, tracking systems, and approval levels.
• Work Authoriza/on System is one of many Enterprise Environmental Factors (EEFs)
• Different types of approvals.
• Approval vs. signoff – Stakeholder approves and sponsor signs off
• Reviewer vs. approver - Who can review, approve may be different from project to project
• Approval authority vs. accountability - BA responsible for the requirements, PM is accountable, and the
sponsor is accountable for the en/re project
• Rejec<on of requirements – Who can reject the requirements may be different from organiza/on to
organiza/on.
• Change Control Board (CCB) and approval of changes - The ul/mate source for approving requirements,
if one is in place

177
Baselining Approved Requirements

• What is a Requirements Baseline?

• The boundary that contains all of the approved requirements for the project, project phase, itera/on,
increment, release, or any other part of a project.
• Provides a mechanism for comparison
• Degree of formality depends oon the project life cycle and organiza/onal norms.
• Rela<onship of Requirements Baseline, Product Scope, and Project Scope
• Project – work performed
• Product – features and func/ons
• Maintaining the Product Backlog
• The product owner is accountable for the product requirements

178
Approval Sessions

• Approval sessions are conducted separately from confirma/on sessions

• When signatures are sought, then the Business owner, Solu.on team, Recipient and BA

179
Resolving Requirements Related Conflicts

Conflicts are inevitable. Let’s figure out ways to get past them…
• Delphi
• Experts on the subject par/cipate in this technique anonymously
• The responses are summarized and are then re-circulated

• Mul<vo<ng
• Team decides how many items will be on the final list
• When votes are tallied, the results are posted. If consensus, the process ends

• Weighted Ranking
• op/ons are listed, ranked, and voted upon
• The op/on with the highest score wins

180
Exec<ng processes in Solu<on Evalua<on

Solu<on Evalua<on

181
Determine what to evaluate

There are number of factors to think about when iden/fying evalua/on criteria.
1. Consider the Business Goals and Objec/ves
2. Consider Key Performance Indicators (KPIs) are metrics defined by an organiza/ons execu/ve.
3. Consider Addi/onal Evalua/on Metrics and Evalua/on Acceptance Criteria
• Project Metrics as Input to the Evalua/on of the Solu/on.
• Differen/ate between solu/on and project metrics.
• Customer Metrics - Ensure both quan/ta/ve and qualita/ve metrics are used

182
When and how to validate solu<on results

• Surveys and Focus Groups

• Survey ques/ons can solicit feedback about solu/on sa/sfac/on
• Focus groups allow for individuals to offer thoughts and ideas about a topic in a group seong and to
discuss or qualify comments from other par/cipants.
• Results from Exploratory Tes<ng and User Acceptance Tes<ng (UAT)
• The results are used to determine whether or not a product, service, or solu/on is working as
intended
• Results from Day-in-the-Life (DITL) Tes<ng
• Consists of a set of use case scenarios or several user stories or func/onal requirements
• Do the features match the need specified? Yes/No

183
When and how to validate solu<on results

• Results from Integra<on Tes<ng

• Does the solu/on perform in context of other ongoing business and systems opera/ons?
• Expected vs. Actual Results for func<onality
• When acceptance criteria is defined in terms of actual usage of a solu/on.
• DITL test can be constructed from one or more func/onal acceptance criteria.
• Expected vs. Actual Results for Nonfunc<onal Requirements
• When the acceptance criteria for nonfunc/onal requirements are define quan/ta/vely within
reasonable ranges. These criteria can also serve as a basis for SLA.
• Outcome measurements and financial calcula<on of benefit.
• Some expected benefits for a project are readily /ed to factors that can be measured; others may need
to be derived or inferred.

184
Expected Vs Actual Results for func<onality

185
Outcome measurements and financial calcula<on of benefits

186
Evaluate Acceptance Results and Address Defects

Inputs Tools and Techniques Outputs

Acceptance Criteria Priori/za/on schemes Evaluated acceptance results
Actual acceptance results Root Cause Analysis
Traceability Matrix
Variance analysis

187
Evaluate Acceptance Results and Address Defects

• Comparison of Expected vs. Actual Results

• Acceptance criteria should be defined in advance

• Examine Tolerance Ranges and Exact Numbers

• Within project management, es/mated vs. actual is applied (Earned Value)
• What is the minimum acceptable value?

• Log and Address Defects

• When a defect is found during evalua/on, it should be addressed by addi/onal requirements analysis,
impact analysis, and change requests, as applicable.

188
Ques<on #1

Func.onal and Non-Func.onal Requirements are considered to be what type of requirements?

a. Business Requirements
b. Stakeholder Requirements
c. Solu/on Requirements
d. Transi/on Requirements

189
Ques<on #2

Generic benchmarking results in the weakest opportunity for improvement

a. True
b. False

190
Ques<on #3

Within Business Analysis, what is seen as being the common term for elicita.on?

a. Striving forth
b. Performing verifica/on
c. Bringing forth
d. Conduc/ng valida/on

191
Ques<on #4

Which element is not recognized as a ques.on category?

a. Closed
b. Contextual
c. Categorized
d. Open

192
Ques<on #5

Document Analysis concern itself with Organiza.onal Process Assets

a. True
b. False

193
Ques<on #6

The facilitated workshop is comprised of

a. Document Analysis
b. Root Cause Analysis
c. Persona Analysis
d. Stakeholder Analysis
e. C and D
f. None of the above

194
Ques<on #7

When comple.ng passive observa.on, when no.cing an inconsistency in the processes of customer facing
staff, should this be seen as an improvement opportunity

a. It can be a problem as customers could become confused or frustrated because of the different
approaches.
b. It is not a problem unless there is a drop in sales so it should be leq alone.
c. It can be a problem as the business rules call for consistency.
d. It is not a problem unless the customer complains.

195
Ques<on #8

You want to create something so that the intended recipient gets the idea of that of what you are trying to
demonstrate and, most importantly, see an added value in this proposi.on, most likely you will be performing.

a. Levels of abstrac/on
b. Progressive elabora/on
c. Prototyping
d. Requirements Workshop

196
Ques<on #9

You are in the final stages of your assignment and are in the process of preparing a decision-making
document for your key stakeholders. Which type of ques.on(s) would be the most effec.ve?

a. Probing ques/ons
b. Open ques/ons
c. Stakeholder ques/ons
d. Closed ques/ons

197
Ques<on #10

So when does elicita.on end?

a. Before moving onto the solu/ons phase

b. When the project is over
c. When the requirements gathering starts
d. Once the decision for a solu/on has been made

198
Answers

1. C
2. B
3. C
4. C
5. A
6. F
7. A
8. C
9. D
10.B
199
Module 6

Execu<ng Process Group

200
Module 7

Monitoring and Controlling Process Group

201
Business Analysis Knowledge Area and Process Groups

Process Group Defining and Ini<a<ng Planning Execu<ng Monitoring and Releasing
& Knowledge Aligning Process Process Process Controlling Process
Area Process Group Group Group Group Process Group Group
Needs
6 1 7
Assessment
Stakeholder
1 3 1 2 7
Engagement
Elicita<on 1 3 4
Analysis 1 8 9
Traceability
and 1 2 1 4
Monitoring
Solu<on
1 1 1 1 4
Evalua<on

8 1 7 15 3 1 35

202
Monitoring and Controlling Process Group - Knowledge Area and Processes

Knowledge Needs Stakeholder Elicita<on (0) Analysis (0) Traceability and Solu<on
Area Assessment (0) Engagement (2) Monitoring (1) Evalua<on (0)
Traceability Manage Manage Changes
and Stakeholder to Requirements
Monitoring Engagement and and Other Product
Communica/on Informa/on
Process Group
(3) Assess Business
Analysis
Performance

203
Traceability and Monitoring

The Traceability and Monitoring knowledge area includes the ac/vi/es related to managing the life cycle of
requirements.
The tasks within this knowledge area comprise the con/nuous monitoring and documen/ng of requirements
as well as the communica/on of the requirements status to stakeholders.
• Manage Stakeholder Engagement and Communica/on
• Assess Business Analysis Performance
• Manage Changes to Requirements and Other Product Informa/on

204
Traceability

• Benefits of Tracing Requirements

• Helps to ensure that each requirement adds business value
• Helps to meet customer expecta/on

• Helps to manage scope

• The Traceability Matrix
• A grid from the source to the deliverables that sa/sfy them
• Supports the goal of business value by linking to the objec/ves

205
Traceability Matrix

206
Traceability – Requirements Anributes

• Requirement ID • Owner
• Short textual descrip/on • Source
• Objec/ves • Version
• Product development stage • Date completed
• WBS • Stakeholder sa/sfac/on
• Status • Stability
• Ra/onale for inclusion • Complexity
• Priority • Acceptance criteria

207
Traceability - Advantages

Advantages
• Provides a logical order for the
requirements
• Can be started as soon as the first
requirement is defined and detailed
• Enables work to be divided up among
the team.

208
Monitoring Requirements using a traceability matrix

• Benefits of Using Traceability to Monitor Requirements

• More detailed requirements that surface are linked to the baselined requirements
• Requirements have the detail needed to build the feature or set of features
• Work products created for each approved requirement
• Scope creep is prevented

209
The Requirements Life Cycle

What possible status do we have?

1. Approving a requirement but postponing it to another project, itera/on, or project phase
2. Deferring a requirement to some unspecified future project, itera/on, or project phase
3. Replacing an approved requirements that has not been started with another requirements.
4. Cancelling an approved requirements
5. Rejec/ng a requested requirements
6. A combina/on of the others

210
Monitoring and Controlling processes in Stakeholder Engagement

Stakeholder Engagement

211
Manage Stakeholder Engagement and Communica<on

Inputs Tools and Techniques Outputs

Stakeholder engagement and Elicita/on techniques Improved stakeholder
communica/on approach engagement and communica/on
Updated stakeholder register

212
Assess Business Analysis Performance

Inputs Tools and Techniques Outputs

Business analysis plan Burndown charts Business analysis performance
Elicita/on techniques assessment
Business analysis organiza/onal
standards Process flows
Business analysis performance Retrospec/ve and lessons learned
metrics and measurement Root cause and opportunity
analysis
Business analysis work products
Variance analysis

213
Monitoring and Controlling processes in Traceability and Monitoring

Traceability and Monitoring

AN

214
Manage Changes to Requirements and Other Product Informa<on

Inputs Tools and Techniques Outputs

Approved Requirements Backlog Management Recommended changes to
Change Control tools Requirements and other product
Business Goals and Objec/ves
informa/on
Group Decision-making
Change Requests
techniques
Product Scope Impact Analysis
Rela/onship and Dependencies Requirements Management Tool
Traceability and Monitoring Traceability Matrix
approach

215
Managing changes to Requirements

Change Management as it relates to Business

Analysis
• Part of the overall change control process
• The BA takes an ac/ve role and might be asked
to determine impact.
• Every logged change should be approved,
deferred or rejected

216
Managing changes to Requirements

Change Control Tools

• Configura/on Management System (CMS)
• Ensure the product or service being built conforms to its approved requirements.
• Provides process to verify this conformance, document changes and report the status of each change.
• Includes documenta/on, a tracking process, and defined approval levels necessary for authorizing
changes
• Enables changes to one product plus its dependencies
• Allows for an easy and comprehensive access
• Version Control System (VCS)
• VCS is part of CMS
• Tracks the history of revisions
• When the requirements documenta/on is extensive, a VCS may be used.

217
Managing changes to Requirements

Impact on Project Management – Where can it be found?

• Scope Management Plan
• Schedule Management Plan
• Cost Management Plan
• Quality Management Plan
• Process Improvement Plan
• Resource Management Plan
• Procurement Management Plan
• Stakeholder Management Plan
• Communica/on Management Plan
• Schedule Baseline
• Cost Baseline
• Scope Baseline

218
Managing changes to Requirements

• Recommending a Course of Ac<on

• Change approved - BA completes documenta/on, and it’s added to the plan
• Change deferred – BA documents decision and ra/onale. Set future date reminder

• Change rejected - BA documents decision and ra/onale. No future date reminder

• More informa/on required – Yet another round of elicita/on and analysis
• Controlling Changes Related to Defects
• Raised aqer formal or informal audits
• Different process depending whether the life cycle is predic/ve or adap/ve

219
Ques<on #1

You are the business analyst for your organiza.on and you are comple.ng the manage requirements
traceability process. You are tracking the requirements to determine how the requirements are interrelated
with one another and with the actual delivery of the project scope. There are actually three reasons why the
business analyst should trace requirements. Which one of the following is not one of the three reasons why
trace requirements is useful?

a. Impact Analysis
b. Requirements Coverage
c. Requirements alloca/on
d. Quality Control

220
Ques<on #2

Impact Analysis is not concerned with a transforma.on from a current state to a future state.

a. True
b. False

221
Ques<on #3

You are the business analyst for a smaller project where there are few requirements. Management would s.ll
like you to create a method to trace the few requirements for this project. What type of matrix would be best
in this instance?

a. Requirements Structure Matrix

b. Requirements Traceability Matrix
c. Coverage Matrix
d. Requirements Trace Matrix

222
Ques<on #4

You are the business analyst for your organiza.on. Jill and Jane, two key stakeholders in the project, are in
disagreement over a requirement. What must happen in this instance before formal approval can be offered?

a. The conflict will need to be resolved through research, resolu/on, or through third-party media/on.
b. Jill and Jane will need to determine who has seniority in the company to determine which requirement
takes precedence.
c. The conflict will need to be removed from the solu/on scope un/l Jill and Jane come to a solu/on.
d. The business analyst will need to make a decision on which requirement is most appropriate.

223
Ques<on #5

The best tool for maintaining a requirements baseline would be

a. Requirements Management Plan

b. Delphi Method
c. Traceability Matrix
d. Weighted Index

224
Ques<on #6

An impact analysis is carried out would be different for adap.ve and predic.ve lifecycles.

a. True
b. False

225
Ques<on #7

Configura.on management systems include a process that verifies an intended outcome conforms to
approved requirements, along with a scheme for documen.ng any changes to the requirements

a. True
b. False

226
Ques<on #8

Which one of these elements is not fund within a traceability matrix?

a. Requirements ID
b. Short textual descrip/on
c. Objec/ons
d. WBS
e. Priority

227
Ques<on #9

When managing changes to requirements, which is a possible course of ac.on?

a. Cancel change
b. Defer change
c. Revise change
d. Implement change

228
Ques<on #10

A CMS and VCS are both used for managing requirements

a. True
b. False

229
Answers

1. D
2. B
3. B
4. A
5. C
6. A
7. A
8. C
9. B
10. B
230
Module 7

Monitoring and Controlling Process Group

231
 Thank You and Good Luck!

www.knowledgehut.com | [email protected]

232
A typical change request form
 Change control procedure
CR Status à Impact Implemente
Raised Rejected Hold analysed Accepted d
No Yes

Change
Raise change request Next release? Analyze impact
necessary? Yes No

Change request form

Decide change Implement, test and

Update plans
strategy baseline CR