MANAGEMENT

Recommendations

Info

5 - REQUIREMENTS ELICITATION These work products may or may not evolve into requirements. However, they are necessary throughout the elicitation process to clarify the information received and identify other items that require additional research or explanation. These additional items should be documented in the form of open issues or action items and recorded appropriately using an action item or issue-tracking mechanism. 5.3 Requirements Elicitation Techniques A wide range of techniques is available for requirements elicitation, with each one having its own strengths and weaknesses. These techniques may be used alone or in combination with others to achieve the desired outcome. It is necessary to understand the characteristics of each technique before selecting and applying the appropriate ones to ensure an optimal exchange of information. 5 Some commonly used techniques are described in Sections 5.3.1 through 5.3.9. 5.3.1 Interviews An interview is a methodical approach used to elicit information from stakeholders by asking relevant questions and documenting the responses. During this activity, questions are posed to program and project participants to identify functions and capabilities that should exist in the end product, service, or result. Interviews may be structured, where questions are prepared in advance of a meeting, or unstructured, where questions are asked in a free-flowing manner based on responses to previous questions. 5.3.2 Facilitated Workshops Facilitated workshops convene stakeholders or multidisciplinary teams in a focused and structured session to identify requirements, reconcile differences, and reach consensus among the participants. These interactive workshops enable discovery of requirements while resolving conflicts early in the project life cycle. 5.3.3 Focus Groups Focus groups assemble prequalified participants, such as subject matter experts, in a group setting to share their attitudes and expectations about a particular product, service, or result. The group members voice their opinions and provide clarity on specific topics. This technique provides qualitative feedback that can be further examined as requirements are analyzed. 5.3.4 Brainstorming Brainstorming is a group technique used to generate multiple ideas related to a particular subject. It uses the collective input from the group to understand different perspectives of a problem or solution and to build upon each ©2016 Project Management Institute. Requirements Management: A Practice Guide 29
5 - REQUIREMENTS ELICITATION other’s ideas. This method relies heavily on the contribution of its participants to gain valuable information regarding a specific topic. Other examples of group creativity techniques include use of the nominal group technique, idea/ mind-mapping, affinity diagram, and multicriteria decision analysis. 5.3.5 Questionnaires and Surveys Questionnaires and surveys are techniques used to quickly solicit and obtain information from a large number of users. These techniques involve prepared questions to elicit subjective and demographic data from respondents. The data is analyzed to extract relevant requirements or may be used to prepare for further elicitation. Questionnaires and surveys are most effective when quick responses are needed and stakeholders are geographically dispersed. Questionnaires and surveys can be closed-ended or open-ended. Closed-ended questions provide the respondent with a predefined list of responses from which to choose. In contrast, open-ended questions allow the respondent to answer questions in his or her own words. 5.3.6 Document Analysis A substantial amount of information can be uncovered by reviewing and analyzing existing documentation. Document analysis inspects a wide range of materials, such as a glossary of terms, strategic and business plans, process flows, problem/issue logs, regulations, policies, and procedures to discover and/or verify requirements. This technique provides a good starting point for eliciting relevant product details. Using up-to-date and accurate documentation is important to safeguard against erroneous information. 5.3.7 Interface Analysis Interface analysis is used to define requirements by examining system interactions between users, processes, and other system components. It helps to establish relationships and boundaries by determining the input and output needs of each interfacing system. This method is useful for identifying additional stakeholders who may be impacted by changes to the system interfaces, as well as potential interoperability issues. 5.3.8 Prototypes Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before actual development. This model is used to progressively refine requirements by giving stakeholders an opportunity to test, experiment, and provide feedback. Prototyping is performed in an iterative manner that consists of prototype creation, evaluation, and revision. It continues until the requirements obtained from the prototype are sufficiently complete to move forward in the requirements process. In an adaptive environment, prototyping is considered to be an evolutionary development process that transforms the requirements into a subset of functionality that provides value. 30 ©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 38 and 39: 5 - REQUIREMENTS ELICITATION • Re
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?