Module 30: Programming Project
From idea to requirements
🏠The everyday picture
Before building a house, the family and the architect agree on a list: three bedrooms, one with a balcony, a kitchen facing east. Building without that list means expensive surprises.
📘What it really is
- Requirements say what the program must do, in plain words, before any code:
- features: "add a product", "record an expense", "see this month's spending by category";
- rules: "stock can't go below zero", "every expense has a date and category";
-
limits: what it will not do, at least for now (no logins, one shop only).
-
Write each requirement so you could test it: "show low-stock products" becomes "show products with stock below their reorder level, lowest first".
-
User stories are a common format: "As a shop owner, I want to see which products need reordering, so I don't run out."
-
Number your requirements; refer to them in commits, tests and your README.
- This is the Builder Path's one-page plan (Builder Path, Lesson 1), made more precise because you'll build it yourself.
🖱️Try it
Write REQUIREMENTS.md for the Inventory and Expense Manager with at least ten numbered requirements, three
rules and three limits. Use the final project list at the end of this module as a starting point, and make each
requirement testable.
✅Quick check
"The app should be fast" isn't testable. How would you rewrite it?
Show the answer
Something measurable, like "the product list shows in under one second with 1,000 products".
Why list what the app won't do?
Show the answer
It keeps the project finishable and stops features being added without a decision.