# Clarifying requirements

> Turn a vague prompt into users, features, scale and constraints before drawing a single box.

Concept · Requirements & scale · https://levelcode.org/concepts/requirements-clarification

Every design starts from a sentence like "design a photo-sharing app". Clarifying requirements turns that into a short, specific list you can design against — and, just as usefully, a list of things you are **not** building.

## The questions worth asking

| Area | Ask | Why it matters |
|---|---|---|
| Users | Who uses it? Consumers, businesses, internal staff? How many? | Sets scale, security and latency expectations |
| Core actions | What are the three things users must be able to do? | Everything else is optional |
| Data | What's created, how big is it, how long is it kept? | Drives storage and cost |
| Reads vs writes | Which happens more, and by how much? | Decides where caching and replicas help |
| Freshness | How soon must a change be visible, and to whom? | Decides the consistency model |
| Constraints | Regions, compliance, budget, existing systems? | Rules options out early |

## Cut scope on purpose

List features, then mark each **in** or **out**. "Out" isn't failure; it's a decision that buys time for the parts that matter. A pastebin without accounts, search or comments is still a pastebin, and much easier to make reliable.

## Write the answers down

Turn the answers into one-line requirements: "users create pastes up to 1 MB", "links expire after a chosen period", "reads must not fail when writes do". Keep them visible while you design; each later decision should point back to one of them.

> [!TIP]
> When the person asking doesn't know an answer, propose a reasonable one and say it out loud: "I'll assume 10 million daily users; tell me if that's off." A stated assumption can be corrected. A silent one can't.

The [non-functional requirements](https://levelcode.org/concepts/non-functional-requirements) note covers how to turn "fast" and "reliable" into numbers.