To adequately determine the requirements and scope of a project, it’s not enough just to sit down with the client and ask a few questions. There’s a lot of groundwork that needs to be done before even one line of code or an image is created. In our previous article about Gathering Requirements, we walked through a checklist of questions that needs answers. Depending on the size of the project, here are a few suggestions as to how to go about eliciting requirements.
- Interviews: Interviews are good for getting people to explore issues. Semi-structured or unstructured interviews are often used early on to elicit scenarios. In the context of establishing requirements, it is equally important for development team members to meet stakeholders and for users to feel involved.
- Questionnaires: Surveys can be used for getting initial responses that can then be analysed so you can get a wider perspective, or perhaps identify people you can interview later on about particular issues that have arisen elsewhere. Or it may simply be used to obtain views and opinions about specific suggestions.
- In-house focus Groups: These are ideal for establishing a consensus view and highlighting any potential areas of conflict or disagreement during requirements gathering. On a social level it also helps for stakeholders to meet with designers to express their views in public. It is not uncommon for one set of stakeholders to be unaware that their understanding of an issue or a process is totally different from another group’s.
- Direct Observation: Observing participants in their natural setting is used to understand the nature of the tasks and the context in which they are performed. Sometimes observations are carried out by trained observers who record their findings and report them back to the design team, more often on smaller projects the observation is carried out by a member of the design team.
- Studying Documentation: Legacy manuals and other documentation are a good source of information about what steps are involved in an activity and any regulations governing a task. Though such documentation should not be used as the only source. Everyday practices may have been devised by those concerned to make the procedures work in a practical setting . Taking a user-centred view of development means that we are more interested in the everyday practices rather than an idealised account.
- Researching Similar Products: Observing and analyzing similar products or businesses can make things easier when trying to establish the requirements for your own product.