Skip to main content

Understanding customers; elicitation guidelines

Short answer

Gaining clear understanding is hard because customers often have unclear scope, unsure needs, implicit knowledge, conflicting demands, and evolving requirements. Guidelines include: assess feasibility, identify stakeholders, define constraints, use multiple elicitation methods (interviews, workshops, prototypes), hold JAD with a facilitator, record rationale, and validate early.

Why is it so difficult to gain clear understanding of what customer wants? What are the guidelines for requirement elicitation process?

Why it is difficult to understand what the customer wants

It looks simple to ask the customer what they want, but in practice it is one of the hardest parts of software engineering. Pressman groups the reasons into three types, and Sommerville adds several more.

  1. Problems of scope: the boundary of the system is not well defined, or customers give unnecessary technical details that confuse rather than clarify the overall objectives.
  2. Problems of understanding: customers are not completely sure what is needed, have a poor understanding of what computers can and cannot do, do not fully understand their own problem domain, or leave out information they think is "obvious".
  3. Problems of volatility: requirements change over time, as the business, technology or people change.
  4. Different language and implicit knowledge: users describe needs in business terms ("close the day") full of domain knowledge that developers do not share.
  5. Many stakeholders with conflicting needs: managers, clerks, customers and regulators all want different things.
  6. Political and organisational factors: some requirements come from power or preference, not real need.
  7. Users cannot imagine an abstract system: software is intangible; people often only know what they want after they see something ("I'll know it when I see it").
  8. Communication gaps: wrong people are consulted, users are busy, or analysts assume instead of asking.

Guidelines for the requirement elicitation process

  1. Assess business and technical feasibility of the proposed system first.
  2. Identify all stakeholders (users, managers, customers, regulators) and the people who can actually specify requirements.
  3. Define the technical environment (hardware, operating system, other systems) in which the system will run.
  4. Identify domain constraints that limit functions and performance (laws, standards, business rules).
  5. Use more than one elicitation method: interviews, observation, questionnaires, workshops, scenarios and prototypes.
  6. Collect requirements from multiple viewpoints and record the source of each requirement.
  7. Hold collaborative requirement-gathering meetings (FAST/JAD) attended by both users and developers, with:
    • rules for preparation and participation,
    • an agenda that covers all important points but allows free flow of ideas,
    • a neutral facilitator to control the meeting,
    • a definition mechanism (worksheets, flip charts, wall stickers, electronic boards).
  8. Encourage participation and build trust; ask open questions, then context-free and specific questions.
  9. Use scenarios and use cases to make requirements concrete; prototype requirements that are poorly understood.
  10. Record the rationale behind each requirement and the business concerns behind it.
  11. Prioritise and negotiate requirements; identify ambiguous, conflicting or unrealistic ones.
  12. Document and validate results promptly, and get stakeholders to review them.

Following these guidelines turns elicitation from a single conversation into a structured, repeated process that brings out the customer's real, complete and agreed needs.

✓ Answer checked by Claude Sonnet 5.5

Related questions

All Software Engineering chapter 1 questions →