---
title: "Requirement gathering and analysis techniques"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:requirement-gathering-techniques"
source: https://www.bctengineer.com/q/semester_5/software_engineering/requirement-gathering-techniques
site: BCT Engineering
---

# Requirement gathering and analysis techniques

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: year not given, 7 marks
- Video: [Requirement Gathering Techniques For A Business Analyst](https://www.youtube.com/watch?v=8EBWxW5Cn1g) — Stefano - The Agile Business Analyst
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/requirement-gathering-techniques
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

What are techniques used for requirement gathering and analysis? Explain any three.

## Short answer

Techniques: interviews, questionnaires, observation, scenarios, prototyping, JAD. Interviews involve asking stakeholders closed/open questions for deep insight. Scenarios and use cases provide concrete examples of system interactions. Ethnography observes users at work to reveal tacit requirements that formal interviews miss.

## Answer

**Requirement gathering and analysis** (elicitation and analysis) is the requirements engineering activity in which analysts work with stakeholders to discover the application domain, the services the system must provide, its performance and other constraints, and then organise, prioritise and negotiate these requirements.

#### Techniques used
- Interviews (closed and open)
- Questionnaires and surveys
- Observation and ethnography
- Scenarios and use cases
- Prototyping
- Brainstorming and facilitated workshops (JAD, FAST)
- Viewpoint-oriented analysis
- Study of documents and existing systems

The analysis activities that follow are: **requirements discovery → classification and organisation → prioritisation and negotiation → documentation**, repeated in a spiral until the requirements are complete enough.

#### 1. Interviewing
The requirements engineer asks stakeholders questions about the system they use now and the system to be developed.
- **Closed interview**: a predefined set of questions is answered.
- **Open interview**: no fixed agenda; the team explores a range of issues.
Good interviewers are open-minded, avoid pre-conceived ideas, and use a "springboard" question or a draft proposal to start discussion.
- Advantages: gives detailed understanding of what stakeholders do and their problems.
- Limitations: users find it hard to explain domain knowledge they use every day, so tacit requirements may be missed.
Example: interviewing a pharmacist about how medicines are dispensed, which records are kept and which reports are needed for a pharmacy system.

#### 2. Scenarios and use cases
**Scenarios** are real-life examples of how the system will be used. A scenario describes the starting situation, the normal flow of events, what can go wrong, other concurrent activities and the state at the end. People relate more easily to concrete examples than to abstract descriptions.
**Use cases** (UML) identify the **actors** and the interactions with the system; each use case is described by a set of scenarios.

```text
                 Library system
             +----------------------+
             |  ( Search book )     |
  Member ----|  ( Reserve book )    |
             |  ( Issue book )      |---- Librarian
             |  ( Return book )     |
             |  ( Pay fine )        |
             +----------------------+
```
Example scenario "Issue book": member gives card, librarian scans card and book; system checks the member has fewer than 5 books and no unpaid fine; records issue with due date; prints slip. Exception: member has unpaid fine, so issue is refused.

#### 3. Ethnography (observation)
An analyst spends time **observing people at their actual work** and notes the real tasks they perform. It helps to discover **implicit requirements** that reflect the real way people work rather than the formal procedures, and requirements arising from cooperation and awareness of other people's activities.
- Advantages: reveals tacit knowledge and real practices; uncovers requirements users forget to mention.
- Limitations: time consuming; focuses on existing practice, so it is weak for innovative features; people may behave differently when observed. Often combined with prototyping ("focused ethnography").
Example: observing bank tellers shows that they often serve two customers at once and keep frequent account numbers on paper, so the new system needs quick switching between customers and a recent-accounts list, which no teller had mentioned in interviews.

Combining these techniques (interview to get an overview, observation to see real work, use cases to describe agreed behaviour) gives a fuller and more accurate set of requirements than any single technique.

## Check yourself

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

1. What is the sequence of activities in requirements analysis after gathering?
   A. Discovery, classification and organisation, prioritisation and negotiation, documentation
   B. Documentation, discovery, negotiation, classification
   C. Prioritisation, discovery, documentation, classification
   D. Classification, documentation, discovery, negotiation
   Answer: A. Requirements are discovered, classified and organised, prioritised and negotiated, then documented, repeated in a spiral. (Key point: Analysis sequence)

2. What is a main limitation of interviewing?
   A. It gives no detail about what users do
   B. Users find it hard to explain everyday domain knowledge, so tacit requirements may be missed
   C. It cannot be used with stakeholders
   D. It requires a formal notation
   Answer: B. Domain knowledge used daily is hard to articulate, so interviews may miss tacit requirements. (Key point: Interview limitation)

3. What does a scenario describe?
   A. Only the final state of the system
   B. The starting situation, normal flow, what can go wrong, concurrent activities and end state
   C. Only the database schema
   D. Only the actors' names
   Answer: B. A scenario is a concrete example covering start, normal flow, exceptions, concurrent activities and end state. (Key point: Scenario content)

4. What is the main benefit of ethnography?
   A. It discovers implicit requirements based on how people really work
   B. It is the fastest technique
   C. It is ideal for innovative features
   D. It avoids needing users
   Answer: A. Observing real work reveals tacit knowledge, though it is time-consuming and weak for innovation. (Key point: Ethnography benefit)

5. In UML, what do use cases identify?
   A. The actors and their interactions with the system
   B. Only the classes in the code
   C. The hardware to buy
   D. The test data
   Answer: A. Use cases identify actors and interactions; each is described by a set of scenarios. (Key point: Use case concept)

## Related in Software Engineering

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

## Related in other subjects

- [Short note: Requirement gathering methods](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Ashort-note-requirement-gathering-methods) — Object Oriented Analysis and Design, chapter 2
- [Communication requirement analysis](https://www.bctengineer.com/question.md?key=semester_7%2Fict_project_management%3Acommunication-requirement-analysis) — ICT Project Management, chapter 11
- [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
- [Software used for FEM and FDM](https://www.bctengineer.com/question.md?key=semester_8%2Fcomputational_techniques_in_civil_engineering%3Asoftware-fem-fdm) — Computational Techniques in Civil Engineering, chapter 1