In this advanced business analysis training session, you will learn Requirement Planning and Monitoring. Topics covered in this session are: • Understand requirements risk approach • Understand the team roles for the project • Be able to determine requirements activities & planning steps • Be able to estimate activities & manage the scope • Be able to manage change to requirements For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/

1. Advanced Business Analysis Training
Requirement Planning and Monitoring

2. AGENDA
● Understand requirements risk approach
● Understand the team roles for the project
● Be able to determine requirements activities & planning steps
● Be able to estimate activities & manage the scope
● Be able to manage change to requirements

3. Phase 1
3
● Requirements Planning involves
◦ Eliciting
◦ Documenting
◦ Analyzing
◦ Communicating
◦ Tracking &
◦ Verifying all the requirements that everyone
thinks should be a part of the project

4. Phase 2
4
● Requirements Plan isuseful in,
◦ Defining of requirements activitiesthat
will beperformed
◦ Requirements Plan itemsinclude

5. Phase 3 Measuring Success
5
● At the end of the project, the requirements
planning process must still continue for a
while
● The requirements planning & management
defines the resources & tasks associated
with the planning & management of
requirements gathering activities
throughout the requirements process

6. Assurance of the proper planning &
management of requirements
6
● Allnecessary stakeholders are identified &
properly represents during the
requirements gathering process
● The requirements work efforts is
coordinated with other work done on the
project
● Changes are captured correctly&
consistently

7. Requirements Planning &
Management
7
● Relationship of Requirements Planning&
Management to otherareas
● Inputs
◦ Feasibility assessment from Enterprise
Analysis
● Outputs
◦ Tools used to gather & communicate
requirements

8. Understand Team roles for the
Project
8
● It is important to the success of the project
that all people involved understand their
roles & responsibilities
● The Business Analyst will be involved in all
requirements related activities & roles
whiles the Project Manager is naturally
concerned with all the projectactivities

9. Identify & Document
Team Roles for the Project
9
● The purpose of this task is to identify &
document all team roles relating to &
involved with the requirementsrelated
project activities
● Inputs to this task will include the current
project plan other initial projectdocuments
as may be available such as such as the
project charter

10. Team Roles -1
10
● Project team roles should be identified early
in the project to help ensure timely delivery
of the project
● Typical team rolesinclude:
◦ Executive Sponsor: Overallresponsibility for
the project at the management level
◦ Business Analyst: Elicits, analyses,
documents & reviews the requirements

11. Team Roles -2
11
◦ Project Manager: manages day‐to‐day
activities of for theproject
◦ Developer: Isthe technical resource assigned
to the project
◦ Quality Assurance Analyst: Is responsible for
ensuring that the quality standards are
adhered to by the projectteam

12. Team Roles -3
12
◦ Trainer: is responsible for developing user
training curriculum materials & delivering
training to end‐user personnel
◦ Application Architect: defines the
architectural approach & high level design
for a projectsolution
◦ Data Modeler: Resolvesenterprise data
modeling issues

13. Team Roles -4
13
◦ Database Analyst (DBA): Responsible for all
technical aspects
◦ Infrastructure Analyst: Designs all the
hardware & software infrastructure &
environment needed
◦ Information Architect: Assessing theoverall
data requirements

14. Team Roles -5
14
◦ Solution Owner: Responsible for defining &
approving the projectscope
◦ End‐User: Represents the group of people in
the organization who will actually interact
directly with the softwareapplication
◦ Subject Matter Expert: Provides expertise in a
particular business functionalarea

15. Team Roles -6
15
◦ Stakeholder: Represents anyone materially
affected by the outcome ofthe project
◦ The deliverables from this task will typically
be a revised business analysis requirements
planning & management plan

16. Identify & Document Team Role
Responsibilities
16
● The purpose of this task is to identify,
document & achieve agreement on the
specific project responsibilities for all
requirements
● The primary input to this task will be the
list of roles defined in the previous task

17. Process & Elements
17
● Project team role responsibilities should be
identified early in the project to help ensure
the timely delivery of the project
deliverables

18. Common Responsibilities -1
18
● Executive Sponsor: The ultimateapprover
of the requirements
● Business Analyst: Defines, documents&
manages therequirements
● Project Manager: Must deal with
requirements through managingthe project
tasks

19. Common Responsibilities -2
19
● Developer: Involved inthe requirements
review, sign‐off & approval discussions
with theBA
● Quality Assurance analyst: should be
involved in requirements review &
approval
● Trainer: Usesthe functional requirements in
developing

20. Common Responsibilities -3
20
● Application Architect: Uses the
requirements to ensure that the
architectural approach & high‐level design
will allowthe application to meet them
● Data Modeler: they should be empowered
to assist in the review of the identified
requirements

21. Common Responsibilities -4
21
● Database Analyst: Responsible for designing &
creating database that willmeet the performance &
data requirements of theproject.
● Infrastructure Analyst: Usesthe requirements
in their designs of the infrastructure needs.
● Information Architect: Responsible for
identifying data requirements

22. Common Responsibilities – 5
22
● Solution Owner: Provides information while
gathering requirements
● End‐user: Often a source of information used in
creating the requirements
● Subject MatterExperts: Major source of
requirements information

23. Common Responsibilities – 6
23
● Stakeholders: The responsibility variesgreatly
depending on the type & level of stakeholder
● The stakeholder may be a decision‐maker
on the solutions & the success of the project

24. The RACI Matrix
24
● The RACI matrix is a powerful tool useful
to illustrate usual responsibilities of the
roles involves in planning the managing
requirements
● Responsible
● Accountable
● Consulted
● Informed

25. Identify Stakeholders -1
25
● The drivingforce behind each project
● It is an important step that should not be
overlooked or minimized

26. Identify Stakeholders -2
26
● BA will create a list of all stakeholders
associated with theproject
● Listing should include persons name, their
job title & some basic demographics

27. Techniques to Identify
Stakeholders
27
● Consult ReferenceMaterial
◦ Existing project materials are usedto identify
people associated with theproject
◦ The listing will be reviewed by project
management

28. Process to Consult Reference
Materials
28
● BA should review existing project reference
materials & create a listing of all potential
resources
● BA will update the listing with the
stakeholder’s name & contact details

29. Strengths & Weaknesses
29
● Minimum skillsare required
● Reference material may not be up dated or
completed

30. Techniques to Identify
Stakeholders
30
● Questionnaire to identified Stakeholders
◦ Based on the questionnaireresponses
◦ It is group of questions posed to elicit a
valued response
◦ The intended audience isthe stakeholder
listing

31. Process for Questionnaire to
identified Stakeholders
31
● Listing of the questions intended to identify
additional stakeholders is prepared
● Open‐endedquestions, more than a Yes‐No
response is required
● Example:
◦ Who is directly impacted by the project?
◦ What are theirroles?

32. Alternative to Questionnaire
32
● Interview: BA may choose to contact each
stakeholder to pose each question & record
each response
● Web Survey: BA may contact the
stakeholders & direct them to an internet
site specializing in managing surveys &
questionnaires

33. Key Features, Strengths &
Weaknesses
33
● Special efforts & skills are required from the
BA to prepare the questions that elicits the
desired response
● The stakeholders those are notdocumented
can be identified
● Takes time to develop the rightquestions

34. Describe the Stakeholders
34
● Stakeholder description provides the
information about each stakeholder toBA
● Stakeholders listing willbe the primary
input to the Questionnaire task

35. Process & Elements to
describe the Stakeholders
35
● Questions are designed to solicitthe
information from eachstakeholder
● Result will be the stakeholdersummary
document

36. Stakeholder Summary
Name & Job Title Project Stake Description
[The name & the job
title of description of
the duties]
The stake or
investment ofthe
stakeholder
Summarize the
stakeholder’s key
characteristics with
regard to theproject
Jatin Deo – Project
sponsor Primary end
user of projectsolution
Primary end user of
project solution
Success of the project
solutions will increase
the quality of output
Jatin’s department
Project selection
Project priority
Project charter
Jaimin Bhatt –
Executive sponsor
Meeting or executing
revenue & expense
budget for the fiscal
year
Ensures thatproject
requirements &
solutions match up
with the Enterprise
Analysis
36

37. Techniques to Describe the
Stakeholders
37
● Interview Stakeholders to solicitdescription
◦ An interview of each stakeholder will solicit
the information used to document the
stakeholder’s involvement, authority &
project impact
● The audience will be the stakeholders noted
in thelisting

38. Process to Interview Stakeholders to
Solicit Description -1
38
● Examples of the questions that will be
intended to the stakeholdersare:
◦ Whoare their customers or suppliers?
◦ What are their paper or hard copy based
processes affected by thisproject?
◦ How will the project change their business
processes?
Conti….

39. Process to Interview Stakeholders
to Solicit Description -2
39
◦ What business processes do they interface
with that are related to theproject?
◦ Where are these peoplelocated
geographically?
◦ What level of risk are they able to tolerate?
Conti….

40. Process to Interview Stakeholders
to Solicit Description -3
40
◦ What is the importance of each key project
success criteria?
◦ Who is the key person that has authority to
sign off for them? Does this person have a
back up?

41. Key Features
41
● Direct contact with the stakeholdersis
required
● Business analyst must be proficient in
various interview technologies

42. Strengths & Weaknesses
42
● Immediate response to the questionsis
solicited
● More of the time of the business analyst is
used for thistechnique

43. Categorize the Stakeholders
43
● Grouping the stakeholders intomultiple
categories uncovers thecommonalities
● Categories are based on various factors
important in theproject
● Stakeholder Summary & Listing are used to
develop & completer the categories

44. Process & Elements to
Categorize the Stakeholders
44
● Example of stakeholdercategories:
◦ Key requirement source
◦ Project Impact
◦ Number of direct endusers
◦ Number of interfacing businessprocesses

45. Define Business Analyst
Work division Strategy
45
● Systematic plan of action intended to
accomplish a specific goal
● Only one BA is assigned to a project & all
requirements activities are assignedto that
BA

46. Business Analyst
Work division Strategy
Define the
Work Division
Co-ordination
of information
among Team
Members
Knowledge
Transfer
among Team
Members
Business
Analysis
complete the
activity
Note:
Out of scope
of this section
46

47. Divide Work amongst a
Business Analyst Team
47
● Obstacles of confusion & uncertainty can be
removed
● The predecessors are therequirements
activities or requirements workplan

48. Process & Elements
48
● The activities & duration of the work effort
is reviewed by BA or Leads or Team
● BA & the stakeholders associated with the
requirement activity are the stakeholders
for the task

49. Technique 1: Business
49
Analyst Work Division
Strategy
● This is an allocation of activities according
to some distinct characteristic
● The most suitable strategy is applied to
achieve specific goals

50. Types of Business Analyst
Work Division Strategy
50
● Subject Matter Expertise
● Complexity
● Area of Interests
● Physical Limitation
● Business Analyst Availability

51. Subject Matter Expertise
51
● The BA exhibits the highest level of
expertise in performing a specialized job or
task
● This work division is based on the skill set
required

52. Complexity
52
● This work division is based on the level of
complexity of theactivities

53. Previous Work Experience
with Stakeholder
53
● This work division is based on which
business analyst has work with which
stakeholder
● The BA’s milestone is Requirements sign‐
off

54. Geography & Culture -1
54
● This work division is based on Physical
location of BA & the shared beliefs
● It will save time & money due to the long
travel time

55. Geography & Culture -2
55
● The BA work division strategy may be
based on theculture
● Share beliefs, values, customs, behavioretc
of the society

56. Area of Interest
56
● This work division strategy is based on the
area of interest of theBA

57. Physical Limitation
57
● This work division strategy is based on the
physical limitation of the BusinessAnalyst

58. Business Analyst Availability
58
● This work division strategy is based on the
availability of the Business Analyst or
commitment to theproject
● The activities assigned to business analyst
must ne within their committed tome to
project

59. Intended Audience, Process
& KeyFeatures
59
● The technique is created to obtain
consensus & understanding among the BAs
● BA or team or the lead will decide the
strategy to be used & document the
rationale
● The techniques is based on the skill set,
previous experience & environment of the
BA

60. Strengths & Weaknesses
60
● This technique is based on the team
member’s skill set
● This work division strategy does not
consider the BA’s timecommitment

61. Technique 2: Co-ordination of
Information within the Team
61
● An information platform is created for the
business analyst pertaining to business
concepts
● The BAs have the same understanding,
information or tool to successfullydeliver
compatible requirements

62. 1. Core Business
Concepts & policies
62
● The look & feel of the web application
● Methodology:
◦ The company has incorporated the ITIL for
service support & RUP for development

63. 1. Core Business
Concepts & policies
63
● Procedural Knowledge: Define & communicate
internal processes
● Document Templates: Set byeither methodology
or the organization
● Artifacts: Methodology or theorganization
requirements
● Terminology: Cheque Vs. check
● Business Documentation: newsletters, booksetc.

64. 2. Functional &
Non-functional Requirements
64
● Strong understanding of In Scope & Out of
Scope items
● Provide instructions & examples
● Consistent Approach forthe Requirement
Activity

65. 3. Project Documentation
65
● How to manage requirements issues?
◦ Strong understanding of In Scope & Out of
Scope items
◦ ApprovalProcess in Governance with
Organization’s Policy

66. Processes for Co-ordination of
Information within the Team
66
● The BA begins the process by asking the
other members of the organization,where
the organization standards, governance
policies can befound
● Key feature of this techniques is sharing the
coordinating the information

67. Strengths & Weaknesses
67
● Saves time & avoids re‐working are the
strengths
● Lack of Access & time, learning curve etc
are the weaknesses

68. Technique 3:
Knowledge Transfer
68
● Systematic Approach to capture & share the
tacit knowledge
● Knowledge transfer may be done at the
beginning, middle or at the end of the
phase

69. Technique 3:
Knowledge Transfer
69
● Examples:
◦ Information exchange
◦ Central Repository
• Mentorship: Senior & junior BAs are paired for
back‐up
● Intended audience is theBA

70. Process of Knowledge
Transfer
70
● The BA decides what type of knowledge
needs to be transferred, from whom to
whom, when etc
● Key Feature is to share & coordinate the
knowledge among the teammembers

71. Strengths & Weaknesses
71
● Benefits include:
◦ Solve problems & make better informed
decisions
◦ Avoid working in silos
● Disadvantages include:
◦ Learning curve
◦ Changing priorities

72. Define Requirements
Risk Approach
72
● The section focuses on the BA’s role in
requirements risk management
● Requirements risks & their management is
a subset of overall projectrisks

73. Typical Roles &
Responsibilities
73
● For End‐to‐end Requirements risk
management BAis responsible, whereas,
for End‐to‐end Project risks management
Project manager is responsible

74. Topics of discussion
for this section
74
● How requirements risk will be managed
throughout the project
● Examples of commonrequirements risks

75. Identify Requirements Risks
75
● Purpose of the task is to identify the list of
the risks associated witheach requirement
● Predecessors are all the requirements ata
Business or userlevel

76. Process & Elements to
Identify the Risks
76
● Each requirement is reviewed & if the risk
associated with it, will be determined by
BA
● Common risks across all the requirements
are identified

77. Common Requirements Risks
77
● Examples include:
◦ Insufficient level of user involvementin
identifying, detailed & analyzing
requirements
◦ Missing, incorrect, & confliction
requirements

78. Common Requirements Risks
78
● The requirements & their attributes are
reviewed with the key stakeholders by the
BA
● The deliverables is the list of requirement
risks, their attributes & common risks

79. Define Requirements Risk
Management Approach
79
● The purpose is to detail a requirements risk
management process
● BA defines the requirements risk
management approach

80. Process & Elements to Define
Requirements Risk Management
Approach
80
● Techniques of requirements Risk planning,
monitoring & control to manage
requirements are used
● BA is responsible for managing
requirements risk throughoutthe
requirements process

81. Technique 1:
Requirements Risk Planning
81
● The technique provides a well thought out
& methodically planed risk response
strategy to beused
● Allproject stakeholders should be involved
& aware of risk management activities

82. Process of Requirements
Risk Planning
82
● The aspects determined for each risk are:
◦ Likelihood: the likelihood that the riskwill
occur
◦ Impact: Cost, Schedule, Scopeetc
◦ Intervention Difficulty: Determine how
difficult it will be to intervene to prevent the
risk from occurring

83. Process of Requirements
Risk Planning
83
◦ Precision of Assessment: Determineshow
precise the overall assessmentis
◦ Mitigation Strategy: Determine thebest
approach to detail with therisk
◦ Action Plan: Determine actionee & what
action should beexecuted

84. Process of Requirements
Risk Planning
84
◦ Contingency Plan: Identify what event will
trigger the risk management
◦ The key feature is a risk response plan
◦ A requirement risk response plan is an
effective method to document requirements
risk assessment

85. Technique 2: Requirements
Risk Monitoring
85
● The technique providesthe current status of
each identified risk
● The BAexecutes the technique to monitor
risks systematically

86. Process of Requirements
Risk Monitoring
86
● BA performs the weekly checks the risk
status
● Risk status & observation details must be
included while risk monitoring &
documentation
● An effective method to ensure you have a
good handle on up to date risk status

87. Technique 2:
Requirement Risk Control
87
● The technique ensures that the riskis
controlled by respondingto it
● Many stakeholders are assigned to control
the specific risks

88. Process of Requirement
Risk Control
88
● The BA will perform various steps
including:
◦ Impact
◦ Mitigation Strategy
◦ Action Plan
◦ Contingency Plan
◦ Lesson Learned

89. Process of Requirement
Risk Control
89
● Keyfeature is that the technique must
include risk materialization results &
lessons learned
● This method is effective to ensure you
understand risk materializationresults

90. Determine Planning
Considerations
90
● The task will explore how the decisions
made in definition & documentation areas
may impact the requirements planning &
management
● The effective BA must be able to identify all
relevant considerations in planning these
activities

91. Identify KeyPlanning
Impact Area
91
● The purpose of this task is to identify key
planning impact areas
● Project historical records mayalso be of
great value in thistask

92. Process & Elements Identify
Key Planning Impact Area
92
● These factors can be convenientlygrouped
by type
● The BA will consider each area in turn to
determine their impact on the planning
process & the proposed requirements
management plan

93. Methodology
93
● Methodology used are SDLE, PLC
● General Project Considerations:
◦ Project Risk
◦ Re‐planning
● Deliverables will be the list relevant items
for the BA to utilize in in the process of the
requirements related activities for the
project

94. Consider
the SDLC Methodology
94
● SDLC is the overall process of designing &
developing information system
● Multiphase approach

95. Process & Elements
95
● The method in use will impact requirement
planning
● BA must be familiar with the SDLC in their
organizations

96. Process & Elements
96
● Each of the SDLC approach will define the
requirements process in differentways
● Examples of SCLE include Waterfall,
Iterative & Agile
● The major deliverables includethe selected
SDLC

97. Consider
the PLC Methodology
97
● Project Life Cycle Methodology can be
defined as all the project phases needed to
complete the project
● The SDLC phases will fit into the PLC
events

98. Process & Elements
98
● The BA must consider the phases, tasks &
subtasks defined in PLC
● Examples of PLC phases:
◦ Definition
◦ Planning
◦ Initiation

99. Process & Elements
99
◦ Execution
◦ Close‐out
● Each of these phase will broken down into
tasks & subtasks
● The selected PLC represents the major
deliverables

100. Consider Project Risk,
Expectations & Standards
100
● Purpose of the process is to remind the BA
that there are a number of project &
organization related factors
● Project risk is an element in any project
planning task

101. Consider Project Risk,
Expectations & Standards
101
● The stakeholders will have their own
expectations regarding theproject
● Organization standards forthe project &
the product may exist in a number of
organizations
● Major input to the task is the current project
plan

102. Process & Elements Consider
Project Risk, Expectations &
Standards
102
● The BA must consider the impact of the
project risk on their planning efforts for
each project on an individual basis
● The BA must have a clear understanding of
the project sponsor’s & other key
stakeholders expectations

103. Process & Elements Consider
Project Risk, Expectations &
Standards
103
● Review of existinghistorical project records
ina part of the expectations process.
● An organization may have the standards
related to the projectplanning.

104. Process & Elements Consider
Project Risk, Expectations &
Standards
104
● Stakeholders for this task are all the project
stakeholders that are impacted by the
project risk
● Modified requirements management plan is
the deliverable

105. Re-planning
105
● Can be defined as the process of modifying
the project plan in response to the events
that have occurred during the project
execution
● 2 inputs are used primarily:
◦ Current baseline requirements plan
◦ Whatever changes have been uncovered to the
existing plan

106. Process & Elements
for Re-planning
106
● The process consists of evaluation of the
impact of the proposed changes in the
project environment to determine the
impact on the base linedplan

107. Process & Elements
for Re-planning
107
● The process includes allthe stakeholders
those are involved in the baselined
requirements management plan
● Updated requirements management plan
will be the deliverable for the process of Re‐
planning

108. Consider KeyStakeholder
Needs & Location
108
● The physical location of the key stakeholder
may have influence on the requirements
planning & management effort
● The major inputs to this task are the
stakeholder list showing the identity,
location & interests of the project
stakeholders.

109. Process & Elements Consider Key
Stakeholder Needs & Location
109
● Two different types of project can be
identified regarding the location ofthe
stakeholders:
◦ Centralized
◦ Dispersed

110. Centralized
110
● All key stakeholders are located in the same
geographic area

111. Dispersed
111
● Some key stakeholders are located in
different geographic area hence more
difficult
● Another situation is, the developmentteam
is physically located in many time zones
away

112. Key Stakeholders
& Deliverables
112
● The process includes allthe stakeholders
those are involved in the baselined
requirements management plan
● Updated requirements managementplan
will be thedeliverable

113. Consider the Project Type
113
● The BA must be aware of the type of project
that is planned
● The major input to this task will be the
current project plan

114. Process & Element to
Consider the Project Type
114
● New SoftwareDevelopment
● Outsourced Development
● Software Maintenance
● Software Package Section
● Process Improvement
● Organizational Change

115. Key Stakeholders
& Deliverables
115
● The process includes allthe stakeholders
involved in the baselined requirements
management plan
● the deliverable will be updated
requirements management plan

116. Select Requirements Plan
116
● Activities undertaken to complete theend‐
to‐end requirements process include:
◦ Requirement Elicitation
◦ Requirements Analysis & Documentation
◦ Requirements communication
◦ Solution Assessment & Validation

117. Topics of Discussion
117
● What the BA needs to be able to select
requirement activities?
● A selection of all activities for the entire
requirements process
● Here we don’t include the selection of any
non‐requirement related activities

118. Determine Requirements Elicitation
stakeholders & Activities
118
● The process determine whichstakeholders
will be involved in the requirements
elicitation activities.
● The BA should satisfied all the perspectives
of the requirements are included to
minimize changes during later phases of
the project.

119. Determine Requirements Elicitation
stakeholders & Activities
119
● The methods for elicitation requirements
should align with the importance, impact,
timing, & value of the project
● The activities should make best use of the
participant’s time

120. Determine Requirements Elicitation
stakeholders & Activities
120
● Technical resources need to be involved to
support the tools used by the BA
● The key stakeholders identified & the
software development methodology

121. Process & Elements to
Determine Requirements Elicitation
stakeholders & Activities
121
● The BA will determine the best way to
gather requirements from thestakeholders
● The various techniques used are Survey,
COTS, requirements workshops etc.

122. Process & Elements to
Determine Requirements
Elicitation stakeholders & Activities
122
● The stakeholders are the keystakeholders
that have needs for theproject
● The task is completer when there is a
complete list of activities such as WBS

123. Determine Requirements Analysis
& Documentation & Activities
123
● The process determines the requirements
analysis & documentation activities that are
need to beundertaken
● The project’s time constraints & budget
should also beconsidered

124. Determine Requirements Analysis
& Documentation & Activities
124
● Including the BA’s justification for the
techniques selected is includedto select the
best the best technique to model & analyze
requirements
● The BA needs to have a good
understanding of the type ofthe project

125. Process & Elements to Determine
Requirements Analysis &
Documentation & Activities
125
● All of the stakeholder information,
requirement elicitation results & project
scope information will be reviewed by the
BA
● For a Data Warehousing project the best
requirements model would be a data model

126. Process & Elements to Determine
Requirements Analysis &
Documentation & Activities
126
● The key stakeholders & the SMEs ensure
that the modeling represent correctly the
requirements & to be implemented
● The predecessor activities have been
identified based on logical dependencies of
the activities.

127. Determine Requirements
Communication Activities
127
● The purpose of the task is to determine the
requirements communication activities
need to be undertaken & the type of
resources required to completethem
● The preceding requirements related
activities need to be successfullycompleted
the requirements elicitation & requirements
analysis & documentation

128. Process & Elements to Determine
Requirements Communication
Activities
128
● The BA reviews all of the stakeholder
information, requirements analysis results
& models
● For the project delivery team, detailedlevel
business rules with decision trees can be
packaged together in the CASE tool

129. Process & Elements to Determine
Requirements Communication
Activities
129
● The key business stakeholders & SMEs
should be involved in the review & signoff
of the requirements
● The predecessor activities have been
identified based on logical dependencies of
the activities

130. Determine Solution Assessment
& Validation Activities
130
● The BA must select the Solution Assessment
& Validation activities that best provides
the solution based onthe requirements

131. Process & Elements to Determine
Solution Assessment & Validation
Activities
131
● The BA reviews all of the stakeholder
information, requirements analysis results
& models, & the final set of requirements
documentation
● The project delivery team will be the key
stakeholder involved in the design of the
solution based onthe requirements

132. Estimate Requirements
Activities
132
● 3 basic parameters are Scope, Schedule&
Resources
● The BA make haphazard estimations of
their requirements parameters

133. Identify Milestones in the
Requirements Activities
Development & Delivery
133
● According to the PMBOK, the milestone is a
significant point inthe project
● Milestone can be used to measure the
progress & completion of the significant
phases of requirements activities

134. Process & Elements to Identify
Milestones in the Requirements
Activities Development & Delivery
134
● The BA will review the list of requirements
activities with the project sponsor & project
manager
● The artifact produced will be a listing of
milestones & associated requirements
activities

135. Define Units of Work
135
● A unit of work is a task that can’t be
decomposed further
● The BA will use the listing of requirements
activities as the basis of defining discrete
units of work & time estimate for
requirements activities

136. Process & Elements
Define Units of Work
136
● The BA will review each requirements
activities & breakdown each activity into
sub‐activities &then further into tasks
● The artifact produced will be a listing of
components & dependencies associated
with every requirementsactivities

137. Estimate Effort
per Unit of Work
137
● This task will document the resource
assigned to eachtask
● The BA will use the listing of requirements
activities & listing of documented
assumptions & risks

138. Process & Elements Estimate
effort per Unit of Work
138
● The BA will assign an available resource &
define a time estimate for each
requirements task
● The stakeholders for the task are the project
team members who will be assigned a task

139. Estimate Duration
per Unit of Work
139
● This task defines the work period in terms
of calendar days for each activity defined
● The list of activities & estimated work
efforts willbe needed to complete the task

140. Process & Elements Estimate
Duration per Unit of Work
140
● The BA will enter the beginning & ending
date for eachtask
● The BA should discus & get agreement on
estimates for the tasks with the Project
manager

141. Technique 1
141
● Techniques to Estimate Requirements
Activities UseDocumentation from Past
Requirements Activities to Estimates
Duration:
◦ The technique will provide the BA with data to
support estimating duration for the task defined

142. Process to use documentation from
Past Requirements Activities to
Estimates Duration
142
● Techniques to Estimate Requirements
Activities UseDocumentation from :
◦ The BA will review the documentation &
artifacts created from other recent projectswithin
the organization

143. Alternatives
143
● Interview
● Duration Estimation fromother projects
● Strengths & Weaknesses
◦ The objective baseline for the BA to use in
estimating duration is provided using the actual
duration for the similar tasks from recent projects
◦ The information will be incomplete or inaccurate

144. Identify Assumptions
144
● The BA will identify & document
assumptions that affect therequirement
planning & management activities

145. Process & Elements to
Identify Assumptions
145
● The BA should review all project
documentation &prepare a list of
assumptions identified
● The stakeholders for this task are Project
Sponsor, Project Manager & the Project
Team

146. Identify Risks
146
● The process will identify & list the risks
associated with requirements planning&
management

147. Process & Elements to
Identify Risks
147
● Some ways to reduce or avoid Risks
include:
◦ Complete tasks simultaneously ratherthan
sequentially
◦ Identify links betweentask
◦ Add resources to critical activities

148. Modify the
Requirements Plan
148
● When estimates assigned to project, tasks
become inaccurate because of changes to
project scope
● The project plan & the current project status
are the predecessors to thistask

149. Process & Elements to Modify
the Requirements Plan
150
● The BA should consider the options other
than modifying taskaspects
● The revised plan along with the
documentation nothing the purpose for the
change will be the deliverable for the task

150. Manage Requirements Scope
150
● The process relates to managing the list of
requirements of the system development
component

151. Establish Requirements Baseline
151
● Baseline is a line or standard by which the
changes to requirements arecompared
● If the list of requirements is not baselined
then it will be very challenging to the BA to
manage the requirements scope

152. Process & Elements to Establish
Requirements Baseline
152
● The BA takes a snapshot of list of
requirements
● All the stakeholders listed in Identify
Stakeholders task

153. Structure Requirements
for Traceability
153
● Requirements traceability assists in
managing changes to the requirementsthat
will occur after the requirements are
baselined

154. Structure Requirements
for Traceability
154
● Project Benefits includes:
● Traceability aids:
◦ Scope Management
◦ Change ImpactAnalysis
◦ Risk Based Testing
● The process supports the ability to trace a
requirement through the developmentlife
cycle

155. Structure Requirements
for Traceability
155
● Traceability Supports the followinggoals:
◦ Links downstream work products to the purpose
for which they werecreated
◦ Facilitates the requirements changecontrol
process

156. Types of Traceability
Information
156
● Source
● Rationale
● Requirements
● Design or test
● Interface

157. Process & Elements to Structure
Requirements for Traceability
157
● Many types of tools can be used to create
product & services
● The user & stakeholder needs documented
in a business case with high‐level product
description will drive all lower
requirements & their dependent
deliverables

158. Model Requirements
Traceability
Business
Requirements
Document
Test case
Design
Artifact
Supplemental
Requirements
Test case
Traces
User Needs
Traces
High-Level Product
Description
Design &
Construction
Traces
158

159. Several techniques
used in Traceability task
159
● Clear numbering scheme
● Unambiguous requirementsstatements
● Document instruction set forproject
traceability requirements

160. Traceability Matrix
160
● This relates one set of elements to another
set
● Analysis can be conducted to determine is
there is any missingconnections

161. Traceability Matrix
161
● If a predecessor has too may successors
then it may becomplex
● Project can use matrixes to describe any key
relationship between the work products

162. Identify Impacts to External Systems
&/or Other Areas of the Project
162
● The process insures that the work is not
authorized for the items that are outside the
baselined list ofrequirements
● The requirements Traceability Matrix,
interfaces column is the predecessor to this
task

163. Process & Elements to Identify
Impacts to External Systems &/or
Other Areas of the Project
163
● The BA identifies any modified, added or
removed Requirements having information
in the Interfaces column in the matrix
● BA communicates the changes to the
stakeholders

164. Process & Elements to Identify
Impacts to External Systems &/or
Other Areas of the Project
164
● The stakeholders identified inthe Source
Column
● Executive Sponsor
● Updated Requirements TraceabilityMatrix
will be the deliverable forthe task

165. Identify Scope Change Resulting
from Requirement Change
165
● This is the process of controlling changes
● Scope changes stem fromthe following
types of the requirementschanges:
◦ New
◦ Modifications of requirements
◦ De‐scoping

166. Process & Elements to Identify
Scope Change Resulting from
Requirement Change
166
● If and when a requirement has changed, the
BA determines the impact by updating the
Requirement Traceability Matrix
● The BA determines any gap due to the
requirement change

167. Process & Elements to Identify
Scope Change Resulting from
Requirement Change
167
● Disposition based on the results as to when
it will bedelivered
● New baseline for the List of Requirements
and the updated RequirementsTraceability
Matrix is the Deliverable for the Task

168. Maintain Scope Approval
168
● As the project progresses, it is more difficult
andcostly to repair requirements errors

169. Process & Elements to
Maintain Scope Approval
169
● Once the approval process has been
completed, the BAbaseline the updated list
of requirements and update the
Requirements Traceability Matrix
● All the stakeholders listed in Identify
Stakeholders that are affected by the
requirements changes

170. Measure & Report on
Requirements Activity
170
● It is suggested from the high failure rate of
many project that many to do not
effectively keep track of metrics of their
teams and products

171. Measure & Report on
Requirements Activity
171
● Metric is a quantitative measure of a
process or aproduct
● Example of questionsinclude:
◦ Are we onschedule?
◦ What is the quality of the product?

172. Measure & Report on
Requirements Activity
172
● Every project has a project life cycle
regardless of the products created in it
● Kind ofmetrics:
◦ Project metrics
◦ Product metrics

173. Measure & Report on
Requirements Activity
173
● Metrics collection and analysis must be
regularly monitored andmeasured
● It is important to the success of the project
that all key stakeholders involved,
understand the metrics to beused

174. Measure & Report on
Requirements Activity
174
● On some projects the primary metrics may
be the number of defects that are found and
fixed in theproduct
● Three types of tasks for both product and
project related metric are theIdentification,
Collection and Reporting

175. Measure & Report on
Requirements Activity
175
● Steps for BA
◦ Determine relevant metrics for therequirements
activities
◦ Determine howthe metrics will be collected,
analyzed, documented and communicated

176. Determine the
Project Metrics
176
● The purpose of this task identify and
document all project metrics that will be
used inthe requirements related project
activities
● Inputs to the task will include the current
project plan

177. Process & Elements to
Determine the Project Metrics
177
● Many organizations may have standards
applicable to defining project metrics for
any type ofproject
● The deliverable from this task will include
the descriptive list of all the currently
identified project metrics for the specific
project

178. Determine the
Product Metrics
178
● It is part of the job of Business Analyst to
elicit and identify the effective product
metrics during thistask
● The BA must work closely with the Project
Manager to identify effective product
metrics for each particularproject

179. Determine the
Product Metrics
179
● Some of the metrics may also be collected
and reported at specific points of the project
● The detailed product requirements will be
used as the major input to this task

180. Process & Elements to
Determine the Product Metrics
180
● Specific reports content and formats may
also be determined at this point but will be
done in latertask
● An example of a useful metric might be the
rate at which the development team is
finding and fixing product defects

181. Process & Elements to
Determine the Product Metrics
181
● Suggestions for initiating a product metrics
program include thefollowing:
◦ Select a small set of metrics initially and add to
carefully as needed
◦ Explanation of the metricsselected to the team is
critical
● Stakeholders include executive sponsor,
project manager and project teammembers

182. Collect Project Metrics
182
● The task will enable the BS to collect the
identified project metrics

183. Process & Element to
Collect Project Metrics
183
● The task is completed by all team members
● The list of the identified project metrics
with any current values and the updated
database for storage of them will be the
deliverables for this task

184. Collect Product Metrics
184
● The purpose of this task is to collect the
specific product metrics identified for all
requirements related tasks

185. Process & Elements to
Collect Product Metrics
185
● Product metrics must be collected with as
little effort and impact aspossible
● The list of the identified product metrics
with any current values and the updated
database for storage of them will be the
deliverables for this task

186. Reporting Product Metrics
186
● The task will enable the BA to report the
identified andagreed to product metrics
● The primary input to this task will be the
product metrics collected andthe updated
of up‐to‐date metrics

187. Process & Elements for
Reporting Product Metrics
187
● Product metrics must be reported to the
appropriate stakeholders
● The BA must remember that “Trend
Analysis” is often a key capability in
metrics reporting and designthe reporting
capability accordingly

188. Reporting Project Metrics
188
● Project status reports are most often used to
report onthe status of the project metrics
● Five primarycriteria are Time, Cost,
Resources, Features, Quality

189. Process & Elements for
Reporting Project Metrics
189
● Project metrics mustbe reported to the
appropriate stakeholders
● The key task of the BA is to identify the
optimum reporting periods for he different
levels of project status information

190. Process & Elements for
Reporting Project Metrics
190
● Stakeholders for this task are all the
stakeholders involved in the input for
project metrics
● The deliverables will be the series of
defined and ad‐hoc reportingcapabilities
utilizing the identified projectmetrics

191. Manage Requirement Change
191
● Plan Requirement Change
● Understand the changes toRequirements
◦ Task 1: Identify issues/changes
◦ Task 2: Participate in impactanalysis

192. Manage Requirement Change
192
● Document the changes torequirements
◦ Task 1: Create Formal ChangeRequest
◦ Task 2: Create Formal ChangeRequest
◦ Task 3: Define linksto other requirements

193. Manage Requirement Change
193
● Analyze change requests
◦ Task 1: Conduct fact‐finding to obtain a greater
understanding of the requirements change,
operational context and potentialissues
◦ Task 2: Categorize/prioritize requirements

194. Manage Requirement Change
194
● Analyze change requests
◦ Task 3: Submit changesfor approval

195. Key Points
195
● The requirements planning & management defines
the resources & tasks associated with the planning
& management of requirements gathering
activities throughout the requirements process
● The requirements planning & management
includes ten tasks the BA will define and manage
through the requirements gathering process
● The BA should identify, understand and document
all needed teamroles

196. Key Points
196
● The purpose of, Identify & Document Team Roles
task involves the BA in identifying and
documenting all teamroles
● Each of the roles defined may share the
responsibility in the activities related to
requirements
● Project Stakeholders are the deriving force behind
each project
● Stakeholders descriptions provide the BA with
information about each Stakeholder that is
important to the project

197. Key Points
197
● Grouping stakeholders into multiplecategories
uncovers the commonalities
● The business analysis work division strategy is a
systematic plan of action intended to accomplish a
specific goal
● Requirements risks and their management is a
subset of overall project risks and their
management
● Identifying, Managing, Planning, Monitoring,
Controlling Requirements risks is job of the BA
● The BA will select a complete set of requirements
activities

198. Key Points
198
● Managing requirements scope relates to managing
the list of the requirements of system development
component
● Requirement traceability assists in managing
changes to the requirements that will occur after
the requirements are baselined

199. Key Points
199
● The purposeof, Determine the Project Metrics, task
identify and document all project metrics that will
be used in the requirements related project
activities
● Determining effective product metrics demandsa
detailed and disciplined process
● Manage requirements change, understand the
changes to requirements, document the changes to
the requirements etc are the tasks of the BA in the
Requirements Planning and Managing

200. Page 200Classification: Restricted
THANKYOU!