Requirements and Constraints
Learn how to turn a vague product idea into clear functional requirements, non-functional requirements, assumptions, and engineering constraints.
What you will be able to do
Most weak system designs fail before the first box is drawn. The engineer starts solving a problem they have not clearly defined. This lesson teaches you how to define the problem first.
Why Requirements Come First
A requirement says what the product or system must do. A constraint limits how the system can do it. If you skip this step, every architecture choice becomes a guess: database, queue, cache, cloud service, deployment model, and even team ownership.
| Input | Bad interpretation | Better requirement |
|---|---|---|
| Build notifications | Send some messages | Users can receive email, push, and in-app notifications based on preferences. |
| Make it fast | Use cache everywhere | The API should acknowledge notification creation within 200 ms at p95. |
| Make it reliable | Use multiple services | Accepted notifications should not be lost if a provider is temporarily down. |
| Support scale | Use Kubernetes | Handle 2,000 writes/sec during campaigns and 10x read traffic after launch. |
Functional vs Non-Functional Requirements
Functional requirements describe user-visible behavior. Non-functional requirements describe system qualities: latency, throughput, availability, durability, security, compliance, cost, maintainability, and observability.
| Requirement type | Question | Notification example |
|---|---|---|
| Functional | What should the system do? | Create, schedule, send, retry, cancel, and show delivery status. |
| Latency | How fast should it feel? | Creating a notification should return quickly; delivery can happen in the background. |
| Throughput | How many operations? | Normal traffic is 100 notifications/sec; campaign traffic peaks at 2,000/sec. |
| Durability | What cannot be lost? | Accepted notification jobs and user preference changes must survive crashes. |
| Security | Who can do what? | Only authorized services can send notifications for a tenant. |
| Cost | What budget pressure exists? | Do not use always-on high-cost streaming if batch workers satisfy the need. |
Design principle
A feature is not a requirement until it has a user, a behavior, a boundary, and at least one measurable expectation.
Scenario: Food Delivery Order Status
Imagine a food delivery app wants real-time order status: order accepted, restaurant preparing, rider assigned, picked up, nearby, delivered. This sounds simple, but the design changes once requirements are clarified.
| Clarifying question | Possible answer | Design impact |
|---|---|---|
| Who watches status? | Customer, restaurant, rider, support team | Multiple clients and permission rules. |
| How fresh must location be? | Customer map updates every 3-5 seconds | Push, polling, or streaming decision. |
| What can be delayed? | Support analytics can lag by minutes | Can use async events and batch processing. |
| What must be correct? | Final delivered status and payment state | Needs durable writes and careful state transitions. |
| What happens during outage? | Show last known status and retry updates | Requires cached state, idempotent events, and observability. |
Constraints That Shape Architecture
Constraints are not annoyances. They are the reason one design is better than another. A small internal tool, a global chat app, and a banking ledger should not have the same architecture.
| Constraint | What it means | Architecture pressure |
|---|---|---|
| Scale | Users, requests/sec, data size, peak traffic | Load balancers, partitioning, queues, caching. |
| Latency | How quickly users need a response | Sync path must stay small; slow work moves async. |
| Consistency | How correct data must be across replicas | Transactions, locking, conflict handling, or eventual consistency. |
| Availability | How often the system must work | Redundancy, failover, degradation, operational maturity. |
| Durability | What data cannot be lost | Reliable storage, backups, replication, replayable logs. |
| Compliance | Legal, privacy, audit, region, retention rules | Access control, encryption, audit trails, data residency. |
| Team constraint | Team size, skills, support capacity | Managed services and simpler designs may beat custom complexity. |
Requirement Brief Template
Before designing, write a compact brief. This prevents vague architecture and gives reviewers a concrete basis for trade-offs.
| Section | What to write | Example |
|---|---|---|
| Users | Who interacts with the system | Customers, restaurants, riders, support agents. |
| Core flows | The main actions | Update order status, view order status, notify customer. |
| Data | Important entities and state | Order, status history, rider location, notification record. |
| Scale | Reads, writes, storage, peak behavior | 20k active orders, 5 location updates/order/minute. |
| Latency | Expected response time | Status page should show fresh updates within 5 seconds. |
| Reliability | What happens during failure | Do not lose final status updates; show last known state if live updates fail. |
| Out of scope | What you will not design yet | Restaurant inventory, payments, pricing, fraud detection. |
Cloud Services Follow the Brief
Cloud platforms matter in real work, but they should appear after the design need is clear. If the requirement says low-latency API plus durable background delivery, then you can map the pieces to managed compute, queues, databases, caches, and observability services.
| Architecture need | AWS | GCP | Azure |
|---|---|---|---|
| HTTP API | API Gateway + ECS/EKS/Lambda | Cloud Load Balancing + Cloud Run/GKE/Functions | API Management + Container Apps/AKS/Functions |
| Durable queue | SQS | Pub/Sub or Cloud Tasks | Service Bus queues |
| State storage | RDS/DynamoDB | Cloud SQL/Firestore/Spanner | Azure SQL/Cosmos DB |
| Fast shared state | ElastiCache | Memorystore | Azure Cache for Redis |
| Metrics and traces | CloudWatch/X-Ray | Cloud Monitoring/Cloud Trace | Azure Monitor/Application Insights |
How to Answer a Vague Request
When someone says, design a notification system or design live order tracking, do not begin with a diagram. First state the questions you need answered, then make reasonable assumptions if the interviewer or product owner does not provide them.
| Step | What to say | Why it matters |
|---|---|---|
| 1 | Let me clarify the users and core flow first. | Prevents designing the wrong product. |
| 2 | I will separate must-have behavior from quality targets. | Keeps functional and non-functional requirements visible. |
| 3 | I will make explicit scale assumptions. | Architecture depends on traffic and data growth. |
| 4 | I will name out-of-scope areas. | Controls complexity and keeps the design focused. |
| 5 | I will revisit assumptions when choosing storage, cache, queue, and cloud services. | Shows trade-off discipline. |
Beginner Mistakes
- Treating requirements as a formality instead of the foundation.
- Writing words like fast, scalable, and reliable without numbers or user impact.
- Mixing must-have product behavior with optional future features.
- Trying to solve every possible failure in the first design.
- Choosing AWS, GCP, Azure, Kafka, or Kubernetes before knowing the real constraint.
Guided Practice
Practice task
Take a notes app. Write three functional requirements, three non-functional requirements, two constraints, and two things you would explicitly keep out of scope for version one.
Sample Answer
| Category | Example answer |
|---|---|
| Functional requirements | Create note, edit note, list notes by updated time. |
| Non-functional requirements | Save should complete within 300 ms p95; notes should not be lost; users should access only their own notes. |
| Constraints | Small team; launch in one region first; mobile clients may be offline. |
| Out of scope | Real-time collaboration and full-text search ranking. |
Before You Continue
- You should be able to define functional requirements.
- You should be able to define non-functional requirements.
- You should understand that constraints shape architecture choices.
- You should be able to write a short design brief before drawing a system.
- You should be ready to quantify non-functional requirements in the next lesson.