Requirements Planning & Management


Published on

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:

Published in: Education, Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirements Planning & Management

  1. 1. Chapter 3Requirements Planning & Management 1
  2. 2. Introduction Understand the team roles for the project Be able to determine requirements activities  & planning steps Understand requirements risk approach Be able to estimate activities & manage the  scope Be able to manage change to requirements 2
  3. 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
  4. 4. Phase 2 Requirements Plan is useful in, ◦ Defining of requirements activities that  will be performed ◦ Requirements Plan items include 4
  5. 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. 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. 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. 8. Understand Team roles for theProject 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. 9. Identify & DocumentTeam 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. 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. 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. 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. 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. 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. 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. 16. Identify & Document Team RoleResponsibilities 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. Identify Stakeholders - 1 The driving force behind each project It is an important step that should not be  overlooked or minimized 25
  26. 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. 27. Techniques to IdentifyStakeholders 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. 28. Process to Consult ReferenceMaterials 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. 29. Strengths & Weaknesses Minimum skills are required Reference material may not be up dated or  completed 29
  30. 30. Techniques to IdentifyStakeholders 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. 31. Process for Questionnaire toidentified 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. 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. 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. 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. 35. Process & Elements todescribe the Stakeholders Questions are designed to solicit the  information from each stakeholder  Result will be the stakeholder summary  document  35
  36. 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 projectJatin Deo – Project  Primary end user of  Project selectionsponsor Primary end  project solution   Project priorityuser of project solution Success of the project  Project charter solutions will increase  the quality of output  Jatin’s departmentJaimin 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. 37. Techniques to Describe theStakeholders 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. 38. Process to Interview Stakeholders toSolicit 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. 39. Process to Interview Stakeholdersto 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. 40. Process to Interview Stakeholdersto 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
  41. 41. Key Features Direct contact with the stakeholders is  required  Business analyst must be proficient in  various interview technologies  41
  42. 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. 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. 44. Process & Elements toCategorize the Stakeholders Example of stakeholder categories: ◦ Key requirement source ◦ Project Impact ◦ Number of direct end users ◦ Number of interfacing business processes 44
  45. 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‐usersStakeholder 1 Gujarat, India Yes 10Stakeholder 2 California, USA No 35Stakeholder 3 Ontario, CA Yes 80Stakeholder 4 Maharashtra, India No 225 45
  46. 46. Define Business AnalystWork 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. 47. Business Analyst Work division Strategy Co-ordination Business Knowledge of information Define the Analysis Transfer among TeamWork Division complete the among Team Members activity Members Note: Out of scope of this section 47
  48. 48. Divide Work amongst aBusiness Analyst Team Obstacles of confusion & uncertainty can be  removed  The predecessors are the requirements  activities or requirements work plan  48
  49. 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. 50. Technique 1: BusinessAnalyst Work DivisionStrategy This is an allocation of activities according  to some distinct characteristic  The most suitable strategy is applied to  achieve specific goals 50
  51. 51. Types of Business AnalystWork Division Strategy Subject Matter Expertise Complexity Area of Interests Physical Limitation Business Analyst Availability 51
  52. 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
  53. 53. Complexity This work division is based on the level of  complexity of the activities  53
  54. 54. Previous Work Experiencewith 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. 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. 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. 57. Area of Interest This work division strategy is based on the  area of interest of the BA 57
  58. 58. Physical Limitation This work division strategy is based on the  physical limitation of the Business Analyst  58
  59. 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. 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. 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. 62. Technique 2: Co-ordination ofInformation 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. 63. 1. Core BusinessConcepts & policies The look & feel of the web application  Methodology: ◦ The company has incorporated the ITIL for  service support & RUP for development  63
  64. 64. 1. Core BusinessConcepts & 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. 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. 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. 67. Processes for Co-ordination ofInformation 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. 68. Strengths & Weaknesses Saves time & avoids re‐working are the  strengths Lack of Access & time, learning curve etc   are the weaknesses  68
  69. 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. 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. 71. Process of KnowledgeTransfer 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. 72. Strengths & Weaknesses Benefits include: ◦ Solve problems & make better informed  decisions  ◦ Avoid working in silos Disadvantages include: ◦ Learning curve ◦ Changing priorities 72
  73. 73. Define RequirementsRisk 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. 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. 75. Topics of discussionfor this section How requirements risk will be managed  throughout the project Examples of common requirements risks  75
  76. 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. 77. Process & Elements toIdentify 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. 78. Common Requirements Risks Examples include: ◦ Insufficient level of user involvement in  identifying, detailed & analyzing  requirements ◦ Missing, incorrect, & confliction  requirements 78
  79. 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. 80. Define Requirements RiskManagement Approach The purpose is to detail a requirements risk  management process  BA defines the requirements risk  management approach  80
  81. 81. Process & Elements to DefineRequirements Risk ManagementApproach 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. 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. 83. Process of RequirementsRisk 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. 84. Process of RequirementsRisk 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. 85. Process of RequirementsRisk 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. 86. Technique 2: RequirementsRisk Monitoring The technique provides the current status of  each identified risk  The BA executes the technique to monitor  risks systematically  86
  87. 87. Process of RequirementsRisk 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. 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. 89. Process of RequirementRisk Control The BA will perform various steps  including: ◦ Impact ◦ Mitigation Strategy ◦ Action Plan ◦ Contingency Plan ◦ Lesson Learned 89
  90. 90. Process of RequirementRisk 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
  91. 91. Determine PlanningConsiderations 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
  92. 92. Identify Key PlanningImpact 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. 93. Process & Elements IdentifyKey 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
  94. 94. Methodology 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
  95. 95. Considerthe SDLC Methodology SDLC is the overall process of designing &  developing information system Multiphase approach 95
  96. 96. Process & Elements The method in use will impact requirement  planning BA must be familiar with the SDLC in their  organizations 96
  97. 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. 98. Considerthe 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. 99. Process & Elements The BA must consider the phases, tasks &  subtasks defined in PLC Examples of PLC phases: ◦ Definition ◦ Planning ◦ Initiation 99
  100. 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. 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. 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. 103. Process & Elements ConsiderProject 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. 104. Process & Elements ConsiderProject 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. 105. Process & Elements ConsiderProject 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
  106. 106. Re-planning 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
  107. 107. Process & Elementsfor 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. 108. Process & Elementsfor 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. 109. Consider Key StakeholderNeeds & 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. 110. Process & Elements Consider KeyStakeholder Needs & Location Two different types of project can be  identified regarding the location of the  stakeholders: ◦ Centralized ◦ Dispersed 110
  111. 111. Centralized All key stakeholders are located in the same  geographic area 111
  112. 112. Dispersed 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
  113. 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. 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. 115. Process & Element toConsider the Project Type New Software Development Outsourced Development Software Maintenance Software Package Section Process Improvement Organizational Change 115
  116. 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. 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. 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. 119. Determine Requirements Elicitationstakeholders & 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. 120. Determine Requirements Elicitationstakeholders & 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. 121. Determine Requirements Elicitationstakeholders & 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. 122. Process & Elements toDetermine Requirements Elicitationstakeholders & 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. 123. Process & Elements toDetermine RequirementsElicitation 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. 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. 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. 126. Process & Elements to DetermineRequirements 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. 127. Process & Elements to DetermineRequirements 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. 128. Determine RequirementsCommunication 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. 129. Process & Elements to DetermineRequirements CommunicationActivities 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. 130. Process & Elements to DetermineRequirements CommunicationActivities 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. 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. 132. Process & Elements to DetermineSolution Assessment & ValidationActivities 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
  133. 133. Estimate RequirementsActivities 3 basic parameters are Scope, Schedule &  Resources The BA make haphazard estimations of  their requirements parameters 133
  134. 134. Identify Milestones in theRequirements ActivitiesDevelopment & 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. 135. Process & Elements to IdentifyMilestones in the RequirementsActivities 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. 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. 137. Process & ElementsDefine 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. 138. Estimate Effortper 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. 139. Process & Elements Estimateeffort 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. 140. Estimate Durationper 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. 141. Process & Elements EstimateDuration 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. 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. 143. Process to use documentation fromPast Requirements Activities toEstimates 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. 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
  145. 145. Identify Assumptions The BA will identify & document  assumptions that affect the requirement  planning & management activities 145
  146. 146. Process & Elements toIdentify 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
  147. 147. Identify Risks The process will identify & list the risks  associated with requirements planning &  management 147
  148. 148. Process & Elements toIdentify 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. 149. Modify theRequirements 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. 150. Process & Elements to Modifythe 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. 151. Manage Requirements Scope The process relates to managing the list of  requirements of the system development  component 151
  152. 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. 153. Process & Elements to EstablishRequirements Baseline The BA takes a snapshot of list of  requirements All the stakeholders listed in Identify  Stakeholders task 153
  154. 154. Structure Requirementsfor Traceability Requirements traceability assists in  managing changes to the requirements that  will occur after the requirements are  baselined 154
  155. 155. Structure Requirementsfor 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. 156. Structure Requirementsfor 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
  157. 157. Types of TraceabilityInformation Source Rationale Requirements Design or test Interface 157
  158. 158. Process & Elements to StructureRequirements 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. 159. Model RequirementsTraceability User Needs Traces High-Level Product Description s Trac Trace es Design & Business Supplemental ConstructionRequirements Requirements Document Traces Design Artifact Traces Traces Test case Test case 159
  160. 160. Several techniquesused in Traceability task Clear numbering scheme Unambiguous requirements statements Document instruction set for project  traceability requirements 160
  161. 161. Traceability Matrix This relates one set of elements to another  set Analysis can be conducted to determine is  there is any missing connections 161
  162. 162. Traceability 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
  163. 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. 164. Process & Elements to IdentifyImpacts to External Systems &/orOther 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. 165. Process & Elements to IdentifyImpacts to External Systems &/orOther 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. 166. Identify Scope Change Resultingfrom 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. 167. Process & Elements to IdentifyScope Change Resulting fromRequirement 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. 168. Process & Elements to IdentifyScope Change Resulting fromRequirement 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. 169. Maintain Scope Approval As the project progresses, it is more difficult  and costly to repair requirements errors 169
  170. 170. Process & Elements toMaintain 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. 171. Measure & Report onRequirements 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. 172. Measure & Report onRequirements 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. 173. Measure & Report onRequirements Activity Every project has a project life cycle  regardless of the products created in it Kind of metrics: ◦ Project metrics ◦ Product metrics 173
  174. 174. Measure & Report onRequirements 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. 175. Measure & Report onRequirements 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. 176. Measure & Report onRequirements Activity Steps for BA ◦ Determine relevant metrics for the requirements  activities ◦ Determine how the metrics will be collected,  analyzed, documented and communicated 176
  177. 177. Determine theProject 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. 178. Process & Elements toDetermine 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. 179. Determine theProduct 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. 180. Determine theProduct 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. 181. Process & Elements toDetermine 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. 182. Process & Elements toDetermine 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. 183. Collect Project Metrics The task will enable the BS to collect the  identified project metrics 183
  184. 184. Process & Element toCollect 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. 185. Collect Product Metrics The purpose of this task is to collect the  specific product metrics identified for all  requirements related tasks 185
  186. 186. Process & Elements toCollect 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. 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. 188. Process & Elements forReporting 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. 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. 190. Process & Elements forReporting 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. 191. Process & Elements forReporting 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. 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. 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. 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
  195. 195. Manage Requirement Change Analyze change requests ◦ Task 3: Submit changes for approval 195
  196. 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. 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. 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. 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. 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. 201. End of Chapter 3Requirements Planning & Management 201
  202. 202. “Like” us on Facebook:  p // / “Follow” us on Twitter: com/WeLearnIndiaWatch informative videos on Youtube: