--- title: "Requirements: Turning a Wish into a Testable Statement" description: "Someone asks for a system that is fast, or fair, or easy. A requirement rewrites that as something with a check attached, separating what the system must do from how well it must do it, and naming wha" canonical: https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1 source: https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1.md retrieved: 2026-09-12 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # Requirements: Turning a Wish into a Testable Statement Someone asks for a system that is fast, or fair, or easy. A requirement rewrites that as something with a check attached, separating what the system must do from how well it must do it, and naming what is out of scope. Subject: Computing · Area: Software Engineering · Ages 19 to 20 Page: https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1 ## Ready when they can - Rewrite a vague request as a statement with an observable pass or fail - Separate functional requirements from qualities such as speed or availability - Write down one thing the system will not do, and why that helps ## Lesson: Turning foggy wishes into checkable promises Every system starts as a foggy ask: make it fast, fair, or easy. Analysis turns fog into lines by naming who needs what and how they will know they got it, with a check attached to each answer. **Example.** Take the wish for a fast search page. Name the page, the load time, and the connection, such as results showing within two seconds on a home connection. Now a stranger can test it without phoning you. Keep two lists apart. Functional requirements state what the system does, like search, borrow, and renew. Quality requirements state how well, like speed, availability, and privacy. Mixing the lists muddles both testing and design. **Tip.** Write down one thing the system will not do, since that boundary guards the schedule. Reviews then catch the classic faults early: two lines demanding opposite things, or a must with no measurable mark. Trace each line back to a named need, and cut orphans nobody asked for. **Recap.** Name the observer, the action, and the pass mark, so every requirement carries a check a stranger can run. ## Practice 8 questions on this page, each with its working shown. ## Opens up - [Interfaces, Coupling and What a Module Promises](https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk) - [Code Review: Reading a Change You Did Not Write](https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s) - [Working in a Team: Issues, Estimates and Iterations](https://lightmysky.com/learn/computing/working-in-a-team-issues-estimates-and-iterations-mt_HNNnVvADcF)