---
title: "Importance of requirement engineering; elicitation techniques"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:requirement-engineering-importance"
source: https://www.bctengineer.com/q/semester_5/software_engineering/requirement-engineering-importance
site: BCT Engineering
---

# Importance of requirement engineering; elicitation techniques

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: 2067 Ashadh (old course), 12 marks
- Video: [Software Requirements | Requirement Engineering | Feasibility Study, Elicitation, SRS, Validation](https://www.youtube.com/watch?v=JNLRXczA9Y0) — Gate Smashers
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/requirement-engineering-importance
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

Explain the importance of requirement engineering. List out requirement elicitation techniques. What are the problems in formation of requirements?

## Short answer

Requirement engineering provides the foundation for design and testing, reduces costly errors, creates common understanding, and supports estimation. Elicitation techniques include interviews, questionnaires, observation, JAD, prototyping, and use cases. Problems include unclear scope, poor customer understanding, volatile requirements, and conflicting stakeholder interests.

## Answer

**Requirements engineering (RE)** is the process of discovering, analysing, documenting, validating and managing the services and constraints of a system. It includes feasibility study, requirements elicitation and analysis, specification, validation and requirements management.

#### Importance of requirement engineering
1. **Foundation for all later work.** Design, coding, testing and maintenance are all based on requirements. Wrong requirements produce the wrong system, however well it is built.
2. **Reduces cost of errors.** Errors fixed during requirements cost very little; the same error found after delivery can cost 100 times or more, because design, code, tests and documents must all change.
3. **Prevents project failure.** Surveys of failed projects repeatedly list incomplete requirements, lack of user involvement and changing requirements as top causes.
4. **Common understanding.** RE creates an agreed statement between customer and developer, reducing disputes; the SRS can serve as a contract.
5. **Basis for estimation and planning.** Cost, effort and schedule estimates (e.g. function points, COCOMO) need clear requirements.
6. **Basis for testing and acceptance.** Test cases and acceptance criteria are derived from requirements.
7. **Controls change.** Requirements management and traceability make the impact of a change visible before it is approved.
8. **Improves user satisfaction**, since users are involved from the start.

#### Requirement elicitation techniques
1. **Interviews** (closed and open): talking to stakeholders with prepared or free questions.
2. **Questionnaires / surveys**: written questions to many users.
3. **Observation and ethnography**: watching users do their real work to find implicit requirements.
4. **Facilitated workshops / JAD (Joint Application Development)**: structured meetings of users and developers with a facilitator.
5. **Brainstorming**: generating many ideas in a group.
6. **Prototyping**: users try an early version and give feedback.
7. **Scenarios and use cases**: describing example interactions step by step.
8. **Document / record analysis**: studying existing forms, reports, manuals and systems.
9. **Viewpoint-oriented elicitation**: collecting requirements from different stakeholder viewpoints (e.g. VORD).
10. **FAST and QFD**: Facilitated Application Specification Techniques and Quality Function Deployment (normal, expected and exciting requirements).

#### Problems in formation of requirements
Pressman groups the problems into three classes:

| Problem class | Meaning |
|---|---|
| Problems of scope | System boundary unclear; customers give unnecessary technical detail |
| Problems of understanding | Customers unsure of needs, limits of computers, or the domain |
| Problems of volatility | Requirements change over time |

Sommerville lists the following difficulties in elicitation and analysis:
1. **Stakeholders do not know what they really want**, or find it hard to say; they may ask for unrealistic things without knowing the cost.
2. **Stakeholders express requirements in their own terms** with implicit domain knowledge that engineers do not understand.
3. **Different stakeholders have conflicting requirements**, for example the manager wants detailed monitoring while staff want simplicity.
4. **Political and organisational factors** influence requirements, e.g. a manager asks for features that increase his or her influence.
5. **The business environment changes** during analysis; new stakeholders appear and priorities change.

Other common problems:
- Poor communication between users and analysts; different vocabularies.
- Requirements that are **ambiguous, incomplete or inconsistent**.
- **Missing non-functional requirements** (performance, security), which are noticed only late.
- Users not available, or the wrong people consulted.
- **Gold plating**: adding features nobody asked for.
- Difficulty in **prioritising** requirements within budget and time.

Example: in a hospital system, doctors want quick access to full patient history, the administration wants strict billing controls and the IT department wants to reuse the old database. Without proper elicitation, negotiation and documentation, these conflicting and implicit needs lead to an SRS that pleases nobody. A structured RE process with interviews, observation of ward routines, a JAD workshop to resolve conflicts and a prototype of key screens would produce clear, agreed and prioritised requirements.

## Check yourself

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

1. Why does requirements engineering reduce project cost?
   A. Errors fixed during requirements cost little, while the same error found after delivery can cost 100 times or more
   B. It removes the need for testing
   C. It makes coding faster by skipping design
   D. It guarantees the requirements never change
   Answer: A. Late errors force changes to design, code, tests and documents, so early fixing is far cheaper. (Key point: Reduces cost of errors)

2. Which technique involves watching users do their real work to find implicit requirements?
   A. Questionnaires
   B. Brainstorming
   C. Observation and ethnography
   D. Document analysis
   Answer: C. Observation and ethnography reveal implicit requirements from real work practices. (Key point: Elicitation techniques)

3. Which is NOT one of Pressman's three classes of requirement problems?
   A. Problems of scope
   B. Problems of understanding
   C. Problems of volatility
   D. Problems of programming language
   Answer: D. Pressman's classes are scope, understanding and volatility. (Key point: Pressman's problem classes)

4. In the hospital example, what causes a poor SRS if elicitation is not done properly?
   A. Doctors, administration and IT have conflicting and implicit needs that are not negotiated
   B. The hospital has too few doctors
   C. The database is too small
   D. Programmers refuse to code
   Answer: A. Conflicting and implicit needs left unresolved yield an SRS that pleases nobody; interviews, observation, JAD and prototypes help. (Key point: Conflicting stakeholders)

5. What does 'gold plating' mean as a requirements problem?
   A. Charging the customer more
   B. Adding features that nobody asked for
   C. Removing essential features
   D. Using expensive hardware
   Answer: B. Gold plating is adding unrequested features, which wastes effort. (Key point: Gold plating)

## Related in Software Engineering

- [Requirement gathering and analysis techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-gathering-techniques) — Software Engineering, chapter 1
- [Requirement engineering and specification](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-engineering-views) — Software Engineering, chapter 1
- [Understanding customers; elicitation guidelines](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Acustomer-understanding) — Software Engineering, chapter 1
- [Requirement management process](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-management) — Software Engineering, chapter 1
- [Requirement gathering processes compared](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-gathering-processes) — Software Engineering, chapter 1
- [Benefits and problems of reuse; reuse planning](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Areuse-benefits-problems) — Software Engineering, chapter 5

## 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
- [Techniques of solving problems; FEM and FDM](https://www.bctengineer.com/question.md?key=semester_8%2Fcomputational_techniques_in_civil_engineering%3Afem-fdm-working-techniques) — Computational Techniques in Civil Engineering, chapter 1
- [Engineering geological problems of Siwalik zone](https://www.bctengineer.com/question.md?key=semester_4%2Fengineering_geology_ii%3Asiwalik-problems) — Engineering Geology II, chapter 2, asked 4×
- [Engineering geological problems in tectonic divisions](https://www.bctengineer.com/question.md?key=semester_3%2Fengineering_geology_i%3Aengineering-geological-problems-in-tectonic) — Engineering Geology I, chapter 7, asked 2×