Chapter 44 — Engineering capstone: design and build
Lesson map
Lesson 44 published. Map, example, EX087.
flowchart TD
N0["Learning outcomes and connection"]
N1["44.1 Capstone brief synthetic"]
N2["44.2 Design dossier"]
N3["44.3 Scoping for buildability"]
N4["44.4 Implementation discipline"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX087"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["44.1 Capstone brief synthetic"]
N2["44.2 Design dossier"]
N3["44.3 Scoping for buildability"]
N4["44.4 Implementation discipline"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX087"]
[Learning outcomes and connection]
|
v
[44.1 Capstone brief synthetic]
|
v
[44.2 Design dossier]
|
v
[44.3 Scoping for buildability]
|
v
[44.4 Implementation discipline]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX087]
Learning outcomes and connection
After this chapter you can (1) scope a capstone response system that is buildable in the available time; (2) produce a design dossier linking requirements, architecture, interfaces and tests; (3) implement the bounded system with reproducible builds and synthetic data; and (4) maintain a risk register and traceability from design to test. It integrates Chapters 20–43 and prepares Chapters 45–50.
44.1 Capstone brief (synthetic)
Build a case-intake and evidence-preservation service for a synthetic multi-service organisation (the HVSS model or your own, clearly labelled). Minimum scope: ingest from at least two synthetic sources with different identifiers; validation and quarantine; content-addressed evidence store with anchored manifest; case workflow with approval gate, timeout escalation and audit trail; one scoped containment action against a simulated target with dry run and reversal; metrics for latency, completeness and integrity. Out of scope: real systems, real data, production deployment. Each scope item corresponds to an earlier lab, from the Lab 4 quarantine and Lab 19 manifest to the Lab 31 workflow.
44.2 Design dossier
The dossier contains: context and constraints (Chapter 20); requirements and service objectives with IDs (Chapter 21); data model and lineage (Chapter 22); threat and failure analysis with cut sets (Chapter 23); architecture with planes, zones and interfaces (Chapters 18, 26); control designs (Chapter 27); verification plan mapping every requirement to a test (Chapters 30, 40); operations sketch (Chapter 37); risk register; and a traceability matrix. Keep it concise and current; it is a working document, versioned with the code. In the HVSS-style extract below, risk entry K4 shows how the dossier and the thesis connect.
44.3 Scoping for buildability
A capstone fails more often from scope than from difficulty. Use a walking skeleton: the thinnest end-to-end path — one source, one validation rule, one stored item, one case, one approval, one action — working and tested in the first weeks; then widen. Track dependencies explicitly; anything external (a cloud account, a mock IdP) is a risk with an owner and a fallback (a local stub).
For the HVSS-style capstone, the walking skeleton is one synthetic identity-provider feed and the Lab 4 severity rule. It continues through one content-addressed item, one case through the approval gate, and one dry-run disable of a simulated account. The mock IdP is the obvious external dependency, which is why risk K4 names it.
44.4 Implementation discipline
Version control from day one; reproducible environment (pinned dependencies, a script that builds from scratch); synthetic data generators with seeds; tests run on every change; no secrets in the repository; changes linked to requirement IDs in commit messages. The SSDF practices scale down to a student project: protect the build, review changes, record provenance of dependencies. In the HVSS-style capstone, a commit fixing AT-02b would therefore name R2 in its message, so the week-8 traceability check can see which requirement a change touched.
44.5 Worked example: an HVSS-style capstone extract
Requirement R2 (no containment without approval by another role) traces to: workflow state machine (component), approval interface (workflow → controller), tests AT-02a (approval by requester rejected), AT-02b (expiry without approval → no action), AT-02c (approved action executes once). Risk register entry K4: "mock IdP behaviour differs from real providers in token revocation semantics — limits validity of containment-verification results"; owner: student; mitigation: document provider semantics from public documentation and test against two mock behaviours; residual: external-validity limit stated in the thesis (Chapter 49).
Traceability check at week 8 found three requirements without tests (R9 retention, R11 metrics export, R14 cross-tenant read denial) and two tests without requirements (performance smoke tests — a missing performance requirement was added).
44.6 Errors and limits
- Scope set by ambition rather than time.
- Dossier written at the end.
- Untraceable tests and untested requirements.
- External dependencies without fallbacks.
The week-8 traceability check in the HVSS-style extract found the third error twice. R9, R11 and R14 had no tests, and the performance smoke tests had no requirement until one was written. Finding that at week 8 rather than at the end is the case for a living dossier. Risk K4 shows the fourth error being avoided, because the mock IdP is recorded with an owner, a mitigation and a stated limit on validity.
Exercises — chapter 44
EX087 — Walking skeleton. Objective: plan the first increment. Inputs: the capstone brief. Steps: define the walking skeleton's components, the single end-to-end test that proves it and the three widening increments that follow, each with its acceptance test. Expected evidence: plan. Rubric: 3 = thin end-to-end path with a real test and sensible increments; 2 = partial; 1 = component list only; 0 = none.
EX088 — Traceability matrix. Objective: check coverage. Inputs: ten requirements of your capstone (or R1–R10 invented for HVSS). Steps: build the matrix requirement → component → interface → test → status; compute coverage and list gaps with actions. Expected evidence: matrix and gap list. Rubric: 3 = complete with coverage figure and actions; 2 = partial; 1 = list; 0 = none.
Chapter synthesis
The capstone builds a bounded, traceable response system: scoped for buildability, started as a walking skeleton, documented in a living dossier, implemented with reproducible discipline and checked continuously for requirement-to-test coverage.
Continue studying — chapter 44 of 50
← Chapter 43 · Course chapter index · Chapter 45 →
Continue to the next authored lesson.