---
title: "Understanding customers; elicitation guidelines"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:customer-understanding"
source: https://www.bctengineer.com/q/semester_5/software_engineering/customer-understanding
site: BCT Engineering
---

# Understanding customers; elicitation guidelines

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: year not given, 4+4 marks
- Video: [25 Requirement Elicitation and Analysis - Steps, Techniques, and Example |SE|](https://www.youtube.com/watch?v=aorzuTjBE6A) — Trouble- Free
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/customer-understanding
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

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

## 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.

## Answer

#### 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.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. Which is a 'problem of understanding' in gathering requirements?
   A. Requirements change over time
   B. The system boundary is poorly defined
   C. Customers are unsure of what is needed and misjudge what computers can do
   D. Too many analysts attend the meeting
   Answer: C. Problems of understanding include customers not knowing their needs or the capabilities and limits of computers. (Key point: Problems of understanding)

2. What are 'problems of volatility'?
   A. Requirements change over time as business, technology or people change
   B. Customers give too much technical detail
   C. The system boundary is unclear
   D. Users are not available for interviews
   Answer: A. Volatility means requirements keep changing; scope concerns the boundary and understanding concerns the customer's knowledge. (Key point: Problems of volatility)

3. In a collaborative requirement-gathering meeting (FAST/JAD), what is the role of the facilitator?
   A. To write the code during the meeting
   B. To act as a neutral person who controls the meeting
   C. To represent the customer's interests only
   D. To decide the requirements alone
   Answer: B. A neutral facilitator controls the meeting; users and developers both attend. (Key point: Role of facilitator)

4. Which is a recommended guideline for the elicitation process?
   A. Use only one elicitation method to stay consistent
   B. Consult only the manager
   C. Use more than one method and collect requirements from multiple viewpoints, recording the source
   D. Skip prioritisation until coding
   Answer: C. The guidelines recommend multiple methods and viewpoints, recording sources, and prioritising and negotiating requirements. (Key point: Elicitation guidelines)

5. Why do users often not know what they want until they see something?
   A. Software is intangible so an abstract system is hard to imagine
   B. Users do not want any software
   C. Analysts hide the details
   D. Requirements never change
   Answer: A. Because software is intangible, people often realise their needs only after seeing a scenario or prototype. (Key point: Intangibility of software)

## Related in Software Engineering

- [Importance of requirement engineering; elicitation techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-engineering-importance) — Software Engineering, chapter 1
- [Requirement management process](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-management) — Software Engineering, chapter 1
- [Book store process model](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Abook-store-process-model) — Software Engineering, chapter 2

## Related in other subjects

- [Requirement elicitation and system behavior](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Arequirement-elicitation-in-ooa) — Object Oriented Analysis and Design, chapter 2
- [SQL: customers with account in Dharan](https://www.bctengineer.com/question.md?key=semester_6%2Fdatabase_management_system%3Asql-customers-dharan-branch) — Database Management System, chapter 3
- [KUKL customer system design and code](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Akukl-use-case-class-diagram-code) — Object Oriented Analysis and Design, chapter 4
- [Doubly linked list: bank customer records](https://www.bctengineer.com/question.md?key=semester_4%2Fdata_structure_and_algorithm%3Adoubly-bank-customer) — Data Structure and Algorithm, chapter 4