MANAGEMENT

Recommendations

Info

5 - REQUIREMENTS ELICITATION • Requirements sources. Determine the potential sources of information that are needed to develop requirements. These sources can be internal or external to the organization and include specific people, reference material, or other documentation relevant to the project or program scope. This information may exist in many forms, including user manuals, procedures, market research, or governmental regulations. Existing requirements can also be viable sources of information. Those requirements that are common across projects and programs should be considered for reuse to improve productivity of the elicitation effort. • Resources. Identify the project resources that are required to participate in the elicitation activities. These resources may include stakeholders, equipment, and facilities. • Expected deliverables. While typically addressed during Requirements Management Planning, revisit the deliverables or work products that will be created during the elicitation process, because more is now known about the problem/opportunity to be solved or addressed. Deliverables will vary depending on the project life cycle and chosen elicitation technique(s). More predictive life cycles typically require formal requirements specifications, whereas highly adaptive life cycles focus on more lightweight documentation, such as user stories. 5 5.2.2 Define Types of Requirements Requirements can be classified into various categories to provide clarity and context to the issue. These categories also help define what information needs to be elicited and the source of that information. Expert judgment, standards, or common practices associated with an organization, industry, or community of knowledge may be used to determine the types of requirements and level of detail sufficient to develop the solution. Common classifications include: • Business requirements. Describe the high-level needs of the overall organization to address a problem or opportunity. These requirements provide the rationale for why a project or program is launched. • Stakeholder requirements. Express the needs of a specific stakeholder or group of stakeholders, which may include customers, users, or suppliers. These requirements communicate the material interest of the stakeholders in the outcome of the product, service, or result. These requirements provide a basis for identifying the solution requirements. • Solution requirements. Describe the features and functions that the product, service, or result needs to exhibit to satisfy the business and stakeholder requirements. Solution requirements may include requirements related to technology and standard compliance. These are often grouped into two categories: functional and nonfunctional requirements. ○ Functional requirements denote particular behaviors and operations that the solution will perform. These focus on the required functionality to enable stakeholders to accomplish their objectives, which in turn fulfills the business need. ○ Nonfunctional requirements describe certain environmental conditions or required attributes to ensure the product or service operates effectively. ©2016 Project Management Institute. Requirements Management: A Practice Guide 27
5 - REQUIREMENTS ELICITATION • Transition requirements. Describe the temporary capabilities that are essential to migrate from the current state to a future state environment. Requirements that fall into this category include conversion of data from the current system and training needed to address skill gaps. • Project requirements. Describe the actions, processes, and other conditions that the project needs to satisfy. These requirements focus on the execution of the work required to deliver the solution. • Quality requirements. Describe the criteria needed to ensure completion of project deliverables and demonstrate compliance with identified standards and quality metrics. • Program requirements. Describe the specifications and outcomes for successful implementation and delivery of the program benefits. Project, quality, and program requirements are not a part of the requirements process but are a part of the project or program work. These requirements are typically the responsibility of the project or program manager but may be delegated as appropriate. 5.2.3 Conduct Elicitation Activities Elicitation is an exploratory activity that draws out implicit and hidden information. During elicitation, input is received by consulting a broad range of stakeholders, as well as reviewing existing systems, historical records, and documentation. This ensures that varying viewpoints are represented and the project goals and objectives are well understood. While elicitation is generally an iterative process for most projects, the timing and degree of iteration varies based on the project life cycle. In a plan-driven or predictive environment, elicitation activities are typically conducted as early as possible in the project. Even in a predictive life cycle, requirements are expected to evolve as the project progresses, both to include increasing levels of detail and to address changes. However, the elicitation of requirements should cease once the solution has been defined to a sufficient level so it can be built. For more adaptive life cycles, elicitation activities occur continuously throughout the project life cycle in conjunction with requirements analysis. The initial work is performed to define the vision, scope, and high-level business needs of the problem or opportunity. As the project evolves, the scope is further evaluated and decomposed into a set of requirements, also known as the product backlog, one iteration at a time. This just-in-time method allows the project team to focus on delivering a portion of the functionality and to receive feedback on the requirements before moving to the next iteration. 5.2.4 Document and Communicate Results The outcome of elicitation activities should be recorded to properly examine and synthesize the relevant information during the analysis process. It is important that the documented results are consolidated, communicated with, and reviewed by the stakeholders to ensure accuracy. This information may be documented in a number of forms, including audio recordings, meeting minutes, interview notes, and survey responses. Work products can be described as informal documents or a collection of notes and diagrams created during elicitation. 28 ©2016 Project Management Institute. Requirements Management: A Practice Guide
Page 1 and 2: REQUIREMENTS MANAGEMENT A PRACTICE
Page 3 and 4: Library of Congress Cataloging-in-P
Page 5 and 6: TABLE OF CONTENTS 3.3.4 Create Bene
Page 7 and 8: TABLE OF CONTENTS 6.3 Requirements
Page 9 and 10: PREFACE Requirements Management: A
Page 12 and 13: 1 - INTRODUCTION 1 1 INTRODUCTION 1
Page 14: 1 - INTRODUCTION need to understand
Page 17 and 18: 2 - REQUIREMENTS MANAGEMENT OVERVIE
Page 24 and 25: 3 - NEEDS ASSESSMENT 3 NEEDS ASSESS
Page 26 and 27: 3 - NEEDS ASSESSMENT 3.3.2 Develop
Page 28: 3 - NEEDS ASSESSMENT 3.5.3 Gap Anal
Page 31 and 32: 4 - REQUIREMENTS MANAGEMENT PLANNIN
Page 33 and 34: 4 - REQUIREMENTS MANAGEMENT PLANNIN
Page 36 and 37: 5 - REQUIREMENTS ELICITATION 5 REQU
Page 40 and 41: 5 - REQUIREMENTS ELICITATION These
Page 42: 5 - REQUIREMENTS ELICITATION 5.3.9
Page 45 and 46: 6 - REQUIREMENTS ANALYSIS open and
Page 47 and 48: 6 - REQUIREMENTS ANALYSIS elaborate
Page 49 and 50: 6 - REQUIREMENTS ANALYSIS 6.3.1.1 M
Page 51 and 52: 6 - REQUIREMENTS ANALYSIS • Use c
Page 54 and 55: 7 - REQUIREMENTS MONITORING AND CON
Page 60 and 61: 8 - SOLUTION EVALUATION 8 SOLUTION
Page 62: 8 - SOLUTION EVALUATION requirement
Page 65 and 66: 9 - PROJECT OR PHASE CLOSURE 9.1.1
Page 67 and 68: 9 - PROJECT OR PHASE CLOSURE 9.3.1
Page 69 and 70: APPENDIX X1 - CONTRIBUTORS AND REVI
Page 71 and 72: APPENDIX X2 - SUGGESTED ADDITIONAL
Page 73 and 74: APPENDIX X3 - REQUIREMENTS MANAGEME
Page 76 and 77: GLOSSARY GLOSSARY Acceptance Criter
Page 78 and 79: GLOSSARY Configuration Management.
Page 80 and 81: GLOSSARY increases. Iterations deve
Page 82 and 83: GLOSSARY Product Backlog. See backl
Page 84 and 85: GLOSSARY Root Cause Analysis. An an
Page 86: GLOSSARY User Story. A one or two s
Page 89 and 90:
INDEX Communications management, 9
Page 91 and 92:
INDEX PMBOK Guide, 1-2 definitions
Page 93:
INDEX Surveys, requirements elicita
show all

MANAGEMENT

Create successful ePaper yourself

Delete template?

Save as template?