5.2 Collect Requirements – A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition

5.2 Collect Requirements

Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives. The key benefit of this process is that it provides the basis for defining and managing the project scope including product scope. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-4. Figure 5-5 depicts the data flow diagram of the process.

The project's success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project. Requirements include conditions or capabilities that are to be met by the project or present in the product, service, or result to satisfy an agreement or other formally imposed specification. Requirements include the quantified and documented needs and expectations of the sponsor, customer, and other stakeholders. These requirements need to be elicited, analyzed, and recorded in enough detail to be included in the scope baseline and to be measured once project execution begins. Requirements become the foundation of the WBS. Cost, schedule, quality planning, and sometimes procurement are all based upon these requirements. The development of requirements begins with an analysis of the information contained in the project charter (Section 4.1.3.1), the stakeholder register (Section 13.1.3.1) and the stakeholder management plan (Section 13.2.3.1).

Many organizations categorize requirements into different types, such as business and technical solutions, the former referring to stakeholder needs and the latter as to how those needs will be implemented. Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated. These classifications include:

  • Business requirements, which describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.
  • Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.
  • Solution requirements, which describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:
    • Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product.
    • Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
  • Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.
  • Project requirements, which describe the actions, processes, or other conditions the project needs to meet.
  • Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.

5.2.1. Collect Requirements: Inputs

5.2.1.1 Scope Management Plan

Described in Section 5.1.3.1. The scope management plan provides clarity as to how project teams will determine which type of requirements need to be collected for the project.

5.2.1.2 Requirements Management Plan

Described in Section 5.1.3.2. The requirements management plan provides the processes that will be used throughout the Collect Requirements process to define and document the stakeholder needs.

5.2.1.3 Stakeholder Management Plan

Described in Section 13.2.3.1. The stakeholder management plan is used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities.

5.2.1.4 Project Charter

Described in Section 4.1.3.1. The project charter is used to provide the high-level description of the product, service, or result of the project so that detailed requirements can be developed.

5.2.1.5 Stakeholder Register

Described in Section 13.1.3.1. The stakeholder register is used to identify stakeholders who can provide information on the requirements. The stakeholder register also captures major requirements and main expectations stakeholders may have for the project.

5.2.2. Collect Requirements: Tools and Techniques

5.2.2.1 Interviews

An interview is a formal or informal approach to elicit information from stakeholders by talking to them directly. It is typically performed by asking prepared and spontaneous questions and recording the responses. Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced project participants, sponsors and other executives, and subject matter experts can aid in identifying and defining the features and functions of the desired product deliverables. Interviews are also useful for obtaining confidential information.

5.2.2.2 Focus Groups

Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview.

5.2.2.3 Facilitated Workshops

Facilitated workshops are focused sessions that bring key stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.

For example, facilitated workshops called joint application design/development (JAD) sessions are used in the software development industry. These facilitated sessions focus on bringing business subject matter experts and the development team together to improve the software development process. In the manufacturing industry, quality function deployment (QFD) is another example of a facilitated workshop technique that helps determine critical characteristics for new product development. QFD starts by collecting customer needs, also known as voice of the customer (VOC). These needs are then objectively sorted and prioritized, and goals are set for achieving them. User stories, which are short, textual descriptions of required functionality, are often developed during a requirements workshop. User stories describe the stakeholder who benefits from the feature (role), what the stakeholder needs to accomplish (goal), and the benefit to the stakeholder (motivation). User stories are widely used with agile methods.

5.2.2.4 Group Creativity Techniques

Several group activities can be organized to identify project and product requirements. Some of the group creativity techniques that can be used are:

  • Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do.
  • Nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
  • Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.
  • Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review and analysis.
  • Multicriteria decision analysis. A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.

5.2.2.5 Group Decision-Making Techniques

A group decision-making technique is an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements.

There are various methods of reaching a group decision, such as:

  • Unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity.
  • Majority. A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
  • Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
  • Dictatorship. In this method, one individual makes the decision for the group.

All of these group decision-making techniques can be applied to the group creativity techniques used in the Collect Requirements process.

5.2.2.6 Questionnaires and Surveys

Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large number of respondents. Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis is appropriate.

5.2.2.7 Observations

Observations provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements. Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a business expert performing a job. It can also be done by a “participant observer” who actually performs a process or procedure to experience how it is done to uncover hidden requirements.

5.2.2.8 Prototypes

Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. Since a prototype is tangible, it allows stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements. Prototypes support the concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision. When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase. Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations. Storyboards are used on a variety of projects in a variety of industries, such as film, advertising, instructional design, and on agile and other software development projects. In software development, storyboards use mock-ups to show navigation paths through webpages, screens, or other user interfaces.

5.2.2.9 Benchmarking

Benchmarking involves comparing actual or planned practices, such as processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.

5.2.2.10 Context Diagrams

The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.

5.2.2.11 Document Analysis

Document analysis is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. There are a wide range of documents that may be analyzed to help elicit relevant requirements. Examples of documents that may be analyzed include, but are not limited to: business plans, marketing literature, agreements, requests for proposal, current process flows, logical data models, business rules repositories, application software documentation, business process or interface documentation, use cases, other requirements documentation, problem/issue logs, policies, procedures, and regulatory documentation such as laws, codes, or ordinances, etc.

5.2.3. Collect Requirements: Outputs

5.2.3.1 Requirements Documentation

Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.

Components of requirements documentation can include, but, are not limited to:

  • Business requirements, including:
    • Business and project objectives for traceability;
    • Business rules for the performing organization; and
    • Guiding principles of the organization.
  • Stakeholder requirements, including:
    • Impacts to other organizational areas;
    • Impacts to other entities inside or outside the performing organization; and
    • Stakeholder communication and reporting requirements.
  • Solution requirements, including:
    • Functional and nonfunctional requirements;
    • Technology and standard compliance requirements;
    • Support and training requirements;
    • Quality requirements; and
    • Reporting requirements, etc. (solution requirements can be documented textually, in models, or both).
  • Project requirements, such as:
    • Levels of service, performance, safety, compliance, etc.; and
    • Acceptance criteria.
  • Transition requirements.
  • Requirements assumptions, dependencies, and constraints.

5.2.3.2 Requirements Traceability Matrix

The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.

Tracing includes, but is not limited to, tracing requirements for the following:

  • Business needs, opportunities, goals, and objectives;
  • Project objectives;
  • Project scope/WBS deliverables;
  • Product design;
  • Product development;
  • Test strategy and test scenarios; and
  • High-level requirements to more detailed requirements.

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved, assigned, completed), and status date. Additional attributes to ensure that the requirement has met stakeholders' satisfaction may include stability, complexity, and acceptance criteria. Figure 5-6 provides an example of a requirements traceability matrix with its associated attributes.