Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 The lab as a system"]
N2["16.2 Interfaces"]
N3["16.3 Requirements traceability"]
N4["16.4 Trade-offs"]
N5["16.5 Stakeholders"]
N6["16.6 Life cycle"]
N7["16.7 Human factors"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 The lab as a system"]
N2["16.2 Interfaces"]
N3["16.3 Requirements traceability"]
N4["16.4 Trade-offs"]
N5["16.5 Stakeholders"]
N6["16.6 Life cycle"]
N7["16.7 Human factors"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 The lab as a system]
|
v
[16.2 Interfaces]
|
v
[16.3 Requirements traceability]
|
v
[16.4 Trade-offs]
|
v
[16.5 Stakeholders]
|
v
[16.6 Life cycle]
|
v
[16.7 Human factors]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) view a forensic lab as a system of people, processes and tools; (2) define interfaces between stages; (3) trace requirements through the system; (4) manage trade-offs.
16.1 The lab as a system
Evidence moves from seizure to intake, imaging, examination, review, reporting and storage. Each stage has inputs, outputs, owners and failure modes. ISO/IEC 27043 describes investigation processes in a similar staged way, from readiness through to closure.
Failure modes differ by stage. At intake an item can be mislabelled. At imaging a write blocker can be skipped. In examination a parser can be out of date, and in storage a disk can fail. Priya draws the flow as boxes and arrows, writes the most likely failure and its control under each box, and then asks Hugo which control he has actually seen fail. His answers reorder her priorities.
16.2 Interfaces
The output of imaging (an image file, its hash, an acquisition log) is the input to examination. Defining that interface precisely — formats, required fields — prevents errors when work changes hands.
Northfield's imaging output had been a folder whose contents depended on the tool used. Priya defines a manifest with fixed fields: item ID, image file names, hash algorithm, hash value, tool, version, examiner and start and end times. Examination refuses to begin until the manifest validates. A missing field, such as the algorithm name, blocks the handover instead of being guessed at later.
16.3 Requirements traceability
A traceability matrix links each requirement (e.g. "every image verified before examination") to the design element that meets it and the test that shows it.
One row reads: R-07, every image verified before examination; design, the examination queue only accepts items whose verification status is 'match'; test, T-21 submits an unverified item and expects a refusal. When an auditor asks how the lab ensures verification, the matrix answers with a test result, not a promise. Rows with no test are visible gaps.
16.4 Trade-offs
Faster triage versus thoroughness; central storage versus local workstations; vendor tools versus in-house scripts. Priya records each decision with its reason and the alternatives rejected.
For central versus local storage, Priya notes that central storage simplifies backups and access logging but needs a fast network, while local workstations are quick but scatter evidence. She chooses central storage with local cache folders that are cleared after each case, records the network upgrade this requires, and lists the conditions under which the decision should be revisited.
16.5 Stakeholders
Examiners, managers, prosecutors, defence experts and auditors want different things. A good design states which needs it serves and which it does not.
Examiners want speed and fewer manual steps. Managers want throughput figures. Prosecutors want clear reports, and defence experts want enough detail to test the work. Auditors want evidence that procedures were followed. Priya's design states that EvidenceDesk serves integrity and traceability first, speed second, and does not try to replace the case-management system, which keeps the scope realistic.
16.6 Life cycle
Systems age: formats change, drives grow, staff turn over. The design includes review points.
Review points are scheduled annually and also triggered by events, such as a new evidence format arriving in volume, a key staff member leaving, or a major operating-system release. Each review checks whether the original requirements still hold. A system designed for laptops may need rethinking when phone and cloud evidence dominate intake, and noticing that early is cheaper than a crisis rebuild. Each review ends with a dated note, even when nothing changes.
16.7 Human factors
Interfaces that make the safe action easy — verification as a default step, not an optional button — reduce errors.
If verification is a separate button, busy examiners will sometimes skip it. If the import step runs verification automatically and refuses to continue on mismatch, skipping becomes impossible without a deliberate, logged override. Priya also designs error messages that say what to do next, such as 're-image the item' or 'contact the evidence officer', rather than simply 'hash error'. Overrides need a reason typed in by the examiner.
Failure modes
For each stage Priya asks what could go wrong: wrong item imaged, hash recorded incorrectly, image stored on the wrong share. Each failure mode gets a detection method and a mitigation, listed in a simple table reviewed with examiners, who add two failure modes she missed.
Worked example
Priya draws Northfield's flow and finds the handover from imaging to examination uses emailed spreadsheets. She defines a structured record (item ID, image path, SHA-256, tool version, examiner, time) and a check that blocks examination until the hash is verified.
Synthetic case. The flow is invented.
Errors and limits
A system diagram simplifies; walk the real process with staff before trusting it.
Exercises
- EX046 — Interface fields. List the fields of the imaging-to-examination record. Rubric: 3 = item ID, path, SHA-256, tool version, examiner, time; 2 = four; 1 = two; 0 = none.
- EX047 — Traceability. What does a traceability matrix link? Rubric: 3 = requirement, design element, test; 2 = two; 1 = one; 0 = none.
- EX048 — Safe default. Give an example of making the safe action easy. Rubric: 3 = verification as default/blocking step; 2 = vague; 1 = training only; 0 = none.
Synthesis
Treat the lab as a system with defined interfaces, traced requirements, recorded trade-offs and safe defaults.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →