Elicitation

Elicitation is “the process of identifying needs and bridging the disparities among the involved communities for the purpose of defining and distilling requirements” [1]. It is a bridging activity, not a collecting one — hence elicitation, not capture.

Brooks gives the reason it is hard, and it is not the analyst’s fault [2]: “the clients do not know what they want… they almost never have thought of the problem in the detail that must be specified.” Elicitation is therefore not a phase before the work; it is the work.

1. Three classes of problem, and they fail differently

Christel and Kang group elicitation problems into scope, understanding and volatility, then classify ten published problems into those three. Seven of the ten are problems of understanding. Two are scope; one is volatility.

Ten elicitation problems sorted into scope, understanding and volatility Seven of ten are understanding. [1]

Each class has a different repair:

  • Scope — the requirements address too much or too little. Go back to the system boundary.
  • Understanding — users do not fully know their needs, misjudge what computers can do, and speak a different language from the analysts; “obvious” information goes unsaid. Get a glossary, a prototype, or someone who will ask the obvious question.
  • Volatility — requirements change. See change control.

“Our requirements are a mess” says nothing; naming the class says what to do next.

2. Why understanding fails: assumptions nobody knows they hold

“Among experts, a common disease is the presence of unstated assumptions. Because they are unstated, no one seems to notice them” [3]. The assumption is invisible because it is shared widely enough that nobody notices it is an assumption.

For example, hardware engineers building an Ethernet switching hub spent four months failing to produce a requirements document. They knew the technology thoroughly; the blocker was that “they were all using the same vocabulary in slightly different ways.” An analyst who knew nothing about Ethernet resolved it in six hours.

3. What the evidence says about technique choice

A systematic review of 30 empirical studies supports three narrow statements [4]:

What the evidence tested against what practitioners actually use Tested against used. [4]

  1. Interview by default — the most effective of all techniques tested, though not always the most efficient.
  2. Write the questions first — structured interviews produce more customer needs than unstructured ones.
  3. Avoid protocol analysis; it came last on all three measures.

Then the result that reorders the topic: when respondents do not know the domain, “it is unimportant which elicitation technique is used.” The first question is not which technique but have I got the right people in the room.

The best-evidenced family and the most-used family are not the same family. The review deliberately excluded group techniques, while a practitioner study found 83% of projects using group interaction — and only 2 of 20 using it alone [5]. There is no technique ranking to memorise.

4. What actually goes wrong, ranked

A survey of 228 organisations across 10 countries names the top three problems: incomplete or hidden requirements (109), communication flaws with the customer (93) and moving targets (76) [6]. None is a technique problem.

Requirements problems: how often cited, and how often blamed for failure Frequency is not damage. [6]

Frequency and damage rank differently. Communication flaws are cited less often than incomplete requirements but blamed for failure more often — 48% of citations against 39% — and moving targets convert at 51%. The most common problem is not the one that kills projects.

5. Two moves that work whatever technique you chose

Run a type check on what people say [3]. Read an imperative sentence as a procedure call — verb as procedure, objects as arguments. “Archive the record.” “Archive the record to the vault.” “Archive the record for the auditor.” When the same verb takes different arguments from different speakers, something is wrong. You need no domain knowledge for this check, which is why an outsider can run it.

Hence a staffing rule: every requirements team wants “at least one domain expert and at least one smart ignoramus”. Failing that, build a glossary with all stakeholders first, and treat every disagreement about a definition as a finding.

Build the model first and let its holes drive the interview [7]: “gaps in knowledge and understanding became evident by the missing parts of the model.” Interviewing first and modelling after tells you nothing about what you forgot to ask.

How solid is this?

  • Where it comes from. One systematic review (30 studies, search closed 2005, mostly student experiments), two practitioner surveys, and two experience reports.
  • What is contested. The review’s section text and its own code table disagree about which interview type is labelled structured, so only the narrower claim above is safe. Its authors bound their results to experienced participants.
  • What we do not hold. No measured effect for the type check, the glossary or the model-first approach — two projects and one case study, whose authors report the method did not transfer.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [8] on software project management.

References

  1. M. G. Christel and K. C. Kang,
    “Issues in Requirements Elicitation,” Software Engineering Institute, Carnegie Mellon University, CMU/SEI-92-TR-012, Sept. 1992.
  2. F. P. Brooks,
    “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, vol. 20, no. 4, pp. 10–19, Apr. 1987, doi: 10.1109/MC.1987.1663532.
  3. D. M. Berry,
    “The importance of ignorance in requirements engineering,” Journal of Systems and Software, vol. 28, no. 2, pp. 179–184, Feb. 1995, doi: 10.1016/0164-1212(94)00054-Q.
  4. O. Dieste and N. Juristo,
    “Systematic Review and Aggregation of Empirical Studies on Elicitation Techniques,” IEEE Transactions on Software Engineering, vol. 37, no. 2, pp. 283–304, Mar. 2011, doi: 10.1109/TSE.2010.33.
  5. C. Palomares, X. Franch, C. Quer, P. Chatzipetrou, L. López, and T. Gorschek,
    “The State-of-Practice in Requirements Elicitation: An Extended Interview Study at 12 Companies,” Requirements Engineering, vol. 26, no. 2, pp. 273–299, June 2021, doi: 10.1007/s00766-020-00345-x.
  6. D. Méndez Fernández et al.,
    “Naming the Pain in Requirements Engineering: Contemporary Problems, Causes, and Effects in Practice,” Empirical Software Engineering, vol. 22, no. 5, pp. 2298–2338, Oct. 2017, doi: 10.1007/s10664-016-9451-7.
  7. S. Fricker, M. Glinz, and R. Kolb,
    “A Case Study on Overcoming the Requirements Tar Pit,” Journal of Universal Knowledge Management, vol. 1, no. 2, pp. 85–98, Sept. 2006.
  8. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.