Operations Management Material Requirements Planning (MRP) & ERP Chapter 14 Week #14-2.
Requirements Planning & Management
-
Upload
we-learn-a-continuous-learning-forum-from-welingkars-distance-learning-program -
Category
Education
-
view
3.419 -
download
0
description
Transcript of Requirements Planning & Management
Chapter 3Chapter 3Requirements Planning & Management
1
IntroductionIntroduction
Understand the team roles for the projectBe able to determine requirements activities & planning stepsUnderstand requirements risk approachBe able to estimate activities & manage the scopeBe able to manage change to requirements
2
Phase 1Phase 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
Phase 2Phase 2
Requirements Plan is useful in,
◦ Defining of requirements activities that will be performed
◦ Requirements Plan items include
4
Phase 3 Measuring SuccessPhase 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
Assurance of the proper planning & Assurance of the proper planning & management of requirementsmanagement 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
Requirements Planning & Requirements Planning & ManagementManagement
Relationship of Requirements Planning & Management to other areas
Inputs◦ Feasibility assessment from Enterprise Analysis
Outputs◦ Tools used to gather & communicate requirements
7
Understand Team roles for the Understand Team roles for the ProjectProject
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
Identify & Document Identify & Document Team Roles for the ProjectTeam 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
Team Roles Team Roles -- 11
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
Team Roles Team Roles -- 22
◦ 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
Team Roles Team Roles --33
◦ 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
Team Roles Team Roles --44
◦ 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
Team Roles Team Roles -- 55
◦ 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
Team Roles Team Roles -- 66
◦ 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
Identify & Document Team Role Identify & Document Team Role ResponsibilitiesResponsibilities
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
Process & ElementsProcess & Elements
Project team role responsibilities should be identified early in the project to help ensure the timely delivery of the project deliverables
17
Common Responsibilities Common Responsibilities -- 11
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
Common Responsibilities Common Responsibilities -- 22
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
Common Responsibilities Common Responsibilities -- 33
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
Common Responsibilities Common Responsibilities -- 44
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
Common Responsibilities Common Responsibilities –– 55
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
Common Responsibilities Common Responsibilities –– 66
Stakeholders: The responsibility varies greatly depending on the type & level of stakeholder
The stakeholdermay be a decision‐maker on the solutions & the success of the project
23
The RACI MatrixThe 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
Identify Stakeholders Identify Stakeholders -- 11
The driving force behind each project
It is an important step that should not be overlooked or minimized
25
Identify Stakeholders Identify Stakeholders -- 22
BA will create a list of all stakeholders associated with the project
Listing should include persons name, their job title & some basic demographics
26
Techniques to Identify Techniques to Identify StakeholdersStakeholders
Consult Reference Material
◦ Existing project materials are used to identify people associated with the project
◦ The listing will be reviewed by project management
27
Process to Consult Reference Process to Consult Reference MaterialsMaterials
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
Strengths & WeaknessesStrengths & Weaknesses
Minimum skills are required
Reference material may not be up dated or completed
29
Techniques to Identify Techniques to Identify StakeholdersStakeholders
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
Process for Questionnaire to Process for Questionnaire to identified Stakeholdersidentified 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
Alternative to QuestionnaireAlternative 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
Key Features, Strengths & Key Features, Strengths & WeaknessesWeaknesses
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
Describe the StakeholdersDescribe the Stakeholders
Stakeholder description provides the information about each stakeholder to BA
Stakeholders listing will be the primary input to the Questionnaire task
34
Process & Elements to Process & Elements to describe the Stakeholdersdescribe the Stakeholders
Questions are designed to solicit the information from each stakeholder
Result will be the stakeholder summary document
35
Stakeholder SummaryStakeholder SummaryName & Job Title Project Stake Description
[The name & the job title of description of the duties]
The stake or investment of the stakeholder
Summarize the stakeholder’s key characteristics with regard to the project
Jatin Deo – Project sponsor Primary end user of project solution
Primary end user of project solution Success of the project solutions will increase the quality of output Jatin’s department
Project selectionProject priorityProject charter
Jaimin Bhatt –Executive sponsor
Meeting or executing revenue & expense budget for the fiscal year
Ensures that project requirements & solutions match up with the Enterprise Analysis
36
Techniques to Describe the Techniques to Describe the StakeholdersStakeholders
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
Process to Interview Stakeholders to Process to Interview Stakeholders to Solicit Description Solicit Description -- 11
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
Process to Interview Stakeholders Process to Interview Stakeholders to Solicit Description to Solicit Description -- 22
◦ 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
Process to Interview Stakeholders Process to Interview Stakeholders to Solicit Description to Solicit Description -- 33
◦ 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
Key FeaturesKey Features
Direct contact with the stakeholders is required
Business analyst must be proficient in various interview technologies
41
Strengths & WeaknessesStrengths & Weaknesses
Immediate response to the questions is solicited
More of the time of the business analyst is used for this technique
42
Categorize the StakeholdersCategorize 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
Process & Elements to Process & Elements to Categorize the StakeholdersCategorize the Stakeholders
Example of stakeholder categories:
◦ Key requirement source
◦ Project Impact
◦ Number of direct end users
◦ Number of interfacing business processes
44
Stakeholder ClassificationStakeholder Classification
Stake holder classification matrix will be the result of the categorizing the stakeholders
Example:
45
Stakeholder Name State/country Key
Stakeholder?Number of 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
Define Business Analyst Define Business Analyst Work division StrategyWork 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
Business AnalystBusiness AnalystWork division StrategyWork division Strategy
47
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
Divide Work amongst a Divide Work amongst a Business Analyst TeamBusiness Analyst Team
Obstacles of confusion & uncertainty can be removed
The predecessors are the requirements activities or requirements work plan
48
Process & ElementsProcess & 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
Technique 1: Business Technique 1: Business Analyst Work Division Analyst Work Division StrategyStrategyThis is an allocation of activities according to some distinct characteristic
The most suitable strategy is applied to achieve specific goals
50
Types of Business AnalystTypes of Business AnalystWork Division StrategyWork Division Strategy
Subject Matter Expertise
Complexity
Area of Interests
Physical Limitation
Business Analyst Availability51
Subject Matter ExpertiseSubject 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
ComplexityComplexity
This work division is based on the level of complexity of the activities
53
Previous Work Experience Previous Work Experience with Stakeholderwith Stakeholder
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 Geography & Culture -- 11
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 Geography & Culture -- 22
The BA work division strategy may be based on the culture
Share beliefs, values, customs, behavior etc of the society
56
Area of InterestArea of Interest
This work division strategy is based on the area of interest of the BA
57
Physical LimitationPhysical Limitation
This work division strategy is based on the physical limitation of the Business Analyst
58
Business Analyst AvailabilityBusiness 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
Intended Audience, Process Intended Audience, Process & Key Features& 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
Strengths & WeaknessesStrengths & 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
Technique 2: CoTechnique 2: Co--ordination of ordination of Information within the TeamInformation 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
1. Core Business1. Core BusinessConcepts & policiesConcepts & policies
The look & feel of the web application
Methodology:◦ The company has incorporated the ITIL for service support & RUP for development
63
1. Core Business1. Core BusinessConcepts & policiesConcepts & 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
2. Functional & 2. Functional & NonNon--functional Requirementsfunctional Requirements
Strong understanding of In Scope & Out of Scope items
Provide instructions & examples
Consistent Approach for the Requirement Activity
65
3. Project Documentation3. 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
Processes for CoProcesses for Co--ordination of ordination of Information within the TeamInformation 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
Strengths & WeaknessesStrengths & Weaknesses
Saves time & avoids re‐working are the strengths
Lack of Access & time, learning curve etc are the weaknesses
68
Technique 3: Technique 3: Knowledge TransferKnowledge 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
Technique 3: Technique 3: Knowledge TransferKnowledge Transfer
Examples:◦ Information exchange◦ Central Repository
Mentorship: Senior & junior BAs are paired for back‐up
Intended audience is the BA
70
Process of Knowledge Process of Knowledge TransferTransfer
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
Strengths & WeaknessesStrengths & Weaknesses
Benefits include:◦ Solve problems & make better informed decisions ◦ Avoid working in silos
Disadvantages include:◦ Learning curve◦ Changing priorities
72
Define RequirementsDefine RequirementsRisk ApproachRisk 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
Typical Roles & Typical Roles & ResponsibilitiesResponsibilities
For End‐to‐end Requirements risk management BA is responsible, whereas, for End‐to‐end Project risks management Project manager is responsible
74
Topics of discussion Topics of discussion for this sectionfor this section
How requirements risk will be managed throughout the project
Examples of common requirements risks
75
Identify Requirements RisksIdentify 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
Process & Elements to Process & Elements to Identify the RisksIdentify 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
Common Requirements RisksCommon Requirements Risks
Examples include:
◦ Insufficient level of user involvement in identifying, detailed & analyzing requirements
◦ Missing, incorrect, & confliction requirements
78
Common Requirements RisksCommon 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
Define Requirements Risk Define Requirements Risk Management ApproachManagement Approach
The purpose is to detail a requirements risk management process
BA defines the requirements risk management approach
80
Process & Elements to Define Process & Elements to Define Requirements Risk Management Requirements Risk Management ApproachApproachTechniques of requirements Risk planning, monitoring & control to manage requirements are used
BA is responsible for managing requirements risk throughout the requirements process
81
Technique 1:Technique 1:Requirements Risk PlanningRequirements 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
Process of Requirements Process of Requirements Risk PlanningRisk 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
Process of Requirements Process of Requirements Risk PlanningRisk 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
Process of Requirements Process of Requirements Risk PlanningRisk 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
Technique 2: Requirements Technique 2: Requirements Risk MonitoringRisk Monitoring
The technique provides the current status of each identified risk
The BA executes the technique to monitor risks systematically
86
Process of Requirements Process of Requirements Risk MonitoringRisk 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
Technique 2:Technique 2:Requirement Risk ControlRequirement Risk Control
The technique ensures that the risk is controlled by responding to it
Many stakeholders are assigned to control the specific risks
88
Process of Requirement Process of Requirement Risk ControlRisk Control
The BA will perform various steps including:
◦ Impact◦ Mitigation Strategy◦ Action Plan◦ Contingency Plan◦ Lesson Learned
89
Process of Requirement Process of Requirement Risk ControlRisk 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
Determine Planning Determine Planning ConsiderationsConsiderations
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 Key Planning Identify Key Planning Impact AreaImpact 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
Process & Elements Identify Process & Elements Identify Key Planning Impact AreaKey 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
MethodologyMethodology
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 Consider the SDLC Methodologythe SDLC Methodology
SDLC is the overall process of designing & developing information system
Multiphase approach
95
Process & ElementsProcess & Elements
The method in use will impact requirement planning
BA must be familiar with the SDLC in their organizations
96
Process & ElementsProcess & 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
Consider Consider the PLC Methodologythe 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
Process & ElementsProcess & Elements
The BA must consider the phases, tasks & subtasks defined in PLC
Examples of PLC phases:◦ Definition◦ Planning◦ Initiation
99
Process & ElementsProcess & Elements
◦ Execution◦ Close‐out
Each of these phase will broken down into tasks & subtasks
The selected PLC represents the major deliverables
100
Consider Project Risk, Consider Project Risk, Expectations & StandardsExpectations & 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
Consider Project Risk, Consider Project Risk, Expectations & StandardsExpectations & 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
Process & Elements Consider Process & Elements Consider Project Risk, Expectations & Project Risk, Expectations & StandardsStandardsThe 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 Process & Elements Consider Project Risk, Expectations & Project Risk, Expectations & StandardsStandardsReview of existing historical project records in a part of the expectations process.
An organization may have the standards related to the project planning.
104
Process & Elements Consider Process & Elements Consider Project Risk, Expectations & Project Risk, Expectations & StandardsStandardsStakeholders for this task are all the project stakeholders that are impacted by the project risk
Modified requirements management plan is the deliverable
105
ReRe--planningplanning
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 Process & Elements for Refor Re--planningplanning
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
Process & Elements Process & Elements for Refor Re--planningplanning
The process includes all the stakeholders those are involved in the baselinedrequirements management plan
Updated requirements management plan will be the deliverable for the process of Re‐planning
108
Consider Key Stakeholder Consider Key Stakeholder Needs & LocationNeeds & 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
Process & Elements Consider Key Process & Elements Consider Key Stakeholder Needs & LocationStakeholder Needs & Location
Two different types of project can be identified regarding the location of the stakeholders:
◦ Centralized
◦ Dispersed
110
CentralizedCentralized
All key stakeholders are located in the same geographic area
111
DispersedDispersed
Some key stakeholders are located in different geographic area hence more difficult
Another situation is, the development team is physically located in many time zones away
112
Key Stakeholders Key Stakeholders & Deliverables& Deliverables
The process includes all the stakeholders those are involved in the baselinedrequirements management plan
Updated requirements management plan will be the deliverable
113
Consider the Project TypeConsider 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
Process & Element to Process & Element to Consider the Project TypeConsider the Project Type
New Software DevelopmentOutsourced DevelopmentSoftware MaintenanceSoftware Package SectionProcess ImprovementOrganizational Change
115
Key Stakeholders Key Stakeholders & Deliverables& Deliverables
The process includes all the stakeholders involved in the baselined requirements management plan
the deliverable will be updated requirements management plan
116
Select Requirements PlanSelect Requirements Plan
Activities undertaken to complete the end‐to‐end requirements process include:
◦ Requirement Elicitation◦ Requirements Analysis & Documentation◦ Requirements communication◦ Solution Assessment & Validation
117
Topics of DiscussionTopics 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
Determine Requirements Elicitation Determine Requirements Elicitation stakeholders & Activitiesstakeholders & 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
Determine Requirements Elicitation Determine Requirements Elicitation stakeholders & Activitiesstakeholders & 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
Determine Requirements Elicitation Determine Requirements Elicitation stakeholders & Activitiesstakeholders & Activities
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 Process & Elements to Determine Requirements Elicitation Determine Requirements Elicitation stakeholders & Activitiesstakeholders & ActivitiesThe BA will determine the best way to gather requirements from the stakeholders
The various techniques used are Survey, COTS, requirements workshops etc.
122
Process & Elements to Process & Elements to Determine Requirements Determine Requirements Elicitation stakeholders & ActivitiesElicitation stakeholders & ActivitiesThe 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
Determine Requirements Analysis Determine Requirements Analysis & Documentation & Activities& 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
Determine Requirements Analysis Determine Requirements Analysis & Documentation & Activities& 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
Process & Elements to Determine Process & Elements to Determine Requirements Analysis & Requirements Analysis & Documentation & ActivitiesDocumentation & ActivitiesAll 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 Process & Elements to Determine Requirements Analysis & Requirements Analysis & Documentation & ActivitiesDocumentation & ActivitiesThe 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 Determine Requirements Communication ActivitiesCommunication 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
Process & Elements to Determine Process & Elements to Determine Requirements Communication Requirements Communication ActivitiesActivitiesThe 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
Process & Elements to Determine Process & Elements to Determine Requirements Communication Requirements Communication ActivitiesActivitiesThe key business stakeholders & SMEsshould 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 Determine Solution Assessment & Validation Activities& Validation Activities
The BA must select the Solution Assessment & Validation activities that best provides the solution based on the requirements
131
Process & Elements to Determine Process & Elements to Determine Solution Assessment & Validation Solution Assessment & Validation ActivitiesActivitiesThe 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
Estimate Requirements Estimate Requirements ActivitiesActivities
3 basic parameters are Scope, Schedule & Resources
The BA make haphazard estimations of their requirements parameters
133
Identify Milestones in the Identify Milestones in the Requirements Activities Requirements Activities Development & DeliveryDevelopment & DeliveryAccording 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
Process & Elements to Identify Process & Elements to Identify Milestones in the Requirements Milestones in the Requirements Activities Development & DeliveryActivities Development & DeliveryThe 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 WorkDefine 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
Process & ElementsProcess & ElementsDefine Units of WorkDefine 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
Estimate Effort Estimate Effort per Unit of Workper 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
Process & Elements Estimate Process & Elements Estimate effort per Unit of Workeffort 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
Estimate Duration Estimate Duration per Unit of Workper 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
Process & Elements Estimate Process & Elements Estimate Duration per Unit of WorkDuration 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
Technique 1Technique 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
Process to use documentation from Process to use documentation from Past Requirements Activities to Past Requirements Activities to Estimates DurationEstimates DurationTechniques to Estimate Requirements Activities Use Documentation from :
◦ The BA will review the documentation & artifacts created from other recent projects within the organization
143
AlternativesAlternatives
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
Identify AssumptionsIdentify Assumptions
The BA will identify & document assumptions that affect the requirement planning & management activities
145
Process & Elements to Process & Elements to Identify AssumptionsIdentify 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
Identify RisksIdentify Risks
The process will identify & list the risks associated with requirements planning & management
147
Process & Elements to Process & Elements to Identify RisksIdentify 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
Modify the Modify the Requirements PlanRequirements 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
Process & Elements to Modify Process & Elements to Modify the Requirements Planthe 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
Manage Requirements ScopeManage Requirements Scope
The process relates to managing the list of requirements of the system development component
151
Establish Requirements BaselineEstablish Requirements Baseline
Baseline is a line or standard by which the changes to requirements are compared
If the list of requirements is not baselinedthen it will be very challenging to the BA to manage the requirements scope
152
Process & Elements to Establish Process & Elements to Establish Requirements BaselineRequirements Baseline
The BA takes a snapshot of list of requirements
All the stakeholders listed in Identify Stakeholders task
153
Structure Requirements Structure Requirements for Traceabilityfor Traceability
Requirements traceability assists in managing changes to the requirements that will occur after the requirements are baselined
154
Structure Requirements Structure Requirements for Traceabilityfor 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
Structure Requirements Structure Requirements for Traceabilityfor 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
Types of Traceability Types of Traceability InformationInformation
Source
Rationale
Requirements
Design or test
Interface
157
Process & Elements to Structure Process & Elements to Structure Requirements for TraceabilityRequirements 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
Model Requirements Model Requirements TraceabilityTraceability
159
High-Level Product Description
User Needs
Business Requirements
Document
Test case
Design Artifact
Supplemental Requirements
Test case
Tra c
es
Trac
es
TracesTraces
Trac
es
Design & Construction
Traces
Several techniques Several techniques used in Traceability taskused in Traceability task
Clear numbering scheme
Unambiguous requirements statements
Document instruction set for project traceability requirements
160
Traceability MatrixTraceability Matrix
This relates one set of elements to another set
Analysis can be conducted to determine is there is any missing connections
161
Traceability MatrixTraceability Matrix
If a predecessor has too may successors then it may be complex
Project can use matrixes to describe any key relationship between the work products
162
Identify Impacts to External Systems Identify Impacts to External Systems &/or Other Areas of the Project&/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
Process & Elements to Identify Process & Elements to Identify Impacts to External Systems &/or Impacts to External Systems &/or Other Areas of the ProjectOther Areas of the ProjectThe 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 Process & Elements to Identify Impacts to External Systems &/or Impacts to External Systems &/or Other Areas of the ProjectOther Areas of the ProjectThe stakeholders identified in the Source Column
Executive Sponsor
Updated Requirements Traceability Matrix will be the deliverable for the task
165
Identify Scope Change Resulting Identify Scope Change Resulting from Requirement Changefrom 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
Process & Elements to Identify Process & Elements to Identify Scope Change Resulting from Scope Change Resulting from Requirement ChangeRequirement ChangeIf 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 Process & Elements to Identify Scope Change Resulting from Scope Change Resulting from Requirement ChangeRequirement ChangeDisposition 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
Maintain Scope ApprovalMaintain Scope Approval
As the project progresses, it is more difficult and costly to repair requirements errors
169
Process & Elements to Process & Elements to Maintain Scope ApprovalMaintain 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
Measure & Report on Measure & Report on Requirements ActivityRequirements 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
Measure & Report on Measure & Report on Requirements ActivityRequirements 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
Measure & Report on Measure & Report on Requirements ActivityRequirements Activity
Every project has a project life cycle regardless of the products created in it
Kind of metrics:◦ Project metrics◦ Product metrics
173
Measure & Report on Measure & Report on Requirements ActivityRequirements 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
Measure & Report on Measure & Report on Requirements ActivityRequirements 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
Measure & Report on Measure & Report on Requirements ActivityRequirements Activity
Steps for BA
◦ Determine relevant metrics for the requirements activities
◦ Determine how the metrics will be collected, analyzed, documented and communicated
176
Determine the Determine the Project MetricsProject 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
Process & Elements to Process & Elements to Determine the Project MetricsDetermine 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
Determine the Determine the Product MetricsProduct 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
Determine theDetermine theProduct MetricsProduct 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
Process & Elements to Process & Elements to Determine the Product MetricsDetermine 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
Process & Elements to Process & Elements to Determine the Product MetricsDetermine 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
Collect Project MetricsCollect Project Metrics
The task will enable the BS to collect the identified project metrics
183
Process & Element to Process & Element to Collect Project MetricsCollect 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
Collect Product MetricsCollect Product Metrics
The purpose of this task is to collect the specific product metrics identified for all requirements related tasks
185
Process & Elements to Process & Elements to Collect Product MetricsCollect 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
Reporting Product MetricsReporting 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
Process & Elements for Process & Elements for Reporting Product MetricsReporting 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
Reporting Project MetricsReporting 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
Process & Elements for Process & Elements for Reporting Project MetricsReporting 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
Process & Elements for Process & Elements for Reporting Project MetricsReporting 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
Manage Requirement ChangeManage Requirement Change
Plan Requirement Change
Understand the changes to Requirements
◦ Task 1: Identify issues/changes
◦ Task 2: Participate in impact analysis
192
Manage Requirement ChangeManage 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
Manage Requirement ChangeManage 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
Manage Requirement ChangeManage Requirement Change
Analyze change requests
◦ Task 3: Submit changes for approval
195
Key PointsKey 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
Key PointsKey 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
Key PointsKey Points
Grouping stakeholders into multiple categories uncovers the commonalitiesThe business analysis work division strategy is a systematic plan of action intended to accomplish a specific goalRequirements risks and their management is a subset of overall project risks and their managementIdentifying, Managing, Planning, Monitoring, Controlling Requirements risks is job of the BAThe BA will select a complete set of requirements activities
198
Key PointsKey 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
Key PointsKey PointsThe 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
End of Chapter 3End of Chapter 3Requirements Planning & Management
201
“Like” us on Facebook: http://www.facebook.com/welearnindia p // /
“Follow” us on Twitter:http://twitter com/WeLearnIndiahttp://twitter.com/WeLearnIndia
Watch informative videos on Youtube: http://www.youtube.com/WelingkarDLP