--- title: "Requirements: turning a wish into a testable statement" description: "Requests such as fast, fair or easy need agreed checks. A testable requirement states the expected behaviour or quality and the conditions for checking it. Requirements also record the system's scope " 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-11-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 Requests such as fast, fair or easy need agreed checks. A testable requirement states the expected behaviour or quality and the conditions for checking it. Requirements also record the system's scope and exclusions. 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 - Identify an observable pass criterion and the missing details in a vague requirement - Separate functional requirements from qualities such as speed or availability - Choose how to review a requirement with no linked need against the agreed release scope ## Lesson: Turning foggy wishes into checkable promises A testable requirement gives the team an agreed way to check an expected result. For 'make checkout easy', ask which users and task matter, then agree the pass criterion and test conditions. For 'handle many active users quickly', agree the active-user count and response-time limit. A requirement can refer to a recorded test plan for details. **Example.** For a search page, plan S fixes the browser, network profile, dataset and 20 test queries. The requirement says: for every query in plan S, all results must be displayed within three seconds of selecting Search. Measure from that selection until all results appear. Each trial passes at three seconds or less and fails above three seconds. *(drawing: Run each agreed query under plan S. The timer starts when Search is selected and stops when all results appear.)* Functional requirements state what the system does, such as returning catalog titles that match search text. Quality requirements state a quality of that service, such as its response time or availability. Record both: correct results do not establish acceptable speed, and speed does not establish correct results. Some checks need no numbers. For a query known to match no records, a tester can compare the displayed message with the agreed wording. The requirement or its referenced test plan must provide enough information to decide whether the observed result meets the criterion. A check can include human review with agreed criteria. Suppose a shop requires each product photo to have a text alternative naming the pictured product. Review the words against the photo. A filled field alone does not meet that requirement. This one check does not establish that the whole site is accessible. Review requirements for conflicts under the same conditions. If two rules set different maximum loan counts for the same guest group at the same time, the team must resolve the limit. Rules for different groups or circumstances may differ without conflicting. *(drawing: Compare the conditions before calling two rules a conflict.)* State scope and its reason: 'This release supports borrowing, not online sales, to avoid payment work.' Link requirements to needs, such as user tasks or applicable obligations. Review missing links with stakeholders. For a valid requirement within scope, recording its existing need or repairing its link may be enough. Remove an unsupported proposal. If a justified requirement falls outside scope, agree whether to defer it or change the release scope. **Recap.** Agree the expected result, check and conditions. Record functions, qualities and scope. Resolve conflicts and review requirements with no linked need. *Lesson, questions and flashcards written for this dataset. Software-engineering textbook records were consulted for concepts; their prose and figures are not reproduced.* ## 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)