---
title: "Requirement elicitation and system behavior"
subject: "Object Oriented Analysis and Design"
chapter: 2
key: "semester_6/object_oriented_analysis_and_design:requirement-elicitation-in-ooa"
source: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/requirement-elicitation-in-ooa
site: BCT Engineering
---

# Requirement elicitation and system behavior

Object Oriented Analysis and Design · Chapter 2: Object Oriented Analysis

- Asked in: 2070 Magh, 7 marks
- Video: [Software Requirements | Requirement Engineering | Feasibility Study, Elicitation, SRS, Validation](https://www.youtube.com/watch?v=JNLRXczA9Y0) — Gate Smashers
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/requirement-elicitation-in-ooa
- Whole chapter: https://www.bctengineer.com/md/semester_6/object_oriented_analysis_and_design/chapter-2

## Question

How does the requirement elicitation process happen in object oriented analysis? Explain with reference to system behavior analysis of any exemplary system case.

## Short answer

In OOA, requirement elicitation is iterative: stakeholders and actors are identified, needs gathered through interviews and workshops, then expressed as use cases with non‑functional specs. System behavior is analyzed with system sequence diagrams. For an ATM withdrawal, events like insertCard, enterPIN, enterAmount become system operations, and concepts like Card and Account are added to the domain model.

## Answer

**Requirement elicitation** is discovering and understanding what the stakeholders need. In OOA it is done iteratively and results in a set of **use cases** and a **domain model**, rather than only a list of "shall" statements.

#### Process in OOA

```text
 Identify stakeholders -> Gather needs (interview, observe,
 workshop) -> Identify actors and goals -> Write use cases
 -> Refine with domain model, SSD, supplementary spec
 -> Review with users -> Next iteration
```

1. **Identify stakeholders and actors** (users, external systems, time-based actors).
2. **Gather information** by interviews, observation, questionnaires, document study and workshops.
3. **Define user goals** and write the **use cases**, first as brief descriptions and then as detailed (fully dressed) scenarios, starting with the architecturally significant ones.
4. **Record non-functional requirements** (performance, security, usability) in a supplementary specification, and the vocabulary in a glossary.
5. **Analyse system behaviour** with system sequence diagrams (SSD), which show the events the actors send to the system, and operation contracts that define their effect.
6. **Validate** with stakeholders and refine in the next iteration as understanding grows.

#### Example: system behaviour analysis of an ATM
**Use case: Withdraw Cash.** Actor: Customer.
Main flow: 1) Customer inserts card. 2) System asks for PIN. 3) Customer enters PIN. 4) System verifies PIN with the bank. 5) Customer enters amount. 6) System checks balance, dispenses cash, updates the account, and prints a receipt.
Alternate flows: wrong PIN (3 attempts, then card retained); insufficient balance; ATM out of cash.

System behaviour (SSD):
```text
 Customer          :ATM System
    | insertCard()     |
    |----------------->|
    | enterPIN(pin)    |
    |----------------->|
    | enterAmount(amt) |
    |----------------->|
    |<-- cash, receipt-|
```
From this, system operations `insertCard`, `enterPIN`, `enterAmount` are found, and the concepts `Card`, `Account`, `Transaction`, `ATM` are added to the domain model. Thus elicitation moves from stakeholders' words to a precise description of the behaviour the system must provide.

## Check yourself

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

1. Elicitation in OOA mainly produces:
   A. A test suite
   B. Final source code
   C. Only a list of 'shall' statements
   D. Use cases and a domain model
   Answer: D. It is iterative and yields use cases and a domain model. (Key point: Outputs of elicitation in OOA)

2. System sequence diagrams are used to:
   A. Show events actors send to the system to find system operations
   B. Draw state machines
   C. Show class inheritance
   D. Plan network nodes
   Answer: A. SSDs analyse system behaviour and reveal operations such as enterPIN. (Key point: SSD role)

3. Where are non-functional requirements like performance recorded?
   A. The glossary
   B. Supplementary specification
   C. Inside every use case step
   D. Operation contracts
   Answer: B. Non-functional needs go in a supplementary specification; vocabulary in a glossary. (Key point: Non-functional requirements)

4. In Withdraw Cash, a wrong PIN entered 3 times leads to:
   A. Receipt printed
   B. Balance updated
   C. Cash dispensed
   D. Card retained
   Answer: D. This is the alternate flow stated in the use case. (Key point: ATM alternate flow)

## Related in Object Oriented Analysis and Design

- [Object oriented system and core concepts](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aoo-system-concepts-explained) — Object Oriented Analysis and Design, chapter 1
- [Algorithmic vs object-oriented decomposition](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aalgorithmic-vs-oo-decomposition) — Object Oriented Analysis and Design, chapter 1
- [Define object; method implements behavior](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Adefine-object-method-behavior) — Object Oriented Analysis and Design, chapter 1
- [Representing dynamic behavior in OOA](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Adynamic-behavior-representation-ooa) — Object Oriented Analysis and Design, chapter 2
- [Behavior modeling and four diagrams](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Abehavior-modeling-four-diagrams) — Object Oriented Analysis and Design, chapter 2
- [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

## Related in other subjects

- [Importance of requirement engineering; elicitation techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-engineering-importance) — Software Engineering, chapter 1
- [Compare procedural and object oriented programming](https://www.bctengineer.com/question.md?key=semester_3%2Fobject_oriented_programming%3Aprocedural-vs-oop-compare) — Object Oriented Programming, chapter 1
- [Object replication; process resilience](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aobject-replication-resilience) — Distributed System, chapter 7
- [Requirement management process](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-management) — Software Engineering, chapter 1