Requirements gathering (functional and non-functional) in HLD - System Design Exercise

Design: Requirements Gathering Process

Focus on the process and best practices for gathering and documenting requirements. Out of scope are detailed design, implementation, and testing phases.

Functional Requirements

FR1: Identify and document functional requirements that describe what the system should do

FR2: Identify and document non-functional requirements that describe system qualities like performance, security, and usability

FR3: Ensure requirements are clear, measurable, and testable

FR4: Prioritize requirements based on stakeholder needs

FR5: Manage changes to requirements throughout the project lifecycle

Non-Functional Requirements

NFR1: Requirements must be gathered within a 2-week timeframe

NFR2: Stakeholder availability may be limited

NFR3: Requirements must be understandable by both technical and non-technical team members

NFR4: Maintain traceability between requirements and design decisions

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Stakeholder interviews and workshops

Requirement documentation templates

Prioritization frameworks (e.g., MoSCoW)

Traceability matrices

Change management process

Design Patterns

Use case modeling

User stories and acceptance criteria

Requirement decomposition

Non-functional requirement categorization

Version control for requirements

Reference Architecture

 +-------------------+       +---------------------+       +-------------------+
 | Stakeholder Input | ----> | Requirements Analyst | ----> | Requirements Doc  |
 +-------------------+       +---------------------+       +-------------------+
          |                            |                             |
          |                            |                             |
          v                            v                             v
 +-------------------+       +---------------------+       +-------------------+
 | Interviews &      |       | Prioritization &    |       | Traceability &    |
 | Workshops        |       | Validation          |       | Change Management |
 +-------------------+       +---------------------+       +-------------------+

Components

Stakeholder Input

Interviews, Surveys, Workshops

Gather initial needs and expectations from users and stakeholders

Requirements Analyst

Documentation tools (e.g., Word, Confluence)

Analyze, clarify, and document requirements

Requirements Documentation

Templates, Traceability Matrices

Store and organize functional and non-functional requirements

Prioritization Framework

MoSCoW method, spreadsheets

Rank requirements by importance and urgency

Change Management Process

Version control, approval workflows

Manage updates and revisions to requirements

Request Flow

1. Stakeholders provide input via interviews and workshops

2. Requirements analyst collects and clarifies needs

3. Functional and non-functional requirements are documented

4. Requirements are prioritized and validated with stakeholders

5. Traceability is established linking requirements to design and tests

6. Change requests are managed through a formal process

Database Schema

Entities: Requirement (id, type [functional/non-functional], description, priority, status), Stakeholder (id, name, role), RequirementChange (id, requirement_id, change_description, date, approved_by). Relationships: Stakeholder submits Requirement; Requirement has many RequirementChange records.

Scaling Discussion

Bottlenecks

Difficulty managing large numbers of requirements from many stakeholders

Ensuring consistent understanding across diverse teams

Tracking changes and maintaining traceability as requirements evolve

Solutions

Use specialized requirements management tools to handle volume and complexity

Standardize documentation formats and conduct regular review sessions

Implement automated traceability and version control systems

Interview Tips

Time: Spend 10 minutes understanding the importance of requirements, 15 minutes discussing functional vs non-functional requirements and gathering techniques, 10 minutes on documentation and change management, 10 minutes on scaling and challenges.

Clear distinction between functional and non-functional requirements

Importance of stakeholder communication and prioritization

Use of structured documentation and traceability

Handling changes and maintaining requirement quality

Challenges in scaling requirements management and practical solutions

Practice

1. Which of the following best describes a functional requirement in system design?

easy

A. A usability guideline for user interface design

B. A quality that defines how fast the system should respond

C. A security measure to protect user data

D. A feature that defines what the system should do

Solution

1. Step 1: Understand functional requirements

   Functional requirements specify the actions or features the system must perform, such as user login or data processing.

2. Step 2: Differentiate from non-functional requirements

   Non-functional requirements describe qualities like speed, security, or usability, not specific features.

3. Final Answer:

   A feature that defines what the system should do -> Option D

4. Quick Check:

   Functional = What system does [OK]

Hint: Functional = what system does; Non-functional = how well [OK]

Common Mistakes:

• Confusing functional with non-functional requirements
• Thinking security is a functional requirement
• Mixing usability with system features

2. Which of the following is a correct example of a non-functional requirement?

easy

A. The system shall respond to user requests within 2 seconds

B. The system shall provide a search feature

C. The system shall store user profiles

D. The system shall allow users to reset their password

Solution

1. Step 1: Identify non-functional requirements

   Non-functional requirements describe system qualities like performance, reliability, or security.

2. Step 2: Match options to definitions

   The system shall respond to user requests within 2 seconds specifies response time, a performance metric, which is non-functional. Others describe features (functional).

3. Final Answer:

   The system shall respond to user requests within 2 seconds -> Option A

4. Quick Check:

   Non-functional = system qualities [OK]

Hint: Look for qualities like speed or security for non-functional [OK]

Common Mistakes:

• Choosing features as non-functional requirements
• Ignoring time or performance constraints
• Confusing functional and non-functional examples

3. Given these requirements:

• The system must allow users to upload files.
• Uploads must complete within 5 seconds.
• The system must support 1000 concurrent uploads.

Which of these is a functional requirement?

medium

A. Uploads must complete within 5 seconds

B. The system must support 1000 concurrent uploads

C. The system must allow users to upload files

D. The system must ensure uploaded files are available 99.9% of the time

Solution

1. Step 1: Identify functional requirements

   Functional requirements describe what the system does, such as allowing file uploads.

2. Step 2: Analyze each option

   A is performance (non-functional). B is capacity/scalability (non-functional). D is availability (non-functional).

3. Final Answer:

   The system must allow users to upload files -> Option C

4. Quick Check:

   Functional = system features [OK]

Hint: Features = functional; qualities like speed = non-functional [OK]

Common Mistakes:

• Selecting performance, capacity, or availability as functional
• Confusing capacity constraints as functional
• Ignoring direct feature statements

4. A system requirement states: "The system shall handle 1000 requests per second." Which type of requirement is this and what is wrong if it is listed as functional?

medium

A. Functional; it describes a feature, so it's correct

B. Non-functional; it describes performance, so listing as functional is incorrect

C. Functional; it describes user behavior, so it's correct

D. Non-functional; it describes security, so listing as functional is incorrect

Solution

1. Step 1: Identify requirement type

   Handling 1000 requests per second is about performance, a non-functional quality.

2. Step 2: Explain why listing as functional is wrong

   Functional requirements describe features, not performance metrics. Mislabeling causes confusion in design and testing.

3. Final Answer:

   Non-functional; it describes performance, so listing as functional is incorrect -> Option B

4. Quick Check:

   Performance = non-functional [OK]

Hint: Performance metrics are non-functional, not features [OK]

Common Mistakes:

• Calling performance a functional requirement
• Confusing user behavior with system qualities
• Ignoring the impact of mislabeling requirements

5. You are gathering requirements for a new messaging app. Which combination below correctly pairs functional and non-functional requirements?

hard

A. Users can send messages; messages must be delivered within 1 second

B. Messages must be encrypted; users can create profiles

C. The app must support dark mode; users can block contacts

D. The app must be available 24/7; Messages must be delivered with 99.99% reliability

Solution

1. Step 1: Identify functional requirements in options

   Functional requirements describe features like sending messages or creating profiles.

2. Step 2: Identify non-functional requirements in options

   Non-functional requirements describe qualities like speed, availability, or security.

3. Step 3: Analyze each option pair

   Users can send messages; messages must be delivered within 1 second pairs sending messages (functional) with delivery speed (non-functional). Others mix two functional or two non-functional requirements incorrectly.

4. Final Answer:

   Users can send messages; messages must be delivered within 1 second -> Option A

5. Quick Check:

   Functional + Non-functional = Users can send messages; messages must be delivered within 1 second [OK]

Hint: Functional = features; Non-functional = qualities like speed or availability [OK]

Common Mistakes:

• Mixing two functional or two non-functional requirements
• Confusing UI features with system qualities
• Ignoring delivery time as non-functional