Requirements — Part 1: Functional vs Non-Functional

maang.io AI-Native Builder Series

---

What is this?

Imagine you order a pizza over the phone. You say: "One large pizza, half pepperoni, half mushroom, extra cheese." That's a list of things the pizza must have — toppings, size, the way it's split. The kitchen can read that list and build exactly the right pie. But notice everything you didn't say out loud, even though you absolutely expect it: the pizza should be hot when it arrives, it should show up in under 45 minutes, the box shouldn't be crawling with ants, and the cheese shouldn't be the kind that sends you to the hospital. Nobody says those things — but if any of them is wrong, the order is a disaster, no matter how perfect the toppings were.

A requirement is a single, specific thing your app must be or do — one line on the order. And as that pizza shows, requirements come in two flavors. There's what the app does (pepperoni, mushroom, the split) and how well it does it (hot, fast, safe, clean). Your product brief — the one you wrote in the Product Thinking topic — tells you the big picture of who the app is for and why it matters. Requirements are where you turn that picture into a concrete, checkable list the kitchen can actually cook from.

The one-line idea: a requirement is one specific thing your app must do or be — and the dangerous half is the one nobody thinks to say out loud.

Remember the head chef from the AI-Native Mindset topic — you directing a brilliant-but-tasteless cook? Requirements are the order ticket you hand that cook. The clearer the ticket, the better the meal. Let's learn to write a good one.

---

1. What a requirement really is

Strip away the jargon and a requirement is just a clear, testable statement of something your app must do or be. "Testable" is the key word. A good requirement is written so that you — or anyone — can look at the finished app and answer yes, it does that or no, it doesn't. There's no maybe.

Compare these two attempts at the same idea:

The first sounds reasonable but it's a wish, not a requirement — you can argue about "easy" forever and never settle it. The second is a real requirement: you can hand the app to a friend, start a timer, and get a clean yes or no. 💡 The test for a good requirement is simple: could you write a check that proves it's met? If you can't, you haven't written a requirement yet — you've written a hope.

Why does this matter so much for you, an AI-native builder? Because your requirements become the instructions you hand the AI. A vague requirement produces vague code. "Make login easy" gives the cook nothing to work with. "Let a user log in with email and password, and show an error if the password is wrong" gives it something it can actually build correctly. The list you write in this topic is the raw material for every prompt you'll write in 201.

---

2. The two flavors: functional and non-functional

Every requirement is one of two kinds. Learning to tell them apart is the whole point of this chapter, so let's nail it with the cleanest definitions:

• A functional requirement describes what the app does — a feature, an action, a behavior. "The app must let a user mark a habit done for today." If you can phrase it as "the app lets the user ..." or "the system must ...", it's functional.
• A non-functional requirement describes how well the app does it — a quality the whole app must have, not a feature you can point at. "The app must load in under 2 seconds." "Passwords must be stored securely." These don't add a button; they set a standard everything has to meet.

Here's the split as a picture:

A trick that almost never fails: functional requirements are usually verbs the user does; non-functional requirements are usually adjectives the app must be. The user creates a habit, marks it done, sees a streak — verbs, functional. The app must be fast, secure, reliable, private — adjectives, non-functional.

One more way to feel the difference: a functional requirement, if missing, means a feature isn't there ("there's no way to log a habit"). A non-functional requirement, if missing, means the feature is there but bad ("you can log a habit, but it takes eight seconds and sometimes loses your data"). Both can ruin the app. Only one of them is obvious.

---

3. StreakUp's functional requirements

Let's make this real with the app you're building. Take StreakUp's core idea and list out what it does — the functional requirements. These come straight from the MVP features in your brief:

Notice the shape of each one — "let a user do something." That's the functional fingerprint. Written out as a proper list, they look like this:

• The app must let a user sign up and log in with an email and password.
• The app must let a logged-in user create a habit with a name.
• The app must show a user today's habits when they open the app.
• The app must let a user mark a habit done for the current day.
• The app must show the current streak for each habit.

Every one is a verb the user does, and every one is testable — you could click through the finished app and check each off. These five are the skeleton of StreakUp. ⚠️ But a skeleton with no skin is not a usable body. Those five features could each technically "work" and the app could still be unusable, unsafe, or so slow nobody comes back. That's where the second flavor comes in — and it's the one that catches beginners off guard.

---

4. The iceberg: why non-functional requirements sink projects

Here's the most important idea in this chapter. Functional requirements are the part of the iceberg above the water — visible, obvious, the stuff everyone remembers to list. Non-functional requirements are the enormous part below the water — invisible, ignored, and exactly what tears the hull open.

Why does the hidden half sink projects? Because nobody asks for non-functional requirements, so beginners never plan for them — and then they show up as emergencies. The app works great on your laptop with two test habits, you demo it, everyone's happy. Then a real person uses it: they have forty habits, they're on a three-year-old phone, the internet's spotty, and suddenly the app is slow, the layout is broken, and — the nightmare — a bug wipes out their data. None of those were "features." All of them were non-functional requirements you didn't write down.

🚫 The classic beginner mistake is treating non-functional requirements as "polish for later." They are not polish. "Don't lose the user's data" and "keep passwords safe" are not nice-to-haves you bolt on in week eight — they're load-bearing decisions that shape how you build from day one. Retrofitting security or performance into a finished app is like trying to add a foundation to a house that's already standing.

---

5. StreakUp's non-functional requirements

So let's haul StreakUp's iceberg above the water on purpose. Here are the qualities the app must have, no matter which features it ships:

• Fast: the app loads and responds quickly — opening it and seeing today's habits should feel instant, not laggy.
• Works on a phone: the screens are readable and tappable on a small phone screen, not just a laptop. (StreakUp's whole point is logging on the go.)
• Keeps passwords safe: passwords are stored securely, never in plain text, so a leak doesn't expose anyone's account.
• Doesn't lose data: a user's habits and streaks are reliably saved — closing the app, or a crash, never wipes their history.
• Minimal, age-appropriate data: the app collects only what it needs (an email and habits) and nothing personal it doesn't — especially important given who builds and uses this.

Map each quality to the disaster it prevents, and the value becomes obvious:

These tie back to the "trust, then verify" and responsible-building threads from the AI-Native Mindset topic. Notice that two of the five — safe passwords and minimal data — aren't just about quality; they're about not harming the people who use your app. That's not optional, and it's a habit you build now, on a small project, so it's automatic when the projects get bigger.

💡 You won't implement all of these in 101 — that's later tiers' job. But naming them now means that when you prompt the AI to build a login in 201, you'll already know to add "store the password securely, never in plain text" to the order ticket. The list is what makes the build go right.

---

6. Putting both halves on one page

A requirements list isn't two separate documents — it's one list with two clearly-labeled sections, so nothing falls below the waterline unnoticed. Here's the shape of StreakUp's, the thing you'll actually write:

That's a complete first requirements list — both flavors, on one page, every line testable. It's not finished thinking, though. Right now everything looks equally important, and it isn't. Some of these are non-negotiable for a first version; others can wait. Sorting which is which — deciding what your first real version actually includes — is the job of the next two chapters: Scope, MVP & Defining Done, then Prioritizing with MoSCoW.

---

Key takeaways

1. A requirement is one clear, testable statement of something your app must do or be. If you can't write a check that proves it's met, it's a wish, not a requirement.
2. Functional requirements describe what the app does (user verbs: create, mark, see). Non-functional requirements describe how well it does it (app adjectives: fast, secure, reliable, private).
3. Non-functional requirements are the invisible iceberg — nobody asks for them, so beginners skip them, and they're exactly what sinks a project once real users arrive.
4. They are not "polish for later." "Keep passwords safe" and "don't lose data" shape how you build from day one and protect the people who use your app.
5. Your requirements list is one page, two labeled sections — and it's the raw material for every prompt you'll hand the AI in later tiers.

Your turn

Open your build journal and start StreakUp's requirements list — the first piece of your Spec Package:

1. Under a heading "Functional", list everything StreakUp must let a user do. Start from the five core features, then add any you think belong. Phrase each as "the app must let a user ..." and make sure each is testable.
2. Under a heading "Non-functional", list at least five qualities the whole app must have. For each, write one sentence on the disaster it prevents — that's how you know it earns its place.
3. Re-read your non-functional list and ask the hard question: which of these did I almost forget? Star it. That starred line is the part of the iceberg that sinks projects — and you just pulled it above the water.

In Part 2, we'll take this list and confront the real enemy of every first project: trying to build all of it at once. You'll learn what an MVP is, how scope quietly creeps, and how to define "done" so you actually finish.