Blame
|
1 | > **DRAFT** — under teacher review. |
||||||
| 2 | ||||||||
| 3 | # Building Your C2-1 Poster |
|||||||
| 4 | ||||||||
| 5 | Hamilton College · Year 12 · 2026 |
|||||||
| 6 | ||||||||
| 7 | 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. |
|||||||
| 8 | ||||||||
| 9 | > [!TIP] |
|||||||
| 10 | > **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. |
|||||||
| 11 | ||||||||
| 12 | --- |
|||||||
| 13 | ||||||||
| 14 | ## 1. Poster structure — the five required sections |
|||||||
| 15 | ||||||||
| 16 | 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). |
|||||||
| 17 | ||||||||
| 18 | | Section | What goes there | Word-count guide | Band 9–10 phrasing example | |
|||||||
| 19 | |---|---|---|---| |
|||||||
| 20 | | **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."* | |
|||||||
| 21 | | **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."* | |
|||||||
| 22 | | **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. | |
|||||||
| 23 | | **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. | |
|||||||
| 24 | | **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."* | |
|||||||
| 25 | ||||||||
| 26 | ::: info |
|||||||
| 27 | **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. |
|||||||
| 28 | ::: |
|||||||
| 29 | ||||||||
| 30 | --- |
|||||||
| 31 | ||||||||
| 32 | ## 2. What labelling actually looks like |
|||||||
| 33 | ||||||||
| 34 | 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. |
|||||||
| 35 | ||||||||
| 36 | Here is what the difference looks like. Both columns come from the same interview with a client: |
|||||||
| 37 | ||||||||
| 38 | | Raw interview note (what you wrote at the time) | Labelled version (what goes on the poster) | |
|||||||
| 39 | |---|---| |
|||||||
| 40 | | *"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]` | |
|||||||
| 41 | | *"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]` | |
|||||||
| 42 | | *"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]` | |
|||||||
| 43 | | *"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]` | |
|||||||
| 44 | | *"There are about 180 students who'd use this"* | *"~180 potential users"* `[Survey Q3 · quant · scope: user base size ≤ 200]` | |
|||||||
| 45 | ||||||||
| 46 | ::: success |
|||||||
| 47 | **What your label should contain** (for each data point): |
|||||||
| 48 | ||||||||
| 49 | 1. **Source** — method + which instance (Interview-1, Survey Q3, Observation-2, Report: IT-device-list) |
|||||||
| 50 | 2. **Type** — qualitative or quantitative |
|||||||
| 51 | 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) |
|||||||
| 52 | 4. **SRS category** — which SRS section it informs (see §3) |
|||||||
| 53 | ::: |
|||||||
| 54 | ||||||||
| 55 | 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. |
|||||||
| 56 | ||||||||
| 57 | --- |
|||||||
| 58 | ||||||||
| 59 | ## 3. Findings → SRS mapping |
|||||||
| 60 | ||||||||
| 61 | 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. |
|||||||
| 62 | ||||||||
| 63 | ::: warning |
|||||||
| 64 | **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. |
|||||||
| 65 | ::: |
|||||||
| 66 | ||||||||
| 67 | 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. |
|||||||
| 68 | ||||||||
| 69 | | Example data point | Method | SRS category | How it shapes the SRS | |
|||||||
| 70 | |---|---|---|---| |
|||||||
| 71 | | 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. | |
|||||||
| 72 | | 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. | |
|||||||
| 73 | | 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). | |
|||||||
| 74 | | 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. | |
|||||||
| 75 | | 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. | |
|||||||
| 76 | | 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. | |
|||||||
| 77 | | 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. | |
|||||||
| 78 | | ~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. | |
|||||||
| 79 | ||||||||
| 80 | ::: info |
|||||||
| 81 | **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". |
|||||||
| 82 | ::: |
|||||||
| 83 | ||||||||
| 84 | --- |
|||||||
| 85 | ||||||||
| 86 | ## 4. Station defence — what the teacher is listening for |
|||||||
| 87 | ||||||||
| 88 | 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: |
|||||||
| 89 | ||||||||
| 90 | 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. |
|||||||
| 91 | 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." |
|||||||
| 92 | 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. |
|||||||
| 93 | ||||||||
| 94 | ::: warning |
|||||||
| 95 | **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. |
|||||||
| 96 | ::: |
|||||||
| 97 | ||||||||
| 98 | --- |
|||||||
| 99 | ||||||||
| 100 | ## Check Your Understanding |
|||||||
| 101 | ||||||||
| 102 | Answer in your head first, then click the spoiler to check. |
|||||||
| 103 | ||||||||
| 104 | **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? |
|||||||
| 105 | ||||||||
| 106 | >! **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. |
|||||||
| 107 | ||||||||
| 108 | **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? |
|||||||
| 109 | ||||||||
| 110 | *(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* |
|||||||
| 111 | ||||||||
| 112 | >! **(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. |
|||||||
| 113 | ||||||||
| 114 | **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? |
|||||||
| 115 | ||||||||
| 116 | *(a) functional requirements · (b) constraints · (c) technical environment · (d) user characteristics* |
|||||||
| 117 | ||||||||
| 118 | >! **(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. |
|||||||
| 119 | ||||||||
| 120 | **4.** During your station defence, the teacher asks: *"Why did you use a survey rather than running more interviews?"* Which answer reaches 9–10? |
|||||||
| 121 | ||||||||
| 122 | *(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."* |
|||||||
| 123 | ||||||||
| 124 | >! **(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. |
|||||||
| 125 | ||||||||
| 126 | --- |
|||||||
| 127 | ||||||||
| 128 | ## See also |
|||||||
| 129 | ||||||||
| 130 | - [Data Collection Methods](Data%20Collection%20Methods.md) — the four methods, their strengths/weaknesses, and how to choose a justified mix |
|||||||
| 131 | - [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 |
|||||||
| 132 | - [Essential Terms](Essential%20Terms.md) — definitions of qualitative, quantitative, SRS categories |
|||||||
| 133 | - [Context Diagram](Context%20Diagram.md) — the entities and data flows you identified during data collection anchor this diagram |
|||||||
| 134 | - [What Is an Entity](What%20Is%20an%20Entity.md) — your data sources may themselves be entities on the context diagram |
|||||||
| 135 | ||||||||
| 136 | --- |
|||||||
| 137 | ||||||||
| 138 | ← Back to [C02 Hub](C02-home.md) |
|||||||
