All software projects do requirements elicitation, explicitly or unintentionally. Requirements elicitation is a fancy term for information collection and evaluation performed in the problem domain. Developers who search Stack Overflow or other media for a programming solution are not doing elicitation, they work in the solution domain. Most projects do ad hoc elicitation when systems architects meet project managers and customers to discuss topics. These meetings are mostly unstructured, undocumented, and has a tendency to touch upon the same issues again and again. They provide no clear and tangible outputs. Dissemination of information is informal, contradictory, and only manages to increase the overall uncertainty. Elicitation activities that are conducted professionally have been prepared in advance; they are structured and have a documented output; they enable and drive real progress by providing valuable input to requirements specification activities, to test planning and execution, and to development activities in general.
The key words and terminology used in this text were defined and used in the early ’90s by the Software Engineering community. No concepts or thinking is invented in this text.
Persons who are assigned to elicitation activities should have certain characteristics. These persons are ”people persons” who enjoy talking to other people. Elicitation can be described in layman terms as a blend between what is normally done in sales and what is done on a higher abstraction level in engineering. People who become responsible for elicitation should be curious, open, friendly, structured, good at communicating, and experienced in their field. Elicitation meetings can result in tough decisions, which need to be clearly communicated in a non-hostile manner to avoid future misunderstandings. Only a selected few should participate in each meeting; who depends on what type of expert knowledge is required. There is a tendency to invite everyone to every meeting, but ”Design by committee” is a bad way to address elicitation and should be replaced by smaller meetings with fewer participants who can focus on specific topics. The key is to document the results and disseminate it to concerned parties, both at the customer and project sides. Despite all good intentions, elicitation meetings can occasionally derail and end up producing little. A solution is to add or replace people on both sides. Unattended friction and interpersonal conflicts will result in rework, late deliveries, possible ill health, and people who abandon the project.
There are usually several elicitation activities to select from during the planning phase, some are optional while others are essential, but which ones depend on the context. A non-optional activity is to describe stakeholder profiles. The profile descriptions act as input to other elicitation activities: what activities to do; who should attend; profile gaps to be filled by real people and identified risks to address. A profile description contains normally a title – such as User, Tech Support, Manager etc. – and a short description of what each profile does and their level of expertise. The profile is not a description of individuals at the customer side but a template that sets the bounds for further work. It can inform the customer what educational activities need to be addressed to operate the product.
The most frequent elicitation activity is open-ended interviews. Questions are prepared in advance, and each interview can be conducted as a one-to-one interview or as a meeting with several participants. Meetings with several attendants tend to be open discussions, where prepared questions are injected in the conversation when needed, but it’s really up to the responsible to decide how formal or informal things should be. Each meeting is documented in minutes of meetings (MoM). Structured interviews are much harder to do and requires a lot more experience to pull off. They may not suit the project as they can introduce a tone of formality. The MoM acts as a major input to the requirements specification activity.
Observations are about visiting stakeholders in their natural work environment. It can be the assembly line in a car factory, a vertical storage system used by logistics, nurses and doctors working with patients, or law enforcement officers in the field. Observations can be done without interacting with the involved persons, or it can be done by asking prepared or improvised questions. Notes should be taken, and depending on the integrity and privacy of the situation, the observer may take photographs and videos.
A rich source of information is documentation that is available. It can be in the form of role descriptions, organisational charts, process descriptions, product documentation, service descriptions, business models, technical and legal standards and operational specifications in general. The information from these sources act as input to elicitation meetings and to requirements specification activities.
The most informal elicitation activity is to examine one’s own conscious thoughts, known as Introspection. It stands in contrast to open-ended interviews, observations and other activities that require interaction with people or systems.
Requirements elicitation will result in a vocabulary that is used throughout the project. Terminology is a practical tool to avoid misunderstandings. It includes made definitions, identified actors in the system, a glossary, and the names of provided services. Terminology is also a tool for programming, when instance variables and methods should be named in new classes. Everyone is helped by consistency and a clear language.
Requirements Modelling is not part of the elicitation activities per se, but models can be used during elicitation work to ask relevant questions and to give an understanding for a specific problem. These models can be paper-based or computer-based. A very common model is user scenarios, where actors and systems interact. User scenarios can be described with tables that contain plain text, as sequence charts, or finite-state machines. One example of a computer-based model comes from the development of the first iPhone. To arrive at the right icon size, an Apple engineer created a game for co-workers to hit different sized icons that popped up randomly on the screen. Depending on the success rate the right icon size was picked.
To succeed with requirements elicitation depends on the leadership and maturity of the organisation. Managers who don’t care end up with subordinates that don’t care. A certain amount can be achieved through training, but success and failure is mostly about how people look upon their own situation, if they will benefit or suffer from made changes.