Product Thinking and Requirements for AI-Generated Software

Why it matters#

A human developer handed a vague request comes back with questions. An AI agent rarely does. It turns whatever you wrote into working software within minutes, including the parts you never thought about. Chapter 1 argued that the bottleneck moves from typing code toward framing problems and checking results; requirements are where the framing happens. A requirement is a statement of something the product must do, or a quality it must have, written clearly enough that someone can check whether it is met. A specification is the collection of requirements, examples, and constraints for a product or feature. For an AI agent, the specification is the job description.

The cheapest place to fix a wrong idea is a sentence. Changing “push everything back a week” to “rebalance the remaining tasks into the weeks before the exam” takes ten seconds. Finding it after an agent has built the wrong feature costs an afternoon; finding it after users rely on it costs their trust.

This chapter turns Maya's notes into a product requirements document for the Learning Coach: who it is for, what it must do, how well, and what it will deliberately not do yet. Every later chapter builds and tests against it.

Learning objectives#

After this chapter you will be able to:

1. Write a problem statement grounded in real users, their situation, and the job they are trying to get done.
2. Separate what users ask for from what they need, and list the assumptions your plan depends on.
3. Write functional requirements as user stories with concrete acceptance criteria, including edge cases and failures.
4. Turn vague qualities like “fast” and “secure” into measurable nonfunctional requirements.
5. Prioritize an MVP by value, risk, and dependencies, and define what is out of scope.
6. Write and review a specification that an AI coding agent can build from and you can test against.

3.1 From idea to problem statement#

Start with a problem, not a feature#

Most ideas arrive as features: “an app that makes study plans”. A feature describes a solution. Before choosing a solution, write down the problem it solves, in a form you can check later:

[Who] needs a way to [make some progress] because [what gets in the way today]. We will know we have helped when [something observable changes].

For the Learning Coach:

University students preparing for a high-stakes exam need a way to turn the weeks before it into a plan they can keep, because they fall behind early and then abandon the plan entirely. We will know we have helped when students who make a plan are still ticking tasks in its last week.

The statement doesn't mention AI, accounts, or phones. Those are answers; the statement is the question every feature must answer to.

Personas from evidence#

A persona is a short description of a typical user, based on what you learned from real people. Describe circumstances and behavior, not demographics: whether Jun likes basketball tells you nothing, but whether he studies in ten-minute gaps on a bus tells you a lot. Include the context of use: where, when, on what device, with how much time, and under what pressure.

Jun, second-year nursing student. Studies on his phone during a 25-minute commute and in the library on two evenings a week, 6–8 hours in total. Clinical placements sometimes run late and wipe out a week of study without warning. Has tried paper planners and abandoned each one after falling behind. Exam: pharmacology, six weeks away.

One or two personas are enough for an MVP. Every detail should come from something a tester said or did; invented details turn a persona into fiction that misleads you.

Jobs to be done#

Jobs to be done is a way of thinking about why people choose products. As the Christensen Institute explains it, people “hire” a product to make progress in a particular situation, and every such job has functional, social, and emotional sides (Christensen Institute).

For the Learning Coach, the job might be:

When my exam is weeks away and I don't know where to start, help me turn it into a plan I can actually keep, so I walk in prepared instead of panicking the night before.

The plan is the functional side; the anxiety is the emotional side; not wanting falling behind to feel embarrassing is the social side. The job also shows your real competition: rarely another app, more often a notebook, a spreadsheet, a general chatbot, or cramming. Your value proposition is one sentence saying why your product does the job better than those:

When you miss study time, Learning Coach rebuilds the rest of your plan around your exam date instead of leaving you behind.

That came straight from the testers who always fall behind in week two, and it is a sharper promise than “AI study plans”.

Requests versus needs#

Testers know their own situation better than anyone, but they rarely see the constraints that shape a good fix. Treat every request as evidence of a need. Two questions find it: “What were you trying to do when you wanted that?” and “What happened the last time this came up?” Ask about past behavior, not hypothetical futures: “Would you use sharing?” invites a polite yes, while “When did you last share your study progress, and how?” gets a real story.

Here is Maya's feedback, translated:

Requirements come from the middle column. Jun's button was one possible solution to the need in row one, and a bad one.

Assumptions, unknowns, and discovery experiments#

An assumption is something you are treating as true without enough evidence. Write them down, because the riskiest one is the one nobody noticed. For each, note what happens if it is wrong and the cheapest way to test it, and decide what result would change your mind before testing, or any result will look encouraging.

The thresholds are judgment calls, not statistics: five people can't prove an idea works, but they can show that it is clearly failing. And notice that A1 needs no software. A message saying “Here is your updated plan” tests the value before anyone writes the algorithm.

Unknowns are questions you can't answer yet, such as “Do students have their syllabus as a file?” Keep them in an open questions list in the specification. An agent that hits an unanswered question will usually guess; the list shows you where.

3.2 Functional requirements#

A functional requirement describes something the system does: a behavior a user or another system can observe. “The student can tick off a task” is functional. “Ticking a task feels instant” is not; that is a quality, covered in section 3.3.

User stories#

A user story is a short description of a capability from the user's point of view, usually written as:

As a [type of user], I want [capability], so that [benefit].

The “so that” links the story to a need, which lets you, or an agent, choose between two ways of building it. In the Extreme Programming tradition a story has three parts: the card that names it, the conversation that fills in the details, and the confirmation, meaning the tests that show it is done (Wake, 2003). With an AI agent the conversation has to be written down, because the agent wasn't there for it.

Bill Wake's INVEST checklist tests a story's quality: Independent, Negotiable, Valuable, Estimable, Small, and Testable (Wake, 2003). With agents, Small and Testable matter most. “Study plans” is a product, not a story; and if you can't say how you would check a story, the agent can't know when it is done. Wake also suggests slicing stories vertically, so each slice works end to end. A slice from screen to stored data can be checked by using it; a database layer with no screen can only be checked by reading code.

Here are the Learning Coach's first stories, each with an ID you will reuse:

Use cases#

Stories name a capability but are weak at flows with branches. A use case lists the main steps of an interaction, then the alternatives, each attached to the step where it branches off.

UC-4: Rebalance after missed study

Main flow

1. The student sees last week has unfinished tasks and chooses “Rebalance my plan”.
2. The app spreads unfinished and remaining tasks across the weeks before the exam, within the weekly hours.
3. The app shows what changed; the student confirms.

Alternatives

• 2a. The tasks need more hours than are left. The app shows the shortfall and offers two choices: raise weekly hours, or pick tasks to drop.
• 2b. The exam is under seven days away. The app suggests a short review plan instead.
• 3a. The student cancels. Nothing changes.

Maya's agent never considered alternative 2a. It only appears when you ask, at each step, “what if this can't be done?”

Acceptance criteria and examples#

Acceptance criteria are the conditions a story must meet to count as done. The clearest format, used by the Gherkin language for executable specifications, is Given a starting situation, When something happens, Then an observable result follows. The Gherkin reference adds two useful points: Then should describe something a user can see, not a change hidden in a database, and examples should avoid assuming a particular interface so they survive design changes (Cucumber).

For US-4:

Rule: A plan never schedules tasks after the exam date

  Example: Rebalancing after a missed week
    Given an exam on June 30 and a plan with 6 hours of study per week
    And it is June 9, with 5 hours of last week's tasks unfinished
    When the student rebalances the plan
    Then every task is scheduled between June 9 and June 29
    And no week has more than 6 hours of tasks
    And the student sees which tasks moved before confirming

  Example: Not enough time left
    Given an exam on June 16 and 6 hours of study per week
    And it is June 9, with 14 hours of tasks left
    When the student rebalances the plan
    Then the student sees "You need about 8 more hours than you have"
    And can choose to raise weekly hours or drop tasks
    And no task is dropped without the student choosing it

Concrete dates and numbers matter. “Tasks fit within the student's hours” sounds clear until someone asks whether that means each week or in total, and whether a 45-minute task can be split across two weeks. Examples settle such questions before an agent guesses. When a rule has many cases (an exam in 21 days, 7 days, 3 days, today), list them as a small table of inputs and expected results.

Happy paths, edge cases, and failures#

The happy path is the flow where everything goes right, and AI-generated code is usually good at it, because the request describes it. An edge case is unusual but valid: an exam tomorrow, one topic, a plan created at 11:59 p.m. A failure case is something going wrong: invalid input, a service that doesn't answer, an action interrupted halfway. Most bugs, and most gaps in an agent's output, live off the happy path. Run each story through this checklist:

• Empty, one, many, and boundaries. No topics, one, forty; the smallest and largest allowed values, and one step beyond.
• Time. Past dates, today, time zones, a plan left open overnight.
• Repeats and two places at once. A button pressed twice; the same account open on a phone and a laptop.
• Interruptions and failing dependencies. The tab closed mid-generation; the AI service slow, down, or returning nonsense.

For failures, the Easy Approach to Requirements Syntax (EARS) helps. EARS gives requirements a fixed sentence structure to reduce ambiguity, and its pattern for unwanted behavior reads: If [trigger], then the [system] shall [response] (Mavin).

FR-9. If plan generation has not finished within 20 seconds, then the Learning Coach shall stop waiting, keep everything the student entered, and offer a simpler plan built from a template.

The fixed order of the sentence makes the missing parts obvious. If you can't fill in the “then”, you haven't decided what should happen, and the agent will decide for you.

Requirements traceability#

Traceability means you can follow a thread from each need to the requirements that serve it, and on to the tests that check them. For a small product it is just a few IDs.

flowchart LR
    N1["N1: Recover after missed study"] --> US4["US-4: Rebalance plan"]
    N1 --> FR9["FR-9: Generation timeout fallback"]
    US4 --> AC41["AC-4.1: No tasks after exam date"]
    US4 --> AC42["AC-4.2: Not enough time warning"]
    AC41 --> T41["Test: rebalance examples"]
    AC42 --> T42["Test: shortfall message and choices"]
    NFR2["NFR-2: Rebalance under 3 s"] --> US4

With these links, a changed need shows you every requirement and test to update, a finished agent task can be checked against the criteria it claims, and a scope cut shows which need goes unserved. Use stable IDs (N, US, AC, FR, NFR) and never reuse one, even after deleting the original.

3.3 Nonfunctional requirements#

A nonfunctional requirement describes how well the system must do things rather than what it does: how fast, how reliably, how securely, for whom, and at what cost. They are also called quality attributes.

When you don't state a quality, an agent still chooses one; it just doesn't tell you. So for each, name what is measured, the target, and the conditions. “Fast” is a wish. “For 95% of page loads on a mid-range phone, the plan appears within 2 seconds” is a requirement. The targets below are illustrative examples for the Learning Coach MVP; yours should come from your users and budget.

Speed#

Start from perception. Jakob Nielsen's long-standing guidance gives three limits: about 0.1 seconds feels instant, about 1 second keeps a person's train of thought, and about 10 seconds is as long as attention holds without feedback (Nielsen, 1993). So ticking a task should feel instant (update the screen, save in the background), opening the plan should take about a second, and AI plan generation must show progress at once and give up gracefully, as FR-9 says.

Measure with percentiles, not averages. “95th percentile under 2 seconds” means 95 of 100 loads were that fast or faster. Google's site reliability engineers prefer percentiles because averages hide the slow tail (Google SRE book): a page that averages one second can still take eight for every twentieth student.

Availability and throughput#

Availability is the share of time the system works. A 30-day month has 43,200 minutes, so:

Each extra nine costs real effort. For this MVP 99.5% is plenty, with one twist you only see by thinking about users: an outage the night before an exam is far worse than on a Tuesday. A cheap requirement protects that moment: “students can view their current plan even when the AI service is down.”

Throughput is how much work the system handles in a period. Estimate honestly (assume, say, 200 active students in month one) and design for ten times that, not a million. Building for millions on day one spends months on problems you don't have.

Accessibility#

Set an explicit target. The usual one is WCAG 2.2 Level AA, the W3C's Web Content Accessibility Guidelines (W3C, 2023). Chapter 2's checks are a starting point, not the whole standard. A written target is one an agent can be told to meet and a reviewer can check.

Security, privacy, retention, and audit#

Start with a data inventory: every piece of personal data the product will hold, why, where it goes, and how long it stays.

Two principles from the EU's General Data Protection Regulation make good defaults even where it doesn't legally apply. Data minimization: collect only what the purpose needs. Storage limitation: keep identifiable data only as long as the purpose requires (GDPR, Art. 5). For every field, ask “what breaks if we don't collect this?” If nothing, don't. Note the second row: the AI provider needs the topics, not the student's identity. That is easy to require now and hard to retrofit once code sends whole user records to a model.

An audit trail records who did what, and when. If anyone on your side can view a student's data, say for support, record each access.

Children's data carries extra legal duties. In the United States, the Children's Online Privacy Protection Act (COPPA) applies to services aimed at children under 13, and to general services that know they are collecting personal information from them (FTC). Other countries have their own rules, so the Learning Coach MVP is for students 18 and over, and opening it to younger learners needs legal review first. This book is not legal advice: for health, financial, children's, or education-record data, get a qualified review of the requirements before you build. Chapter 15 covers security and privacy in depth.

Budget and operational constraints#

Money and time are requirements too. Write them down with the arithmetic visible:

Assumption: each AI-generated plan costs about $0.02 in model fees, and an active student generates or rebalances about five plans a month. At 200 active students, that is about $20 a month for AI, plus hosting.

Chapter 9 replaces these placeholders with real prices. A budget becomes requirements: a monthly cap, a daily limit on rebalances, a cheaper model for small changes. Operations matter too: a solo builder can't promise to answer outages within 15 minutes at any hour, but can require that the plan stays readable with a clear message when the AI service is down.

Maintainability and future extension#

Some requirements protect the future: a fresh AI agent can run the project from the README in under 30 minutes; the plan's data format has a version number; and known future features (uploading notes and asking questions about them, chapter 9) are named so today's design doesn't block them.

3.4 MVP planning#

Chapter 2 defined an MVP, a minimum viable product, as the smallest version that delivers the core value to real users and lets you learn from them (Ries, 2011). Planning one is mostly deciding what to leave out.

Prioritize by value, risk, and dependencies#

Rank each candidate on value (which need, for how many users), risk (does it test an assumption that could sink the product? build the riskiest valuable thing early, which here is rebalancing, not dark mode), and dependencies (rebalancing needs a plan; syncing needs accounts).

A common way to record the result is MoSCoW, from the DSDM agile framework: Must have, Should have, Could have, and Won't have this time. DSDM's test for a Must is sharp: you would cancel the release without it. If any workaround exists, even a painful manual one, it isn't a Must. DSDM also recommends Musts take no more than about 60% of the planned effort, leaving room for surprises (Agile Business Consortium).

Define what is out of scope#

The Won't have this time row is a decision, not a wish list. It stops excluded features drifting back in, and it gives agents a boundary. Maya's agent added a streak counter nobody asked for; “no streaks, badges, or social features in this release” turns that surprise into a rule you can check. Give each exclusion a reason, such as “Sharing: needs consent and privacy design, and has no evidence of value yet”, so a future reader knows when to reconsider.

Build versus buy#

A rule of thumb: build what makes your product different; buy what is risky or ordinary.

Buying has costs too: fees, data sent to someone else (add it to the data inventory), and lock-in, meaning switching later is hard. Record them next to the decision.

Define measurable release criteria#

Release criteria say when the MVP is ready for real users. Without them, “ready” tends to mean “when the demo works”. For the Learning Coach:

1. Every acceptance criterion for the Must stories passes.
2. Each nonfunctional requirement has been measured, and the results are recorded.
3. Five students who have not seen the app complete the main flow (sign up, create a plan, tick a task, rebalance) without help.
4. The data inventory matches what the app actually stores and sends.
5. Deleting an account removes the student's data, and you have checked this yourself.
6. No known security issue rated high or critical is open.

Add one success metric, taken from the problem statement: of students who create a plan, the share still ticking tasks in its last week. The target is an assumption to test; 30% is a reasonable first goal for a tool many people abandon in week two.

Architect's decision: where should the first plans come from?#

3.5 Specification as a contract with AI coding agents#

The product requirements document#

A product requirements document (PRD) collects this chapter's work in one place. For an MVP keep it short, three to eight pages, as a Markdown file in the repository so it has a history, can be reviewed like code, and agents can read it. A workable outline: (1) problem and goals, (2) users, (3) scope, (4) user flows and states, (5) functional requirements, (6) nonfunctional requirements, (7) data and privacy, (8) release criteria, (9) assumptions, risks, and open questions, (10) change log.

The PRD is a living document. Change it first, then the code. When a chat with an agent and the PRD disagree, the PRD wins; if the chat was right, update the PRD.

User flows and states#

Chapter 2 drew a user flow, the path a user takes to get something done. Requirements also need the states the important things in your product can be in, and what moves them between states. Every state needs a screen and every transition a rule, and generated code tends to forget the states nobody mentioned.

Here is the life of a study plan:

stateDiagram-v2
    [*] --> Generating: student submits exam details
    Generating --> Active: plan passes rule checks
    Generating --> Fallback: timeout or invalid plan
    Fallback --> Active: student accepts template plan
    Active --> Behind: a week ends with unfinished tasks
    Behind --> Active: student rebalances and confirms
    Behind --> Behind: student dismisses the reminder
    Active --> Completed: all tasks done
    Active --> Ended: exam date passes
    Behind --> Ended: exam date passes
    Completed --> [*]
    Ended --> [*]

Drawing this raised questions the stories had missed. What does the student see in Behind if they never rebalance? Can a plan in Ended be reopened for a resit? Each question goes into the PRD as a requirement or an open question, before any code exists.

Testable examples and a completion rubric#

An agent needs to know when it is finished. Give it a definition of done for every feature: all acceptance criteria pass, including failure cases; the PRD's edge-case examples give the expected results; relevant nonfunctional requirements were checked, with results stated; no files outside the stated area changed; and the PRD and README are updated if behavior changed.

AI-generated content, like a study plan, needs a rubric: a short list of criteria for judging quality.

Code can check dates and hours; other criteria need a person, or later an AI judge tested against people. Chapters 9 and 13 turn this rubric into an evaluation set and automated tests. Writing it now gives “good plan” a meaning before anyone generates one.

Review the specification before coding#

Review the PRD three ways before an agent builds from it:

1. Hunt for vague words: “fast”, “easy”, “intuitive”, “secure”, “etc.”, “and/or”, and “should” where you mean “must”. Each is a decision not yet made.
2. Walk a tester through the flows: “You missed last week; what do you expect when you press this?” Disagreements here are cheap.
3. Give it to a fresh AI session, which has none of the context in your head. Ask it to find problems, not to build:

Here is a product requirements document. Don't write any code. List every ambiguity, contradiction, missing state, missing failure case, and question you would need answered before building it. For each one, say which section it is in and why it matters.

Answer in the PRD, not the chat: an answer in chat helps one session, an answer in the PRD helps every agent after it. Stop when the questions turn from what to how. “Which database?” is a fair question for architecture, in chapter 5.

AI collaboration recipe#

AI is a strong partner for requirements: tireless at listing edge cases and quick to structure messy notes. It is a poor owner of them, because it invents plausible needs nobody has. Let it draft, question, and check; make every decision yourself.

1. Interview me. Use this before writing anything.

I'm planning a product. Interview me about it, one question at a time, to help me write a problem statement and a persona. Ask about the users, their situation, what they do today, and what goes wrong. Don't suggest features or solutions until I say we're done.

2. From notes to needs.

Below are my notes from five user tests. Group them into underlying needs. For each need, quote the notes that support it and say how strong the evidence is. Don't add needs that aren't supported by the notes, and don't propose features.

3. Edge cases and failures.

Here is user story US-4 with its acceptance criteria. Using this checklist (empty/one/many, boundaries, time, repeats, two devices, interruptions, failing dependencies), list edge and failure cases I haven't covered. For each, propose a Given/When/Then example. Mark any case where the right behavior is a product decision I need to make.

4. Critique the specification. Use the fresh-session prompt from section 3.5.

Boundaries to state every time: “Mark anything you add as [proposed].” “Don't decide anything about privacy, legal, safety, or pricing; list it as a question for me.” “The PRD in the repository is the source of truth; point out conflicts with it.” And “prefer questions to assumptions”, because to an agent, being helpful often means guessing.

Worked example: the Learning Coach PRD#

Here is an excerpt of the Learning Coach PRD, version 0.1. Yours will differ in detail; the shape is what matters.

# Learning Coach: Product Requirements (v0.1)

## 1. Problem and goals
University students preparing for a high-stakes exam need a way to turn
the weeks before it into a plan they can keep, because they fall behind
early and then abandon the plan entirely.
Value: when you miss study time, Learning Coach rebuilds the rest of the
plan around your exam date instead of leaving you behind.
Success metric: share of students who create a plan and are still
ticking tasks in its last week. First target: 30% (assumption).

## 3. Scope
Must: US-1 to US-6. Should: notes Q&A (ch. 9). Could: email reminder.
Won't have this time:
- Friends, sharing, leaderboards: needs consent design; no evidence yet.
- Streaks and badges: risk of shaming students who fall behind.
- Native apps, payments, users under 18 (legal review needed).

## 5. Functional requirements
US-4: As a student who missed study time, I want to rebalance the rest
of my plan, so that I can still cover everything before the exam.
- AC-4.1: A plan never schedules tasks after the exam date.
- AC-4.2: If remaining tasks need more hours than are left, show the
  shortfall and let the student raise hours or choose tasks to drop.
  No task is dropped without the student's choice.
- AC-4.3: The student sees what moved and confirms before anything changes.
FR-9: If plan generation has not finished within 20 seconds, then the
Learning Coach shall keep the student's input and offer a template plan.

## 6. Nonfunctional requirements
NFR-1: Ticking a task updates the screen within 0.1 s.
NFR-2: Rebalancing completes within 3 s at the 95th percentile.
NFR-3: The plan page shows the current week within 2 s at the 95th
       percentile on a mid-range phone over a mobile connection.
NFR-4: WCAG 2.2 Level AA.
NFR-5: The AI provider receives exam details only, never email or name.
NFR-6: Deleting an account removes all of the student's data within 7 days.
NFR-7: Sign-up requires confirming the user is 18 or older.

## 9. Open questions
Q1: Can a plan in Ended be reopened for a resit?
Q2: What does the Behind state show if the student never rebalances?
Q3: Do students have their topic list as a file? (affects ch. 9 upload)

Next to the PRD, keep a prioritized backlog: the ordered list of work, with each item pointing at the requirement IDs it delivers.

Rebalancing comes before accounts on purpose: it tests the assumption the product rests on while changing direction is still cheap.

Verification: checking the requirements#

Requirements can be checked before any code exists. Run each one through these questions:

Then run the fresh-agent test: give the PRD alone to a new AI session, and ask it to explain the product back and list its questions. The PRD is ready when the explanation matches what you meant and the questions are about how, not what. “What happens when there isn't enough time before the exam?” means a gap. “Should rebalancing run on the server or in the browser?” is a fair question for chapter 5.

Failure clinic: the plan that ran past the exam#

Back to Jun's plan. You can reproduce this one on paper.

Symptom. After rebalancing twice, Jun's plan schedules tasks a week after his exam.

Reproduce. Exam in three weeks, six-week plan, one week missed. Press “Push back one week”. The last week of tasks now falls after the exam date. Press it again and two weeks do.

Look at the requirement. Maya's notes became this story: “As a student who missed a week, I want to push my plan back a week, so I can catch up.” The agent implemented exactly that: it added seven days to every task. The code is correct. The requirement is wrong.

Diagnose. Two requirements problems. The story copied the tester's solution (“push back a week”) instead of the need (cover the material before a fixed exam). And the domain's most important rule, that nothing happens after the exam, was never written down. Every student found it obvious, so nobody said it, and obvious rules are exactly the ones an agent misses.

Fix. Rewrite the story around the need (US-4), state the rule (AC-4.1), add the hard case of too little time (AC-4.2), and add concrete examples. Only then ask an agent to rebuild the feature, pointing it at those IDs.

Lesson. When generated code does the wrong thing correctly, the bug is upstream, in the requirement. Ask “what's the need behind this request?”, and write down the rules that seem too obvious to say.

Architect's checklist#

Before you hand the PRD to an AI agent:

• ☐ The problem statement names who, what progress, what gets in the way, and how we will know it worked.
• ☐ Personas and needs come from real evidence, not invention.
• ☐ The riskiest assumptions have a cheap test and a decision rule.
• ☐ Every Must story has acceptance criteria with concrete examples, and at least one failure case.
• ☐ Every nonfunctional requirement names a measure, a target, and conditions.
• ☐ The data inventory says why each piece of personal data is needed, who receives it, and how long it is kept.
• ☐ The Won't-have list, release criteria, and a success metric are written down.
• ☐ A fresh AI session's questions have been answered in the PRD itself.
• ☐ Anything involving legal, privacy, or safety questions is marked for expert review.

Exercises#

Beginner: from requests to requirements. The Meal Planner turns what's in your fridge and how you like to eat into a week of meals and a shopping list. Five testers said:

1. “Can it look inside my fridge with my phone camera?”
2. “I want it to count calories.”
3. “Remind me to take the chicken out of the freezer.”
4. “My partner should see the shopping list too.”
5. “It needs to be fast.”

Make a table with the three columns from section 3.1 (tester said, underlying need, candidate requirement). For each request, write the follow-up question you would ask (“What were you trying to do when...?”) and one possible answer. Some rows may end in “no requirement yet, test assumption first”. Then turn request 5 into a nonfunctional requirement that names what is measured, the target, and the conditions. You're done when no cell in the need column names a feature, and someone else could check your speed requirement with a stopwatch.

Intermediate: split and specify one big story. For the Shop Help Chat (an online shop's assistant that answers questions about orders, starts returns, and hands off to a person), you're handed this story: “As a customer, I want the chat to help me with my order.”

1. Split it into three to five vertical slices that each work end to end, with IDs, and check each against INVEST.
2. For the slice that answers “where is my order?”, write two Given/When/Then examples with concrete data: a real-looking order number, a real question, and the exact text the customer sees.
3. Run the edge-and-failure checklist from section 3.2 over the returns slice and write three EARS requirements: an order number that belongs to a different customer, a return asked for after the return window has closed, and a question the order data can't answer.
4. Sort the slices with MoSCoW and give each Won't a one-line reason.

You're done when every Then describes something visible on screen, and a friend reading only your examples can say “pass” or “fail” for each without asking you a question.

Advanced: the two-agent ambiguity test. The Trip Planner turns travel dates, a budget, and interests into a day-by-day itinerary. Write a full specification for one of its features, the reminder email the evening before each travel day, using every tool from this chapter:

• a story;
• a use case with alternatives (the trip was cancelled, the traveler unsubscribed, the email bounces);
• acceptance criteria with dates and times, including what happens when the traveler's home and destination are in different time zones;
• EARS failure cases;
• a nonfunctional requirement for delivery time;
• the new row in the data inventory;
• an out-of-scope list;
• traceability links to a need.

Rules about sending email differ by country, so find out which apply to you; this book can't give legal advice. Then give the specification, and nothing else, to two fresh agent sessions separately, and ask each for a test plan: every situation it would test and the expected result. Compare the two plans line by line. Every place they disagree, or one covers a case the other skips, marks a gap in your specification. Fix those gaps and repeat. You're done when two new sessions produce test plans that agree on every expected result. Record how many gaps each round found, and which sections of the specification they were in.

Lab, artifact, and review#

Lab. Write the PRD for the Learning Coach MVP, including at least three failure cases with expected behavior.

Deliverable. Add to your portfolio the PRD as Markdown in your repository, the backlog linked to requirement IDs, the assumptions table with the result of at least one test, and the fresh session's questions with where in the PRD you answered each.

Reflection#

• Which requirement in your PRD would cause the most damage if an agent misread it? How did you make it hard to misread?
• Which decisions did you leave for the agent to make? Were any of them really product decisions?
• Where did you write a number you are not sure about? How will you find out the real one?

Next, in chapter 4, you will build the software literacy to read what an agent produces from this PRD: how a web application is put together, how Git records changes, and how to find your way around a codebase you didn't write.

References#

• Agile Business Consortium. MoSCoW Prioritisation. DSDM Project Framework.
• Christensen Institute. Jobs to Be Done Theory. Clayton Christensen Institute for Disruptive Innovation.
• Cucumber. Gherkin Reference. Cucumber documentation.
• European Union. (2016). General Data Protection Regulation, Article 5: Principles relating to processing of personal data. Regulation (EU) 2016/679.
• Federal Trade Commission. Complying with COPPA: Frequently Asked Questions. FTC Business Guidance.
• Google. Service Level Objectives. In B. Beyer, C. Jones, J. Petoff, & N. R. Murphy (Eds.), Site Reliability Engineering. O'Reilly, 2016.
• Mavin, A. EARS: Easy Approach to Requirements Syntax. First published 2009.
• Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group. Excerpt from Usability Engineering.
• Ries, E. (2011). The Lean Startup. Crown Business.
• W3C. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, October 5, 2023.
• Wake, B. (2003). INVEST in Good Stories, and SMART Tasks. XP123.

Links checked October 2026.