Definition: Requirements elicitation is the art of determining the needs of stakeholders.
Other names: (whose meanings may have subtle differences) include systems analysis, problem analysis, needs analysis, (plain) analysis, inception, and mission needs assessment.
Titles of those who do it: systems analyst, problem analyst, (plain) analyst
How (generally) is it done? By listening to and/or observing stakeholders. But doing it effectively usually entails doing things (such as providing the stakeholders with an appropriate environment and stimuli to which to react) that make the stakeholders provide more information than they otherwise could/would.
Who are the stakeholders? They include anyone (even organizations or "systems" could be included) who will be affected by the presence of the proposed new/enhanced system.
Here is a classification of typical stakeholder groups:
Note that marketing and development personnel tend to dislike each other. Marketing mistrusts development because product delivery is consistently late and the latter tend to be negative towards any new/changing requirements. Development dislikes marketing because the latter is always putting pressure on them to do more work in less time.
Determining requirements is nontrivial, in part because the stakeholders tend to be a heterogeneous lot. (The fact that Extreme Programming relies upon a single customer being available all the time (to interact with the developers as they program) is one of its weaknesses, as a single customer is typically not in a position to speak for all stakeholders.)
A major goal of elicitation is to come to an understanding of the wants/needs/problems of the user community. Because these are constantly changing, elicitation should continue on an ongoing basis. (Of course, the level of elicitation activity is not constant, as it is much higher during the planning stages for a new product or product release than at other times.)
Perhaps a more accurate title for this section would have been "How Much Elicitation To Do?"
The purpose of building software is to help solve problems. But one cannot (or at least is very unlikely to) solve a problem without understanding it. The purpose of requirements elicitation is to (at least begin to) discover what the problem is. Hence, if an insufficient effort is put into elicitation, it is very likely that the system that is eventually built will be the wrong one, leading to unhappy users/customers.
On the other hand, it is possible to spend too much effort in elicitation, which will result in too much time being taken to finish the project. (Davis does not indicate what would signal that too much effort is being spent on elicitation, however.)
One of the tricks to performing just enough elicitation is to select the right techniques and use them wisely. Different projects call for different techniques.
The general rules for doing good elicitation (whatever the technique) are similar to those that apply in any situation involving communication.
The skills needed to perform the various elicitation techniques tend to come pretty naturally to many people, but the know-how to choose the right technique(s), based upon the situation, seems not to come as naturally.
Here's a survey of common elicitation techniques and an indication, for each one, of what kind of situations it is effective in.
Such knowledge (possessed by stakeholders, but not by the elicitators) can lead to missed requirements (because no stakeholder thought it necessary to even mention some important fact).
Interviewing is the technique of choice when there are only a small
number of people who know a lot about what you are trying to learn.
(Note: Wouldn't it be more accurate to characterize the situation
this way: "Interviewing is the technique of choice when it is possible
to learn a lot about the subject from a small number of people."?
(This way of saying it does not exclude the possibility of there being
lots of people all of whom have a lot of knowledge about the subject!)
End of note.)
Many variations of facilitated group meetings exist, including joint application development (JAD), requirements workshops, and others.
Facilitated group meetings are the technique of choice when there are something like five to twenty-five people each of whom knows a little about what you are trying to learn (but their knowledge does not overlap too much). The idea is that having such a group session will allow them to fill in the holes in each other's understanding, to the point that all of them will end up understanding even more than the sum of what they understood before!
It's not a good idea to invite to such a session someone who knows a lot about the subject, because she is likely to dominate the session.
Among the reasons for conducting a group session using this approach are
CSCW is the technique of choice under similar conditions as facilitated group meetings (see above), but when the latter is not practical due to the infeasibilty of gathering all the stakeholders at one place. Or when stakeholders' anonymity is important.
Because much of the communication that occurs in group meetings is non-verbal (e.g., body language, facial expressions), there is something lost in using CSCW rather than a group meeting.
Observation is called for especially when failing to uncover a requirement could have life-or-death consequences or when the goal is to automate a process currently carried out by highly-skilled professionals.
It is the technique of choice when answers are needed to a set of very specific questions. A good time to use them is after a group meeting or interviews, in order to validate that the requirements identified by a relatively small set of stakeholders (i.e., those participating in the group meeting or in interviews) is consistent with what the larger population of stakeholders wants.
Davis emphasizes that it is important to build a prototype quickly but that it is rarely a good idea to allow the prototype to "evolve" into the final software system (even after several iterations). (After all, "build it quickly" and "build it to be a quality product" are not usually compatible.)
In the early 1990's, Ivar Jacobsen introduced the related use case concept into the realm of OO development. And story is the term often used in connection with agile methods.
Davis says that the sequence diagram of a use case documents a scenario. (Figure 2-4, page 57, for example, applies to the fighter pilot scenario.)
Karl Wiegers, a very well known writer about requirements, says that what distinguishes use case, scenario, and story is the level of abstraction/generality:
Use cases/scenarios are not so much methods of elicitation as modeling notations. They can be very effective in group meetings and interviews. For example, each answer to the question "What features do you want?" could serve as the basis for a use case.
In an (elicitation) interview, the answer to a question such as "What steps do you follow when X occurs?" is likely to describe a scenario.
Scenarios/use cases are applicable for any system that has a lot of interactive features. Wiegers points out that they are not particularly good for systems involving data warehouses, batch processes, embedded control software, or computationally intensive applications. (For some kinds of apps (such as traffic/pedestrian lights at a highway intersection), event-response tables are much better.) (Use cases wouldn't help much in describing Naur's text formatting problem!)
Davis warns, though, that the stakeholder will be "turned off" if the notation used (or the language used in discussing it) is not easy to understand.
The result of elicitation is a list of candiate requirements. (See Figure 2-5 on page 60 for a short list of requirements for a traffic signal.)
At some point, the list should be organized into a hierarchical structure. (See Figure 2-6 on page 61.)