The change
Start with the capability, not the technology.
The project is being assessed against one core change request: enable historical analysis of Queensland traffic events and make useful patterns quickly explorable in a web interface.
The review deliberately separates the business need from implementation choices. A pipeline, database, web framework or deployment method may support the change, but none of those technologies are the requirement by themselves.
The technical prototype already existed. This case study applies a structured BA review to formalise the need, test the scope, establish traceability and identify what still requires verification before further development.
Context
Who interacts with the solution, and where does the boundary sit?
The context model separates the source of traffic information from the people who analyse it, the people who consume selected results, and the components responsible for keeping the platform available.
Context diagram
Current state & gap
The problem is not access to live traffic information. It is retaining and analysing it over time.
The current-state review compares what is already available with the capability needed for historical analysis. The important gaps are persistent collection and storage, programmatic analysis, and a clear way to expose selected results.
Current state, future state and gap analysis
The existing prototype includes notifications. During requirements refinement that capability is being reassessed because it does not directly support the current core change request. It is not being used to justify the primary business outcome simply because it already exists.
Requirements
Eight requirements currently define the working scope.
The matrix is still a working artefact: all verification and validation fields remain open. The summary below keeps the case study readable while the full traceability matrix is available as supporting evidence.
R-001Historical retention
Use case: The Data Analyst can access traffic events from the previous 30 days after they are no longer available from the live source.
Acceptance: Unique events remain queryable across a continuous 30-day period after disappearing from the source.
R-002Automated collection
Use case: The system collects traffic-event information without manual intervention.
Acceptance: New traffic-event observations are collected automatically at the agreed interval throughout the collection period.
R-003Event identity vs observations
Use case: The Data Analyst can count and compare events without repeated observations being counted as separate incidents.
Acceptance: Repeated observations with the same source event identifier remain associated with one event while state changes can still be retained.
R-004Queryable historical analysis
Use case: The Data Analyst can analyse traffic events by time, suburb or location, and event type.
Acceptance: Stored data can be filtered or grouped across those dimensions and return consistent counts.
R-005Public metrics
Use case: A public viewer can quickly understand selected traffic patterns through the website.
Acceptance: Selected metrics are presented in plain language without requiring access to the underlying dataset.
R-006Time since last crash
Use case: A public viewer can see how long it has been since the most recent selected traffic event.
Acceptance: Elapsed time is calculated from the latest qualifying stored event and presented in a human-readable form.
R-007Analysis-ready data
Use case: The Data Analyst can obtain retained data in a structure suitable for further analysis.
Acceptance: Historical records can be retrieved as consistent tabular data without manual restructuring.
R-008Collection completeness
Use case: The analyst can determine when historical data may be incomplete because collection failed.
Acceptance: Failed collection periods are identifiable and cannot silently appear as valid zero-event periods.
Solution definition
A deliberately simple view of what must exist to deliver the capability.
The high-level solution remains technology-agnostic: obtain traffic events, retain them, process them for analysis, and make the result available to the analyst and public viewer.
High-level solution definition
From requirements to delivery
Trace the requirement to an existing capability, then prove it.
This is retrospective traceability, not a claim that every requirement existed before the first line of code. The purpose is to identify what the existing prototype already supports, what evidence exists, and what still has to be tested.
| Requirement | What exists | Implementation decision | Evidence |
|---|---|---|---|
| R-001 | Historical traffic-event storage | Persist events after they disappear from the live source | Database / sample historical records |
| R-002 | Automated data collection | Scheduled collection from QLD Traffic source | Repository / running deployment |
| R-003 | Event vs observation handling | Use source event identifiers to prevent repeated observations being counted as new events | Database records / query result |
| R-004 | Snapshot export and analysis notebook | Export the database to CSV, analyse it in Python and publish the results as a report | 29 Sep 2026 report |
| R-005 | Public analytical interface | Expose selected metrics through the website | Live prototype |
| R-006 | Time since latest crash | Show the latest crash's start time in Brisbane time and the time elapsed since | Live prototype |
| R-007 | Analysis-ready data | Store records in structured fields suitable for querying and dataframes | Database / query example |
| R-008 | Not implemented | Deferred: low value relative to effort at project close. The worker logs failed polls and retries, but nothing is stored | None |
R-004 and R-006 were delivered after the initial review. R-008 was deferred: recording each collection cycle would need changes to the database and the collector, and with the project closing after 15 days of data, the effort outweighs the benefit. Gaps in collection cannot currently be told apart from quiet periods, so this is the first item to revisit if the project reopens.
Current status
The analysis is public before the case study is finished.
The next stage is not another feature sprint. It is verification: execute the defined test cases, capture actual outcomes, resolve failures, then complete UAT and assess whether the original change request has actually been satisfied.
This page will evolve as those stages are completed. The aim is to make the reasoning, evidence and unresolved work visible rather than present an unfinished project as a finished one.