When observing users, record the actions and activities that take place. What already works well? What causes users difficulty? Note the obstacles users must routinely overcome. Frequently overlooked, document analysis is another highly effective technique for gathering requirements. The latter will aid you in determining where the business needs revealed earlier—through your interviews, questionnaires, and user observation—are not being met. Nuggets of information on why the existing system works as it does are often buried within the specifications and design documentation.
The insights gained from document analysis can help you formulate further questions and evaluate the completeness of your requirement set. Thorough interface analysis—really understanding the interactive context of the system— will frequently uncover requirements not readily visible to users.
Brainstorming can be performed as part of a workshop see technique 7, which follows or on its own, in either large or small groups. In your brainstorming session, consider different parts of the system individually. Explore various what-if scenarios and blue-sky ideas. The general idea is to break away from existing conventions. Consider visionary ideas for pushing current boundaries. Useful tools for brainstorming sessions include whiteboards, mind mapping software, and empathy maps the latter for exploring user needs.
You will need to resolve these issues, however, before implementation begins. Once you have a broad set of candidate requirements defined and organized, convene your stakeholders and hash through these candidates together. Gather additional detail. Give a fair hearing to opposing views. Grant everyone ample opportunity to provide the rationale for their positions.
Seek to resolve discrepancies and conflicts, gain consensus, and validate your requirements. These activities are vital to ensuring your system will best meet the needs of all users and stakeholders, not just the most vocal groups.
Some systems—certain kinds of enterprise software, like ERP, for example—must meet the needs of a variety of user types. Role-play can help to ensure that the needs of all users are being met. In a role-play session, different people take the roles of the different user types. Having the various roles interact with one another helps examine individual system requirements from different perspectives and generates discussions and new ideas. In effect, role-play is an additional brainstorming technique.
It is a good way to gain a solid understanding of how the various parts of the system need to function to support the overall process. Once you have high-level functional requirements in place, it is a good idea to explore a variety of use cases and scenarios. Use cases are the specific, individual business objectives the system must accomplish and the various situations in which a given feature or functionality will be used.
They describe the various external entities that act on the system and the specific interactions they have with the system to accomplish the business objective. Use cases are expressed as step-by-step lists of tasks performed during a process. Collect requirements process is the second process of scope management knowledge area. In order to define the scope, the requirements of the stakeholders must be collected first.
The main purpose of the collect requirements process is gathering stakeholder requirements in a project. Requirements of the project stakeholders must be gathered in the project and managed properly. After requirements are finalized, these must be included in the scope and tracked throughout the project. Also, how requirements are met with the project deliverables must be demonstrated to the project stakeholders to complete a project successfully.
Note that, there will be several requirements in a project and we just listed three of them here to illustrate requirements of a project in your mind. High-level requirements of a project are defined in the project charter. The project charter is created in the project initiation. As long as high-level requirements of a project are determined, these are included in the project charter.
But, new requirements will be received later and requirements will be gathered and finalized during planning. Therefore, collect requirements process involves more specific inputs. Collecting Requirements is a crucial activity in project management.
Because requirements of a project define the project scope. And any weakness in requirements management will cause scope issues respectively. In order to collect requirements from project stakeholders, several tools and techniques are used. Interviewing is the first collect requirements technique.
It can be done through a meeting, through a phone call or through e-mails. In this collect requirements technique Project Manager interviews the stakeholders to get their requirements. There can be a checklist, a list of questions or project manager can just ask the stakeholders to express their expectations from the project in a free form. Project manager notes down and stores the requirements received from the project stakeholders.
For instance, you can organize a meeting with executive directors in your company to get their requirements first, and then organize a separate meeting with the functional managers to get their requirements. In facilitated workshops, stakeholders with different perspectives are brought together.
You can bring analysts, software developers, test engineers, operation team, and customer together. Each group of project stakeholders will look to the project from their perspective and express their requirements. For instance, operation team will consider operational aspects, the customer will express business requirements, software developers will state the technical requirements.
Fourth collect requirements process technique is called Brainstorming and it is actually a Group Think. Because several people come together to list requirements of a project. And during the meeting, new ideas are generated from existing ideas. This helps to identify new requirements. This is actually a collect requirements process technique to prioritize ideas rather than generating new requirements.
In nominal group technique, meeting participants rank the most successful ideas. This helps to focus on more valuable or prioritized ideas first in generating project requirements. Nominal group technique is usually used in brainstorming meetings. Techniques describe how tasks are performed under specific circumstances.
A task may have none or one or more related techniques. A technique should be related to at least one task. Brainstorming is used in requirement gathering to get as many ideas as possible from group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Reviewing the documentation of an existing system can help when creating AS—IS process document, as well as driving gap analysis for scoping of migration projects.
In an ideal world, we would even be reviewing the requirements that drove creation of the existing system — a starting point for documenting current requirements.
Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness. A focus group is a gathering of people who are representative of the users or customers of a product to get feedback.
This form of market research is distinct from brainstorming in that it is a managed process with specific participants. Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. User centric design approaches are very effective at making sure that we create usable software.
Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them.
0コメント