Module 01 · Lesson 5 of 14Free

Functional and non-functional requirements

Level

Beginner

Topic

System design fundamentals

Reading time

15 min

Kartly adds order tracking before its festival sale. A customer opens her order and waits 8 seconds to see “Shipped”.

The feature passes its test: it displays the right status. The customer still thinks it is broken.

What must we specify beyond “customers can track orders” to build the right feature?

A working feature can still fail

Start with two statements:

• A customer can view the shipping status of her own order.
• The tracking response arrives within 300 ms for at least 95% of eligible requests.

The first describes what the system does: a functional requirement. The second describes how well it must do it: a non-functional requirement.

Non-functional does not mean optional. Both belong in the design’s acceptance criteria, rather than being left for implementation teams to guess. Microsoft’s architecture guidance similarly connects functional and non-functional choices to business needs.^{3Develop an architecture design specificationMicrosoft, Microsoft Learn: Azure Well-Architected Framework, 2025}

For this lesson, Kartly still has one app server and one PostgreSQL database. Tracking shows shipment status, not a live courier map.

The initial behavior is small:

The ownership rule describes behavior and also supports privacy. The categories can overlap. Their purpose is to reveal missing requirements, not to force every sentence into one category.

We now know what tracking does. We still need to define acceptable service.

“Fast” needs a measurement boundary

“Make tracking fast” leaves several questions unanswered. Does timing start when the customer taps, when the server receives the request, or when a database query starts?

As Latency and throughput established, the boundary changes the number.

A service-level indicator, or SLI, measures an aspect of service quality. A service-level objective, or SLO, gives that indicator a target over a stated period. A useful indicator is often good events divided by eligible events.^{1Implementing SLOsSteven Thurgood and David Ferguson, with Alex Hidalgo and Betsy Beyer, The Site Reliability Workbook, 2018}

Here is Kartly’s proposed tracking agreement.

These are illustrative product targets, not measured Kartly performance or universal recommendations.

Define eligible reads as authenticated requests for an existing order owned by the requester. Time starts when the request reaches Kartly’s public entry point and ends when its response leaves.

Timeouts and server errors count as bad events. A quick error does not count as a fast, valid status. Invalid requests and deliberate attempts to read someone else’s order are excluded from these service indicators.

The update objective has a different boundary. It starts when PostgreSQL confirms a status change. It applies to customers already viewing that order in an online, foreground app. An expected update that misses its deadline counts as bad, not as a missing sample.

This objective does not promise that Kartly knows about a parcel within 30 seconds of physical movement. That would require a separate agreement about how staff record shipment events.

Measurement boundaries expose promises that the system cannot make.

One extra nine removes most allowance

An error budget is the bad-event allowance implied by an SLO. A 99.9% success objective leaves 0.1% for bad events. It is a planning limit, not permission to ignore failures.^{1Implementing SLOsSteven Thurgood and David Ferguson, with Alex Hidalgo and Betsy Beyer, The Site Reliability Workbook, 2018}

People often translate availability percentages into minutes. That is valid for a time-based measure: available time divided by total time. Request-based availability uses a different denominator.^{2AvailabilityAmazon Web Services, AWS Well-Architected Framework: Reliability Pillar, 2026}

For the following calculation only, assume a time-based objective and an exact 30-day month.

Under this time-based example, a 6-minute restart exceeds the entire 99.99% allowance. It does not exceed the 99.9% allowance by itself.

But Kartly’s proposed objective counts requests. In an illustrative month with one million eligible reads, 99.9% allows 1,000 bad reads. At 99.99%, the allowance is 100.

Do not describe those request budgets as guaranteed downtime allowances. A short interruption during the festival sale can affect more requests than a longer interruption overnight.

Higher availability targets also require more demanding recovery and operating practices. Buying another server alone does not establish a service guarantee.^{2AvailabilityAmazon Web Services, AWS Well-Architected Framework: Reliability Pillar, 2026}

For Kartly, the consequence is a question for the product owner: does reducing the allowance justify the additional engineering work?

Targets choose the refresh behavior

The simplest implementation reads the status when the customer opens the page. The app server checks ownership, reads PostgreSQL, and returns the status.

That satisfies the initial display behavior. It cannot satisfy the update objective if the customer leaves the page open.

A small improvement is polling: the app asks for the current status repeatedly. The question becomes how often.

For a worked example, assume a change commits just after a poll. The next poll starts about 20 seconds later. Suppose its request and rendering take another second. The customer sees the change after about 21 seconds.

A 30-second interval leaves almost no room for that extra work. Setting an interval equal to the deadline confuses one component’s timing with the whole experience.

Server concurrency explains how the server handles overlapping reads. We will estimate their volume in Capacity estimation.

Freshness has changed client behavior. The failure objective changes what happens when refreshing cannot succeed.

A fallback can hide a failure

Suppose a refresh cannot reach PostgreSQL. The app already displays an earlier status.

Showing that status is useful, but calling it current would mislead the customer.

This choice preserves information without changing the meaning of success. Google’s SLO guidance similarly distinguishes degraded service from an undegraded result.^{1Implementing SLOsSteven Thurgood and David Ferguson, with Alex Hidalgo and Betsy Beyer, The Site Reliability Workbook, 2018}

The privacy constraint changes a third implementation detail. The server checks ownership on every read, even when an order identifier appears difficult to guess.

If ownership cannot be verified, it returns no order information. On logout, the app clears its retained tracking display.

For this scenario, privacy wins over returning a status. It is a required rule, not something Kartly may violate within a monthly allowance.

Requirements become useful when they say what to sacrifice during a conflict.

Conflicts need an explicit owner

Suppose the team proposes two launch requirements:

• Every tracking view must confirm the latest status.
• Tracking must remain usable when the database cannot be reached.

If PostgreSQL is the only source of current status, the system cannot meet both during a database outage.

Do not hide that conflict behind “best effort”. Present the product owner with the consequences:

For this lesson, the product owner accepts the labelled old display. Current verification remains unavailable during the outage.

Record the decision, its owner and its reconsideration condition. Here, reconsider if customers need tracking information to make a time-sensitive delivery choice.

Negotiation and clear documentation are part of architecture work, not evidence that requirements have failed. Microsoft’s guidance describes requirements refinement as an iterative, collaborative process.^{3Develop an architecture design specificationMicrosoft, Microsoft Learn: Azure Well-Architected Framework, 2025}

Evidence turns targets into decisions

Before launch, write acceptance checks from the agreement:

• Delay a tracking response beyond its deadline.
• Commit a change immediately after a poll.
• Interrupt database access during a refresh.
• Request another customer’s order.
• Log out after displaying an order.

For timing, begin with controlled test clients. Compare the last observed status with the committed change, and record whether the deadline was met.

In production, entry-point measurements cover Kartly’s response boundary, not the whole phone experience. Client measurements can reveal failures outside that boundary, but introduce their own coverage limitations.^{1Implementing SLOsSteven Thurgood and David Ferguson, with Alex Hidalgo and Betsy Beyer, The Site Reliability Workbook, 2018}

Keep the objectives provisional until there is evidence. If measurements miss a target, investigate the cause before choosing between changing the design and negotiating the target.

Detailed operating policies belong in SLOs and error budgets.

Where this shows up

• Design: a fast product catalog page: acceptable staleness helps determine whether stored copies are useful.
• Design: a notification service: delivery deadlines must specify what counts as delivered.

Kartly now has explicit promises; next, it needs to estimate the traffic and storage required to support them.

Common mistakes

• Naming a technology as a requirement. “Use push” is a proposed solution. “Show updates within 30 seconds” leaves alternatives open.
• Reporting only an average. It does not establish that the agreed fraction of requests meets the deadline.
• Excluding inconvenient failures. A database timeout still affects the customer.
• Treating every rule as a percentage. Protecting another customer’s information is not an error-budget tradeoff.

Check your understanding

Summary