The expectations, needs, and objectives of the customer and stakeholders are identified, clarified, documented, prioritized, and managed through activities the Collect Requirements Process.
The success of the project is directly tied to how well these activities are performed because requirements are what drive the project’s scope, which is central to all project management activities.
Collect Requirements Process Decomposition
Collect Requirements Process: Inputs
- Project charter
The project charter formally authorizes the project and the project manager. It also provides the business case, objectives, and success criteria of the project.
The charter provides the framework for project planning activities.
- Stakeholder register
The stakeholder register identifies all project stakeholders and contains attributes such as the person's name, title, position, project interest, expectations, and influence.
Collect Requirements Process: Tools and Techniques
Interviews are any formal or informal interaction technique involving questions.
- Focus groups
Focus groups are moderated discussions with a group of people usually conducted informally and centered on well-defined subjects.
- Facilitated workshops
Facilitated workshops are interactive discussions with participants usually conducted informally to encourage an open dialogue.
Facilitated workshops are central to many different methodologies, and include Quality Function Deployment, Voice of the Customer, and Joint Application Development.
- Group creativity techniques
These techniques encourage lateral thinking for creative problem-solving or identifying innovative solutions. They include brainstorming, idea and mind mapping, affinity diagrams, and nominal group technique.
- Group decision-making techniques
These are group techniques for reaching a decision. At the root, they involve decisions based on unanimity, majority, plurality, or dictatorship.
- Questionnaires and surveys
These are paper- or electronic-based questioning to collect responses from a group of people. These are useful for obtaining a large number of results relatively quickly.
These are interactive participation or passive observation to collect data, such as viewing how a process is performed.
It's useful for defining and measuring existing processes, identifying improvements, and collecting requirements.
Prototypes are models or designs of a product, usually with limited functionality. They're useful for providing a tangible example of a concept or idea so that others can provide feedback.
Collect Requirements Process: Outputs
- Requirements documentation
The product scope and project objectives are broken down into requirements and described in a collection of requirements documentation that's applicable to the project and requirement type.
Requirements can be documented and described in a number of different levels (executive, summary, and detailed) and in a variety of methods (textually or visually).
- Requirements management plan
The requirements management plan describes how project requirements from the customer, stakeholders, and project team will be collected, organized, prioritized, tracked, and measured.
It is a subsidiary component of the project management plan.
- Requirements traceability matrix
All requirements are logged onto a requirements traceability matrix. The main purpose of the matrix is to enable every requirement to be logged and attached to a project objective or to another requirement in a hierarchical manner.
The project charter helps by providing a starting reference for the initial requirements because it contains the project objectives and statement of work, but it shouldn’t be relied upon as the only source.
There are many different methods for eliciting requirements, but they all center around interactions with the sponsor, customer, and stakeholders, and most projects will need a combination of different methods performed several times.
In practice, the techniques used to define the product scope, requirements, and the project scope are often performed simultaneously since all are closely related.
Passive observation of how people perform their processes can be helpful as can “participant observation” by actually performing a process or procedure to see how it’s done.
Interviews, brainstorming, focus groups, and workshops will give forums for the stakeholders to express themselves, and skilled project managers, team leaders, and business analysts will view themselves as liaisons between the stakeholders and project teams and rely on good communication and listening skills to convert expressed needs into project requirements.
Regardless of the type of product, service, or result the project is developing, collecting requirements is a collaborative effort with a lot of clarification, translation, and restatement of requirements between all parties.
Our purpose isn’t so much to lead the discussions during these meeting but rather to serve as a facilitator:
- Restate what was said. This is helpful not only to make sure that we’ve grasped the speaker’s meaning, but it can also help others in the group better understand by hearing it phrased differently.
- Avoid acronyms and jargon unless we’re absolutely sure everyone understands exactly what the terms mean.
- Withhold judgment while another is talking.
- Ask probing and direct questions that require more than simple yes or no responses, and give the person time to respond in his or her own manner.
- Make sure everyone has an opportunity to provide his or her thoughts.
- Listen fully to what everyone is saying, and watch non-verbal cues. If we suspect someone isn’t agreeing with what is being said, give him or her an opportunity to discuss why.
It’s better to bring these issues out in the open rather than have somebody disagree later after everything has been approved.
In all likelihood, there will be more requirements found than what can be accomplished within the project’s constraints.
Time, money, and resources will limit what requirements can be accepted, so a method of prioritizing and agreeing upon requirements should have been defined in the requirements management plan.
When only a finite amount of requirements can be addressed, prioritization can often bring out the worst qualities in people since everyone will have a different view of which requirements are mandatory, which are essential, and which are merely desirable.
The group may need different decision-making techniques for different categories of requirements, but in some manner, the requirements will be decided by:
- Unanimity: Every single group member agrees on the same option
- Majority: The option with more than 50% of support from group is chosen
- Plurality: The option with the largest block of support is chosen (even if the largest block doesn’t have a majority)
- Dictatorship: One person chooses the option.
There are many methods and tools that can help with the prioritization process by introducing some objectivity into the decision-making process.
Scoring matrices, decision trees, and voting methods are very frequently used.
Two easy voting methods are:
- Numerical Assignment Technique (Joachim Karlsson)
Participants are asked to rank requirements on a scale of 1 to 5 indicating the importance of the requirement. The final ranking of requirements is the average of all responses.
- 100-Point Method (Leffingwell and Widrig)
Each stakeholder is given 100 points that he or she can use to vote for any number of requirements. There are no limitations, so a voter could put all 100 points on a single requirement or split his or her votes in any manner.
Requirements Traceability Matrix
Projects often have several different types of requirements.
There’ll be requirements needed:
- To achieve the business objectives.
- To create the deliverables.
- To conform to product design or development specifications.
- To meet project objectives.
- To meet project management needs.
- To develop testing strategies for deliverables..
Requirements are documented in a method that’s specific to the project.
For example, some projects may rely on textual descriptions, use cases, and process maps while another project may require schematics.
But in addition to documentation, requirements are logged onto a requirements traceability matrix.
The main purpose of the matrix is to enable every requirement to be logged and attached to a project objective or to another requirement in a hierarchical manner.
This makes sure that every requirement adds value that the customer and stakeholders need, and it exposes the relationships requirements have with each other.
Knowing the relationship between requirements makes sure that changes can be accurately evaluated for whether they support the project’s objectives.
To be useful, at a minimum, the requirements traceability matrix should contain:
- A unique identifier for the requirement
- A textual narrative of the requirement
- The requestor and owner of the requirement
- The requirement’s priority
- Relationship to other requirements
- Requirement’s status (whether under review, approved, canceled, deferred, and so on)
- References to other documentation about the requirement.