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.
What a learner can do afterwards
- 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
1 · Read
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.
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.
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.
Name the observer, the action, and the pass mark, so every requirement carries a check a stranger can run.
2 · Watch
Take it off screen
Where it sits
Learn first
Nothing; this is a starting point.
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.