Requirements and use cases in LLD - Deep Dive

Overview - Requirements and use cases

What is it?

Requirements and use cases describe what a system should do and how users will interact with it. Requirements are detailed statements about system functions and constraints. Use cases are stories or scenarios showing how users achieve goals with the system. Together, they guide the design and development of software or systems.

Why it matters

Without clear requirements and use cases, systems often fail to meet user needs or have costly errors. They prevent misunderstandings between users and developers, saving time and money. Imagine building a house without a blueprint; it would be chaotic and wasteful. Requirements and use cases act like that blueprint for software.

Where it fits

Before learning requirements and use cases, you should understand basic software development and user needs. After mastering them, you can move on to system architecture, design patterns, and testing. They form the foundation for building systems that work well for real people.

Mental Model

Core Idea

Requirements and use cases capture what a system must do and how users will use it to ensure the system solves real problems.

Think of it like...

It's like planning a trip: requirements are the list of places you want to visit and rules you must follow, while use cases are the stories of how you travel from one place to another and what you do there.

┌───────────────┐       ┌───────────────┐
│ Requirements  │──────▶│ Use Cases     │
│ (What system  │       │ (How users    │
│ must do)      │       │ interact)     │
└───────────────┘       └───────────────┘
          │                      │
          ▼                      ▼
    ┌─────────────────────────────────┐
    │ System Design and Development   │
    └─────────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding System Requirements

Concept: Introduce what system requirements are and their types.

Requirements are statements describing what a system should do or constraints it must follow. They come in two main types: functional (what the system does) and non-functional (how the system performs, like speed or security). For example, a functional requirement might be 'The system must allow users to log in,' while a non-functional one could be 'The system must respond within 2 seconds.'

Result

You can identify and classify system needs clearly into functional and non-functional requirements.

Understanding the difference between functional and non-functional requirements helps you capture both what the system does and how well it does it.

2

Foundation

What Are Use Cases?

Concept: Explain use cases as user-focused scenarios describing system interactions.

Use cases tell stories about how users achieve goals with the system. Each use case describes a sequence of steps between a user (called an actor) and the system to complete a task. For example, a use case for logging in might include entering username and password, system verifying credentials, and granting access.

Result

You can describe user interactions with the system in clear, step-by-step scenarios.

Use cases help translate abstract requirements into concrete user actions, making the system easier to understand and design.

3

Intermediate

Writing Clear and Testable Requirements

🤔Before reading on: do you think requirements should be vague or precise? Commit to your answer.

Concept: Teach how to write requirements that are clear, measurable, and testable.

Good requirements avoid vague words like 'fast' or 'user-friendly' without explanation. Instead, they specify exact criteria, such as 'The system must process 100 transactions per second.' This clarity allows developers to build the right system and testers to verify it works as expected.

Result

You can write requirements that everyone understands the same way and can verify objectively.

Clear and testable requirements reduce confusion and rework, improving project success.

4

Intermediate

Structuring Use Cases Effectively

🤔Before reading on: do you think use cases should be long stories or concise steps? Commit to your answer.

Concept: Show how to organize use cases with actors, main flow, alternative flows, and exceptions.

A well-structured use case includes: the actor (who uses the system), the main flow (normal steps), alternative flows (optional or error paths), and exceptions (failures). For example, a payment use case might have an alternative flow for declined cards. This structure helps cover all scenarios and edge cases.

Result

You can create use cases that cover normal and unusual user interactions clearly.

Structured use cases ensure the system handles all expected and unexpected user behaviors.

5

Intermediate

Connecting Requirements to Use Cases

🤔Before reading on: do you think requirements and use cases are independent or linked? Commit to your answer.

Concept: Explain how use cases derive from and validate requirements.

Each functional requirement should map to one or more use cases showing how users achieve that function. For example, a requirement 'Users can reset passwords' corresponds to a use case describing the reset steps. This connection ensures requirements are practical and complete.

Result

You can trace requirements to user scenarios, improving system completeness and clarity.

Linking requirements and use cases bridges the gap between what the system must do and how users experience it.

6

Advanced

Handling Non-Functional Requirements in Use Cases

🤔Before reading on: do you think use cases cover only functional needs or also non-functional? Commit to your answer.

Concept: Teach how to incorporate performance, security, and other quality needs into use cases.

Non-functional requirements like speed or security often affect use cases indirectly. For example, a use case for data access might include a step 'System encrypts data before sending.' You can add notes or constraints in use cases to reflect these quality needs, ensuring they are considered during design.

Result

You can represent both functional and quality requirements in user scenarios.

Including non-functional needs in use cases helps build systems that not only work but work well.

7

Expert

Common Pitfalls and Advanced Use Case Modeling

🤔Before reading on: do you think use cases should be detailed or high-level? Commit to your answer.

Concept: Explore advanced topics like use case granularity, avoiding over-detailing, and integrating with other models.

Too detailed use cases become hard to maintain; too vague ones miss important steps. Experts balance detail by focusing on user goals, not internal system steps. Also, use cases can link to sequence diagrams or user stories for richer design. Recognizing when to stop detailing is key to efficient modeling.

Result

You can create use cases that are clear, maintainable, and integrate well with other design artifacts.

Mastering use case granularity and integration prevents wasted effort and supports scalable system design.

Under the Hood

Requirements and use cases work by capturing user needs and system functions in structured language and scenarios. They act as contracts between users and developers, guiding design and testing. Internally, they break down complex system goals into manageable pieces, ensuring all stakeholders share a common understanding.

Why designed this way?

They were created to solve communication gaps between technical teams and users. Early software projects failed due to unclear needs. Requirements provide precise goals, while use cases tell user stories that are easier to grasp. This dual approach balances technical rigor with user perspective.

┌───────────────┐       ┌───────────────┐
│ User Needs    │──────▶│ Requirements  │
└───────────────┘       └───────────────┘
          │                      │
          ▼                      ▼
    ┌─────────────────────────────────┐
    │ Use Cases (User Scenarios)       │
    └─────────────────────────────────┘
          │                      │
          ▼                      ▼
    ┌───────────────┐       ┌───────────────┐
    │ System Design │       │ Testing Plans │
    └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do use cases describe only system functions or also user goals? Commit to one.

Common Belief: Use cases only describe system functions in technical detail.

Reality: Use cases focus on user goals and interactions, not just system internals.

Why it matters: Ignoring user goals leads to systems that work technically but fail user needs.

Quick: Are non-functional requirements less important than functional ones? Commit yes or no.

Common Belief: Non-functional requirements like performance or security are less important and can be added later.

Reality: Non-functional requirements are critical and must be considered early to avoid costly redesigns.

Why it matters: Neglecting quality needs causes poor user experience and system failures.

Quick: Should requirements be vague to allow flexibility? Commit yes or no.

Common Belief: Vague requirements give developers freedom to decide implementation details.

Reality: Vague requirements cause misunderstandings and rework; clear, testable requirements are essential.

Why it matters: Unclear requirements lead to wasted time and systems that don't meet expectations.

Quick: Do use cases need to cover every tiny system step? Commit yes or no.

Common Belief: Use cases must detail every internal system action for completeness.

Reality: Use cases focus on user-visible steps; internal details belong elsewhere.

Why it matters: Over-detailing use cases makes them hard to maintain and understand.

Expert Zone

1

Experienced practitioners know that use cases should focus on user intent, not system implementation details.

2

Non-functional requirements often require creative ways to represent them in use cases, such as constraints or notes.

3

Balancing use case granularity is subtle: too detailed wastes effort, too vague misses important flows.

When NOT to use

For highly exploratory or research projects where requirements are unknown, agile user stories or prototypes may be better. Also, very small or simple systems may not need formal use cases; lightweight checklists suffice.

Production Patterns

In real projects, requirements are managed with traceability matrices linking them to use cases, design documents, and tests. Use cases often evolve into user stories in agile teams, maintaining user focus while supporting iterative development.

Connections

User Experience Design

Builds-on

Understanding requirements and use cases helps UX designers create interfaces that truly meet user needs and workflows.

Project Management

Supports

Clear requirements and use cases enable project managers to plan scope, estimate effort, and track progress effectively.

Storytelling in Literature

Shares pattern

Use cases are like stories with actors, goals, and conflicts; knowing storytelling principles improves use case clarity and engagement.

Common Pitfalls

#1 Writing vague requirements that are open to interpretation.

Wrong approach:

"The system should be fast and user-friendly."

Correct approach:

"The system must respond to user input within 2 seconds and support keyboard navigation for accessibility."

Root cause:

Misunderstanding the need for measurable and testable criteria.

#2 Confusing use cases with technical design documents.

Wrong approach:

Use case step: "System calls database API to fetch user data."

Correct approach:

Use case step: "User requests their profile information; system displays the profile."

Root cause:

Mixing user perspective with internal system implementation.

#3 Ignoring non-functional requirements in use cases.

Wrong approach:

Use case for login without mentioning security constraints.

Correct approach:

Use case for login including step: "System encrypts password before verification."

Root cause:

Separating functional and non-functional requirements too strictly.

Key Takeaways

Requirements define what a system must do and the qualities it must have, guiding development and testing.

Use cases tell user-focused stories that show how people interact with the system to achieve goals.

Clear, testable requirements and well-structured use cases prevent misunderstandings and costly errors.

Linking requirements to use cases ensures the system meets real user needs, not just technical specs.

Balancing detail and user perspective in use cases is key to maintainable and effective system design.

Practice

1. What is the main purpose of requirements in system design?

easy

A. To write the system's source code

B. To describe how users interact with the system

C. To design the user interface layout

D. To specify what the system must do

Solution

1. Step 1: Understand the definition of requirements

   Requirements define the functions and features the system must provide.

2. Step 2: Differentiate from use cases

   Use cases describe user interactions, not the system's core functions.

3. Final Answer:

   To specify what the system must do -> Option D

4. Quick Check:

   Requirements = system functions [OK]

Hint: Requirements = what system must do, not how users act [OK]

Common Mistakes:

• Confusing requirements with use cases
• Thinking requirements include UI design
• Assuming requirements are code instructions

2. Which of the following best describes a use case in system design?

easy

A. A scenario showing user interaction with the system

B. A code module for user authentication

C. A diagram of system architecture

D. A detailed list of system features

Solution

1. Step 1: Define use case

   A use case is a story or scenario describing how a user uses the system.

2. Step 2: Eliminate unrelated options

   System features list, architecture diagrams, and code modules are not use cases.

3. Final Answer:

   A scenario showing user interaction with the system -> Option A

4. Quick Check:

   Use case = user scenario [OK]

Hint: Use case = user story or interaction example [OK]

Common Mistakes:

• Mixing use cases with system features
• Confusing use cases with technical diagrams
• Thinking use cases are code components

3. Given a system that allows users to upload photos and comment, which of the following is a valid use case?

medium

A. System stores photos in a database

B. User uploads a photo and receives confirmation message

C. Database schema includes photo metadata fields

D. Server runs a nightly backup process

Solution

1. Step 1: Identify user actions in options

   User uploads a photo and receives confirmation message describes a user action and system response, fitting a use case.

2. Step 2: Recognize system internals vs user interaction

   Options A, C, and D describe internal system details, not user interactions.

3. Final Answer:

   User uploads a photo and receives confirmation message -> Option B

4. Quick Check:

   User action + system response = use case [OK]

Hint: Use case = user action plus system reaction [OK]

Common Mistakes:

• Choosing system internal processes as use cases
• Ignoring the user perspective
• Confusing data storage details with use cases

4. A system design document lists: "Users can reset passwords via email." Which of the following is a problem in this use case description?

medium

A. It includes too much technical detail about email servers

B. It lacks the steps describing how users reset passwords

C. It incorrectly describes a system requirement instead of a use case

D. It is missing the database schema for password storage

Solution

1. Step 1: Analyze the use case description

   The statement is a high-level feature but lacks detailed user steps.

2. Step 2: Understand use case completeness

   Use cases should describe user actions step-by-step, not just state features.

3. Final Answer:

   It incorrectly describes a system requirement instead of a use case -> Option C

4. Quick Check:

   Use case needs detailed user steps [OK]

Hint: Use cases must show user steps, not just features [OK]

Common Mistakes:

• Confusing requirements with use cases
• Expecting technical details in use cases
• Ignoring the need for step-by-step user actions

5. You are designing a ride-sharing app. Which of the following best combines requirements and use cases for the feature "Request a ride"?

hard

A. Requirement: The system must match riders with drivers within 2 minutes. Use case: Rider opens app, enters destination, and confirms ride request.

B. Requirement: The app must have a blue color theme. Use case: Driver updates profile picture.

C. Requirement: The system stores all ride data for 1 year. Use case: Admin views system logs.

D. Requirement: The app sends promotional emails weekly. Use case: Rider rates driver after ride.

Solution

1. Step 1: Identify relevant requirement for ride request

   Matching riders with drivers quickly is a key system requirement for this feature.

2. Step 2: Identify matching use case

   The use case describes the rider's interaction to request a ride step-by-step.

3. Step 3: Verify other options

   Other options mix unrelated requirements or use cases not tied to "Request a ride" feature.

4. Final Answer:

   Requirement: The system must match riders with drivers within 2 minutes. Use case: Rider opens app, enters destination, and confirms ride request. -> Option A

5. Quick Check:

   Requirement + user steps = correct combination [OK]

Hint: Match system needs with user steps for correct design [OK]

Common Mistakes:

• Mixing unrelated requirements and use cases
• Ignoring user interaction details
• Choosing cosmetic or admin features instead of core ones