Skip to main content

Requirement elicitation and system behavior

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.

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

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

 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):

 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.

✓ Answer checked by Claude Opus 5.5 (high effort)

Related questions

All Object Oriented Analysis and Design chapter 2 questions →