Collecting requirements means finding out what stakeholders want and need, writing them down, and keeping track of them so that goals are met. The best thing about collecting requirements in project management ( PMP ) process ( requirement collection methods ) is that it helps you figure out what the product and project goals are. This step is only done once or at set times during the job. The inputs, tools and methods, and outputs of this process are shown in the figure below.
Collect Requirements: Inputs
Project Charter
The project Charter has a high-level description of the project and high-level requirements that will be used to make more specific requirements for collecting requirements in project management ( PMP ) .
Project Management Plan
Project management plan components include but are not limited to:
- The scope management plan details the process by which the project’s scope will be established and evolved.
- The requirements management plan details the collection, analysis, and documentation of project requirements.
- Understanding stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the degree of stakeholder participation in requirements activities is the purpose of the stakeholder engagement plan.
Project Documents
Input documents for requirement collection methods may consist of the following, among other examples of project documents:
- The assumption log recorded assumptions pertaining to the stakeholders, product, project, environment, and other variables that have the potential to impact the requirements.
- For projects utilizing an iterative or adaptive product development methodology in particular, the lessons learned register is a valuable resource for information regarding efficient techniques for gathering requirements.
- Users can find stakeholders who can give information about the needs by looking through the stakeholder register. It also writes down what people who have a stake in the project want and expect from it.
Business Documents
A business document called the business case can have an effect on the Collect Requirements method. It can list criteria that are needed, wanted, or optional to meet the business goals.
Agreements
Contracts can include standards for both projects and products and use in requirement collection methods.
Enterprise Environmental Factors
Some of the business environment factors that can affect the Collect Requirements process are the organization’s mindset, its infrastructure, how it manages its employees, and the state of the market.
Organizational Process Assets
Some of the things that an organization’s process assets can do to affect the Collect Requirements process are policies and procedures, as well as a store for historical information and lessons learned from past projects.
Collect Requirements: Tools And Techniques
Expert Judgment
People or groups with specialized knowledge or training in the following areas should be considered for the job: Business analysis, gathering requirements, analyzing requirements, writing requirements down, project requirements from similar past projects, facilitation, conflict management, and diagramming techniques.
Data Gathering
For collecting requirements in project management ( PMP ) process, you can use the following data-gathering methods, but they are not limited to them:
- You can come up with and collect many ideas linked to project and product needs by brainstorming.
- Interviews are a way to get information from stakeholders by talking to them directly. They can be formal or casual. People usually do it by asking both planned and unplanned questions and writing down the answers. Multiple interviewers and/or subjects may be present at the same time. Interviews are usually one-on-one between an interviewer and an interviewee. Interviewing project participants with a lot of experience, sponsors, other leaders, and subject matter experts can help you figure out what features and functions you want the deliverables to have. Interviews are another good way to get private information.
- Focus groups are a way to find out what stakeholders and subject matter experts think about a suggested product, service, or result and how they feel about it. It’s more like a conversation than a one-on-one interview, but a skilled moderator leads the group through an interactive argument.
- Questionnaires and surveys are compilations of written inquiries made to quickly gather data from a lot of people. While polls and questionnaires are best for a wide range of people, quick responses, people in different places, and situations where statistical analysis might be useful, they are not the best choice for many situations.
- Benchmarking is the process of comparing current or planned products, processes, and practices to those of similar businesses in order to find the best ways to do things, come up with ways to make things better, and get a way to measure success. When you do benchmarking, you can compare both internal and external groups.
Data Analysis
To do this, you can use data analysis methods like document analysis, but they are not the only ones. Document analysis is the process of looking over and judging any important written information.
Doing requirement collection methods uses document analysis to find information that is important to the requirements by looking through existing documentation. A lot of different kinds of documents can be looked at to help find the right standards. The following are some examples of papers that can be analyzed:
- Agreements;
- Business plans;
- Business process or interface documentation;
- Business rules repositories;
- Current process flows;
- Marketing literature;
- Problem/issue logs;
- Policies and procedures;
- Regulatory documentation such as laws, codes, or ordinances, etc.;
- Requests for proposal; and
- Use cases.
Decision Making
In the Collect Requirements process, you can use the following decision-making methods, but they are not limited to them:
Voting
The voting process is a way for everyone to make a decision together. It looks at a number of options and predicts what will happen next. You can use these methods to come up with, sort, and rank product needs. Here are some examples of voting methods:
- Unanimity : When all parties are in agreement regarding a particular course of action.
- Majority : When more than half ( 50% )of the people in the group agree with the choice, it passes. When there are an even number of people in a group, there will be a choice, not a tie.
- Plurality : A choice that is made when the biggest group of people in a group decide, even if a majority is not met. People usually use this method when they have more than two options to choose from.
Autocratic decision making
With this approach, one person is in charge of making the choice for the group after requirement collection methods.
Multicriteria decision analysis
A method that uses a decision matrix to build a structured way to evaluate and rank many ideas by setting factors like risk levels, uncertainty, and value.
Data Representation
For collecting requirements in project management ( PMP ) process, you can use any of the following data format methods:
Affinity diagrams
With affinity diagrams, you can put a lot of ideas into groups that you can then look over and analyze.
Mind mapping
Mind mapping is a way to bring together ideas from different brainstorming groups into a single map that shows where people understand things the same way or differently and helps people come up with new ideas.
Interpersonal And Team Skills
In requirement collection methods , you can use the following relationship and teamwork skills, but not just those:
Nominal group technique
The nominal group method improves brainstorming by letting people vote on which ideas are the best for further brainstorming or setting priorities. The nominal group method is a structured way to come up with ideas. It has four steps:
- They give the group a question or problem. Each person comes up with thoughts in silence and writes them down.
- As soon as someone comes up with an idea, the editor writes it down on a flip chart.
- All group members talk about each recorded thought until everyone has a good understanding of it.
- People quietly vote on which ideas are most important, using a scale from 1 to 5, where 1 is the least important and 5 is the most important. Voting could happen several times so that people can narrow down and focus on the best ideas. The votes are counted after each round, and the ideas with the most votes are chosen.
Observation/conversation
Observation and conversation are direct ways to see people in their natural surroundings and how they do their jobs, tasks, and processes. When people who use the product have trouble or don’t want to say what they need, this is especially helpful for specific processes.
Observation is another word for “job shadowing.” External observers generally do it while watching a business expert do a job. Another way is for a “participant observer” to actually do a process or procedure to find out what needs to be done but isn’t being said.
Facilitation
Focused sessions where key stakeholders get together to spell out product needs use facilitation. Workshops are a quick way to come up with cross-functional needs and find common ground between stakeholders. Well-led meetings can help people trust each other, get along better, and talk to each other better because they are interactive groups. This can lead to more agreement among stakeholders. You can also find problems earlier and fix them faster than in one-on-one sessions.
context diagram
One type of scope model is the context diagram. Context diagrams show the scope of a product by showing a business system (like a process, piece of equipment, computer system, etc.) and how people and other systems (called “actors”) interact with it. There are actors that give input to the business system, actors that receive output from the business system, and actors that give input.
Prototyping
Prototyping is a method of obtaining early feedback on collecting requirements in project management ( PMP ) by providing a model of the expected product before actually building it. Small-scale goods, computer-made 2D and 3D models, mock-ups, and simulations are all types of prototypes. When stakeholders work on prototypes, they can try out a model of the end product instead of just talking about vague ideas of what they want. Prototypes help the idea of gradual improvement by going through iterative cycles of making a mock-up, letting users try it out, getting input, and revising the prototype. Once there have been enough feedback cycles, the prototype’s requirements are complete enough to move on to the design or build step.
Collect Requirements: Outputs
Requirements Documentation
Requirements documentation describes how individual requirements meet the business need for the project. It’s possible for standards to start out general and get more specific as more information is available. Before they are baselined, requirements must be clear (they must be measurable and testable), tracible, full, consistent, and acceptable to the people who matter the most. The requirements document can be as simple as a list of all the requirements sorted by stakeholder and importance, or it can be more complex and include an executive summary, detailed descriptions, and attachments.
Many businesses divide requirements into different types, like business and technical solutions. Business solutions are for meeting the needs of stakeholders, while technical solutions are for putting those needs into action. It’s possible to group requirements into classifications, which lets more refinement and information be added as the requirements are explained in more detail. This list of categories includes:
- Requirements for business. These talk about the bigger needs of the company as a whole, like problems or chances for business, and the reasons a project was starting.
- Stakeholder requirements. These list the wants of a stakeholder or group of stakeholders.
- Solution requirements. These list the features, functions, and attributes of the product, service, or outcome that will meet the needs of the business and stakeholders. Functional requirements and nonfunctional requirements are the two other types of solution requirements:
- Functional requirements explain how the product should work. Actions, requirement collection methods , data, and interactions that the product should carry out are some examples.
- Solution requirements. These list the features, functions, and attributes of the product, service, or outcome that will meet the needs of the business and stakeholders. Functional requirements and nonfunctional requirements are the two other types of solution requirements:
- Nonfunctional requirements go along with functional requirements and describe the conditions or qualities of the surroundings that the product needs to work. Some examples are protection, performance, safety, level of service, supportability, retention/purge, and so on.
- Transition and readiness requirements. These list the short-term skills, like data transfer and training needs, that are needed to move from the current “as-is” state to the desired “future” state.
- Project requirements. These lay out the steps, methods, or other requirements that the project must meet. Dates for milestones, contractual responsibilities, limits, and so on are some examples you can use in collecting requirements in project management ( PMP ) .
- Quality requirements. These list any conditions or factors that must be met in order to confirm that a project deliverable was completed successfully or that other project requirements were met. Tests, certificates, validations, and other things are examples.
Requirements Traceability Matrix
In the requirements traceability matrix, there is a grid that shows the relationship between product requirements and the outputs that meet those requirements. By connecting each requirement to the project and business goals, a requirements traceability grid helps make sure that every requirement adds value to the business. It lets you keep track of requirements throughout the whole project, which helps make sure that the requirements that were approved in the requirements documentation are given at the end of the project. Lastly, it gives you a way to handle changes to the product scope.
References :