You have the whole idea in your head. Your agent cannot build a feeling, and you cannot check whether a feeling is finished. Before any code, you turn that idea into a clear, specific list of what the software must do. This chapter gets you that list.
A requirement is testable, not a wish1.1.1
A requirement is one thing your software must do, written plainly enough that anyone can tell whether it works yet.
| Wish | Requirement |
|---|---|
| Users can log in | A person signs in with an email and password, and resets a forgotten one through an email link |
The difference is that you can test the requirement and point at a clear yes or no. Write every requirement so it passes that test.
Write each one as a user story1.1.2
Professional teams capture requirements as user stories, one line each: As a [type of user], I want to [do something], so that [reason]. It forces you to name who the feature is for and why it exists, which quietly kills the features nobody actually needs.
Example: As a shopper, I want to save items to a cart, so that I can pay for them all at once.
Split must-have from later1.1.3
List every story you can think of, then mark each one must-have or later. Be harsh: a must-have is something the product is useless without, not something that would be nice to have. The must-haves are all you build first; everything else waits its turn.
Get them from real users, not your head1.1.4
Requirements come from the people who will actually use the thing, not your imagination. Talk to three to five real potential users and write down what they ask for in their own words.
If you cannot find a single person who wants it, that is the cheapest moment you will ever get to learn that, long before you have built anything. Ideally you check this before you build; if you are set on building anyway, at least know you skipped it.
Do this now: write your idea as a list of user stories, each one marked must-have or later. That list is the raw material for every chapter that follows.
