In this presentation, we will understand about team roles for project, how to determine requirements activities and planning steps and understanding requirements risk approach. We will also discuss about identifying stakeholders, defining business analyst work division strategy, core business concepts, risk control, various related documentations and procedure of collecting product metrics.
To know more about Welingkar School’s Distance Learning Program and courses offered, visit:
http://www.welingkaronline.org/distance-learning/online-mba.html
3. Phase 1
Requirements Planning involves
◦ Eliciting
◦ Documenting
◦ Analyzing
◦ Communicating
◦ Tracking &
◦ Verifying all the requirements that every one
thinks should be a part of the project
3
5. Phase 3 Measuring Success
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
5
6. Assurance of the proper planning &
management of requirements
All necessary 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
6
7. Requirements Planning &
Management
Relationship of Requirements Planning &
Management to other areas
Inputs
◦ Feasibility assessment from Enterprise
Analysis
Outputs
◦ Tools used to gather & communicate
requirements
7
8. Understand Team roles for the
Project
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 project activities
8
9. Identify & Document
Team Roles for the Project
The purpose of this task is to identify &
document all team roles relating to &
involved with the requirements related
project activities
Inputs to this task will include the current
project plan other initial project documents
as may be available such as such as the
project charter
9
10. Team Roles - 1
Project team roles should be identified early
in the project to help ensure timely delivery
of the project
Typical team roles include:
◦ Executive Sponsor: Overall responsibility for
the project at the management level
◦ Business Analyst: Elicits, analyses,
documents & reviews the requirements
10
11. Team Roles - 2
◦ Project Manager: manages day‐to‐day
activities of for the project
◦ Developer: Is the technical resource assigned
to the project
◦ Quality Assurance Analyst: Is responsible for
ensuring that the quality standards are
adhered to by the project team
11
12. Team Roles -3
◦ 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 project solution
◦ Data Modeler: Resolves enterprise data
modeling issues
12
13. Team Roles -4
◦ Database Analyst (DBA): Responsible for all
technical aspects
◦ Infrastructure Analyst: Designs all the
hardware & software infrastructure &
environment needed
◦ Information Architect: Assessing the overall
data requirements
13
14. Team Roles - 5
◦ Solution Owner: Responsible for defining &
approving the project scope
◦ End‐User: Represents the group of people in
the organization who will actually interact
directly with the software application
◦ Subject Matter Expert: Provides expertise in a
particular business functional area
14
15. Team Roles - 6
◦ Stakeholder: Represents anyone materially
affected by the outcome of the project
◦ The deliverables from this task will typically
be a revised business analysis requirements
planning & management plan
15
16. Identify & Document Team Role
Responsibilities
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
16
17. Process & Elements
Project team role responsibilities should be
identified early in the project to help ensure
the timely delivery of the project
deliverables
17
18. Common Responsibilities - 1
Executive Sponsor: The ultimate approver
of the requirements
Business Analyst: Defines, documents &
manages the requirements
Project Manager: Must deal with
requirements through managing the project
tasks
18
19. Common Responsibilities - 2
Developer: Involved in the requirements
review, sign‐off & approval discussions
with the BA
Quality Assurance analyst: should be
involved in requirements review &
approval
Trainer: Uses the functional requirements in
developing
19
20. Common Responsibilities - 3
Application Architect: Uses the
requirements to ensure that the
architectural approach & high‐level design
will allow the application to meet them
Data Modeler: they should be empowered
to assist in the review of the identified
requirements
20
21. Common Responsibilities - 4
Database Analyst: Responsible for designing &
creating database that will meet the performance &
data requirements of the project.
Infrastructure Analyst: Uses the requirements
in their designs of the infrastructure needs.
Information Architect: Responsible for
identifying data requirements
21
22. Common Responsibilities – 5
Solution Owner: Provides information while
gathering requirements
End‐user: Often a source of information used in
creating the requirements
Subject Matter Experts: Major source of
requirements information
22
23. Common Responsibilities – 6
Stakeholders: The responsibility varies greatly
depending on the type & level of stakeholder
The stakeholder may be a decision‐maker
on the solutions & the success of the project
23
24. The RACI Matrix
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
24
25. Identify Stakeholders - 1
The driving force behind each project
It is an important step that should not be
overlooked or minimized
25
26. Identify Stakeholders - 2
BA will create a list of all stakeholders
associated with the project
Listing should include persons name, their
job title & some basic demographics
26
27. Techniques to Identify
Stakeholders
Consult Reference Material
◦ Existing project materials are used to identify
people associated with the project
◦ The listing will be reviewed by project
management
27
28. Process to Consult Reference
Materials
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
28
29. Strengths & Weaknesses
Minimum skills are required
Reference material may not be up dated or
completed
29
30. Techniques to Identify
Stakeholders
Questionnaire to identified Stakeholders
◦ Based on the questionnaire responses
◦ It is group of questions posed to elicit a
valued response
◦ The intended audience is the stakeholder
listing
30
31. Process for Questionnaire to
identified Stakeholders
Listing of the questions intended to identify
additional stakeholders is prepared
Open‐ended questions, more than a Yes‐No
response is required
Example:
◦ Who is directly impacted by the project?
◦ What are their roles?
31
32. Alternative to Questionnaire
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
32
33. Key Features, Strengths &
Weaknesses
Special efforts & skills are required from the
BA to prepare the questions that elicits the
desired response
The stakeholders those are not documented
can be identified
Takes time to develop the right questions
33
34. Describe the Stakeholders
Stakeholder description provides the
information about each stakeholder to BA
Stakeholders listing will be the primary
input to the Questionnaire task
34
35. Process & Elements to
describe the Stakeholders
Questions are designed to solicit the
information from each stakeholder
Result will be the stakeholder summary
document
35
36. Stakeholder Summary
Name & Job Title Project Stake Description
[The name & the job The stake or Summarize the
title of description of investment of the stakeholder’s key
the duties] stakeholder characteristics with
regard to the project
Jatin Deo – Project Primary end user of Project selection
sponsor Primary end project solution Project priority
user of project solution Success of the project Project charter
solutions will increase
the quality of output
Jatin’s department
Jaimin Bhatt – Meeting or executing Ensures that project
Executive sponsor revenue & expense requirements &
budget for the fiscal solutions match up
year with the Enterprise
Analysis
36
37. Techniques to Describe the
Stakeholders
Interview Stakeholders to solicit description
◦ 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 the listing
37
38. Process to Interview Stakeholders to
Solicit Description - 1
Examples of the questions that will be
intended to the stakeholders are:
◦ Who are their customers or suppliers?
◦ What are their paper or hard copy based
processes affected by this project?
◦ How will the project change their business
processes?
Conti….
38
39. Process to Interview Stakeholders
to Solicit Description - 2
◦ What business processes do they interface
with that are related to the project?
◦ Where are these people located
geographically?
◦ What level of risk are they able to tolerate?
Conti….
39
40. Process to Interview Stakeholders
to Solicit Description - 3
◦ 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?
40
42. Strengths & Weaknesses
Immediate response to the questions is
solicited
More of the time of the business analyst is
used for this technique
42
43. Categorize the Stakeholders
Grouping the stakeholders into multiple
categories uncovers the commonalities
Categories are based on various factors
important in the project
Stakeholder Summary & Listing are used to
develop & completer the categories
43
44. Process & Elements to
Categorize the Stakeholders
Example of stakeholder categories:
◦ Key requirement source
◦ Project Impact
◦ Number of direct end users
◦ Number of interfacing business processes
44
45. Stakeholder Classification
Stake holder classification matrix will be the
result of the categorizing the stakeholders
Example:
Stakeholder Key Number of
State/country
Name Stakeholder? end‐users
Stakeholder 1 Gujarat, India Yes 10
Stakeholder 2 California, USA No 35
Stakeholder 3 Ontario, CA Yes 80
Stakeholder 4 Maharashtra, India No 225
45
46. Define Business Analyst
Work division Strategy
Systematic plan of action intended to
accomplish a specific goal
Only one BA is assigned to a project & all
requirements activities are assigned to that
BA
46
47. Business Analyst
Work division Strategy
Co-ordination
Business Knowledge
of information
Define the Analysis Transfer
among Team
Work Division complete the among Team
Members
activity Members
Note:
Out of scope
of this section
47
48. Divide Work amongst a
Business Analyst Team
Obstacles of confusion & uncertainty can be
removed
The predecessors are the requirements
activities or requirements work plan
48
49. Process & Elements
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
50. Technique 1: Business
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
51. Types of Business Analyst
Work Division Strategy
Subject Matter Expertise
Complexity
Area of Interests
Physical Limitation
Business Analyst Availability
51
52. Subject Matter Expertise
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
54. Previous Work Experience
with Stakeholder
This work division is based on which
business analyst has work with which
stakeholder
The BA’s milestone is Requirements sign‐
off
54
55. Geography & Culture - 1
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
56. Geography & Culture - 2
The BA work division strategy may be
based on the culture
Share beliefs, values, customs, behavior etc
of the society
56
57. Area of Interest
This work division strategy is based on the
area of interest of the BA
57
59. Business Analyst Availability
This work division strategy is based on the
availability of the Business Analyst or
commitment to the project
The activities assigned to business analyst
must ne within their committed tome to
project
59
60. Intended Audience, Process
& Key Features
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
61. Strengths & Weaknesses
This technique is based on the team
member’s skill set
This work division strategy does not
consider the BA’s time commitment
61
62. Technique 2: Co-ordination of
Information within the Team
An information platform is created for the
business analyst pertaining to business
concepts
The BAs have the same understanding,
information or tool to successfully deliver
compatible requirements
62
63. 1. Core Business
Concepts & policies
The look & feel of the web application
Methodology:
◦ The company has incorporated the ITIL for
service support & RUP for development
63
64. 1. Core Business
Concepts & policies
Procedural Knowledge: Define & communicate
internal processes
Document Templates: Set by either methodology
or the organization
Artifacts: Methodology or the organization
requirements
Terminology: Cheque Vs. check
Business Documentation: newsletters, books etc.
64
65. 2. Functional &
Non-functional Requirements
Strong understanding of In Scope & Out of
Scope items
Provide instructions & examples
Consistent Approach for the Requirement
Activity
65
66. 3. Project Documentation
How to manage requirements issues?
◦ Strong understanding of In Scope & Out of
Scope items
◦ Approval Process in Governance with
Organization’s Policy
66
67. Processes for Co-ordination of
Information within the Team
The BA begins the process by asking the
other members of the organization, where
the organization standards, governance
policies can be found
Key feature of this techniques is sharing the
coordinating the information
67
68. Strengths & Weaknesses
Saves time & avoids re‐working are the
strengths
Lack of Access & time, learning curve etc
are the weaknesses
68
69. Technique 3:
Knowledge Transfer
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
70. Technique 3:
Knowledge Transfer
Examples:
◦ Information exchange
◦ Central Repository
Mentorship: Senior & junior BAs are paired for
back‐up
Intended audience is the BA
70
71. Process of Knowledge
Transfer
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 team members
71
72. Strengths & Weaknesses
Benefits include:
◦ Solve problems & make better informed
decisions
◦ Avoid working in silos
Disadvantages include:
◦ Learning curve
◦ Changing priorities
72
73. Define Requirements
Risk Approach
The section focuses on the BA’s role in
requirements risk management
Requirements risks & their management is
a subset of overall project risks
73
74. Typical Roles &
Responsibilities
For End‐to‐end Requirements risk
management BA is responsible, whereas,
for End‐to‐end Project risks management
Project manager is responsible
74
75. Topics of discussion
for this section
How requirements risk will be managed
throughout the project
Examples of common requirements risks
75
76. Identify Requirements Risks
Purpose of the task is to identify the list of
the risks associated with each requirement
Predecessors are all the requirements at a
Business or user level
76
77. Process & Elements to
Identify the Risks
Each requirement is reviewed & if the risk
associated with it, will be determined by
BA
Common risks across all the requirements
are identified
77
78. Common Requirements Risks
Examples include:
◦ Insufficient level of user involvement in
identifying, detailed & analyzing
requirements
◦ Missing, incorrect, & confliction
requirements
78
79. Common Requirements Risks
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
80. Define Requirements Risk
Management Approach
The purpose is to detail a requirements risk
management process
BA defines the requirements risk
management approach
80
81. Process & Elements to Define
Requirements Risk Management
Approach
Techniques of requirements Risk planning,
monitoring & control to manage
requirements are used
BA is responsible for managing
requirements risk throughout the
requirements process
81
82. Technique 1:
Requirements Risk Planning
The technique provides a well thought out
& methodically planed risk response
strategy to be used
All project stakeholders should be involved
& aware of risk management activities
82
83. Process of Requirements
Risk Planning
The aspects determined for each risk are:
◦ Likelihood: the likelihood that the risk will
occur
◦ Impact: Cost, Schedule, Scope etc
◦ Intervention Difficulty: Determine how
difficult it will be to intervene to prevent the
risk from occurring
83
84. Process of Requirements
Risk Planning
◦ Precision of Assessment: Determines how
precise the overall assessment is
◦ Mitigation Strategy: Determine the best
approach to detail with the risk
◦ Action Plan: Determine actionee & what
action should be executed
84
85. Process of Requirements
Risk Planning
◦ 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
86. Technique 2: Requirements
Risk Monitoring
The technique provides the current status of
each identified risk
The BA executes the technique to monitor
risks systematically
86
87. Process of Requirements
Risk Monitoring
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
88. Technique 2:
Requirement Risk Control
The technique ensures that the risk is
controlled by responding to it
Many stakeholders are assigned to control
the specific risks
88
89. Process of Requirement
Risk Control
The BA will perform various steps
including:
◦ Impact
◦ Mitigation Strategy
◦ Action Plan
◦ Contingency Plan
◦ Lesson Learned
89
90. Process of Requirement
Risk Control
Key feature is that the technique must
include risk materialization results &
lessons learned
This method is effective to ensure you
understand risk materialization results
90
92. Identify Key Planning
Impact Area
The purpose of this task is to identify key
planning impact areas
Project historical records may also be of
great value in this task
92
93. Process & Elements Identify
Key Planning Impact Area
These factors can be conveniently grouped
by type
The BA will consider each area in turn to
determine their impact on the planning
process & the proposed requirements
management plan
93
95. Consider
the SDLC Methodology
SDLC is the overall process of designing &
developing information system
Multiphase approach
95
96. Process & Elements
The method in use will impact requirement
planning
BA must be familiar with the SDLC in their
organizations
96
97. Process & Elements
Each of the SDLC approach will define the
requirements process in different ways
Examples of SCLE include Waterfall,
Iterative & Agile
The major deliverables include the selected
SDLC
97
98. Consider
the PLC Methodology
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
99. Process & Elements
The BA must consider the phases, tasks &
subtasks defined in PLC
Examples of PLC phases:
◦ Definition
◦ Planning
◦ Initiation
99
100. Process & Elements
◦ Execution
◦ Close‐out
Each of these phase will broken down into
tasks & subtasks
The selected PLC represents the major
deliverables
100
101. Consider Project Risk,
Expectations & Standards
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
102. Consider Project Risk,
Expectations & Standards
The stakeholders will have their own
expectations regarding the project
Organization standards for the project &
the product may exist in a number of
organizations
Major input to the task is the current project
plan
102
103. Process & Elements Consider
Project Risk, Expectations &
Standards
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
104. Process & Elements Consider
Project Risk, Expectations &
Standards
Review of existing historical project records
in a part of the expectations process.
An organization may have the standards
related to the project planning.
104
105. Process & Elements Consider
Project Risk, Expectations &
Standards
Stakeholders for this task are all the project
stakeholders that are impacted by the
project risk
Modified requirements management plan is
the deliverable
105
107. Process & Elements
for Re-planning
The process consists of evaluation of the
impact of the proposed changes in the
project environment to determine the
impact on the base lined plan
107
108. Process & Elements
for Re-planning
The process includes all the 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
109. Consider Key Stakeholder
Needs & Location
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
110. Process & Elements Consider Key
Stakeholder Needs & Location
Two different types of project can be
identified regarding the location of the
stakeholders:
◦ Centralized
◦ Dispersed
110
113. Key Stakeholders
& Deliverables
The process includes all the stakeholders
those are involved in the baselined
requirements management plan
Updated requirements management plan
will be the deliverable
113
114. Consider the Project Type
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
115. Process & Element to
Consider the Project Type
New Software Development
Outsourced Development
Software Maintenance
Software Package Section
Process Improvement
Organizational Change
115
116. Key Stakeholders
& Deliverables
The process includes all the stakeholders
involved in the baselined requirements
management plan
the deliverable will be updated
requirements management plan
116
117. Select Requirements Plan
Activities undertaken to complete the end‐
to‐end requirements process include:
◦ Requirement Elicitation
◦ Requirements Analysis & Documentation
◦ Requirements communication
◦ Solution Assessment & Validation
117
118. Topics of Discussion
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
119. Determine Requirements Elicitation
stakeholders & Activities
The process determine which stakeholders
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
120. Determine Requirements Elicitation
stakeholders & Activities
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
121. Determine Requirements Elicitation
stakeholders & Activities
Technical resources need to be involved to
support the tools used by the BA
The key stakeholders identified & the
software development methodology
121
122. Process & Elements to
Determine Requirements Elicitation
stakeholders & Activities
The BA will determine the best way to
gather requirements from the stakeholders
The various techniques used are Survey,
COTS, requirements workshops etc.
122
123. Process & Elements to
Determine Requirements
Elicitation stakeholders & Activities
The stakeholders are the key stakeholders
that have needs for the project
The task is completer when there is a
complete list of activities such as WBS
123
124. Determine Requirements Analysis
& Documentation & Activities
The process determines the requirements
analysis & documentation activities that are
need to be undertaken
The project’s time constraints & budget
should also be considered
124
125. Determine Requirements Analysis
& Documentation & Activities
Including the BA’s justification for the
techniques selected is included to select the
best the best technique to model & analyze
requirements
The BA needs to have a good
understanding of the type of the project
125
126. Process & Elements to Determine
Requirements Analysis &
Documentation & Activities
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
127. Process & Elements to Determine
Requirements Analysis &
Documentation & Activities
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
128. Determine Requirements
Communication Activities
The purpose of the task is to determine the
requirements communication activities
need to be undertaken & the type of
resources required to complete them
The preceding requirements related
activities need to be successfully completed
the requirements elicitation & requirements
analysis & documentation
128
129. Process & Elements to Determine
Requirements Communication
Activities
The BA reviews all of the stakeholder
information, requirements analysis results
& models
For the project delivery team, detailed level
business rules with decision trees can be
packaged together in the CASE tool
129
130. Process & Elements to Determine
Requirements Communication
Activities
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
131. Determine Solution Assessment
& Validation Activities
The BA must select the Solution Assessment
& Validation activities that best provides
the solution based on the requirements
131
132. Process & Elements to Determine
Solution Assessment & Validation
Activities
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 on the requirements
132
134. Identify Milestones in the
Requirements Activities
Development & Delivery
According to the PMBOK, the milestone is a
significant point in the project
Milestone can be used to measure the
progress & completion of the significant
phases of requirements activities
134
135. Process & Elements to Identify
Milestones in the Requirements
Activities Development & Delivery
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
136. Define Units of Work
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
137. Process & Elements
Define Units of Work
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 requirements activities
137
138. Estimate Effort
per Unit of Work
This task will document the resource
assigned to each task
The BA will use the listing of requirements
activities & listing of documented
assumptions & risks
138
139. Process & Elements Estimate
effort per Unit of Work
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
140. Estimate Duration
per Unit of Work
This task defines the work period in terms
of calendar days for each activity defined
The list of activities & estimated work
efforts will be needed to complete the task
140
141. Process & Elements Estimate
Duration per Unit of Work
The BA will enter the beginning & ending
date for each task
The BA should discus & get agreement on
estimates for the tasks with the Project
manager
141
142. Technique 1
Techniques to Estimate Requirements
Activities Use Documentation from Past
Requirements Activities to Estimates
Duration:
◦ The technique will provide the BA with data to
support estimating duration for the task defined
142
143. Process to use documentation from
Past Requirements Activities to
Estimates Duration
Techniques to Estimate Requirements
Activities Use Documentation from :
◦ The BA will review the documentation &
artifacts created from other recent projects within
the organization
143
144. Alternatives
Interview
Duration Estimation from other 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
146. Process & Elements to
Identify Assumptions
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
148. Process & Elements to
Identify Risks
Some ways to reduce or avoid Risks
include:
◦ Complete tasks simultaneously rather than
sequentially
◦ Identify links between task
◦ Add resources to critical activities
148
149. Modify the
Requirements Plan
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 this task
149
150. Process & Elements to Modify
the Requirements Plan
The BA should consider the options other
than modifying task aspects
The revised plan along with the
documentation nothing the purpose for the
change will be the deliverable for the task
150
151. Manage Requirements Scope
The process relates to managing the list of
requirements of the system development
component
151
152. Establish Requirements Baseline
Baseline is a line or standard by which the
changes to requirements are compared
If the list of requirements is not baselined
then it will be very challenging to the BA to
manage the requirements scope
152
153. Process & Elements to Establish
Requirements Baseline
The BA takes a snapshot of list of
requirements
All the stakeholders listed in Identify
Stakeholders task
153
154. Structure Requirements
for Traceability
Requirements traceability assists in
managing changes to the requirements that
will occur after the requirements are
baselined
154
155. Structure Requirements
for Traceability
Project Benefits includes:
Traceability aids:
◦ Scope Management
◦ Change Impact Analysis
◦ Risk Based Testing
The process supports the ability to trace a
requirement through the development life
cycle
155
156. Structure Requirements
for Traceability
Traceability Supports the following goals:
◦ Links downstream work products to the purpose
for which they were created
◦ Facilitates the requirements change control
process
156
158. Process & Elements to Structure
Requirements for Traceability
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
159. Model Requirements
Traceability
User Needs
Traces
High-Level Product
Description
s Trac
Trace es
Design &
Business Supplemental Construction
Requirements Requirements
Document Traces Design
Artifact
Traces
Traces
Test case Test case
159
160. Several techniques
used in Traceability task
Clear numbering scheme
Unambiguous requirements statements
Document instruction set for project
traceability requirements
160
163. Identify Impacts to External Systems
&/or Other Areas of the Project
The process insures that the work is not
authorized for the items that are outside the
baselined list of requirements
The requirements Traceability Matrix,
interfaces column is the predecessor to this
task
163
164. Process & Elements to Identify
Impacts to External Systems &/or
Other Areas of the Project
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
165. Process & Elements to Identify
Impacts to External Systems &/or
Other Areas of the Project
The stakeholders identified in the Source
Column
Executive Sponsor
Updated Requirements Traceability Matrix
will be the deliverable for the task
165
166. Identify Scope Change Resulting
from Requirement Change
This is the process of controlling changes
Scope changes stem from the following
types of the requirements changes:
◦ New
◦ Modifications of requirements
◦ De‐scoping
166
167. Process & Elements to Identify
Scope Change Resulting from
Requirement Change
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
168. Process & Elements to Identify
Scope Change Resulting from
Requirement Change
Disposition based on the results as to when
it will be delivered
New baseline for the List of Requirements
and the updated Requirements Traceability
Matrix is the Deliverable for the Task
168
169. Maintain Scope Approval
As the project progresses, it is more difficult
and costly to repair requirements errors
169
170. Process & Elements to
Maintain Scope Approval
Once the approval process has been
completed, the BA baseline 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
171. Measure & Report on
Requirements Activity
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
172. Measure & Report on
Requirements Activity
Metric is a quantitative measure of a
process or a product
Example of questions include:
◦ Are we on schedule?
◦ What is the quality of the product?
172
173. Measure & Report on
Requirements Activity
Every project has a project life cycle
regardless of the products created in it
Kind of metrics:
◦ Project metrics
◦ Product metrics
173
174. Measure & Report on
Requirements Activity
Metrics collection and analysis must be
regularly monitored and measured
It is important to the success of the project
that all key stakeholders involved,
understand the metrics to be used
174
175. Measure & Report on
Requirements Activity
On some projects the primary metrics may
be the number of defects that are found and
fixed in the product
Three types of tasks for both product and
project related metric are the Identification,
Collection and Reporting
175
176. Measure & Report on
Requirements Activity
Steps for BA
◦ Determine relevant metrics for the requirements
activities
◦ Determine how the metrics will be collected,
analyzed, documented and communicated
176
177. Determine the
Project Metrics
The purpose of this task identify and
document all project metrics that will be
used in the requirements related project
activities
Inputs to the task will include the current
project plan
177
178. Process & Elements to
Determine the Project Metrics
Many organizations may have standards
applicable to defining project metrics for
any type of project
The deliverable from this task will include
the descriptive list of all the currently
identified project metrics for the specific
project
178
179. Determine the
Product Metrics
It is part of the job of Business Analyst to
elicit and identify the effective product
metrics during this task
The BA must work closely with the Project
Manager to identify effective product
metrics for each particular project
179
180. Determine the
Product Metrics
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
181. Process & Elements to
Determine the Product Metrics
Specific reports content and formats may
also be determined at this point but will be
done in later task
An example of a useful metric might be the
rate at which the development team is
finding and fixing product defects
181
182. Process & Elements to
Determine the Product Metrics
Suggestions for initiating a product metrics
program include the following:
◦ Select a small set of metrics initially and add to
carefully as needed
◦ Explanation of the metrics selected to the team is
critical
Stakeholders include executive sponsor,
project manager and project team members
182
183. Collect Project Metrics
The task will enable the BS to collect the
identified project metrics
183
184. Process & Element to
Collect Project Metrics
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
185. Collect Product Metrics
The purpose of this task is to collect the
specific product metrics identified for all
requirements related tasks
185
186. Process & Elements to
Collect Product Metrics
Product metrics must be collected with as
little effort and impact as possible
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
187. Reporting Product Metrics
The task will enable the BA to report the
identified and agreed to product metrics
The primary input to this task will be the
product metrics collected and the updated
of up‐to‐date metrics
187
188. Process & Elements for
Reporting Product Metrics
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 design the reporting
capability accordingly
188
189. Reporting Project Metrics
Project status reports are most often used to
report on the status of the project metrics
Five primary criteria are Time, Cost,
Resources, Features, Quality
189
190. Process & Elements for
Reporting Project Metrics
Project metrics must be 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
191. Process & Elements for
Reporting Project Metrics
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 reporting capabilities
utilizing the identified project metrics
191
192. Manage Requirement Change
Plan Requirement Change
Understand the changes to Requirements
◦ Task 1: Identify issues/changes
◦ Task 2: Participate in impact analysis
192
193. Manage Requirement Change
Document the changes to requirements
◦ Task 1: Create Formal Change Request
◦ Task 2: Create Formal Change Request
◦ Task 3: Define links to other requirements
193
194. Manage Requirement Change
Analyze change requests
◦ Task 1: Conduct fact‐finding to obtain a greater
understanding of the requirements change,
operational context and potential issues
◦ Task 2: Categorize/prioritize requirements
194
196. Key Points
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 team roles
196
197. Key Points
The purpose of, Identify & Document Team Roles
task involves the BA in identifying and
documenting all team roles
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
198. Key Points
Grouping stakeholders into multiple categories
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
199. Key Points
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
200. Key Points
The purpose of, 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 demands a
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
201. End of Chapter 3
Requirements Planning &
Management
201
202. “Like” us on Facebook:
p // /
http://www.facebook.com/welearnindia
“Follow” us on Twitter:
http://twitter.com/WeLearnIndia
http://twitter com/WeLearnIndia
Watch informative videos on Youtube:
http://www.youtube.com/WelingkarDLP