Requirements and the Design Loop

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Start every design by asking what the system must do and how well: functional and non-functional requirements, SLIs, SLOs and SLAs, percentiles, error budgets, scope, and the design loop.

Imagine a friend asks you to build a house.

You would not start by buying bricks right away. First, you would ask important questions. How many people will live there? How many bedrooms are needed? What is the budget? Only after getting those answers would you create a plan.

Software works the same way. Before designing a system, you need to understand what it must do and how well it must do it. These two groups of requirements guide every design decision.

The main idea: you can only evaluate a design against its requirements. Without requirements, there is no way to know whether a design is good or not.

Meet QuickBite

Throughout this course, we will use the same example application called QuickBite, a food delivery platform.

QuickBite has three types of users:

• Customers place food orders.
• Restaurants prepare the food.
• Riders deliver the food.

Each lesson builds on the same application. The numbers and decisions you make here will be used again in later lessons.

What You Will Learn

In this lesson, you will learn:

1. Why requirements should come before design.
2. Which questions to ask before designing a system.
3. What functional requirements are.
4. What non-functional requirements are.
5. How to turn a goal such as "fast" into a measurable target using SLI, SLO, and SLA.
6. Why percentiles are more useful than averages.
7. What an error budget is.
8. How to define what is out of scope.
9. The design process used throughout this course.

Why Requirements Come First

Consider this short story.

Asha is asked during an interview to design a food delivery application. She immediately starts drawing servers and system components. Ten minutes later, the interviewer asks, "How many orders per second must the system support?" Asha does not know because she never asked.

Ravi receives the same question. Instead of designing immediately, he spends the first few minutes gathering requirements. His design is simpler than Asha's, but every part of it exists for a clear reason.

Without requirements, it is impossible to distinguish a good design from a bad one. You end up guessing, and large guesses often waste both time and money.

In simple terms: ask questions first and design second.

Step 1: Ask Good Questions

Good questions are short, practical, and useful. They help you understand:

• who uses the system;
• what the system must do;
• how large the system is expected to be.

Click each card to see why the question matters.

Each answer influences the design. If an answer changes your design decisions, the question was worth asking.

Functional Requirements

What They Are

A functional requirement describes what the system does.

A functional requirement usually contains:

• an actor: who performs the action;
• an action: what they do.

For example:

"Customers can search for restaurants."

The actor is the customer, and the action is searching.

A Quick Trick: Look for the Verb

Functional requirements often contain verbs such as:

• search
• order
• pay
• accept
• deliver
• track

If you can imagine a user clicking a button to perform the action, it is probably a functional requirement.

Pick the Core Three to Five

A real food delivery application may contain hundreds of features. Designing everything at once is not practical.

Instead, focus on the three to five most important features and clearly state them.

For QuickBite:

1. Customers search for restaurants.
2. Customers place orders and make payments.
3. Customers track riders on a map.

Trying to design every feature is one of the most common reasons people run out of time.

Non-Functional Requirements

What They Are

A non-functional requirement describes how well the system performs.

It focuses on quality rather than functionality.

A customer never clicks a "be fast" button, but customers will stop using an application that feels slow.

The Six Common Types

In simple terms:

• Speed (Latency): how long a request takes.
• Availability (Uptime): how often the system is working.
• Scale: how much traffic the system can handle.
• Consistency: whether users see the correct and up-to-date data.
• Durability: whether saved data stays saved.
• Security: whether private data is protected.

Non-functional requirements often influence the design more than the features themselves.

Searching for restaurants looks similar whether there are 100 users or 10 million users. The infrastructure behind it is very different.

Not Every Feature Needs the Same Rules

Different parts of the application have different requirements.

• Payments must be completely accurate. Charging a customer twice is a serious problem.
• Restaurant ratings can be slightly outdated. Most users will not notice if ratings lag by a few seconds.

Stating these differences clearly allows you to apply strict and expensive solutions only where they are truly needed.

Turning Wishes into Numbers

"The application should be fast" sounds good, but it cannot be measured.

To make it measurable, you need three concepts:

• SLI
• SLO
• SLA

The Pizza Shop Story

Imagine a pizza shop with a sign that says:

"Delivered in 30 minutes or your pizza is free."

Internally, the manager tells the staff:

"Let's aim for 25 minutes so we have a safety margin."

Meanwhile, every delivery is timed with a stopwatch.

What Each Term Means

Using this example:

• SLI (Service Level Indicator) is the stopwatch. It measures performance.
• SLO (Service Level Objective) is the team's internal goal.
• SLA (Service Level Agreement) is the promise made to customers.

For QuickBite:

• SLI → menu page load time.
• SLO → 99% of menu loads complete in under 300 ms.
• SLA → a customer-facing promise that may include penalties if broken.

The SLO should be stricter than the SLA to provide a safety margin.

In simple terms: measure it with an SLI, define a goal with an SLO, and make customer promises through an SLA.

An SLI Is a Simple Fraction

Most SLIs are calculated as:

good events ÷ total events

Step through yesterday's orders at QuickBite:

Although 84 failures may sound large, the system still meets the 99.9% objective because there were 120,000 total orders.

Percentiles: Why Not Use the Average?

The Problem with Averages

Averages can hide slow experiences.

Take 200 menu loads. 196 take 150 ms, and four take between 1.2 and 1.5 seconds. Their average is 174 ms, which looks fast:

The average looks excellent, but some customers waited more than a second. The average hides those users.

What a Percentile Is

A percentile answers a different question:

"How long did the slowest users wait?"

• p50 represents the typical user.
• p99 represents the unlucky user.

To find a percentile, sort the values and pick the one at that position. Step through it:

The code behind the animation:

The right way: the p99 finds the slow loads

const ms = [...Array(196).fill(150), 1200, 1300, 1400, 1500];

// Sort, then pick the value that p% of loads are at or below.
function percentile(values, p) {
  const sorted = [...values].sort((a, b) => a - b);
  const index = Math.ceil((p / 100) * sorted.length) - 1;
  return sorted[index];
}

console.log(`p50 (typical user): ${percentile(ms, 50)} ms`);
console.log(`p99 (unlucky user): ${percentile(ms, 99)} ms`);

Expected output:

p50 (typical user): 150 ms
p99 (unlucky user): 1300 ms

The average suggests everything is fine, but the p99 immediately shows there is a problem.

See It for Yourself

Move the slider to add slow requests and compare the average with the p99.

The average changes only slightly, while the p99 reacts quickly when more users experience slow requests.

Error Budgets

No System Is Available 100% of the Time

Servers restart. Networks fail. Software contains bugs.

Instead of aiming for perfection, systems define a goal such as 99.9% availability.

The remaining 0.1% represents the amount of failure the system is allowed to have. This allowance is known as the error budget.

In simple terms: an error budget is the amount of failure your target allows.

Working It Out

A 30-day month has 30 × 24 × 60 = 43,200 minutes. Multiply by the part that may fail:

Each extra 9 cuts the error budget by ten.

While 99% sounds impressive, it still allows more than seven hours of downtime each month.

Try Different Targets

What Teams Do with the Budget

An error budget is meant to be used carefully.

• While budget remains, teams can continue releasing new features.
• When the budget is exhausted, reliability becomes the priority instead of new development.

This gives teams an objective way to balance innovation and reliability.

Pick the Right Target

Every additional "9" requires more infrastructure, engineering effort, and cost.

Match reliability goals to business importance.

Scope: What You Will Not Design

Your requirements should also include an out-of-scope list.

This list explains what is not included in the design.

It keeps the problem manageable and prevents unnecessary expansion.

In interviews, state this clearly:

"Payroll and loyalty points are out of scope. I will focus only on search, ordering, and tracking."

The Design Loop

Every system design in this course follows the same process.

1. Requirements – What should the system do and how well should it do it?
2. Estimate – How many users, requests, and bytes are involved?
3. Design – What components are needed and how do they interact?
4. Check – Does the design satisfy the requirements?

The cycle repeats until the design meets the requirements.

Watch three passes through the loop for QuickBite's menu page. The goal from the SLO: 99% of menu loads under 300 ms.

Without the 300 ms goal, there would be no clear way to decide when the design is good enough.

Try It: Sort the Requirements

Place each requirement into the correct category, then press Check.

Common Mistakes

Practice

What to Remember

• A design can only be evaluated against its requirements.
• Functional requirements describe what the system does.
• Non-functional requirements describe how well it performs.
• Focus on the 3 to 5 most important features.
• SLI measures performance, SLO defines a goal, and SLA defines a customer promise.
• Use percentiles, not averages.
• An error budget defines how much failure is acceptable.
• Clearly document what is out of scope.
• Follow the design loop: requirements → estimate → design → check.

Further Reading

These are the sources this lesson was checked against:

• Google SRE Workbook: Implementing SLOs: SLIs as good events over all events, and error budgets.
• Hello Interview: Requirements Gathering: picking core features, putting numbers on qualities, and setting rules per part.
• ByteByteGo: A Framework for System Design Interviews: the four-step interview flow and how long to spend on each step.
• System Design Primer: a free overview of the whole subject.

Next: Back-of-Envelope Estimation, where you will convert QuickBite's users into requests per second, storage requirements, and bandwidth estimates.