In this chapter, we are going to take a look at how the requirement collection activity happens.
So, lets get started!!!
Collecting Requirements:
You collect requirements by using the Collect Requirements process as shown in the picture below
As you can see, the Project Charter and the Stakeholder Register are the inputs to the Requirements Collection process.
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. Let us take a detailed look at these tools & techniques. Even though, you might be aware of these things, there is no harm in
revising them again...
Observations
Observation is the technique in which the requirements about a product or process are gathered by directly observing the user who is going to use the product or perform the process.
Interviews, questionnaires, and surveys
An interview is typically performed by asking predetermined and on the spot questions and recording the responses of the users/stakeholders. 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. It is always easier to have those people answer the questions in one shot than having to meet them all one by one and collecting their response.
Focus groups
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.
Facilitated workshops
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.
Group creativity techniques
These are group activities organized to identify project & product requirements. Some examples are:
• 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. This is one of the most widely used techniques where you let everyone come up with creative ideas and then consolidate/analyze them to choose the best suggestions. There are two specific kinds of brainstorming, which are:
o 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.
o 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. Some are:
• 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. This is usually because, people don't like to be told what needs to be done in a one way traffic kind of environment
• Unanimity - 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. Like a usual election
• 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.
Trivia:
Prototyping is a very effective way of getting new projects. Large IT organizations who serve clients, usually have senior members of their organizations (working for that client) to come up with possible enhancements to their existing IT system. These ideas are then made into small working prototypes that can be explained easily to the customer. Once the customer likes the prototype, he/she can be convinced to grant the budget required to take up this initiative as a full fledged project. In my personal experience, this method has a very good success or hit rate.
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. CMMI level 4 or higher organizations usually have predefined formats using which they prepare such documents.
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:
o Quality requirements, such as not more than three bugs per software module.
o Support and training requirements, such as that the product will be released with a manual.
o 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.
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 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:
• Requirements linked to the origin of the project, such as the opportunity 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
Trivia:
The Traceability Matrix is a valuable tool at the end of the project to validate if all the requirements have been captured in the end product. Every single entry in the traceability matrix must have been addressed by the product in order for it to be a success/completed project.
Previous: Collecting Requirements for Projects
Next: Defining the Project Scope
No comments:
Post a Comment