Requirements Elicitation
Requirements elicitation is the process of gathering requirements, typically from members of the community or communities that will eventually use the product.
There are many techniques that can be used for elicitation, the most popular being those based on face to face meetings between requirements engineers and users. Forms of such sessions may be referred to as interviews, workshops and meetings.
A major challenge to development projects is that of gaining sufficient access to the most appropriate representatives of the business and user community. The Prince project management method mandates the inclusion of a ‘senior user’ in the ‘project board’. The senior user is supposed to ensure that project teams do get the necessary level of support from the users; the senior user also has the authority to make it happen. This is a great idea, but unfortunately, the senior users may not receive adequate training in exactly what is expected of their role, and they may exist on the project in name only - an opportunity wasted.
Another challenge is that of ensuring that the project team and the users understand each other. There are many techniques to support this need. Among the most popular are the use of scenarios and use cases. We should also ensure that we use the language of the user. The creation of models and use of devices such as prototypes may help to create visibility of the requirements; users are known to define requirements only to reject them once they can see what the result is. On a personal level, it is vital that the requirements engineer have adequate experience of the business (or administrative) domain.
The amount of elicitation and the formality of recording the requirements varies considerably between organisations and projects. It can useful to adopt a risk based approach to requirements – the higher the risk the greater the effort and the greater the formality. For environments in which requirements engineers, users, business representatives (owners of the business case) and developers work closely together, know each other well and have considerable joint experience ofthe business and the organisation, the risks may be relatively low; informal approaches may be warrented. Where the project is being done offshore with an untried supplier and according to a contract, the potential risks will probably justify greater formality.
In all environments, the presence on the project team of real business experts can be valuable. The user community in a given organisation may have experience limited by their current processes, systems and technology. It is possible to be blinkered when one is not fully up to date with the latest and best ways of doing things.