◇ OpenCyber Academy
Engineering · Chapter 16 · English

Chapter 16 — Systems engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 16 — Systems engineering

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Testable requirements"]
  N2["16.2 Traceability"]
  N3["16.3 Interfaces"]
  N4["16.3b Interface SLAs"]
  N5["16.1b Glossary for stakeholders"]
  N6["Practice note"]
  N7["Synthesis"]
  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 Testable requirements"]
  N2["16.2 Traceability"]
  N3["16.3 Interfaces"]
  N4["16.3b Interface SLAs"]
  N5["16.1b Glossary for stakeholders"]
  N6["Practice note"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 Testable requirements]
    |
    v
[16.2 Traceability]
    |
    v
[16.3 Interfaces]
    |
    v
[16.3b Interface SLAs]
    |
    v
[16.1b Glossary for stakeholders]
    |
    v
[Practice note]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) write requirements that are testable; (2) trace a requirement to an artefact; (3) manage interfaces between TrackScope, FindingsDesk and PulseMap.

16.1 Testable requirements

"The system should be secure" is not a requirement. "TrackScope rejects any target outside the signed CIDR/port set and records the reason code" is. Each requirement needs an id, a shall-statement, a verification method (test, inspection, analysis) and an owner.

Shall-statements with ids turn arguments into checks. Verification method and owner stop requirements that nobody can prove and nobody maintains. Sam writes the reject-and-record behaviour of TrackScope as requirement TS-SCOPE-1 with a unit test as its method. Anything weaker is rewritten before design starts.

16.2 Traceability

A simple matrix: requirement → design element → test case → engagement evidence. When a finding shows a scope bypass, you know which requirement and test failed. Without the matrix, post-mortems become blame.

When a scope bypass appears, the matrix names the broken test and the requirement it was meant to enforce. Blame cultures grow in the gap where that link is missing. Sam updates the matrix in the same change as the code so the link cannot rot for a week. Post-mortems open on that row first.

16.3 Interfaces

TrackScope emits allow/deny events; FindingsDesk consumes finding drafts; PulseMap consumes technique tags. Agree JSON schemas and version them. An interface change is a release, not a silent edit.

Synthetic case — Riverstone Transit. Requirement R-17 "deny reasons are immutable after insert" traced to the FindingsDesk append-only event table and test T-17 that tries an UPDATE and expects failure.

Silent schema edits break stop-condition pages at the worst moment. Versioned JSON contracts make breakage a deliberate release with a migration note. Each consumer declares the versions it accepts. Sam's integration tests publish a sample event at each supported version.

16.4 Errors and limits

Traceability matrices rot if not updated in the same PR as the code. Keep them next to the code.

A matrix in a slide deck dies first. Keeping it beside the code means the same review that merges a feature sees the traceability update. Sam fails CI if a new requirement id lacks a test row. Slide-only matrices are rejected in review. Owners get a weekly mail if their rows lag the merged code, and the engagement cannot cite a requirement that has no current test.

16.3b Interface SLAs

Internal SLAs between services matter: TrackScope may need FindingsDesk to accept an event within N seconds during a stop condition. Write that as a requirement with a synthetic load test. Without it, stop-condition pages arrive after the human already called the client.

A stop-condition event that arrives late is an event that failed its purpose. Synthetic load tests prove FindingsDesk can accept bursts when TrackScope denies many targets at once. Writing the latency budget as a requirement makes it visible in planning, not only in an outage. Sam pages on SLA breaches during exercises so the path is rehearsed.

16.1b Glossary for stakeholders

Maintain a one-page glossary: ROE, ScopeVersion, deny-list, planned technique, sealed evidence. Stakeholders misuse "coverage" and "risk" constantly; the glossary is a requirements artefact, not decoration, and appears in the engagement kickoff deck.

Coverage and risk are everyday words with special meanings here, and misuse drives bad decisions. A one-page glossary in the kickoff deck gives everyone the same definitions before the window opens. ROE, ScopeVersion and sealed evidence each get one plain sentence. Sam reads the three most-abused terms aloud at kickoff and leaves the page in the shared folder.

Practice note

Traceability also covers retirement: when a requirement is withdrawn, mark it superseded with a pointer to the replacement rather than deleting the row. Historical findings still cite old ids. A living matrix that forgets history makes last year's dossier unverifiable and trains engineers to treat requirements as disposable slides instead of engineering artefacts that outlive a single release train.

Exercises

Synthesis

Requirements you can test, links you can follow, schemas you version.

Continue studying — chapter 16 of 50

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →