Use one consistent technology context: web applications. The ten fictional cases move across music, public exhibitions, repair, gardens, art and community services so learners can transfer the same analysis, but the proposed digital context stays web. Schools may select another QCAA-permitted context and adapt the examples; do not claim this starter covers all contexts or programming features.
Routine for a 25-minute block
Give the two- or three-sentence source on the learner card. Ask: Who is trying to do what? What blocks them now? What information would we need before building? Insist on a source detail for each claimed problem. Model a diagram or table, then offer the three routes. Collect one short product: a need statement, decomposition, scope decision or criterion. Ask “How would we know?” to make a criterion observable. Finish by naming one untested assumption.
Equivalent routes: a written table, a spoken explanation with exact points captured by a scribe, and a labelled diagram or movable paper strips with a dictated rationale all demonstrate the same target. Let learners switch routes each day. A visual route must retain captions; a spoken route needs recorded reasoning. Do not sort students into fixed learning-style groups. Quiet reading, teacher read-aloud, a screen-reader text copy and extra time are legitimate access adjustments.
Keep the analysis disciplined
- A feature (“add live stock”) is a proposal, not the user's need (“know whether a copy is at the desk”). Ask whether the required data exists and can be updated.
- A user perspective is a hypothesis unless a real user has confirmed it. The fictional cards are design exercises, not research evidence.
- Separate must work, could help, and out of scope. Make trade-offs visible. A small paper-based process may be more appropriate than a web app for some cases.
- A success criterion should specify an observable test and a condition: “In a paper trial, a reader finds the updated room in under 20 seconds using the page” is more testable than “easy to use”. Do not present classroom trial values as real outcomes.
- For impacts, name a mechanism and a group: a web-only page may reduce printing yet exclude visitors without connectivity. Do not declare a net benefit without evidence.
- Emerging technology is not a compulsory solution. Compare a simple labelled filter with a machine-learning suggestion when the data, risk and workload justify discussion. Do not claim a model was trained or accurate.
- Avoid collecting names, contact details, diagnoses, location histories or actual learner information. The offline lab stores nothing and uses only prewritten fictional facts.
What to prepare
Print need-map, scope-boundary, criterion-test, impact-lens or decision-grid when helpful; each has full text and tactile build directions. Put a few scrap-paper strips on each table. The problem-framing lab is optional on Day 9; its paper route is on the page and in the learner card. No specialist software is required for this starter.
Check and feedback
The Day 5 and Day 10 checks use new cases. The key is public, so collect first responses before feedback; adapt a case if prior key access matters. Respond to the reason, not just the chosen label. This is informal classroom feedback and is not an A–E or QCAA result.