Introduction

Requirements discovery is the structured process of identifying, clarifying, documenting and validating what a system must achieve. It happens before detailed architecture decisions are made.

A system-design request often begins as a short and ambiguous statement:

Design a URL shortener.
Design a notification service.
Design an online marketplace.
Design a chat application.
Design a video-streaming platform.

These statements name a product category, but they do not contain enough information to produce a defensible architecture. A designer must discover users, workflows, data, scale, quality expectations, constraints, failure behaviour and scope boundaries.

In your System Design.xlsx curriculum, Requirements Discovery is the first topic under System Design Process and Estimation. The module combines requirements, constraints, request flow, high-level diagrams, quality attributes and scale estimation before component selection. 【1-c3ca5d】

Prerequisites

Purpose of Requirements Discovery

Requirements discovery helps a system designer determine:

• What problem the system must solve
• Who will use or interact with the system
• Which workflows must be supported
• Which data enters, leaves and remains in the system
• How well the system must perform
• Which failures must be tolerated
• Which legal, technical or business constraints apply
• Which features are essential for the first release
• Which features are outside the current scope
• How successful behaviour will be verified

Requirements gathering is commonly described as identifying and recording what users and stakeholders want a system to do, including scope, constraints, functional requirements and non-functional requirements. 【2-65d6bc】

Requirements Discovery Workflow

Start with the Problem, Not the Solution

We need microservices, Redis, Kafka and a NoSQL database.

Users need short, shareable links that redirect reliably to long destination
URLs. The system must support high redirect traffic, prevent abusive links and
provide basic usage statistics.

The first statement locks the design into technologies before the problem has been measured. The second identifies user value and design pressures while leaving room to evaluate alternatives.

Problem Statement Template

Problem:
What difficulty, delay, risk or unmet need exists?

Affected users:
Who experiences the problem?

Current process:
How is the work performed today?

Business impact:
What cost, delay, risk or missed opportunity results?

Desired outcome:
What improvement should the new system provide?

Success evidence:
How will stakeholders know that the problem has been addressed?

Identify Stakeholders

A stakeholder is a person, group or external party that uses, funds, operates, supports, regulates or is affected by the system.

Define the System Boundary

The system boundary distinguishes responsibilities owned by the proposed system from responsibilities owned by users or external services.

Example: URL Shortener Boundary

Inside the system:
- Accept a long URL
- Generate or accept a short alias
- Store the mapping
- Redirect a visitor
- Disable an invalid or abusive link
- Record basic access events

Outside the system:
- Render the destination website
- Guarantee the destination website's availability
- Operate third-party identity providers
- Control external social-media platforms
- Repair invalid destination content

Explicitly stating what is outside the system reduces scope drift and prevents the architecture from silently assuming responsibilities that belong to another service.

Discover User Journeys

A user journey describes a concrete path from an actor's goal to an observable result.

Journey Template

Actor:
Who initiates the journey?

Trigger:
What event starts it?

Preconditions:
What must already be true?

Main flow:
What actions occur in the normal case?

Alternative flow:
What happens when a decision differs?

Failure flow:
What can fail and what should the user observe?

Result:
What state or output exists after completion?

Example Journey

Actor:
Registered user

Trigger:
The user submits a long URL.

Preconditions:
The account is active and the submitted URL uses an allowed scheme.

Main flow:
1. The system validates the URL.
2. The system generates a unique short code.
3. The system stores the short-code mapping.
4. The system returns the short URL.

Alternative flow:
The user supplies an available custom alias.

Failure flow:
The URL is malformed, the custom alias is already used, or the request exceeds
an applicable limit.

Result:
A valid short URL is returned, or a descriptive error is provided without
creating a partial mapping.

Functional Requirements

Functional requirements define the behaviours, capabilities and operations the system must provide. In simple terms, functional requirements describe what the system must do. 【3-31a261】【4-6f1c4c】

URL Shortener Functional Requirements

Functional Discovery Questions

• Who can create, read, update or delete data?
• Which actions require authentication?
• What information is required for each operation?
• What does the system return after success?
• What happens when a record does not exist?
• Can users repeat the same operation safely?
• Which actions must be reversible?
• Which reports, searches or filters are required?
• Which external systems participate in the workflow?
• What should happen when an external dependency fails?

Non-functional Requirements

Non-functional requirements define quality attributes and operating constraints. They describe how well the system must work, including performance, reliability, security, usability, scalability and maintainability. 【3-31a261】【4-6f1c4c】

Make Quality Requirements Measurable

The redirect service must be very fast and highly available.

Under:
<defined workload and environment>

The system shall:
<perform a specified operation>

Within:
<measurable target and unit>

Measured at:
<defined boundary or observation point>

Excluding:
<documented exclusions, if any>

Exact values must come from stakeholders, product evidence, existing measurements or an explicitly documented design assumption. Do not invent a target merely because it is common in another system.

Constraints

A constraint limits the solution space. Unlike a requirement that describes desired behaviour, a constraint describes a condition the solution must respect.

Assumptions vs Constraints

Assumption Register

Assumption ID:
A-01

Statement:
Redirect traffic is expected to be substantially greater than link-creation
traffic.

Source:
Initial product discussion

Impact if false:
The read-optimized design may not suit the actual workload.

Validation owner:
Product analytics owner

Validation evidence:
Traffic report or approved forecast

Status:
Open / Confirmed / Rejected

Requirements Discovery Techniques

Requirements elicitation can use stakeholder interviews, surveys, observation, workshops, brainstorming, document analysis, use cases, role-playing and prototypes. No single technique is guaranteed to uncover every relevant requirement. 【5-bf4ff0】

Effective Discovery Questions

Business Questions

• What problem should this system solve?
• Who experiences the problem?
• What happens if the problem is not solved?
• Which outcome would make the project successful?
• Which capabilities are mandatory for the first release?

User Questions

• Who are the primary and secondary users?
• What starts each user journey?
• What information does the user provide?
• What result does the user expect?
• Which errors occur most frequently today?
• Which actions require approval or escalation?

Data Questions

• Which entities must the system store?
• Which fields uniquely identify each entity?
• Where does the data originate?
• How frequently is the data created, read, updated or deleted?
• How long must the data be retained?
• Can data be corrected or permanently deleted?
• Which data is sensitive or regulated?

Scale Questions

• How many active users are expected?
• What are the average and peak request rates?
• Which operations dominate the workload?
• How large is a typical request, response or stored record?
• How quickly is traffic or data volume expected to grow?
• Are workloads global, regional or concentrated in a particular period?

Reliability and Security Questions

• Which operations must continue during partial failure?
• What data loss, if any, is acceptable?
• Can an operation be retried safely?
• Which actions require authentication and authorization?
• What abuse scenarios should be prevented?
• Which events require an audit record?
• How should operators detect and diagnose failures?

Prioritize Requirements

Requirements should be prioritized because time, cost and implementation capacity are limited.

Priority should reflect business value, risk, dependency and release necessity. It should not simply reflect which stakeholder speaks most frequently.

Validate Requirements

A high-quality requirement should be:

• Necessary
• Clear
• Consistent
• Complete enough for its purpose
• Feasible
• Measurable
• Testable
• Traceable
• Prioritized
• Owned

Requirement Template

Requirement ID:
<Unique identifier>

Title:
<Short descriptive name>

Statement:
The system shall <specific capability or quality>.

Reason:
<Business or user need>

Source:
<Stakeholder, document, policy or analysis>

Priority:
Must / Should / Could / Will not now

Acceptance criteria:
<Observable conditions proving completion>

Dependencies:
<Related system, requirement or decision>

Assumptions:
<Unconfirmed inputs affecting the requirement>

Owner:
<Accountable role>

Status:
Draft / Reviewed / Approved / Changed / Retired

Acceptance Criteria

Acceptance criteria convert a requirement into observable verification conditions.

Requirement:
The system shall create a short link for a valid destination URL.

Given:
The destination URL uses an allowed scheme and the requested alias is available.

When:
The client submits the create-link request.

Then:
The system stores one mapping.
The response contains the generated short URL.
A repeated request using the documented idempotency mechanism does not create
an unintended duplicate.
No partial record remains when the operation fails.

Requirements Traceability

Traceability connects the original need to design decisions, implementation components and verification evidence.

Complete URL Shortener Discovery Example

Problem

Users need compact links that can be shared conveniently and redirected to longer destination URLs.

Actors

• Anonymous link creator
• Registered link owner
• Redirect visitor
• System operator
• Abuse-review process

Core Functional Scope

• Create a short link
• Redirect a short code
• Reject invalid destinations
• Return a clear result for unknown or expired links
• Allow an owner to deactivate an owned link

Initial Out-of-scope Items

• Rendering destination content
• Guaranteeing external website availability
• Advanced marketing campaigns
• Complex attribution reporting
• Custom domain management

Quality Questions Requiring Answers

• What redirect latency is acceptable?
• What availability target applies to redirects?
• What availability target applies to link creation?
• How long should a mapping remain valid by default?
• How quickly must deactivated links stop redirecting?
• How much analytics delay is acceptable?
• What protection is required against malicious links or automated abuse?

Scale Inputs Requiring Evidence

• Average links created per day
• Peak link-creation requests per second
• Average redirects per day
• Peak redirect requests per second
• Average destination URL length
• Retention period
• Expected growth

Open Decisions

• Whether anonymous creation is supported
• Whether custom aliases are supported
• Whether links expire automatically
• Whether analytics is required in the first release
• Whether one short code can map to a changing destination
• Whether redirects must work during analytics failure

Requirements Discovery Output

A completed discovery activity should produce:

• Problem statement
• Stakeholder list
• System context and boundary
• In-scope and out-of-scope lists
• Functional requirements
• Non-functional requirements
• Constraints
• Assumptions and open questions
• User journeys and failure flows
• Data and access-pattern summary
• Scale inputs
• Requirement priorities
• Acceptance criteria
• Traceability matrix

Common Requirements Discovery Mistakes

Requirements Review Checklist

Practice Exercise

Perform requirements discovery for a notification service that can deliver email, SMS and mobile push notifications.

Tasks

1. Write the problem statement.
2. Identify at least five stakeholder types.
3. Define the system boundary.
4. Write five functional requirements.
5. Write five non-functional requirement questions.
6. Define the main send-notification journey.
7. Describe behaviour when a delivery provider is unavailable.
8. List data that must be stored.
9. Identify assumptions that require validation.
10. Separate must-have features from later features.

Model Functional Requirements

FR-01:
The system shall accept a notification request containing a recipient,
channel, template reference and template data.

FR-02:
The system shall validate that the requested channel is supported.

FR-03:
The system shall generate channel-specific content from an approved template.

FR-04:
The system shall record the current delivery status.

FR-05:
The system shall expose the delivery status to an authorized requester.

Model Discovery Questions

• May one request target several channels?
• What delivery delay is acceptable for each notification category?
• Are duplicate notifications acceptable after a retry?
• How long must delivery status be retained?
• Which failures should trigger retries?
• How many retry attempts are permitted?
• Which notifications require user consent?
• What happens when one provider is unavailable?
• Which delivery events require an audit trail?
• Who may create or modify message templates?

Frequently Asked Questions