Search
Subjects and activities

Class 9 · Computing and AI literacy

Write requirements for a school library app

Your school wants a library app. If you just say "make it easy and fast", how will anyone know when it is finished?

What you will learn: Write clear, testable requirements and separate must-have from nice-to-have.

Small test at the end: scroll down to the end of this page for five short questions that check what you have learnt. Tap an answer, then press Check answer. Go to the questions ↓

Jump to: Check yourself · For grown-ups · For teachers

Safety first

Made-up names and books only.

Keep it safe:

  • Use made-up books and made-up users only. Do not collect real students' names or borrowing records.

You will need

  • Paper and pencil
  • Ideas from classmatesWhat do they want from a library app?

Time: About 45 minutes.

The story

The school wants a library app, and Dhruv's cousin will build it. "Make it easy and fast!" says Tanmay. The cousin smiles. "Easy for whom? Fast at what?" How do you write down what an app must do so clearly that anyone can test whether it does it?

The idea

A requirement says what the system must do, clearly enough that someone can test it.

Vague words such as "easy", "fast" or "nice" cannot be tested. "Results appear in under 2 seconds" can.

Label each requirement. Must: the app is not acceptable without it. Should: wanted, but the app can launch without it if time runs out.

Write a test for each requirement: what you do, and what you should see if it works.

A table of made-up library app requirements. Search by title or author: must; test by searching Malgudi and seeing the book appear. Show if a book is on loan: must; test by lending it and searching, which should show On loan. Results in under 2 seconds: must; test by timing 5 searches. Dark mode: should; test by switching it on.Library app requirements (made up)RequirementLabelTestSearch by title or authorMustSearch "Malgudi": book appearsShow if a book is on loanMustLend it, search: "On loan"Results in under 2 secondsMustTime 5 searchesDark modeShouldSwitch on: screen goes dark
A table of made-up library app requirements. Search by title or author: must; test by searching Malgudi and seeing the book appear. Show if a book is on loan: must; test by lending it and searching, which should show On loan. Results in under 2 seconds: must; test by timing 5 searches. Dark mode: should; test by switching it on.

Worked example

Making "easy search" testable

  1. First draft: "Search should be easy."
  2. Question: easy how? What would a student actually do?
  3. Rewrite: "Searching by title or author shows matching books." Label: must.
  4. Test: search "Malgudi Days". Expected: the book appears in the results.

A vague wish became a requirement that anyone can test, with a clear pass or fail.

Try it

  1. Collect wishes.

    Ask three classmates what they want from a library app.

  2. Rewrite them as requirements.

    Replace vague words with something you can test.

  3. Label them.

    Must or should. Keep the must list short.

  4. Write a test for each.

    What you do, and what you should see.

  5. Swap and check.

    Can a friend test each one without asking you what you meant?

What you make (paper or offline)

Your requirements list

A requirements table with labels and a test for each requirement.Library app requirements (made up)RequirementLabelTestSearch by title or authorMustSearch "Malgudi": book appearsShow if a book is on loanMustLend it, search: "On loan"Results in under 2 secondsMustTime 5 searchesDark modeShouldSwitch on: screen goes dark
A requirements table with labels and a test for each requirement.

At least five requirements, each testable.

A must or should label for each.

A test for each one.

Make it on paper. Keep it with you. Nothing to upload.

Check yourself

Five questions about what this page teaches. Choose an answer and press Check answer, or open "See the answer and why". Nothing is saved or sent: your choices stay on this screen and disappear when you leave or reload the page.

  1. Question 1 of 5Which requirement can be tested?

    See the answer and why
    • A. "Search results appear in under 2 seconds" Correct. You can time it and see whether it passes.
    • B. "The app looks nice" Not this one. People disagree about "nice". It cannot be tested.
    • C. "The app is fast" Not this one. "Fast" is vague. How fast?
    • D. "Search is easy" Not this one. "Easy" needs to be turned into something you can check.
  2. Question 2 of 5What is the difference between a "must" and a "should" requirement?

    See the answer and why
    • A. Must: needed to be acceptable. Should: wanted if time allows Correct. The app cannot launch without its musts.
    • B. They mean the same thing Not this one. They mark different levels of need.
    • C. Should is more important, because it comes later in the list Not this one. It is the other way round: musts matter most.
    • D. Must is for teachers and should is for students Not this one. The labels are about need, not about who asked.
  3. Question 3 of 5Which test checks the requirement "Shows whether a book is on loan"?

    See the answer and why
    • A. Ask users whether they like the colours Not this one. That is about looks, not loans.
    • B. Search for any book and check that some results appear on screen Not this one. That tests search, not loan status.
    • C. Lend a book, search for it, and check it says "On loan" Correct. It does exactly what the requirement says and checks the result.
    • D. Check that the app has a logo Not this one. A logo has nothing to do with loans.
  4. Question 4 of 5A student wants dark mode. The app works well without it. Which label fits?

    See the answer and why
    • A. Should Correct. It is wanted, but the app is acceptable without it.
    • B. Must, because a student asked for it Not this one. Who asked does not decide the label. Need does.
    • C. Delete it: it is not a requirement Not this one. It is a real wish. Label it should, do not lose it.
    • D. Must Not this one. The app can launch without dark mode.
  5. Question 5 of 5Why write a test for every requirement?

    See the answer and why
    • A. So the app never needs any other checking Not this one. Other checks, such as trying it with real users, are still useful.
    • B. Because tests replace the requirements Not this one. Tests check requirements. They do not replace them.
    • C. To make the list look longer Not this one. Length is not the point.
    • D. So anyone can check whether the app meets it Correct. A test turns "done?" into a clear pass or fail.

Think back

Which wish was hardest to turn into a testable requirement?

Which must could become a should if time ran out?

Investigate further

  • Write requirements for a school canteen menu board.
  • Find a vague promise in an advert and rewrite it as a testable requirement.

For grown-upsTap a heading to open it. The safety notes are at the top of the page.

Before you start
  • Paper. Think of an app or machine at home the student could write requirements for.
Questions that help
  • "How would we test that?"
  • "Could the app work without it?"
What's really going on

Clear, testable requirements are how engineers and software teams agree what "finished" means.

Prioritising (must/should) is how real projects cope with limited time.

Other ways to do it
  • Write requirements for a school bag or a water bottle instead.

For teachersLearning aims, classroom ideas and what to look for.

Learning aims
  • Write testable requirements and prioritise them.
  • Design an acceptance test for each requirement.
Subject links
  • Computing: requirements and testing.
  • Language: precise writing.
  • Design: user needs.

These links are general. They have not been checked against a specific board syllabus.

In the classroom
  • Pairs swap lists and try to "break" each requirement by finding a vague word.
What to look for
  • Vague words replaced with measurable ones.
  • A test that matches each requirement.
ProLearners Assist