DRAFT — under teacher review.

Documenting Analytical Tools in the SRS — UCD, CD, DFD

Hamilton College · Year 12 · 2026

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.


Don't redraw — refresh and reference

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:

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

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.

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

Per-tool descriptive tables

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.

Use Case Diagram (UCD)

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.

Context Diagram (CD)

External Entities Description

Entity Name Description Interactions with System

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.

Data Flow Diagram (DFD)

Data Dictionary

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


← Back to C03 — Skills in Documenting a Software Requirements Specification