Requirements analysis in LLD - System Design Exercise

Design: Requirements Analysis Process

Focus on the process of gathering, analyzing, and documenting requirements for software systems. Out of scope are implementation details and coding.

Functional Requirements

FR1: Identify and document functional requirements clearly

FR2: Capture non-functional requirements such as performance and security

FR3: Prioritize requirements based on stakeholder needs

FR4: Ensure requirements are testable and measurable

FR5: Manage changes to requirements throughout the project lifecycle

Non-Functional Requirements

NFR1: Requirements must be understandable by both technical and non-technical stakeholders

NFR2: Analysis should be completed within project timelines to avoid delays

NFR3: Requirements must be feasible within given technology and budget constraints

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Stakeholder interviews and workshops

Use case and user story documentation

Requirement prioritization matrix

Traceability matrix linking requirements to tests

Change management process

Design Patterns

MoSCoW prioritization (Must have, Should have, Could have, Won't have)

User story mapping

Requirements traceability

Iterative refinement and validation

Reference Architecture

  +-------------------+       +---------------------+       +-------------------+
  | Stakeholder Input | ----> | Requirements Analyst | ----> | Requirements Doc  |
  +-------------------+       +---------------------+       +-------------------+
           |                            |                             |
           |                            |                             |
           v                            v                             v
  +-------------------+       +---------------------+       +-------------------+
  | Use Cases & Stories|       | Prioritization Tool |       | Traceability Matrix|
  +-------------------+       +---------------------+       +-------------------+

Components

Stakeholder Input

Interviews, Surveys, Workshops

Gather initial requirements and expectations from users and stakeholders

Requirements Analyst

Manual analysis, Documentation tools

Analyze, clarify, and document requirements

Requirements Document

Word processors, Requirement management tools

Centralized, clear, and accessible record of requirements

Use Cases & User Stories

Templates, Agile tools

Describe system interactions and user needs

Prioritization Tool

Spreadsheets, Specialized software

Rank requirements to focus on critical features

Traceability Matrix

Requirement management software

Link requirements to design and test cases for validation

Request Flow

1. Stakeholders provide input through interviews and workshops.

2. Requirements analyst collects and organizes this input.

3. Use cases and user stories are created to represent functional needs.

4. Requirements are prioritized using a prioritization tool.

5. A requirements document is created and shared with stakeholders.

6. Traceability matrix is maintained to ensure coverage in design and testing.

7. Change requests are managed and updated in the documentation.

Database Schema

Entities: Stakeholder (id, name, role), Requirement (id, description, type, priority, status), UseCase (id, title, description), TraceabilityLink (requirement_id, design_id, test_id). Relationships: Stakeholder to Requirement (1:N), Requirement to UseCase (N:1), Requirement to TraceabilityLink (1:N).

Scaling Discussion

Bottlenecks

Difficulty managing large numbers of requirements and stakeholders

Keeping documentation up to date with frequent changes

Ensuring all requirements are testable and traceable

Communication gaps between technical and non-technical teams

Solutions

Use specialized requirement management tools with collaboration features

Implement automated traceability and change tracking

Adopt iterative and incremental requirement refinement

Facilitate regular cross-team meetings and reviews

Interview Tips

Time: Spend 10 minutes understanding the problem and clarifying requirements, 20 minutes outlining the process and components, 10 minutes discussing challenges and scaling, 5 minutes for questions.

Importance of clear and testable requirements

Balancing stakeholder needs and technical feasibility

Use of prioritization and traceability to manage complexity

Handling changes and communication effectively

Practice

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

easy

A. To deploy the system to users

B. To write the system code

C. To test the system performance

D. To define what the system must do

Solution

1. Step 1: Understand the role of requirements analysis

   Requirements analysis focuses on understanding and defining the system's needs and functions.

2. Step 2: Differentiate from other phases

   Writing code, testing, and deployment happen after requirements are clear.

3. Final Answer:

   To define what the system must do -> Option D

4. Quick Check:

   Requirements analysis = Define system needs [OK]

Hint: Requirements analysis = What system must do [OK]

Common Mistakes:

• Confusing requirements analysis with coding
• Thinking testing is part of requirements
• Mixing deployment with requirements gathering

2. Which of the following is a correct step in requirements analysis?

easy

A. Writing deployment scripts

B. Compiling source code

C. Gathering user needs

D. Running system tests

Solution

1. Step 1: Identify key activities in requirements analysis

   Gathering user needs is essential to understand what the system should do.

2. Step 2: Exclude unrelated activities

   Deployment scripts, compiling code, and testing happen after requirements are set.

3. Final Answer:

   Gathering user needs -> Option C

4. Quick Check:

   Requirements analysis = Gather needs [OK]

Hint: Gather user needs first in requirements analysis [OK]

Common Mistakes:

• Mixing coding or deployment with requirements
• Ignoring user input during analysis
• Confusing testing with requirements gathering

3. Given these requirements:
- System must handle 1000 users simultaneously
- Data must be encrypted
- Users can reset passwords
Which requirement type is "Data must be encrypted"?

medium

A. Non-functional requirement

B. Functional requirement

C. Business requirement

D. User interface requirement

Solution

1. Step 1: Classify the requirement "Data must be encrypted"

   This describes a quality or constraint on the system, not a specific function.

2. Step 2: Understand requirement types

   Functional requirements describe actions; non-functional describe qualities like security.

3. Final Answer:

   Non-functional requirement -> Option A

4. Quick Check:

   Encryption = Non-functional requirement [OK]

Hint: Security needs are non-functional requirements [OK]

Common Mistakes:

• Confusing security with functional features
• Mixing business goals with technical details
• Assuming all requirements are functional

4. A requirements document states: "Users must login with username and password." Later, it says: "Users can login using email and password." What is the main issue here?

medium

A. Performance bottleneck

B. Ambiguous requirements

C. Security vulnerability

D. Scalability problem

Solution

1. Step 1: Identify conflicting statements

   The document gives two different login methods without clarifying which is correct.

2. Step 2: Understand impact of ambiguity

   Ambiguous requirements confuse developers and cause design errors.

3. Final Answer:

   Ambiguous requirements -> Option B

4. Quick Check:

   Conflicting login info = Ambiguity [OK]

Hint: Conflicting info means ambiguous requirements [OK]

Common Mistakes:

• Assuming security or performance issues without evidence
• Ignoring requirement conflicts
• Thinking scalability relates to login methods

5. You are designing a messaging app. Which of these is the best way to gather requirements to ensure scalability and user satisfaction?

hard

A. Interview users, analyze competitors, and document clear functional and non-functional needs

B. Start coding immediately based on your assumptions

C. Only focus on UI design without backend planning

D. Ignore user feedback and add features later

Solution

1. Step 1: Identify best practices in requirements gathering

   Interviewing users and analyzing competitors helps understand real needs and market standards.

2. Step 2: Emphasize clear documentation of all requirements

   Clear functional and non-functional requirements guide scalable and user-friendly design.

3. Final Answer:

   Interview users, analyze competitors, and document clear functional and non-functional needs -> Option A

4. Quick Check:

   User research + clear docs = good requirements [OK]

Hint: Gather user input and document clearly before coding [OK]

Common Mistakes:

• Skipping user research
• Starting development without clear requirements
• Ignoring backend needs for scalability