Object-Oriented Analysis: Requirements & Use Cases

Object-Oriented Analysis (OOA) is the first technical step in the software development lifecycle where we focus on what the system should do, rather than how it should do it. The goal is to create a model of the functional requirements that is independent of implementation details.

1. Understanding Requirements

Requirements are the “wants and needs” of the stakeholders. In OOA, we categorize them into two main types:

Functional Requirements

These describe the specific behaviors, services, and tasks the system must perform.

Example: “The system must allow users to reset their passwords via email.”
Example: “The software must calculate the total tax based on the user’s region.”

Non-Functional Requirements (Qualities)

These describe how the system performs its functions—attributes like performance, security, and usability.

Example: “The system must respond to search queries in less than 200ms.”
Example: “Password data must be encrypted using AES-256.”

2. Use Case Modeling

Use case modeling is the primary tool for OOA. It helps identify the boundaries of the system and the interactions between the system and its environment.

Key Components:

Actors: Entities outside the system that interact with it. They can be human users (e.g., “Customer”) or external systems (e.g., “Payment Gateway”).
Use Cases: A discrete unit of functionality that provides value to an actor.
System Boundary: A box representing the limits of the software.

Use Case Diagram Example (PlantUML)

@startuml
left to right direction
actor "Customer" as C
actor "Bank System" as B

rectangle "ATM System" {
  use case "Withdraw Cash" as UC1
  use case "Check Balance" as UC2
  use case "Deposit Funds" as UC3
  use case "Transfer Money" as UC4
}

C --> UC1
C --> UC2
C --> UC3
C --> UC4

UC1 -- B
UC4 -- B
@enduml

3. Detailed Use Case Scenarios

A diagram is not enough. Each use case needs a description, often written as a “Success Scenario.”

Use Case: Withdraw Cash

Primary Actor: Customer
Preconditions: Customer has a valid card and the ATM has cash.
Trigger: Customer inserts card.
Main Success Scenario:
1. System prompts for PIN.
2. Customer enters PIN.
3. System validates PIN.
4. System prompts for amount.
5. Customer enters amount.
6. System checks account balance with Bank System.
7. System dispenses cash.
8. System updates balance and prints receipt.
Extensions (Alternative Flows):
- 3a. Invalid PIN: System requests re-entry.
- 6a. Insufficient Funds: System displays error and ejects card.

4. Requirements Elicitation Techniques

How do we find these requirements?

Interviews: Talking directly to stakeholders.
Workshops: Collaborative sessions with users and developers.
Observation: Watching how users perform their current tasks.
Prototyping: Building “mock-ups” to get early feedback.

5. From Requirements to Objects

During OOA, we also perform Domain Modeling. This involves identifying the “nouns” in our requirements which will eventually become our classes.

Nouns: Customer, Account, Transaction, ATM, Receipt.
Verbs: Withdraw, Deposit, Validate, Print.

Identifying these early ensures that the software structure mirrors the real-world domain, a core tenet of Object-Oriented Design.

Summary Checklist for OOA

Have all actors been identified?
Are the system boundaries clear?
Does every use case provide value to an actor?
Have non-functional constraints been documented?
Is there a glossary of domain terms?

OO Analysis: Requirements & Use Cases