Commit e15de9
2026-04-30 07:50:48 lisa: C02: add 4 new pages closing remaining wiki gaps Closes the original 8-gap audit by consolidating into 4 pages (parallel sonnet build): - Building Your C2-1 Poster — poster structure + labelled raw-data artefact + findings-to-SRS mapping (covers gaps 2, 3, 4) - Data Flow Diagram (Level-1) — standalone DFD page with mermaid worked example, mirrors Context Diagram and UCD pattern (gap 1) - User Stories and MoSCoW — three-part formula + MoSCoW matrix + user-story-to-method-choice pipeline (gap 6) - Hand-Drawing Cheat-Sheet — cross-cutting notation reference for hand-drawn versions of all 3 diagrams; right-vs-wrong tables (gap 5) Plus enhancement (gap 7): - Data Collection Methods: new 'Qualitative or quantitative?' section with same-project two-data-point comparison and decision rule C02-home updated with both new C2-1 pages, the new DFD page, and the cheat-sheet — restructured order so each section reads in pedagogical order.| /dev/null .. sd/C02/Building Your C2-1 Poster.md | |
| @@ 0,0 1,138 @@ | |
| + | > **DRAFT** — under teacher review. |
| + | |
| + | # Building Your C2-1 Poster |
| + | |
| + | Hamilton College · Year 12 · 2026 |
| + | |
| + | Your C2-1 poster is not a summary of what you did — it is the **documented evidence** the teacher scores you on during the gallery walk. Everything the rubric rewards (methods, findings mapped to SRS categories, visible labelling work, method rationale) must appear on the poster itself. Your station defence adds depth, but the poster sets your floor. |
| + | |
| + | > [!TIP] |
| + | > **The rubric stake.** The jump from 7–8 to 9–10 is the jump from *describing* your findings to *showing your preparation work*. Students who score 7–8 often have good data — they just haven't made their labelling and categorising *visible* on the poster. That's the most common reason for capping below top band, and it's the most fixable. |
| + | |
| + | --- |
| + | |
| + | ## 1. Poster structure — the five required sections |
| + | |
| + | Your poster must cover all five sections. On A3 portrait, a clean layout is two columns with Section 3 spanning the full width (it needs the most space). |
| + | |
| + | | Section | What goes there | Word-count guide | Band 9–10 phrasing example | |
| + | |---|---|---|---| |
| + | | **1 — What data did I need?** | 3–5 bullets: the specific questions your data collection needed to answer to inform the SRS. Not generic topics — specific gaps ("I needed to know which device types Year 7s used at school, because my technical environment was unknown"). | 50–80 words | *"I needed to know: (1) what tasks users currently do manually, (2) which devices they use, (3) what frustrates them about the existing process, (4) what constraints the school IT policy places on third-party software, (5) how many concurrent users the system must support."* | |
| + | | **2 — Methods used** | Each method (interviews / observations / surveys / reports): who/what, sample size, timing, how. One row or bullet per method. | 60–100 words total | *"Interviews: semi-structured, 3 × ~25 min with client and two target users, T1W7–8. Survey: 14 closed-ended items + 2 open, Google Forms, sent to 22 Year 8 students, T1W8, 19 responses. Observation: non-participant, 2 × 20 min watching students use current spreadsheet system, T1W9. Reports: school IT device list (requested from IT coordinator, current year) + DET Acceptable Use Policy PDF."* | |
| + | | **3 — Findings → SRS mapping** | A table: data point → SRS category. Must cover all six categories (see §3 below). | Table; aim for 8–12 rows | One row per data point with the SRS category named explicitly — see the full table in §3. | |
| + | | **4 — Data preparation** | Show **actual examples** of labelled/categorised data — not a claim that you labelled it. A before/after table, colour-coded excerpt, or a reproduced note with tags is required for 9–10 (see §2 below). | 80–120 words + visual | *"Each interview note was colour-coded: orange = features requested, blue = pain points, green = technical constraints, purple = user characteristics. Below is an excerpt from the Interview 1 transcript showing the labels applied."* Then show the excerpt. | |
| + | | **5 — Method rationale** | 2–3 sentences **per method** explaining why that method was right *for this specific project* — not generic. | 80–120 words | *"I chose interviews because my client is the only person who could define the scope and must-have features — a survey would have given breadth at the cost of losing the nuance I needed to distinguish Could Haves from Must Haves. I added a survey because my client's view of 'what users want' disagreed with my interview with a target user — I needed breadth data to resolve that contradiction."* | |
| + | |
| + | ::: info |
| + | **Layout tip for A3.** Portrait orientation works well with these proportions: Sections 1 + 2 side by side in the top third; Section 3 across the full middle third (it needs room for the table); Sections 4 + 5 side by side in the bottom third. Put your name, project title, and date in a narrow header strip. Use a consistent colour scheme for the SRS categories — it makes your Section 4 labelling self-evident. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## 2. What labelling actually looks like |
| + | |
| + | The most common reason students cap at 7–8 is that Section 4 says *"I labelled my data"* without showing it. For 9–10, the rubric requires that the labelling and categorising be **visible** on the poster. The teacher's authenticity checklist explicitly flags *"no labelling/categorising visible"* as a 7–8 ceiling. |
| + | |
| + | Here is what the difference looks like. Both columns come from the same interview with a client: |
| + | |
| + | | Raw interview note (what you wrote at the time) | Labelled version (what goes on the poster) | |
| + | |---|---| |
| + | | *"She said she's sick of entering the same data in two places"* | *"She said she's sick of entering the same data in two places"* `[Interview-1 · qual · pain point · functional req: data entry should not be duplicated]` | |
| + | | *"All the kids use iPads at her school — no Windows machines in classrooms"* | *"All the kids use iPads at her school"* `[Interview-2 · quant · technical environment: device type = iPad iOS, n=~30 per class]` | |
| + | | *"She mentioned the system has to work offline because the wifi at camp drops out"* | *"System must work offline at camp"* `[Interview-1 · qual · constraint: offline functionality required · non-functional req: availability]` | |
| + | | *"Year 7s find multi-step menus confusing — she's seen them give up"* | *"Year 7s give up on multi-step menus"* `[Observation-1 · qual · user characteristics: low UI literacy for nested navigation]` | |
| + | | *"There are about 180 students who'd use this"* | *"~180 potential users"* `[Survey Q3 · quant · scope: user base size ≤ 200]` | |
| + | |
| + | ::: success |
| + | **What your label should contain** (for each data point): |
| + | |
| + | 1. **Source** — method + which instance (Interview-1, Survey Q3, Observation-2, Report: IT-device-list) |
| + | 2. **Type** — qualitative or quantitative |
| + | 3. **Theme** — the category you grouped it into (features requested, pain points, existing workarounds, technical constraints, accessibility needs — use the themes that emerge from *your* data) |
| + | 4. **SRS category** — which SRS section it informs (see §3) |
| + | ::: |
| + | |
| + | You don't need to put every raw note on the poster — choose 5–8 that cover all six SRS categories and show the range of your labelling work. The point is that someone reading the poster can see you processed the raw data, not just collected it. |
| + | |
| + | --- |
| + | |
| + | ## 3. Findings → SRS mapping |
| + | |
| + | Section 3 of your poster is a table showing how your collected data informs the SRS. Students who score 5–6 usually map to requirements, constraints, and scope only. The 7–8 jump requires user characteristics and technical environment. Both are often missed because students don't recognise what kind of data goes there. |
| + | |
| + | ::: warning |
| + | **The two most missed categories.** If your Section 3 table has no rows for "user characteristics" or "technical environment", you will not reach 7–8 regardless of how good your other sections are. Scan your raw data — these categories are almost certainly there, just unlabelled. |
| + | ::: |
| + | |
| + | Below is a worked example for a project building a quiz/homework tracking app for a Year 7–9 cohort. Use it as a model for your own table — the *structure* is what matters, not the specific content. |
| + | |
| + | | Example data point | Method | SRS category | How it shapes the SRS | |
| + | |---|---|---|---| |
| + | | Client requires a login so students can't see each other's scores | Interview-1 | **Functional requirement** | FR-1: The system shall authenticate each user with a unique username and password before granting access. | |
| + | | System must load each quiz in under 3 seconds on school wifi | Survey Q9 (80% cited speed as important) | **Non-functional requirement** | NFR-1: Response time for quiz load ≤ 3 seconds under typical school network conditions. | |
| + | | School IT policy prohibits storing student data on overseas servers | Report: DET Data Residency Policy | **Constraint** | C-1: All student data must be stored on servers located in Australia (DET policy). | |
| + | | Project covers Year 7–9 students at one campus only; no staff marking interface in scope | Interview-1, scope discussion | **Scope** | The system covers student quiz submission and score tracking only. Teacher marking workflow is out of scope for this iteration. | |
| + | | Year 7 students struggle with multi-step menus; they expect apps to look like TikTok or Instagram | Observation-1 + Interview-2 | **User characteristics** | Users: age 12–15, high smartphone literacy, low tolerance for complex navigation hierarchies, no formal keyboard-shortcut training. | |
| + | | All classroom devices are iPad (iOS 16+); no Windows laptops in Year 7–9 classrooms; school uses Google Workspace | Report: IT device list + Interview with IT coordinator | **Technical environment** | Client-side: Safari on iPadOS 16+. No local storage permitted; must use Google OAuth for authentication. No desktop app required. | |
| + | | Teachers want to bulk-export results to a CSV for their gradebooks | Interview-1 + Interview-3 | **Functional requirement** | FR-4: The system shall allow teachers to export quiz results as a CSV file. | |
| + | | ~180 students across four Year 7 homerooms would use the system | Survey Q1 (enrolment count) | **Scope** | System must support up to 200 concurrent users without degraded performance. | |
| + | |
| + | ::: info |
| + | **Scope vs constraint — a quick distinction.** *Scope* defines what the system will and won't do (the boundaries of your build). *Constraints* define external conditions you cannot change (policy, platform, budget, timeline). Both are real SRS sections but they answer different questions: scope = "what's in/out", constraints = "what limits how you build it". |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## 4. Station defence — what the teacher is listening for |
| + | |
| + | The poster is the documented artefact. During the gallery walk, when the teacher visits your station, they are listening for three things that the poster alone cannot prove: |
| + | |
| + | 1. **Ownership** — can you answer specific questions about your own data? ("What did your second interviewee say about the notification system?") A student who actually did the work can answer; a student who outsourced cannot. |
| + | 2. **Depth behind Section 4** — can you walk through *how* your labelling enabled your analysis? Not "I colour-coded by theme" but "colour-coding interview themes meant I could quickly see that 3 of 4 interviewees raised the same usability concern — that pattern became user story US-12." |
| + | 3. **Project-specific rationale** — can you explain *why* your particular methods were right for *your* project, not just why those methods exist in general? The 9–10 descriptor says *explains the use of the selected data collection methods* — "explains" = project-specific justification, not a methods textbook summary. |
| + | |
| + | ::: warning |
| + | **Common defence mistakes.** Reading your poster verbatim scores no higher than the poster floor. Generic method explanations ("interviews are good because you can ask follow-up questions") are describing methods, not explaining your choice. The teacher has heard both before. Be specific: name your interviewees' roles, cite your actual survey response count, describe what you observed and when. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | Answer in your head first, then click the spoiler to check. |
| + | |
| + | **1.** A student's Section 3 table maps all collected data to *functional requirements*, *non-functional requirements*, and *constraints* only. What is the highest rubric band this poster can reach? |
| + | |
| + | >! **7–8 is the ceiling, and likely not even that.** The 7–8 descriptor requires describing how data informs *user characteristics* and *technical environment* — both are missing. The poster can reach 5–6 (two categories covered: req + constraints). Without user characteristics and technical environment, 7–8 is not achievable regardless of how many methods were used. |
| + | |
| + | **2.** Section 4 of a student's poster says: *"I organised my interview notes by theme and labelled each note with which SRS section it relates to."* Which band does this most likely evidence? |
| + | |
| + | *(a) 9–10, because labelling and categorising is described · (b) 7–8, because the preparation is mentioned · (c) 7–8 at best, because no visible preparation is shown · (d) 5–6, because it's vague* |
| + | |
| + | >! **(c) 7–8 at best.** The 9–10 descriptor requires *"prepares the data for analysis by labelling and categorising"* — and the teacher's rubric guidance explicitly states that claiming preparation happened is not the same as showing it. Visible evidence of labelling (a colour-coded excerpt, a table with tags, an annotated note) is what lifts a poster from 7–8 to 9–10. |
| + | |
| + | **3.** Your school IT coordinator gives you the device list: *"All Year 7–9 classrooms use iPad (iOS 16). No Windows. Google Workspace accounts for all students."* Which SRS category does this data belong to? |
| + | |
| + | *(a) functional requirements · (b) constraints · (c) technical environment · (d) user characteristics* |
| + | |
| + | >! **(c) technical environment.** Technical environment covers the hardware, software, and network conditions the system must run in — device types, operating systems, browsers, accounts already in use. Constraints are external limits on how you build (policy, budget, timeline), not descriptions of the platform. The device list is a platform description, so it is technical environment. |
| + | |
| + | **4.** During your station defence, the teacher asks: *"Why did you use a survey rather than running more interviews?"* Which answer reaches 9–10? |
| + | |
| + | *(a) "Surveys are faster and reach more people." · (b) "I used a survey because my client and one user gave me their personal views in interviews, but I needed to know whether those views were typical across the 22 Year 8 students who would actually use the system — I needed breadth data to validate the patterns I'd identified, and a 14-item survey was the fastest way to get it." · (c) "The rubric says you need three methods, so I added a survey." · (d) "I prefer surveys because they're easier to analyse."* |
| + | |
| + | >! **(b).** Option (b) is a project-specific justification: it names the gap the survey was filling (validating interview patterns across the actual user group), the population surveyed (22 Year 8 students), and why the interview alone wasn't sufficient. Options (a), (c), and (d) are generic or rubric-mechanical — they describe what surveys are or why the student chose them procedurally, not why this method was right for this project at this stage. |
| + | |
| + | --- |
| + | |
| + | ## See also |
| + | |
| + | - [Data Collection Methods](Data%20Collection%20Methods.md) — the four methods, their strengths/weaknesses, and how to choose a justified mix |
| + | - [Explaining vs Describing Your Data Collection](Explaining%20vs%20Describing%20Your%20Data%20Collection.md) — the verb ladder the rubric uses to separate 7 from 9–10 |
| + | - [Essential Terms](Essential%20Terms.md) — definitions of qualitative, quantitative, SRS categories |
| + | - [Context Diagram](Context%20Diagram.md) — the entities and data flows you identified during data collection anchor this diagram |
| + | - [What Is an Entity](What%20Is%20an%20Entity.md) — your data sources may themselves be entities on the context diagram |
| + | |
| + | --- |
| + | |
| + | ← Back to [C02 Hub](C02-home.md) |
| sd/C02/C02-home.md .. | |
| @@ 12,15 12,19 @@ | |
| ## Topics — Data collection (C2-1) | |
| + | - [User Stories and MoSCoW](/sd/C02/User%20Stories%20and%20MoSCoW) — the three-part user-story formula, MoSCoW priority matrix, and how stories drive method choice |
| - [Data Collection Methods](/sd/C02/Data%20Collection%20Methods) — the four methods (interview, survey, observation, report) — when to use each, strengths/weaknesses, recommended 3-method mix | |
| - [Explaining vs Describing Your Data Collection](/sd/C02/Explaining%20vs%20Describing%20Your%20Data%20Collection) — the exact rubric difference between 7–8 and 9–10 for Indicator 1; worked examples of each level | |
| + | - [Building Your C2-1 Poster](/sd/C02/Building%20Your%20C2-1%20Poster) — poster structure, what labelled raw data looks like, findings → SRS mapping; the single page to read before C2-1 |
| ## Topics — Analytical diagrams (C2-2) | |
| - [Context Diagram](/sd/C02/Context%20Diagram) — Yourdon-DeMarco notation, a worked example, "draw it / check it" steps, common mistakes | |
| + | - [Data Flow Diagram (Level-1)](/sd/C02/Data%20Flow%20Diagram) — process / entity / data store / data flow notation; numbered processes; common mistakes |
| - [Context Diagram vs Data Flow Diagram](/sd/C02/Context%20Diagram%20vs%20Data%20Flow%20Diagram) — what can appear on each diagram, side-by-side; the most common notation errors in C2-2 | |
| - [Use Case Diagram (UCD)](/sd/C02/Use%20Case%20Diagram) — actors, use cases, system boundary, and the four relationships; arrow-direction rules for «include» / «extend» | |
| - [What Is an Entity?](/sd/C02/What%20Is%20an%20Entity) — why entities include external systems (APIs, email servers) as well as human users; how to find every entity from your user stories | |
| + | - [Hand-Drawing Cheat-Sheet](/sd/C02/Hand-Drawing%20Cheat-Sheet) — single visual reference for hand-drawn versions of all three diagrams (right vs wrong symbols) |
| - [Excalidraw Diagram Starters](/sd/C02/Excalidraw%20Diagram%20Starters) — pre-framed skeletons for all three C02 diagrams (context diagram, DFD, use case diagram) with shape keys and notation checks (DRAFT) | |
| ## Resources | |
| sd/C02/Data Collection Methods.md .. | |
| @@ 164,6 164,21 @@ | |
| --- | |
| + | ## Qualitative or quantitative? |
| + | |
| + | Every data point you collect is either **qualitative** (descriptive — words, themes, observations) or **quantitative** (countable — numbers, frequencies, ratings). Knowing which is which matters for your poster's labelling section and for explaining why you chose each method. |
| + | |
| + | | Same project, two data points | Type | How you'd present it | |
| + | |---|---|---| |
| + | | *"Year 9 students said the canteen queue is too slow at lunch."* | **Qualitative** | Direct quote, theme tag (*pain points*), source attribution | |
| + | | *"On average, students spend 6.5 minutes in the canteen queue (n=30 observations)."* | **Quantitative** | Number, sample size, summary statistic | |
| + | |
| + | ::: info |
| + | **The decision rule:** the *data type* is determined by what you can do with the result, not by how it was collected. Surveys can produce both: a closed-ended scale gives quantitative data; an open-ended response gives qualitative. The same goes for interviews and observations. |
| + | ::: |
| + | |
| + | --- |
| + | |
| ## Choosing your mix | |
| For C02 you must use **three or more** methods. A balanced mix: | |
| /dev/null .. sd/C02/Data Flow Diagram.md | |
| @@ 0,0 1,194 @@ | |
| + | > **DRAFT** — under teacher review. |
| + | |
| + | # Data Flow Diagram (Level-1) |
| + | |
| + | Hamilton College · Year 12 · 2026 |
| + | |
| + | A Level-1 DFD is the **floor-plan view** of your software: the single circle from your context diagram is split open to reveal the major processes inside, the data stores where information lives, and the labelled flows connecting everything. Every entity that appeared on your context diagram must reappear here — and no new ones should suddenly show up. |
| + | |
| + | > [!TIP] |
| + | > Your **C2-2 validation** is a rubric ladder: you need a working context diagram to score 3–4, *and* a working Level-1 DFD to reach **5–6**. The DFD is the second rung. Getting the four notation rules right (see below) is what separates a 5–6 from a diagram that costs you that band. |
| + | |
| + | --- |
| + | |
| + | ## Why a DFD / what it shows |
| + | |
| + | Think of the relationship between your context diagram and your Level-1 DFD as the difference between a **satellite view** and a **floor plan**. |
| + | |
| + | - The **context diagram** (Level 0) shows the building's outline and everything crossing its boundary — nothing inside. |
| + | - The **Level-1 DFD** opens the roof and shows the rooms (processes), the filing cabinets (data stores), and the corridors connecting them (data flows). |
| + | |
| + | It does four jobs: |
| + | |
| + | - **Decomposes the system** — the single context-diagram circle becomes 3–6 numbered processes |
| + | - **Reveals data storage** — shows where your system persists data (databases, tables, files) |
| + | - **Traces data transformations** — every process takes in data and produces *different* data out |
| + | - **Maintains consistency** — entities and flow names must match your context diagram exactly |
| + | |
| + | ::: info |
| + | **Why entities must stay the same.** The VCAA rubric at 9–10 requires *"no errors, inconsistencies or omissions"*. An entity labelled *"User"* on the context diagram but *"Customer"* on the DFD is an inconsistency — even if both diagrams are otherwise perfect. Use the exact same names throughout. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## The four elements |
| + | |
| + | | Element | Symbol | Rules | |
| + | |---|---|---| |
| + | | **Process** | Circle (Yourdon-DeMarco) | Numbered verb-noun phrase (e.g. *"1. Verify Login"*, *"2. Save Order"*). Must have **at least one input and one output** — and the output must differ from the input (the process *transforms* the data). | |
| + | | **External entity** | Rectangle | Same entities as your context diagram — same names, same roles. They sit outside the logic of the system and can only connect to processes. | |
| + | | **Data store** | Two parallel horizontal lines (or cylinder) | A named repository where data persists (e.g. *"Orders"*, *"User Accounts"*). Must have at least one flow **in** and one flow **out**. Can only connect to processes. | |
| + | | **Data flow** | Labelled arrow | Carries the specific data moving between elements. Every arrow must be labelled (not *"data"* or *"info"*). **All flows are unidirectional** — one arrowhead, one direction. | |
| + | |
| + | ::: warning |
| + | **Three connections that are never allowed** |
| + | |
| + | - **Entity ↔ Entity** — two external entities cannot exchange data directly on this diagram |
| + | - **Data store ↔ Data store** — data cannot move between stores without passing through a process |
| + | - **Entity ↔ Data store** — an entity cannot read from or write to a store directly; data always flows through a process first |
| + | |
| + | If data genuinely moves in *both* directions between two elements, draw **two separate arrows**, each with its own label — one for each direction. Never use a double-headed arrow. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Worked example: Sales Order System |
| + | |
| + | The same Sales Order System from the context diagram page, now decomposed to Level 1. Three entities (Managers, Employees, Customers), four processes, three data stores. |
| + | |
| + | ```mermaid |
| + | flowchart LR |
| + | M[Managers] |
| + | E[Employees] |
| + | C[Customers] |
| + | |
| + | P1(("1. Manage\nEmployees")) |
| + | P2(("2. Manage\nProducts")) |
| + | P3(("3. Process\nOrder")) |
| + | P4(("4. Generate\nInvoice")) |
| + | |
| + | DS1[("Employee\nRecords")] |
| + | DS2[("Product\nCatalogue")] |
| + | DS3[("Orders")] |
| + | |
| + | M -->|new employee details| P1 |
| + | P1 -->|employee record| DS1 |
| + | DS1 -->|employee list| P1 |
| + | P1 -->|employee lists| M |
| + | |
| + | E -->|product & category info| P2 |
| + | P2 -->|product record| DS2 |
| + | DS2 -->|product list| P2 |
| + | |
| + | C -->|customer details & order| P3 |
| + | P3 -->|order record| DS3 |
| + | DS3 -->|order data| P4 |
| + | P2 -->|product pricing| P3 |
| + | P4 -->|invoice| C |
| + | ``` |
| + | |
| + | **Read it like this:** |
| + | |
| + | - **Processes** (numbered circles): *1. Manage Employees*, *2. Manage Products*, *3. Process Order*, *4. Generate Invoice* |
| + | - **External entities** (rectangles): *Managers*, *Employees*, *Customers* — identical to the context diagram |
| + | - **Data stores** (cylinders): *Employee Records*, *Product Catalogue*, *Orders* |
| + | - **Selected data flows to trace:** |
| + | - **Managers → P1**: *new employee details* |
| + | - **P1 → Employee Records**: *employee record* (write) |
| + | - **Employee Records → P1**: *employee list* (read — a separate arrow back) |
| + | - **P1 → Managers**: *employee lists* (output back to manager) |
| + | - **C → P3**: *customer details & order* |
| + | - **P3 → Orders**: *order record* |
| + | - **Orders → P4**: *order data* |
| + | - **P4 → C**: *invoice* |
| + | |
| + | > [!IMPORTANT] |
| + | > Notice that **P1 reads back from Employee Records with a separate arrow** — it does not use a double-headed arrow. Every read and every write is its own labelled flow. This is the most-tested notation rule in C2-2. |
| + | |
| + | --- |
| + | |
| + | ## How to draw one |
| + | |
| + | 1. **Start from your context diagram.** Pull in the same external entities and the same flow names. The boundary of your DFD is the same boundary as your context diagram — you're just looking inside it now. |
| + | |
| + | 2. **Identify 3–6 major processes.** Each is a major function your system performs. Ask: *"What are the key things my system actually does?"* Name each with a verb-noun phrase and number them sequentially (*1. …*, *2. …*, *3. …*). |
| + | |
| + | 3. **Add data stores.** For every piece of data your system needs to *remember* across sessions or between processes, add a named data store. If your software saves nothing, you have no stores — but most SAT projects have at least one. |
| + | |
| + | 4. **Map the data flows.** Work systematically: for each process, ask *"what data does this need as input, and what does it produce as output?"* Label every arrow with specific data. Check that every entity flow from the context diagram has made it onto the DFD. |
| + | |
| + | 5. **Validate against the rules.** See the quality check below before moving on. |
| + | |
| + | ::: success |
| + | **Quality check before you move on** |
| + | |
| + | - Every process has **at least one input *and* one output**? ✓ |
| + | - Every process label is a **numbered verb-noun phrase**? ✓ |
| + | - Every data store has at least one flow **in** and one flow **out**? ✓ |
| + | - **No entity↔entity, no store↔store, no entity↔store** connections? ✓ |
| + | - Every arrow has a **specific** label (not *"data"* or *"info"*)? ✓ |
| + | - All arrows are **unidirectional** — two-way data = two separate arrows? ✓ |
| + | - **Entity names match** your context diagram exactly? ✓ |
| + | |
| + | Seven ticks → your DFD is ready for the validation. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ::: danger |
| + | **Most common DFD mistakes** |
| + | |
| + | 1. **One circle only — it's still a context diagram.** A DFD must decompose the system into *multiple* numbered processes. If there's only one circle, you have not drawn a DFD. |
| + | 2. **Process with no output (or no input).** A process that takes data in but sends nothing out is not transforming anything. Every process needs both sides. |
| + | 3. **Direct entity-to-data-store connection.** Data must pass through a process first. An arrow from *Customer* directly to *Orders* is a notation error. |
| + | 4. **Store-to-store flow.** Data cannot travel between two stores without a process in between. |
| + | 5. **Double-headed arrows.** Each direction of data flow is a separate, labelled, single-headed arrow. |
| + | 6. **Unlabelled or vague arrows.** *"info"* or *"data"* is not a label. Name the actual data (*"login credentials"*, *"order confirmation"*). |
| + | 7. **Inconsistent entities.** If your context diagram says *"Year 7 Student"*, your DFD must say *"Year 7 Student"* — not *"Student"* or *"User"*. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | Answer in your head first, then click the spoiler to check. |
| + | |
| + | **1.** A Level-1 DFD has a process called *"Save Record"* with one arrow in (*"new record"* from an entity) and nothing going out. What is wrong? |
| + | |
| + | >! **The process has no output.** Every process must transform data — it takes something in and produces something different out. *"Save Record"* should output *something* (e.g. *"confirmation"* back to the entity, or a *"saved record"* to a data store). A process with only an input arrow is not doing anything by DFD rules. |
| + | |
| + | **2.** You need to show that a *Customer* can read their past orders *and* add a new order. How do you show both on the DFD? |
| + | |
| + | *(a) One double-headed arrow between Customer and the Orders data store* |
| + | *(b) One double-headed arrow between Customer and the relevant process* |
| + | *(c) Two separate single-headed arrows between Customer and the relevant process, each labelled differently* |
| + | *(d) A single arrow labelled "orders (in and out)"* |
| + | |
| + | >! **(c) Two separate single-headed arrows, each labelled.** All data flows are **unidirectional**. If data moves in both directions, you draw two arrows — one for each direction — each with its own specific label (e.g. *"new order"* going in, *"order history"* coming out). Double-headed arrows are never valid in Yourdon-DeMarco notation. |
| + | |
| + | **3.** Which of these connections is **allowed** on a Level-1 DFD? |
| + | |
| + | *(a) Customer → Orders (data store)* |
| + | *(b) Orders (data store) → Product Catalogue (data store)* |
| + | *(c) Process 2 → Orders (data store)* |
| + | *(d) Customer → Employee (entity)* |
| + | |
| + | >! **(c) Process 2 → Orders (data store).** A process can write to (or read from) a data store — that is a valid and normal DFD connection. The other three all break the rules: (a) entity directly to a data store — not allowed; (b) store to store — not allowed; (d) entity to entity — not allowed. |
| + | |
| + | **4.** Your context diagram shows entities *"Homeroom Teacher"*, *"Student"*, and *"School Admin"*. On your Level-1 DFD you wrote *"Teacher"*, *"Learner"*, and *"Admin"*. What rubric consequence does this have? |
| + | |
| + | >! **It is an inconsistency — and at 9–10, any inconsistency is disqualifying.** The VCAA descriptor for 9–10 reads *"no errors, inconsistencies or omissions"*. Mismatched entity names between diagrams is an inconsistency even if both diagrams are otherwise perfect. At 5–6 *"some errors or omissions"* are tolerated, so you would still score that band — but you cannot reach 9–10 with mismatched names. Always copy entity names exactly from your context diagram. |
| + | |
| + | --- |
| + | |
| + | ## See also |
| + | |
| + | - [Context Diagram](Context%20Diagram.md) — Level 0; the entities and flows here must be consistent with your DFD |
| + | - [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — side-by-side comparison of what appears on each level |
| + | - [Use Case Diagram](Use%20Case%20Diagram.md) — the third C2-2 analytical diagram; actors must match entities across all three |
| + | - [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — pre-framed DFD canvas for rehearsing before the timed validation |
| + | - [Essential Terms](Essential%20Terms.md) — definitions of *process*, *data store*, *data flow*, *external entity* |
| + | |
| + | --- |
| + | |
| + | ← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
| /dev/null .. sd/C02/Hand-Drawing Cheat-Sheet.md | |
| @@ 0,0 1,256 @@ | |
| + | > **DRAFT** — under teacher review. |
| + | |
| + | # Hand-Drawing Cheat-Sheet |
| + | |
| + | Hamilton College · Year 12 · 2026 |
| + | |
| + | This page is your single reference for what every symbol should look like when drawn **by hand under timed conditions**. It does not re-teach concepts — it shows you the right shape, the wrong shape, and what gets crossed off by the marker. |
| + | |
| + | > [!TIP] |
| + | > **The C2-2 stake.** The validation runs for a full lesson (~50 min) under locked conditions: no internet, no AI, no Excalidraw, no notes, no reference sheets. You draw all three diagrams — Context Diagram, Level-1 DFD, Use Case Diagram — from memory, for your own project. Band 9–10 requires *no errors, no inconsistencies, no omissions* across all three. One wrong shape or one unlabelled arrow and you cap at 7–8. This cheat-sheet is for **home practice only** — you cannot bring it to the validation. |
| + | |
| + | --- |
| + | |
| + | ## Context Diagram — Symbol Reference |
| + | |
| + | ### Shape key |
| + | |
| + | | Symbol | What you draw | Rules | |
| + | |---|---|---| |
| + | | **System** | One circle in the centre, system name inside | Exactly **one** circle — the whole system is one shape | |
| + | | **External entity** | Rectangle, role name inside | All entities **outside** the circle | |
| + | | **Data flow** | Arrow with a label on the line | Every arrow must carry a **specific** data label | |
| + | |
| + | ### Right vs Wrong — Context Diagram |
| + | |
| + | | Element | Correct | Common error | |
| + | |---|---|---| |
| + | | System shape | Clean circle, labelled with the system name | An oval squashed sideways, or a rectangle — the system must be a **circle** | |
| + | | Number of circles | Exactly one | Two circles (e.g. adding *"Verify User"* as a second circle) — that is a DFD, not a context diagram | |
| + | | Entity shape | Rectangle clearly outside the system circle | Rectangle drawn inside the circle — entities are always **outside** | |
| + | | Data flow label | *"Assignment submission form"* | *"data"* or *"info"* — these are not labels; name the actual data | |
| + | | Entity–entity arrow | Not present — all flows touch the system circle | Arrow drawn directly between two entities, bypassing the system | |
| + | | Data stores | Not present at context level | Double-line (data store shape) included — data stores do not exist at Level 0 | |
| + | |
| + | ### Canonical shape — mermaid |
| + | |
| + | ```mermaid |
| + | flowchart LR |
| + | E1[External Entity] |
| + | E2[External Entity] |
| + | S(("Your System\nName")) |
| + | |
| + | E1 -->|specific data label| S |
| + | S -->|specific data label| E2 |
| + | E2 -->|specific data label| S |
| + | ``` |
| + | |
| + | ::: warning |
| + | **Do NOT draw on a context diagram** |
| + | |
| + | - A second circle (any internal process) |
| + | - Data stores (double-line shapes) |
| + | - Entity-to-entity arrows |
| + | - Arrows without labels |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Level-1 DFD — Symbol Reference |
| + | |
| + | ### Shape key |
| + | |
| + | | Symbol | What you draw | Rules | |
| + | |---|---|---| |
| + | | **Process** | Circle, numbered + verb-noun name inside | 3–6 circles; each needs ≥1 input AND ≥1 output | |
| + | | **External entity** | Rectangle — same names as context diagram | Never connect to a data store directly | |
| + | | **Data store** | Two parallel horizontal lines, name between them | At least one in AND one out flow; only connects to processes | |
| + | | **Data flow** | Arrow with a label | Every arrow must be labelled with the specific data | |
| + | |
| + | ### Right vs Wrong — Level-1 DFD |
| + | |
| + | | Element | Correct | Common error | |
| + | |---|---|---| |
| + | | Process shape | Circle (round), with a number and verb-noun name | Oval so squashed it looks like a rectangle, or an actual rectangle — must be **clearly circular** | |
| + | | Process label | *"1. Verify Login"* | No number, or a noun only (*"Login"*) — processes need a number and a verb-noun phrase | |
| + | | Data store shape | **Two parallel horizontal lines** with a name between them | Plain rectangle without the second line — the double-line is what distinguishes a data store from an entity | |
| + | | Data store connections | Only to/from processes | Arrow from entity directly to data store — illegal; data must flow **through a process** first | |
| + | | Data store connections | Only to/from processes | Arrow from one data store to another — also illegal | |
| + | | Data flow label | *"student login credentials"* | Unlabelled arrow — every arrow on a DFD must have a label | |
| + | | Entity names | Exactly match the context diagram | *"User"* in the DFD vs *"Student"* in the context diagram — inconsistency costs marks | |
| + | | Every process | At least one input AND one output | A circle with only outputs (or only inputs) — a process must transform data | |
| + | |
| + | ### Canonical shape — mermaid |
| + | |
| + | ```mermaid |
| + | flowchart LR |
| + | E[External Entity] |
| + | P1(("1. Process\nName")) |
| + | P2(("2. Process\nName")) |
| + | DS[("Data Store")] |
| + | |
| + | E -->|specific data| P1 |
| + | P1 -->|stored data| DS |
| + | DS -->|retrieved data| P2 |
| + | P2 -->|output data| E |
| + | ``` |
| + | |
| + | ::: warning |
| + | **Do NOT draw on a Level-1 DFD** |
| + | |
| + | - Entity-to-data-store arrows (must go through a process) |
| + | - Data-store-to-data-store arrows |
| + | - A process with no input, or no output |
| + | - Unlabelled arrows |
| + | - Entity names that differ from your context diagram |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Use Case Diagram — Symbol Reference |
| + | |
| + | ### Shape key |
| + | |
| + | | Symbol | What you draw | Rules | |
| + | |---|---|---| |
| + | | **Actor** | Stick figure, **outside** the rectangle, role name below | Role name (e.g. *Teacher*), not a personal name; non-human systems are actors too | |
| + | | **Use case** | Oval, **inside** the system boundary rectangle | Verb-noun label: *"Submit Assignment"*, not *"Login Page"* | |
| + | | **System boundary** | Rectangle labelled with the system name | All use cases inside; all actors outside | |
| + | | **Association** | Solid line, actor ↔ use case | Every actor needs at least one | |
| + | | **«include»** | Dashed arrow, arrow points TO the included use case | Triggered **always**; arrow: base → included | |
| + | | **«extend»** | Dashed arrow, arrow points TO the base use case | Triggered **optionally**; arrow: extension → base | |
| + | |
| + | ### Right vs Wrong — Use Case Diagram |
| + | |
| + | | Element | Correct | Common error | |
| + | |---|---|---| |
| + | | System boundary shape | **Rectangle**, labelled with the system name | Oval or circle as the boundary — the system boundary must be a **rectangle** | |
| + | | Actor position | Stick figure outside the rectangle | Stick figure drawn inside the rectangle — actors are **always external** | |
| + | | Use case position | Oval inside the rectangle | Oval outside the rectangle — use cases describe **your** system's functions | |
| + | | Use case label | *"Submit Quiz"* (verb-noun) | *"Quiz Submission Page"* or *"Database"* — labels must be action phrases | |
| + | | Actor label | Role name: *"Teacher"* | Personal name: *"Mr Smith"* — use the **role**, not the person | |
| + | | «include» arrow direction | Base use case → included use case | Arrow pointing the wrong way (included → base) — this is the most common mistake | |
| + | | «extend» arrow direction | Extending use case → base use case | Arrow pointing the wrong way (base → extending) | |
| + | | «include» / «extend» line style | **Dashed** line with the stereotype label | Solid line with no label — dashed + label is required | |
| + | | Association line | **Solid** line | Dashed line for a plain association — save dashed for «include»/«extend» | |
| + | |
| + | ### Canonical shape — mermaid |
| + | |
| + | ```mermaid |
| + | flowchart LR |
| + | A1(["👤 Actor A"]) |
| + | A2(["👤 Actor B"]) |
| + | |
| + | subgraph SYS["Your System Name"] |
| + | UC1(["Use Case 1"]) |
| + | UC2(["Use Case 2"]) |
| + | UC3(["Use Case 3"]) |
| + | end |
| + | |
| + | A1 --- UC1 |
| + | A1 --- UC2 |
| + | A2 --- UC3 |
| + | UC1 -.->|«include»| UC3 |
| + | UC2 -.->|«extend»| UC1 |
| + | ``` |
| + | |
| + | *(In a hand-drawn version, actors are traditional stick figures. The mermaid icons above are just a stand-in.)* |
| + | |
| + | ::: warning |
| + | **Do NOT draw on a Use Case Diagram** |
| + | |
| + | - Actors inside the system boundary rectangle |
| + | - A circle (oval) as the system boundary — boundary must be a **rectangle** |
| + | - «include» / «extend» arrows on solid lines |
| + | - «include» / «extend» arrows pointing the wrong direction |
| + | - Use case labels that are nouns only (*"Login Page"*, *"Database"*) |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Arrow Direction Memory Aid |
| + | |
| + | The «include»/«extend» arrows trip up nearly everyone. One rule covers both: |
| + | |
| + | > **The arrow always points toward the use case that is being *used* or *added to*.** |
| + | |
| + | | Relationship | Who initiates | Arrow direction | Reads as | |
| + | |---|---|---|---| |
| + | | **«include»** | Base use case (it needs the other one) | Base → Included | *"Base use case uses Included"* | |
| + | | **«extend»** | The optional extension | Extension → Base | *"Extension adds to Base"* | |
| + | |
| + | Example: |
| + | - *Submit Quiz* **includes** *Validate Answers* → arrow: Submit Quiz → Validate Answers |
| + | - *Display Error* **extends** *Submit Quiz* → arrow: Display Error → Submit Quiz |
| + | |
| + | --- |
| + | |
| + | ## Before You Flip the Paper — Final Check |
| + | |
| + | ::: success |
| + | **Run through this list before you put your pen down.** |
| + | |
| + | **Context Diagram** |
| + | - [ ] Exactly one circle, labelled with the system name |
| + | - [ ] All entities are rectangles, drawn outside the circle |
| + | - [ ] Every arrow has a specific data label |
| + | - [ ] No entity-to-entity arrows |
| + | - [ ] No data stores, no internal circles |
| + | |
| + | **Level-1 DFD** |
| + | - [ ] 3–6 numbered processes (circles), each with a verb-noun label |
| + | - [ ] Every process has at least one input AND one output arrow |
| + | - [ ] At least one data store (two parallel lines, not a plain rectangle) |
| + | - [ ] No entity-to-data-store arrows |
| + | - [ ] No data-store-to-data-store arrows |
| + | - [ ] Every arrow labelled |
| + | - [ ] Entity names match the context diagram exactly |
| + | |
| + | **Use Case Diagram** |
| + | - [ ] System boundary is a rectangle, labelled with the system name |
| + | - [ ] All actors (stick figures) are outside the rectangle |
| + | - [ ] All use cases (ovals) are inside the rectangle |
| + | - [ ] Actor labels are role names, not personal names |
| + | - [ ] Every actor has at least one solid association line |
| + | - [ ] At least one «include» (dashed, arrow to included use case) |
| + | - [ ] At least one «extend» (dashed, arrow to base use case) |
| + | - [ ] Arrow directions are correct for both «include» and «extend» |
| + | |
| + | **Cross-diagram consistency** |
| + | - [ ] Entity and actor names are identical across all three diagrams |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | Answer in your head first, then click the spoiler to check. |
| + | |
| + | **1.** You're drawing a context diagram by hand and you've just drawn a second circle labelled *"Verify Login"* next to the main system circle. What's wrong? |
| + | |
| + | >! A context diagram has **exactly one circle** — the whole system. Adding a second circle (like *"Verify Login"*) turns it into a DFD. Cross out the second circle; *"Verify Login"* belongs on your Level-1 DFD as a numbered process. |
| + | |
| + | **2.** On your Level-1 DFD, you draw a data store as a rectangle with no second line because you're drawing quickly. How will the marker read it? |
| + | |
| + | >! As an **external entity** — a plain rectangle is the entity shape. Without the second parallel line, the marker cannot distinguish it from an entity. The double-line is not optional; it is the notation. Draw it even when rushed. |
| + | |
| + | **3.** You draw «extend» as a dashed arrow pointing FROM the base use case TO the optional extension. What mark does this attract? |
| + | |
| + | >! This is a **notation error**. «extend» arrows point FROM the extending use case TO the base. The wrong direction means the marker reads your diagram as saying the base use case triggers the extension — the opposite of «extend» semantics. At 9–10 this is a credited error; it caps you at 7–8 or below. |
| + | |
| + | **4.** Your context diagram shows *"Student"* as an entity. On your DFD you've written *"User"* for what is clearly the same person. Is this a problem? |
| + | |
| + | >! Yes — it is a **named inconsistency**. The 9–10 band requires *"no errors, inconsistencies or omissions"*. Entity names must match across all three diagrams. Change *"User"* to *"Student"* on the DFD (and the UCD). |
| + | |
| + | --- |
| + | |
| + | ## See also |
| + | |
| + | - [Context Diagram](Context%20Diagram.md) — concepts, worked example, and notation rules |
| + | - [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — what can appear on each level |
| + | - [Use Case Diagram](Use%20Case%20Diagram.md) — the four relationships and arrow-direction rules |
| + | - [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — skeleton canvases for pre-validation practice |
| + | |
| + | --- |
| + | |
| + | ← Back to [C02 Home](C02-home.md) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
| /dev/null .. sd/C02/User Stories and MoSCoW.md | |
| @@ 0,0 1,280 @@ | |
| + | > **DRAFT** — under teacher review. |
| + | |
| + | # User Stories and MoSCoW |
| + | |
| + | Hamilton College · Year 12 · 2026 |
| + | |
| + | Every requirement you write, every question you ask in data collection, and every scope decision in your SRS traces back to one source: what your users actually need. User stories give that need a concrete written form. MoSCoW tells you which ones to act on first. Together they are the foundation the entire C02 pipeline rests on. |
| + | |
| + | > [!TIP] |
| + | > If you can't write a user story for a feature, you don't know whose problem it solves or why. Stop and ask your client before coding anything. |
| + | |
| + | --- |
| + | |
| + | ## The three-part formula |
| + | |
| + | Every user story follows the same structure: |
| + | |
| + | > **As a [role], I want [goal] so that [benefit].** |
| + | |
| + | Each part does a specific job: |
| + | |
| + | | Part | What it captures | Common question it answers | |
| + | |---|---|---| |
| + | | **As a [role]** | *Who* has this need — a specific user type, not "the system" | Who are my stakeholders? | |
| + | | **I want [goal]** | *What* they want to accomplish — one concrete action | What does this user need to do? | |
| + | | **so that [benefit]** | *Why* they want it — the underlying motivation | What value does this deliver? | |
| + | |
| + | **Example — well-formed story:** |
| + | |
| + | > "As a **teacher**, I want to **mark student attendance** so that I can **track who attended class and report to administration**." |
| + | |
| + | - Role: `teacher` — a specific human user role |
| + | - Goal: `mark student attendance` — one discrete action |
| + | - Benefit: `track who attended class and report to administration` — a genuine motivation tied to real workflow |
| + | |
| + | --- |
| + | |
| + | ## Breaking down each part |
| + | |
| + | ### The role |
| + | |
| + | The role must be **specific enough to imply context**. "User" is almost never enough — a student using a school timetable app has completely different needs from a teacher or an administrator using the same system. |
| + | |
| + | ::: info |
| + | **Picking the right role** |
| + | |
| + | For each user story, ask: *"If two different people read this, would they imagine the same person?"* If not, your role is too vague. |
| + | |
| + | - Too vague: `As a user...` |
| + | - Better: `As a Year 9 student...` |
| + | - Best (when you know your data): `As a Year 9 student who accesses the system on a school iPad...` |
| + | ::: |
| + | |
| + | Roles map directly to entities on your context diagram. Every role in your user stories should appear as an entity — work through this list before you finalise your diagram. (See [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) for the full method.) |
| + | |
| + | ### The goal |
| + | |
| + | The goal is **one concrete action**. Keep it atomic — if the story requires more than one verb to describe, split it. |
| + | |
| + | ::: warning |
| + | **Conflating multiple goals in one story** |
| + | |
| + | A story like *"As a student, I want to log in and view my timetable and download it as a PDF"* contains three separate features. When you apply MoSCoW, you may find login is Must Have but PDF download is Could Have — you cannot separate them if they are written as one story. |
| + | |
| + | One goal per story. Always. |
| + | ::: |
| + | |
| + | ### The benefit |
| + | |
| + | The benefit is the part students most often skip — and it is the part the rubric cares about most. Without the benefit, a user story is just a feature list with a persona stapled on. |
| + | |
| + | The benefit: |
| + | - Ties the feature to a real user need |
| + | - Drives your **non-functional requirements** (the "so that" often implies a performance or reliability constraint) |
| + | - Gives you a way to decide whether a proposed solution *actually solves the problem* |
| + | |
| + | **Example:** *"so that I can access my timetable wherever I am"* implies a portability requirement. Your SRS non-functional requirement would read something like: *"The system shall function on desktop, tablet, and mobile devices."* |
| + | |
| + | --- |
| + | |
| + | ## Common mistakes |
| + | |
| + | ::: danger |
| + | **These stories will cost you marks — fix them before submitting** |
| + | |
| + | | Mistake | Weak example | What's wrong | Improved version | |
| + | |---|---|---|---| |
| + | | Vague role | *"As a user..."* | No context; could mean anyone | *"As a teacher..."* | |
| + | | Missing benefit | *"As a student, I want to log in."* | No "so that" — we can't verify this solves a real need | *"As a student, I want to log in so that my data is private and personalised."* | |
| + | | Multiple goals | *"As a teacher, I want to create questions and manage a question bank and export to PDF."* | Three stories crammed into one; MoSCoW becomes impossible | Write three separate stories | |
| + | | Technical implementation, not user goal | *"As a student, I want the system to use JWT authentication."* | Students don't care about JWT; this is a design decision, not a user need | *"As a student, I want to log in securely so that my data is protected."* | |
| + | | Every story is Must Have | All five stories marked M | You haven't thought about scope; the rubric explicitly looks for a range | Apply MoSCoW honestly — see below | |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## Acceptance criteria |
| + | |
| + | Acceptance criteria turn a user story into something **testable**. The standard format is: |
| + | |
| + | > **Given** [some precondition], **when** [the user does something], **then** [the expected outcome]. |
| + | |
| + | **Example:** |
| + | |
| + | > **User story:** *"As a teacher, I want to mark student attendance so that I can track who attended class."* |
| + | > |
| + | > Acceptance criteria: |
| + | > - Given I am viewing my class list, when I click a student's name, then their status toggles between "Present" and "Absent". |
| + | > - Given I have marked attendance, when I click "Save", then the records are stored and I see a confirmation message. |
| + | > - Given I have saved attendance, when I navigate away and return, then the saved records are still there. |
| + | |
| + | Each acceptance criterion becomes a **validation** in your SRS — a concrete, observable check that the requirement has been met. |
| + | |
| + | ::: info |
| + | **Gherkin and test scenarios** |
| + | |
| + | This Given / When / Then format comes from a testing practice called Gherkin. It is not required by VCAA, but it is worth understanding because it connects user stories directly to system testing. See [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) for a worked Gherkin example and how it surfaces entities you would otherwise miss. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## MoSCoW priority matrix |
| + | |
| + | Once you have a list of user stories, you need to decide which ones are in scope for *this version* of your software. MoSCoW is the tool for that decision. |
| + | |
| + | | Priority | Definition | Scope meaning | Examples | |
| + | |---|---|---|---| |
| + | | **M — Must Have** | Non-negotiable. The software cannot function without this. | In scope; must be delivered | Login, core data entry, basic view of records | |
| + | | **S — Should Have** | Important and expected, but not critical to launch. | In scope; deliver if possible | Notifications, filtering, basic reporting | |
| + | | **C — Could Have** | Desirable but genuinely optional; a "nice to have". | In scope but deprioritised; deliver only if time permits | Calendar export, dark mode, advanced search | |
| + | | **W — Won't Have** | Acknowledged and deliberately excluded from this version. | **Out of scope** — written down so everyone agrees | Parent portal, external LMS integration, analytics | |
| + | |
| + | ### Must Have |
| + | |
| + | Must Haves define your **minimum viable product (MVP)** — the smallest version of your software that is actually useful to your client. If you removed a Must Have, the software would fail to solve the core problem. |
| + | |
| + | A disciplined test: *"If I deliver without this feature, would my client consider the project a failure?"* If yes, it is Must Have. |
| + | |
| + | ### Should Have |
| + | |
| + | Should Haves are important but not critical. If you run out of time, your client will be disappointed but the core product still works. In practice, most well-managed projects deliver most of their Should Haves. |
| + | |
| + | ### Could Have |
| + | |
| + | Could Haves are features that would be pleasant to include but have low impact if dropped. They are the first things cut when time is short. If you find yourself with a long list of Could Haves, that is a sign your Must Have scope is well-controlled — that is good. |
| + | |
| + | ### Won't Have |
| + | |
| + | ::: warning |
| + | **Won't Have is not "I didn't bother"** |
| + | |
| + | This is the most misunderstood category. Won't Have is a **deliberate, documented scope exclusion**. It means: |
| + | |
| + | - You considered the feature. |
| + | - You discussed it with your client (or thought through the implications). |
| + | - You agreed it will **not** be in this version. |
| + | - You wrote it down so no-one can later claim it was forgotten. |
| + | |
| + | Won't Have protects you from scope creep. When a stakeholder asks *"but what about parent access?"*, you can point to the Won't Have list and say *"we agreed that was out of scope for Version 1."* |
| + | |
| + | Writing *"I couldn't be bothered"* as the reason for a Won't Have will not score well. Write the actual reason: time constraints, out of scope for this user group, planned for Version 2. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## A worked example |
| + | |
| + | **Project:** School canteen pre-order app for Hamilton College students. |
| + | |
| + | | # | User story | MoSCoW | Why | |
| + | |---|---|---|---| |
| + | | US1 | As a **student**, I want to **browse the canteen menu** so that I know what is available before ordering. | **Must Have** | Core feature — without it, the system cannot function | |
| + | | US2 | As a **student**, I want to **place an order in advance** so that I can avoid the lunchtime queue. | **Must Have** | Primary user goal; the reason the system exists | |
| + | | US3 | As a **canteen staff member**, I want to **view the day's orders** so that I can prepare the right quantities in advance. | **Must Have** | Staff-facing core feature; without it the system is one-sided | |
| + | | US4 | As a **student**, I want to **receive a notification when my order is ready** so that I know when to collect it. | **Should Have** | Valuable but the system works without it; students can check manually | |
| + | | US5 | As a **student**, I want to **see my order history** so that I can quickly reorder my usual items. | **Could Have** | Convenience feature; no impact on core functionality | |
| + | | US6 | As a **parent**, I want to **top up my child's canteen account online** so that I do not need to send cash to school. | **Won't Have** | Out of scope for Version 1; requires payment gateway integration and parent authentication — acknowledged for Version 2 | |
| + | |
| + | This range — at least one story in each MoSCoW category — is what the rubric expects. If every story is Must Have, you haven't thought critically about scope. |
| + | |
| + | --- |
| + | |
| + | ## From user stories to data collection |
| + | |
| + | User stories are hypotheses. Before C02 is finished, your data collection must **test** those hypotheses — confirming, refining, or replacing them with what you actually learn. |
| + | |
| + | Each user story drives specific questions you need to answer, which drives method choice: |
| + | |
| + | | User story element | Questions it raises | Method best suited | |
| + | |---|---|---| |
| + | | **Role** (who are they?) | What are their characteristics, skill level, context of use? | Interview, observation | |
| + | | **Goal** (what do they do?) | What does the current workflow look like? Where are the pain points? | Observation, interview | |
| + | | **Benefit** (why do they want it?) | Is this a real need or an assumed one? Do others share it? | Survey, interview | |
| + | | **Acceptance criteria** | What does "done" look like to the user? | Interview with client | |
| + | | **Technical preconditions** (Given…) | What devices, accounts, network access do users have? | Reports (IT device list), observation | |
| + | |
| + | **Example:** For US1 in the canteen app (*"As a student, I want to browse the canteen menu so that I know what is available before ordering"*): |
| + | |
| + | - *Who are your students?* → Survey: "Which device do you use at school?" → shapes technical environment in SRS |
| + | - *Do students currently look at the menu?* → Observation: do students read the noticeboard menu, or do they just queue and decide at the counter? |
| + | - *What information do they need?* → Interview: "What would you want to see on a digital menu that the noticeboard doesn't show?" |
| + | |
| + | The data collection plan's Section 4 (user stories and MoSCoW) and Section 2 (methods) must align — for each story, at least one method should directly address a question that story raises. |
| + | |
| + | --- |
| + | |
| + | ## User stories in your SRS |
| + | |
| + | Once data is collected and analysed, your user stories feed into two parts of the SRS: |
| + | |
| + | **Functional requirements** — derived from the *"I want [goal]"* part: |
| + | - User story: *"As a teacher, I want to mark student attendance..."* |
| + | - Functional requirement: *"The system shall allow teachers to select a class and mark each student as present or absent."* |
| + | |
| + | **Non-functional requirements** — derived from the *"so that [benefit]"* part and acceptance criteria: |
| + | - Benefit: *"...so that I can report to administration."* |
| + | - Non-functional requirement: *"Attendance records shall be retrievable within 2 seconds of a teacher's request."* |
| + | |
| + | ::: success |
| + | **Tracing requirements back to user stories** |
| + | |
| + | In your SRS, label each requirement with the user story it came from (e.g. *"[US3]"*). This traceability shows examiners that your requirements came from real data collection, not guesswork — and it is exactly the kind of evidence that separates 9–10 responses from 7–8. |
| + | ::: |
| + | |
| + | --- |
| + | |
| + | ## MoSCoW and your SRS scope statement |
| + | |
| + | The Won't Have list becomes the **exclusions** section of your SRS scope. A well-formed scope statement: |
| + | |
| + | ``` |
| + | The [Project Name] will provide [Must Have features] (Must Have). |
| + | The system will aim to include [Should Have features] (Should Have). |
| + | [Could Have features] may be included if time permits (Could Have). |
| + | |
| + | The following are explicitly out of scope for Version 1: |
| + | - [Won't Have feature 1] — reason |
| + | - [Won't Have feature 2] — reason |
| + | ``` |
| + | |
| + | This structure prevents scope creep and gives your client a clear record of what was agreed. |
| + | |
| + | --- |
| + | |
| + | ## Check Your Understanding |
| + | |
| + | Answer in your head first, then click the spoiler to check. |
| + | |
| + | **1.** A student writes: *"As a user, I want to log in so that I can access the system."* What is the **biggest** problem with this story? |
| + | *(a) it is too long · (b) the role is too vague · (c) there is no acceptance criteria · (d) "log in" is a technical term* |
| + | |
| + | >! **(b) the role is too vague.** "User" tells us nothing about who this person is, what context they work in, or whether their login needs are different from other roles. Every other issue (no acceptance criteria, technical language) is secondary — a vague role means you cannot derive meaningful requirements. Fix: replace "user" with the specific role (student, teacher, administrator). |
| + | |
| + | **2.** A student assigns **Must Have** to all eight of their user stories. What does this tell you about their scope planning? |
| + | *(a) they have a very focused project · (b) they probably haven't thought critically about what is truly essential · (c) this is correct — every story matters · (d) they need more user stories* |
| + | |
| + | >! **(b) they probably haven't thought critically about what is truly essential.** If everything is Must Have, MoSCoW is doing no work. A genuine Must Have is something the project *fails without*. Most projects have 3–5 true Must Haves. The rubric explicitly expects a mix of all four MoSCoW categories — students with all Must Haves are likely to lose marks for scope planning. |
| + | |
| + | **3.** A student writes: *"Won't Have: Parent portal — I couldn't find time to build it."* What is wrong with this Won't Have? |
| + | *(a) parent portals are always Must Have · (b) Won't Have should only be used for technical impossibilities · (c) the reason doesn't show deliberate scope planning · (d) nothing — this is fine* |
| + | |
| + | >! **(c) the reason doesn't show deliberate scope planning.** Won't Have is a *deliberate* scope exclusion, not a de-facto one. The reason should explain a *decision*: "out of scope for this user group", "requires payment integration planned for Version 2", "agreed with client as future enhancement". "I couldn't find time" reads as oversight, not planning. |
| + | |
| + | **4.** Which part of a user story most directly generates **non-functional requirements** in your SRS? |
| + | *(a) the role · (b) the goal · (c) the benefit · (d) the acceptance criteria* |
| + | |
| + | >! **(c) the benefit.** The "so that [benefit]" clause captures *why* the user wants the feature — and the qualities that make that benefit possible (speed, reliability, portability, usability) are exactly what non-functional requirements describe. The goal generates functional requirements; the benefit generates non-functional ones. |
| + | |
| + | --- |
| + | |
| + | ## See also |
| + | |
| + | - [Data Collection Methods](/sd/C02/Data%20Collection%20Methods) — the four methods and how to choose your mix; connects to the "from user stories to data collection" section above |
| + | - [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) — how to use user story roles to find every entity for your context diagram; includes Gherkin acceptance criteria worked example |
| + | - [Explaining vs Describing Your Data Collection](/sd/C02/Explaining%20vs%20Describing%20Your%20Data%20Collection) — the rubric difference between 7–8 and 9–10 for Indicator 1; directly relevant once you have your user stories and methods aligned |
| + | - [Essential Terms](/sd/C02/Essential%20Terms) — definitions of functional/non-functional requirements, scope, constraints, and other SRS terms |
| + | |
| + | --- |
| + | |
| + | ← Back to [C02 Home](/sd/C02/C02-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |