Collecting Requirements for the Project

The project success is defined as the delivery of the planned outcome with full scope, on time, and within the budget. To realize this success, it’s very important that there is an agreement on what exactly is being delivered with what requirements. A requirement is a condition, characteristics, or a capability that a specific outcome of the project must have. For example, an online banking website is an outcome of the project, and the condition that it must record the number of users who have visited the site each day is a requirement. Requirements may come from different sources, such as from standards, specifications, and contracts. Stakeholder expectations and needs often materialize into requirements as well.

NOTE Generally speaking, project requirements should include the "product" requirements. However, many organizations distinguish between project requirements and product requirements, in which case project requirements include strictly project-related requirements, such as schedule and delivery requirements, business-related requirements, and other project management requirements, whereas product requirements include the product-related requirements, such as requirements related to performance, security, and defects.

You need to do some requirements planning, which includes:

◆ Defining and documenting the project requirements

◆ Defining and documenting the product requirements

◆ Developing a plan to manage the requirements— the requirements management plan

You do all this in order to determine and fulfill stakeholder expectations and needs.

TIP How effective you are in capturing requirements will determine how effective you will be in getting agreement on these requirements from the stakeholders and in managing the stakeholder expectations and needs. Also, these requirements go right into the foundations of the WBS, along with the deliverables. Therefore, collecting requirements effectively is critical for the success of the project.

You collect requirements by using the Collect Requirements process (illustrated below) in terms of input, tools and techniques, and output. During project initiation, you created the project charter and the stakeholder register. These two documents are the input to the Collect Requirements process. Recall that the project charter contains the high-level product description and requirements. You get information about the stakeholders from the stakeholder register to identify those stakeholders who can provide information about requirements.

The Collect Requirements process: input, tools and techniques, and output.

Collect Requirements Process.jpg

With these input items at your disposal, you use some tools and techniques to collect the requirements.

Tools and Techniques for Collecting Requirements

You collect the needed information about the requirements by using various techniques, such as observations, interviews, questionnaires and surveys, focus groups, facilitated workshops, group creativity and decision-making techniques, and prototypes. These tools and techniques are described here.

Observations. Observation is the technique in which the requirements about a product or process are gathered by directly observing the user using the product or performing the process. In other words, the process or product is observed in action in the real world with people on the job. For that reason, this techniques is also called job shadowing. Depending on the situation, the observer can simply observe the user doing the job, or he or she can participate in it.

Interviews, questionnaires, and surveys. An interview is typically performed by asking predetermined and on-the-spot questions and recording the responses. Depending on the situation, interviews may take several forms, such as one on one, multiple interviewees, or multiple interviewers. For example, by interviewing subject matter experts and individuals who ran similar projects before, you may identify and define some features and functions of the project deliverables.

When you want to cover a large number of respondents quickly, questionnaires and surveys will be more appropriate. These are based on written sets of questions.

Focus groups and facilitated workshops. A focus group is a set of prequalified stakeholders and subject matter experts that are brought together with the purpose of learning about their opinions, expectations, and attitudes about a product, service, or result that will be the output of the project. Generally speaking, a moderator facilitates the interactive discussion to make this experience more conversational than one-on-one interviews.

A facilitated workshop is a session that brings together the cross-functional stakeholders to focus on defining product requirements. It generally proves to be an effective technique for quickly defining cross-functional requirements and reconciling differences among the stakeholders regarding the requirements. These workshops also help in developing trust and improving communication among the stakeholders and therefore fostering relationships that will help the project to succeed.

A Map Day is a facilitated workshop used at leading organizations like Intel and Nasa to quickly plan and launch projects. BYUH Enactus also uses this technique which focuses on creating a complete WBS in a single meeting of 2 hours- 2 days depending on the complexity of the project.

Group creativity techniques. These are group activities organized to identify project (including product) requirements. Here are some examples of such activities:

◆ Affinity diagram. In this technique, a large number of ideas are classified into different groups by using some criteria. This facilitates an effective and efficient review and analysis.

◆ Brainstorming. This is a creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue without any immediate evaluation of these ideas. The evaluation and analysis of these ideas happens later. Obviously, this technique can also be used to collect requirements. Here are examples of two specific kinds of brainstorming:

◆ Idea/mind mapping. This is an individual brainstorming technique in which a multitude of ideas are mapped around a central or key concept in order to expose commonalities and differences among ideas and generate new consolidated ideas. Mapping also helps in classifying ideas into groups by discovering relationships among them. In addition to project management, this technique is also used in other areas, such as personal, family, and education. It helps in summarizing, clarifying, and revising ideas.

◆ Nominal group technique. This is the brainstorming technique with voting. The voting process is used to rank the ideas generated by brainstorming for further brainstorming or for prioritization.

◆ Delphi technique. This refers to an information-gathering technique used for experts to reach a consensus while sharing their ideas and preferences anonymously.

Group decision-making techniques. Group decision making is, in general, a process used to collectively assess and evaluate multiple alternatives in terms of expected outcomes. The decisions usually result in taking specific actions. This general technique can also be used to identify/generate, classify, and prioritize project requirements, including the product requirements. To reach a group decision, multiple methods are available, including the following:

◆ Dictatorship. One person has the authority to make the decision. While this expedites the decision making, it may not be the most effective decision-making method.

◆ Unanimity/Consensus. This is opposite of dictatorship: A decision is accepted only if everyone agrees.

◆ Majority. A decision must be supported by more than 50 percent of the members of the group.

◆ Plurality. The alternative supported by largest number of members wins even if this number does not make a majority. This situation arises when there are more than two alternatives. Plurality with two alternatives is simply a majority method.

Prototypes. A prototype is a working model of a product put together without developing the actual product. Organizations usually make prototypes for developing proof of concept. Prototypes can also be used to collect requirements by experimenting with the prototype and by letting stakeholders experiment with it and offer feedback. A prototype is more tangible than the abstract idea of a product. Prototypes can be improved and modified based on feedback from the stakeholders. In this way, prototypes support the progressive elaboration process of developing requirements.

You use one or more of these techniques to generate the output of the Collect Requirements process.

Output of Collecting Requirements
During this process of collecting the requirements, you will produce two documents: the stakeholder requirements document and the requirements management plan.

Requirements documentation. Also called the stakeholder requirements document, this document consists of a list of requirements and any necessary detail for each item in the list. The details of the requirements and the format of the document depend on the project and the rules within the performing organization. Following are some essential elements of the requirements document:

◆ Sources of requirements. This describes the overall project outcome to which the requirements apply and the purpose of the project, such as the opportunity being seized or the business problem being solved.

◆Types of requirements. For effective management, you can organize the requirements into different categories using some criteria. For example, all requirements can be broadly organized into two categories: functional requirements, referring to the functionality of the project outcome, and nonfunctional requirements, such as compliance, compatibility, and support. Furthermore, these broad categories can be subdivided into more specific types, such as the following:

◆ Quality requirements, such as not more than three bugs per software module.

◆ Support and training requirements, such as that the product will be released with a manual.

◆ Sustainability requirements, the minimum requirements to ensure the customer can maintain the benefits of the project after the project is complete.

◆ Requirements that are based on assumptions and requirements that lead to constraints— for example, phase one of the project must be completed before a specific date.

◆ Impacts of the requirements. This element describes the impact of requirements on the project and on entities external to the project, such as different groups in the organization.

CAUTION The requirements must be well defined and not vague. As a test, always ask this question: How will I be able to measure or test it? Also, make sure that a requirement is consistent within itself and with other requirements.

The requirements that you collected will need to be managed.

Requirements management plan. This plan documents how the requirements will be managed throughout the project life, which includes how they will be documented and analyzed.

The requirements management plan includes the following elements:

◆ Prioritization. The process and criteria to prioritize the requirements.

◆ Configuration management. How the changes to the requirements will be processed: initiated, analyzed, tracked, and reported.

◆ Reporting. How, by whom, and to whom the activities related to the requirements will be reported.

◆Traceability. What the traceability structure of the requirements will be— for example, which attributes of a requirement will be captured on the traceability matrix.

Requirements are usually tracked by using a tool called a requirements traceability matrix.

Requirements traceability matrix. As the name suggests, the requirements traceability matrix is a table that traces each requirement back to its origin, such as product or business objective, and tracks its progress throughout the project life. Linking a requirement to the business objective underlines its value. Tracking the requirement throughout the lifecycle of the project ensures that it will be delivered before the project is completed. So, this table becomes a very useful tool to remind the team how important these requirements are, when they are going to be implemented, and how they are progressing in implementing them. The requirements traceability matrix includes the following links:

◆ Requirements linked to the origin of the project, such as the opportunity, problem statement or customer or business need

◆ Requirements linked to the project objectives and deliverables

◆ Requirements linked to the project scope and the product scope

◆ Requirements linked to the product design, development, and testing

◆ High-level requirements linked to their details

◆ The attributes linked to a requirement

The key information about a requirement can be stored in the form of its attributes. Here are some examples of attributes of a requirement: a unique identifier, description, owner, source, priority, status, and completion date.

With the definition of the project determined during project initiation and the requirements collected during planning, and with the project scope management plan in your hands, you are all set to begin defining the project scope.