Functional Requirements

Functional requirements describe what the system should do. They define the specific behaviors, features, and functions of the system.

Simple Definition

Functional Requirements = WHAT the system does
Non-Functional Requirements = HOW WELL the system does it

Examples

For a URL shortener:

• The system shall generate a short URL from a long URL
• The system shall redirect short URLs to original URLs
• The system shall allow users to specify custom aliases
• The system shall expire URLs after a configurable period

Characteristics of Good Functional Requirements

1. Specific: Clear and unambiguous
2. Testable: Can be verified through testing
3. Complete: Covers all expected behaviors
4. Consistent: No contradictory requirements
5. Traceable: Links to business needs

Where Functional Requirements Come From

Business Needs
├── Stakeholder interviews
├── User stories
├── Market research
├── Competitor analysis
└── Regulatory requirements
         ↓
Functional Requirements
├── Feature specifications
├── Use cases
├── User flows
└── API contracts

Functional Requirements vs User Stories

Format	Example
FR	"The system shall allow users to search products by name"
User Story	"As a shopper, I want to search products so I can find what I need"

Both describe the same feature, but FRs are more formal and precise.

Good system design starts with clearly defined features. Here's how to approach feature definition.

Feature Decomposition

System: Social Media Platform
│
├── User Management
│   ├── Registration
│   ├── Authentication
│   ├── Profile Management
│   └── Privacy Settings
│
├── Content
│   ├── Create Post
│   ├── Edit/Delete Post
│   ├── Like/React
│   └── Comment
│
├── Feed
│   ├── Home Feed
│   ├── Trending
│   └── Search
│
└── Messaging
    ├── Direct Messages
    ├── Group Chat
    └── Notifications

Prioritizing Features

Use MoSCoW method:

Priority	Description	Example
Must Have	Core functionality	User registration, posting
Should Have	Important but not critical	Notifications, search
Could Have	Nice to have	Custom themes, advanced analytics
Won't Have	Out of scope for now	Video calls, marketplace

Feature Specification Template

Feature: URL Shortening

Description:
Generate a unique short URL (6-8 characters) from a long URL.

Inputs:
- Long URL (required)
- Custom alias (optional)
- Expiration time (optional)

Outputs:
- Short URL
- QR code (optional)

Rules:
- Short URL must be unique
- Custom alias must not conflict with existing URLs
- Default expiration: never
- Maximum URL length: 2048 characters

Common Mistakes in Feature Definition

1. Vague requirements: "System should be fast" → Specify exact numbers
2. Missing edge cases: What happens with invalid URLs?
3. No priority: Not all features are equal
4. Implicit assumptions: Document everything explicitly

Use cases describe how users interact with the system to achieve specific goals.

Use Case Diagram

[User] ──→ (Login)
[User] ──→ (Create Account)
[User] ──→ (Post Content)
[User] ──→ (View Feed)
[Admin] ──→ (Moderate Content)
[Admin] ──→ (View Analytics)

Use Case Template

Use Case: Shorten URL

Actor: Registered User
Precondition: User is logged in

Main Flow:
1. User enters long URL
2. System validates URL format
3. System generates unique short code
4. System stores mapping in database
5. System returns short URL to user

Alternative Flows:
2a. Invalid URL format → Show error message
3a. Custom alias provided → Check availability
3a1. Alias available → Use custom alias
3a2. Alias taken → Suggest alternatives

Postcondition: Short URL is created and accessible

Mapping Use Cases to Components

Use Case	Components Needed
Shorten URL	API, URL Generator, Database
Redirect URL	API, Cache, Database
View Analytics	API, Analytics Service, Database
Delete URL	API, Authorization, Database

Use Cases for Interview Problems

For URL Shortener:

1. User creates short URL
2. User redirects via short URL
3. User views click analytics
4. User deletes expired URLs

For Chat System:

1. User sends message
2. User receives real-time messages
3. User creates group chat
4. User searches message history

From Use Cases to System Design

Use Cases → Components → Interfaces → Data Models → Architecture

1. Identify actors (users, services)
2. List their goals
3. Define system responses
4. Identify data needed
5. Design components to support each use case