đź“š ICS4U

Requirements Discovery

Why this matters

Before we write code, we want to understand the real problem and how people work today. We collect facts from real events, turn them into job stories and user stories, and write acceptance criteria so we know when we are “done.”

NOTE

Steps 2 to 4 fit on one sheet: the planner.

Step 1 – Stakeholder Interview

  • Ask for consent to take notes/record. Explain where notes will be stored.
  • Focus on real past events: “Tell us about the last time you did this task.”
  • Listen for pains, constraints (rules/policies), and what “success” looks like.
  • Roles during the interview: Interviewer, Note-taker, Timekeeper.
    Tip: Silence is okay–give time for thinking.

Asking about a real event

Three students check the recycling bins in every classroom each Friday. You are interviewing them.

Weak question: “Would you like an app for checking the bins?” They will say yes, and you learn nothing.

Strong question: “Tell me about last Friday. What happened, from the first room to the last?”

The strong question gets you facts: “We always forget Room 12, and then it smells.” “It takes the whole recess.”

NOTE

Here is a printable guide to conducting an interview, and an example of the type of rough notes that might be taken.

Step 2 – Note-taking matrix

  • Capture short points and key quotes (use quotation marks).
  • Record Need/Pain, How often?, Impact, Constraints (rules/limits), and Opportunities/Ideas.
  • You can do this during the interview or after, using a transcript.

One row of the matrix

ColumnWhat goes in it
Quote”We always forget Room 12, and then it smells.”
Need or painRooms get missed during the check.
How often?Every Friday.
ImpactThe missed room smells for a week. The team has to go back.
Rule or limitThe whole check must fit inside one recess.
Opportunity or ideaSome way to see which rooms are still left.

Each column says something different about the same quote. The idea comes last, and it stays loose.

NOTE

Here is a blank note-taking matrix and an example of a completed matrix.

Step 3 – Job stories

  • Job Story template: When (situation), I want to (motivation), so I can (outcome).
  • Choose a clear situation from your notes, then write the motivation and outcome.
  • Convert each Job Story into a User Story: As a (role), I want (goal), so that (value).
  • Key decisions during conversion: Who is the user/role? How will they complete the job?

NOTE

Here is a blank template for writing job stories and converting to a user story; here is an example of this process.

Job story or user story?

Three students check the recycling bins in every classroom each Friday. They told an interviewer: “We always forget Room 12.”

Job story: When I am checking bins on Friday, I want to know which rooms are still left, so I can finish without missing one.

User story: As a Green Team member, I want a list of rooms that I tick off as I go, so that no room is forgotten.

Job storyUser story
DescribesThe problem, in the moment it happensOne way to solve it
Starts fromA situation (“When…“)A person (“As a…“)
Names a user?No. Anyone in that situation has the job.Yes. You decide who.
Mentions a feature?No. Nothing is designed yet.Yes. The list of rooms first appears here.

A quick test: if your job story would still be true with no app at all, it is a job story. One job story can lead to several different user stories.

Step 4 – Acceptance criteria

  • Use Given–When–Then to describe behaviour we can verify.
    • Given (starting state) • When (action) • Then (result).
  • Start with typical behaviour (the “happy path”), then add edge cases.
  • Aim for small, testable stories (short, specific, and valuable).

From a user story to an acceptance criterion

User story: As a Green Team member, I want a list of rooms that I tick off as I go, so that no room is forgotten.

Too vague: “The list is easy to use.” Two people could disagree about whether it passed.

Happy path: Given the Friday check has started and Room 12 is not ticked, when I tick Room 12, then Room 12 shows as done and the number of rooms left goes down by one.

Anyone could watch this happen and say “pass” or “fail”. It says what the user sees, not how the code works.

NOTE

Here a template for authoring acceptance criteria and an example of that process.

Deliverables

  • Interview notes (matrix) with at least 3 meaningful quotes.
  • 2–3 Job Stories and their User Stories.
  • Acceptance criteria for each User Story (at least the happy path).

When did we do this?