2026-04-26 08:55:54lisa:
Refocus C03 Analytical Tools page on documentation, not creation
Rubric distinction: C02 creates the analytical tools (UCD/CD/DFD);
C03 documents them inside the SRS. Page now covers the four-part
documentation pattern (purpose, changes, diagram, descriptive tables),
the per-tool tables (Use Cases Description, External Entities, Data
Dictionary), and the traceability matrix. Links to C02 page for
redrawing/notation skill.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
sd/C03/Analytical Tools Template Guide.md ..
@@ 1,86 1,93 @@
> **DRAFT** — under teacher review.
-
# Analytical Tools Template — UCD, Context Diagram, and DFD
+
# Documenting Analytical Tools in the SRS — UCD, CD, DFD
Hamilton College · Year 12 · 2026
-
When you update your analytical tools in C3-1 (Step 1), you need to reproduce a Use Case Diagram, a Context Diagram, and a Data Flow Diagram. Setting up the notation from scratch each time costs 15–20 minutes and introduces layout errors. This page explains what is in the pre-labelled Excalidraw template and how to use it.
+
In **C02** you *created* the Use Case Diagram, Context Diagram, and Data Flow Diagram (the analytical tools). In **C03** you *document* those diagrams inside your formal SRS — that's a different job. C03's rubric reads "Documents the analytical tools" — the diagrams are evidence, but the tables, descriptions, and traceability around them are what the marker reads. This page is a guide to the documentation pattern.
---
-
## What the template contains
+
## Don't redraw — refresh and reference
-
The Excalidraw file (`C03-Analytical-Tools.excalidraw`) has three pre-built diagram skeletons on a single canvas, each with placeholder nodes labelled by notation role:
+
If the diagram still tells the truth, reuse it. If C02 work has shifted (new actor, renamed data store, added flow) update the existing diagram rather than starting over. The C02 page covers the drawing/notation skill itself:
-
| Diagram | Pre-built elements |
-
|---|---|
-
| **Use Case Diagram (UCD)** | System boundary box; actor stick figures (primary user, secondary user); labelled oval placeholders for use cases; `«include»` and `«extend»` relationship stubs |
-
| **Context Diagram** | Central process circle (labelled with your system name placeholder); external entity rectangles on each side; labelled data-flow arrows in and out |
-
| **Data Flow Diagram (DFD)** | Level 1 layout with process circles, data store open rectangles, external entity rectangles, and directional arrow stubs; numbered process placeholders |
+
- [Excalidraw Diagram Starters (C02)](/sd/C02/Excalidraw%20Diagram%20Starters) — pre-framed canvases for UCD / Context Diagram / DFD with correct shape vocabulary.
-
All three diagrams use the standard Yourdon–DeMarco notation that VCAA markers expect.
+
In C03 the diagram is a *figure* in your SRS, not the final product. The marks live in the explanatory text around it.
-
---
+
## The four-part documentation pattern
-
## How to use it
+
Every analytical-tool section in your C03 SRS follows the same four-part pattern. `C031-Step-1-Analytical-Tools-Guide.md` lays this out — work through it for each of the three tools.
-
1. **Download the file** — ask your teacher for `C03-Analytical-Tools.excalidraw`.
-
2. **Open in Excalidraw** — go to [excalidraw.com](https://excalidraw.com) and drag the file onto the canvas, or use the **Open** menu.
-
3. **Replace placeholders** — click each labelled placeholder and type your own system name, actor names, use cases, data stores, and process names.
-
4. **Add or remove elements** — copy a placeholder shape to add more use cases, or delete extras. Keep the notation style consistent (don't mix shapes between diagram types).
-
5. **Export** — when done, export as PNG or SVG to paste into your SRS document.
+
| Part | What it does | Common omission |
+
|---|---|---|
+
| **Purpose** | One paragraph on what this diagram shows and why it's in the SRS | Stating the title without the *why* — "this is the use case diagram" is not a purpose statement |
+
| **Changes from previous version** | Bulleted list of every meaningful edit since C02 (new actor, merged use cases, renamed entity, split process, etc.) | Writing "no changes" when in fact the SRS now has a constraint or scope item that contradicts the diagram |
+
| **The diagram itself** | Inserted as an image (PNG/SVG export from Excalidraw) | Embedding a screenshot at the wrong resolution; making it tiny |
+
| **Descriptive tables** | The structured detail tables — see below per tool | Leaving template placeholders (`[Entity1]`, `[Description]`) in the submitted SRS |
---
-
## What to notice when you update
+
## Per-tool descriptive tables
-
Coming back to these diagrams from C02, check:
+
These are the tables your SRS must contain for each diagram. Fill the templates in `C031-Step-1-Analytical-Tools-Guide.md` directly — don't paraphrase the structure.
-
- **New actors**: has your scope change added a new type of user? Add them to the UCD.
-
- **New data flows**: does your updated scope require new data in or out? Update the Context Diagram arrows.
-
- **New processes**: does the DFD reflect how data now moves through the updated system?
+
### Use Case Diagram (UCD)
-
The rubric at 7–8 band requires diagrams that accurately reflect your current SRS — not your C02 version. Change what has changed; don't just copy-paste from C02.
+
**Use Cases Description**
-
---
+
| Use Case ID | Use Case Name | Description | Primary Actor | Preconditions | Basic Flow | Alternative Flows | Postconditions |
+
|---|---|---|---|---|---|---|---|
+
+
**Tip:** populate the Basic Flow column with numbered steps, not a single sentence. Rubric language at 9–10 wants *granularity* — the marker is checking that each use case has been thought through, not just named.
-
## Notation quick reference
+
### Context Diagram (CD)
-
### Use Case Diagram
+
**External Entities Description**
-
| Symbol | Meaning |
-
|---|---|
-
| Stick figure | Actor (a person or external system that interacts with yours) |
-
| Oval | Use case (a goal the actor achieves using the system) |
-
| Rectangle | System boundary (what is inside vs outside the scope) |
-
| `«include»` arrow | Use case A always includes use case B |
-
| `«extend»` arrow | Use case B optionally extends use case A |
+
| Entity Name | Description | Interactions with System |
+
|---|---|---|
-
### Context Diagram
+
**Tip:** the Interactions column should split *Sends* and *Receives* (one bullet list each). Otherwise it reads as a single arrow when in reality each entity has bidirectional flows.
-
| Symbol | Meaning |
-
|---|---|
-
| Circle | The system (one only — this is a Level 0 DFD) |
-
| Rectangle | External entity (person, group, or system outside your scope) |
-
| Arrow with label | Data flow (label = what data moves, direction = which way) |
+
### Data Flow Diagram (DFD)
-
### Data Flow Diagram (Level 1)
+
**Data Dictionary**
-
| Symbol | Meaning |
-
|---|---|
-
| Circle | Process (transforms data; numbered: 1.0, 2.0…) |
-
| Open rectangle | Data store (where data is held; labelled D1, D2…) |
-
| Rectangle | External entity (same as context diagram) |
-
| Arrow with label | Data flow |
+
| Data Flow / Store Name | Description | Composition | Source | Destination |
+
|---|---|---|---|---|
+
+
**Tip:** Composition is where most students lose marks — list the actual data elements (e.g. *Username, Password*), not just "user credentials". This column is what proves the DFD has been thought through at the data level, not just the box level.
---
+
## Traceability Matrix
+
+
The C031 task ends with a traceability matrix: every functional requirement maps to use cases, external entities, and DFD elements. This is the matrix the C1-3 interview question *"how do we know this requirement is in the design?"* expects you to point at.
+
+
| Requirement ID | Requirement Description | Related Use Cases | Related External Entities (CD) | Related DFD Elements |
+
|---|---|---|---|---|
+
+
A good traceability matrix has **at least one entry per row in your functional requirements list** — a requirement that doesn't trace to anything is a requirement you can't evidence.
+
+
## Common mistakes at this checkpoint
+
+
- **Submitting C02 diagrams unchanged with no Changes-from-Previous section.** The marker reads this as "no thought given to whether the analytical tools still match the requirements".
+
- **Treating tables as optional.** The diagram is the figure; the tables are the evidence. C03 is graded on the tables.
+
- **Leaving template placeholders.** `[Entity1]`, `[List data flows]`, `[Description]` in the submitted document.
+
- **No traceability matrix.** Or a matrix that only links to use cases (omitting CD entities and DFD elements).
+
+
## Why VCAA cares
+
+
C03's rubric explicitly asks for *"Documents the analytical tools"* — and the level descriptors lean on completeness and rigour of documentation, not artistic quality of diagrams. A clean DFD with no data dictionary will mark lower than a slightly messy DFD with a thorough data dictionary.
+
## See also
-
- [Functional vs Non-Functional Requirements](/sd/C03/Functional%20vs%20Non-Functional%20Requirements) — requirements that feed into your diagrams
-
- [Scope vs Constraints](/sd/C03/Scope%20vs%20Constraints) — what determines the system boundary in your UCD and Context Diagram
-
- C03 Resources: [external reading and videos](/sd/Resources/C03-Resources)
+
- [Excalidraw Diagram Starters (C02)](/sd/C02/Excalidraw%20Diagram%20Starters) — for redrawing or refreshing diagrams.
+
- [Context Diagram vs Data Flow Diagram](/sd/C02/Context%20Diagram%20vs%20Data%20Flow%20Diagram) — disambiguation if you're refreshing.
+
- [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) — for the External Entities table.
---
-
← Back to [C03 Home](/sd/C03/C03-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
+
← Back to [C03 — Skills in Documenting a Software Requirements Specification](/sd/C03/C03-home)
