Judge the Claim
Distinguish an evidenced user need from an assumption or proposed solution.
From an idea to a justified decisionCHC5056 / 2026–2027
CHC5056 · S1 WEEK 02
From Idea
to Requirement.
How do we know what
a product needs to do?
Javier Jia · 2026–2027
THE PROPOSAL“We need a booking app.”
↓
THE QUESTIONWhat problem would it solve?
OUR CASECampus room booking
Fictional teaching simulation
Fictional teaching simulation
A proposed app is a solution idea. Before choosing its features, investigate who is struggling, what happens and why it matters. All room-booking people, records and rules in this deck are fictional teaching material.
Three decisionsCHC5056 / 2026–2027
What Will We Learn?
Choose How to Investigate
Select an elicitation method appropriate to a stakeholder and explain its limitations.
Recognise a Testable Requirement
Distinguish functional and non-functional requirements, and explain how user stories and acceptance criteria express user value and testable expectations.
Today: judge, select and explain. In the Seminar: investigate and write.
You are aiming to recognise and explain sound requirements reasoning. Independent problem statements, elicitation plans, user stories and acceptance criteria are developed in the two Seminar sessions.
01 / Frame the problemCHC5056 / 2026–2027
Problem or Solution?
A / PROPOSAL
“Build a Booking App.”
It names a product form. It does not tell us who struggles or what goes wrong.
B / PROBLEM CANDIDATE
“I Cannot Tell If the Room Is Booked.”
A student arranging group work reports uncertainty after requesting a room.
Which statement describes a difficulty that still needs investigation?
A problem statement can be specific without claiming it is already proven.
A problem candidate identifies a user and a difficulty without locking the team into a technology. A report from one user is a useful clue, not proof that every student has the same need.
01 / Separate the claim from the evidenceCHC5056 / 2026–2027
What Is Still an Assumption?
Problem candidate: Students arranging group work cannot tell whether a requested room is confirmed, so they contact staff before sharing a meeting location.
USER + CONTEXT
Group Organisers
Arranging a room for a group meeting.
DIFFICULTY
Unclear Status
Cannot distinguish a request from a confirmed booking.
CONSEQUENCE
Extra Checking
Contact staff before telling the group where to meet.
Select the claim above. What evidence would you need before accepting it?
A problem statement combines a user, context, difficulty and consequence. Each part can still require evidence. Do not turn a desired benefit into a guaranteed outcome.
02 / Identify stakeholdersCHC5056 / 2026–2027
Whose Needs Matter?
STUDENT / GROUP ORGANISER
Can We Rely on This Room?
Needs to know whether the room is secured before inviting the group.
FACILITIES / ROOM MANAGER
Can We Trust the Schedule?
Needs booking decisions to reflect availability and avoid conflicting confirmations.
Also consider: teaching staff reserving rooms and people with access requirements. The first two voices do not represent everyone.
DiscussIf students want instant confirmation, what must the room manager clarify first?
Stakeholders include people who use the service and people who operate or are affected by it. A request for speed must be considered alongside availability and booking rules. This case does not claim all stakeholder needs have been discovered.
02 / Read the source carefullyCHC5056 / 2026–2027
What Does This Evidence Tell Us?
E1 / INTERVIEW
“After I send a request, I email reception to ask whether we have the room.”
One fictional student’s account; not a measure of prevalence.E2 / OBSERVATION
In one simulated booking attempt, the student received “request sent” and then contacted reception.
Observed sequence; it does not establish the person’s reason.E3 / INTERVIEW
A fictional manager reports resolving requests for the same room and time.
A reported workflow issue; check records and rules.All E1–E3 materials are simulated. In a real project, keep the source, context and limits of each finding. Observation can show an action; an interview can explore its meaning. Neither automatically establishes how common it is.
03 / Requirements elicitationCHC5056 / 2026–2027
Choose the Question First
Elicitation means investigating needs, constraints and expectations.
LEADING QUESTION
“Would a Booking App Help You?”
Introduces our solution and invites agreement.
NEUTRAL QUESTION
“Tell Me About Your Last Room Request.”
Follow up: “What happened next?” and “How did you know it was confirmed?”
Question→Stakeholder→Method→Limitations
Choose a PurposeAre we investigating a person’s reasoning, their actual steps, or how widely an issue is reported?
Choose a method after deciding what you need to learn. Neutral questions invite accounts of real situations without pushing participants towards your preferred feature. Do not collect sensitive or personal information for this classroom exercise.
03 / Match evidence to the questionCHC5056 / 2026–2027
Choose a Method
| Method | Useful for | Watch for |
|---|---|---|
| Interview | Exploring reasons, context and experiences. | Recall errors, leading prompts, limited reach. |
| Observation | Seeing actual steps and workarounds. | Behaviour may change; motives remain unclear. |
| Survey | Comparing reported experiences across respondents. | Sampling, wording and self-report bias. |
Scenario A: Why does a student email reception after requesting a room?
There is no context-free ranking of research methods. Judge the choice by the question, access to stakeholders and the limitations you can manage. A survey describes its respondents; wider claims depend on sampling.
03 / Explain the trade-offCHC5056 / 2026–2027
What Could This Method Miss?
Scenario B: You have a list of recent room requesters. How widespread is uncertainty about confirmation among them?
DOCUMENT ANALYSIS
Check the Rules
Read booking policies and existing records.
COMPETITOR ANALYSIS
Explore Alternatives
Inspect other services; do not treat their features as proof of our users’ needs.
FOCUS GROUP
Hear Different Views
Explore reactions together; dominant voices may shape the discussion.
Combine methods where useful. Documents can clarify constraints; competitor analysis suggests possibilities; focus groups expose differing perspectives but can be shaped by group dynamics. None substitutes for evidence about your intended users.
04 / Make the reasoning visibleCHC5056 / 2026–2027
From Findings to Requirements
E1 + E2
Finding: uncertainty is followed by extra checking in this simulated case.
N1 / USER NEED
Know whether the room is secured before telling the group where to meet.
R1 / CANDIDATE
Show whether a room request is confirmed or unsuccessful, with the room and time.
H1 / Still a hypothesis: clearer status will reduce follow-up checking. Investigate this effect.
Business goal: reduce avoidable enquiries. User need: know the booking outcome.
Related candidate: R0, show available time slots. Neither feature is proven by its wording.
R1 is a design response to N1, not a direct quotation from a user. The evidence supports investigating uncertainty; it does not prove that the proposed response will produce the intended benefit. R0 and R1 remain candidates.
04 / Classify and clarifyCHC5056 / 2026–2027
Behaviour or Quality?
R1 / EXPECTED BEHAVIOUR
Show the Booking Outcome
Display whether the request is confirmed or unsuccessful, with room and time.
Q1 / TEACHING TARGET
Show It Within Two Seconds
In a defined test environment, at least 95% of 1,000 requests render the outcome within two seconds at 50 concurrent users.
“The system must be fast” lacks a threshold and test conditions.
Q1 figures are invented for teaching. Full test setup must be agreed before execution.
Functional requirements describe required behaviour; non-functional requirements constrain qualities such as performance. Testability needs measurable criteria and a reproducible context. Numeric precision alone does not make a target justified.
05 / From requirement to conversationCHC5056 / 2026–2027
A Story Expresses User Value
US1 · BASED ON N1 / R1 · REVEAL EACH PART
As a student organising a group meeting,
I want to see the outcome of my room request,
So that I can tell my group whether we have a room.
“Build the database” is an implementation task. It does not explain the user’s goal or value.
A story connects a role, a goal and an intended value. The template is a useful prompt rather than a complete specification. US1 expresses a candidate response to N1; stakeholders still need to discuss its details and value.
05 / More than a sentenceCHC5056 / 2026–2027
Card, Conversation, Confirmation
01 / CARD
Capture the Intention
US1 keeps the user, goal and value visible.
02 / CONVERSATION
Clarify the Details
What if another request takes the room before confirmation?
03 / CONFIRMATION
Agree What to Check
Use acceptance criteria and examples to check the expected behaviour.
Different scopes: acceptance criteria describe expectations for this story. The Definition of Done describes shared quality expectations for the Increment.
We will develop Definition of Done later. A story is not complete just because its template is filled in.
The 3C model keeps discussion and checking alongside the written card. Story-specific acceptance criteria should not be confused with the Definition of Done, which applies to the quality of the Increment. Sources: Agile Alliance, The Three C’s; Scrum Guide, Definition of Done.
06 / Acceptance criteria for US1CHC5056 / 2026–2027
How Will We Know It Works?
Simulation rule B1: one room and time slot can have at most one confirmed booking.
AC1 / SUCCESS
The Room Is Available
Given an eligible request and a slot still available at confirmation,
When the request is processed,
Then one booking is recorded and the student sees “confirmed”, room and time.
AC2 / CONFLICT
The Room Was Taken
Given the requested slot is already confirmed for another booking,
When this request is processed,
Then no extra booking is recorded and the student sees “unsuccessful: slot taken”, room and time.
B1 is a fictional rule, not a university policy. Given / When / Then is one useful format.
AC1 and AC2 describe observable outcomes for the same story under different conditions. A team must also clarify eligibility, processing and other cases before implementation. These examples introduce acceptance criteria, not a complete test specification.
06 / Recognise observable expectationsCHC5056 / 2026–2027
Which Criteria Can We Test?
A
“Booking Is Easy.”
“The system works well and users are happy.”
B
“A Conflict Is Reported.”
When a requested slot is already taken, no extra booking is recorded and the outcome identifies the conflict, room and time.
Which criterion lets two people check the same expected outcome?
An acceptance criterion should support a repeatable decision about expected behaviour. The software can meet a criterion while the wider user problem persists. User value therefore still needs evidence.
06 / Keep the evidence and gaps visibleCHC5056 / 2026–2027
Trace It Back
E1 + E2 →
Source
Reported uncertainty and an observed follow-up enquiry.
N1 →
Need
Know whether the room is secured.
R1 / US1 →
Response
Show the request outcome so the group can plan.
AC1 + AC2
Checks
Confirm available slots; report conflicts under rule B1.
↶ H1 unresolved: does clearer status reduce follow-up checking?
Return to investigation, then revise the need, response or criteria.
Return to investigation, then revise the need, response or criteria.
E3 motivates checking conflicts; B1 sets this case’s rule. Q1 is a separate proposed performance target.
Traceability exposes reasoning rather than certifying truth. More evidence may alter the need or reveal that a different response is necessary. Keep policies, assumptions, research findings and design decisions distinguishable.
07 / Transfer to a new situationCHC5056 / 2026–2027
Exit Check
New fictional case: students cannot tell whether a lab-help request has been received.
L1 / JUDGE THE CLAIM
“We need an AI chatbot.”
What is this?
L2 / CHOOSE A METHOD
To see what students do after submitting, start with…
L3 / CHECK THE CRITERION
Which outcome is more directly testable?
Use this new case to check whether you can apply the reasoning beyond room booking. For method choices, explain what the method reveals and one thing it can miss. These are formative practice questions, not formal assessment items.
07 / Apply it to your projectCHC5056 / 2026–2027
Bring This Thinking to the Seminar
FIRST 45-MINUTE SESSION
Investigate the Problem
Develop a problem statement and stakeholder map. Identify evidence gaps and design a neutral elicitation activity.
SECOND 45-MINUTE SESSION
Express and Check the Need
Use available findings to write user stories and testable acceptance criteria. Keep assumptions visible.
Bring: your Week 1 project-interest card, available source material and one unresolved question. Do not invent findings to fill a gap.
Next Lecture: connect stories through a user journey and organise a Product Backlog.
The Seminar activity design and formal assessment instructions are provided separately.
The Seminar provides the time for independent writing and feedback. If your project has no research evidence yet, label the gap and plan how to investigate it. Optional INVEST reminder: Independent, Negotiable, Valuable, Estimable, Small, Testable. This is a heuristic for later refinement, not today’s exit-check content.