EDUKATESINGAPORE · SUBJECT READING ROOM
Start with the problem a system must solve. This reading room connects scientific understanding, mathematical models, computing, data and design. It helps you move from a need to a testable requirement, examine a proposed solution and decide what evidence would count as success.
Before you begin: Be ready to name a user, a task and a constraint. A familiar everyday problem is enough for the first exercise.
Choose the part of the system
- Engineering — requirements, models, trade-offs and reliable performance.
- Computer Science — computation, algorithms and information processing.
- Design — users, prototypes and evaluation.
- Data Science and Data Management — analysis, data quality, identity and usable records.
- Mathematics Learning Library and Science World — return to the mathematical or physical idea when a prerequisite needs attention.
Study the complete case
Library Catalogue Requirements and Acceptance Tests: A Worked Guide
Turn reader needs into catalogue requirements using six fictional records, exact acceptance cases, traceability and changed-condition exercises.
Turn a wish into a requirement
“Make it better” leaves the task undefined. A useful requirement identifies an observable result, the conditions under which it matters and an acceptance method. Separate a requirement from a favourite implementation: a reader needs to find a book, but a particular search box is only one possible way to help.
| Stage | Illustrative library example |
|---|---|
| Need | A reader wants to locate a title in a small catalogue. |
| Requirement | For a stated set of titles and spelling variants, the catalogue should return the intended record. |
| Design option | Normalise spacing and keep an explicit table of approved title variants. |
| Verification | Run the stated cases and examine incorrect or missing results. |
| User evaluation | Observe whether readers can complete the task in realistic conditions. |
Passing the predefined cases supports a bounded result. It does not establish that every future query will work or that readers understand the interface. Technical correctness and practical usefulness require related but different checks.
Models, boundaries and failure
Every model leaves something out. Write down its assumptions and expected operating conditions. A classroom model can help explain a mechanism while remaining unsuitable for a real structure or a consequential decision.
When a result fails, ask where the mismatch begins: the need, the measurement, the model, the data, the implementation or the conditions of use. Change one relevant factor where possible and retain what the failed attempt taught you. Use Learning Manuals to follow materials and mechanisms through concrete examples.
Try a design inquiry
- Choose a small information task, such as finding a book or organising a reading list. Name the user and the difficulty.
- Write two requirements and compare two possible designs against them.
- List ordinary cases, an edge case and a failure case. Explain how each would be checked.
Transfer check: change a condition, such as the number of records or the reader’s access needs. Revisit the requirements before claiming the original design still fits. A successful demonstration is a starting point for evidence, not a guarantee of performance at a new scale.
Continue into delivery
Read Project Management for planning and controlled delivery, Teamwork for coordination, and Research Methods and Source Evaluation for choosing evidence that can answer a design question. Keep the scientific mechanism, the software implementation and the project decision distinguishable as you move between them.
Continue through the library
Return to World Knowledge Research Library to choose another subject, or use the eduKateSingapore Hub for school learning, science, vocabulary and study support.
Collection note: This reading room brings together currently published introductions and selected reading routes. The linked articles provide the detailed explanations; the collection is developing and is not an exhaustive survey of the subject.