Requirements Elicitation

Updated 24 Jul 2026

•
def
- •
  the process of actively gathering and obtaining requirements from stakeholders
- •
  also known as requirements discovery or requirements gathering
- •
  not just collecting stated requests, but discovering what is truly needed to support business processes or user activities — even when stakeholders cannot articulate it clearly
- •
  "Elicitation is about understanding what stakeholders really need, not just what they say they want." — Wiegers & Beatty (2013)
•
importance
- •
  requirements are not always clear at the start of a project — many stakeholders don't know exactly what they need
- •
  different stakeholders have different perspectives; elicitation helps unify them
- •
  errors identified early are far less costly to fix than errors discovered during or after development
•
stages / process
- •
- •
  requirements discovery — interacting with stakeholders to discover requirements; domain requirements are also discovered here
- •
  requirements classification and organization — grouping related requirements into coherent clusters
- •
  requirements prioritization and negotiation — prioritizing requirements and resolving conflicts
- •
  requirements specification — documenting requirements as input to the next iteration
•
elicitation techniques
- •
  interview — structured, semi-structured, or unstructured questioning sessions; see Interview
- •
  observation — directly observing stakeholder activities without active involvement
  - •
    reveals actual processes rather than described ones
  - •
    e.g., students observing how administrative staff manually processes certificate requests
- •
  ethnographic study — immersing in the stakeholder's work environment over an extended period. see Ethnography (Requirements Engineering)
  - •
    deeper and more comprehensive than basic observation
  - •
    e.g., a system analyst working alongside academic staff for several days to understand the complete document request lifecycle
- •
  questionnaire / survey — distributing standardized questions to many respondents simultaneously
  - •
    types — online surveys, paper surveys, telephonic surveys, one-to-one written interviews
  - •
    efficient for gathering input from a large number of respondents
- •
  workshops / focus group discussion (FGD) — structured group discussions to gather and validate ideas collaboratively
  - •
    stages — choose topic → gather participants → set schedule → prepare guiding questions → reach decisions → write and distribute meeting minutes
- •
  document analysis — reviewing existing documents: SOPs, reports, previous project documents, regulations, organizational charts
- •
  prototyping — presenting an early version or mockup of the system to users to gather feedback
  - •
    e.g., a UI wireframe shown to potential users, who then provide structured input
•
strategy for choosing techniques
- •
  use interviews for key stakeholders who hold significant domain knowledge
- •
  use workshops when collaborative idea generation is needed across many parties
- •
  use observation when there is a gap between what stakeholders say and what they actually do
- •
  use prototyping for new features that are not yet clearly understood by stakeholders
•
common problems
- •
  stakeholders don't know what they really want
- •
  stakeholders express requirements in their own domain terms, not technical language
- •
  conflicting requirements across different stakeholders
- •
  organisational and political factors influence what requirements are surfaced
- •
  requirements change during the analysis process
•
work products
- •
  statement of need and feasibility
- •
  bounded scope statement
- •
  list of customers, users, and stakeholders
- •
  description of the technical environment
- •
  list of requirements organized by function
- •
  preliminary use cases or usage scenarios
- •
  any prototypes developed during elicitation
•
related

Linked references 15

◌ Explore connections in Graph view