Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes and connection"]
N1["16.1 The system and its lifecycle"]
N2["16.2 Stakeholders and needs"]
N3["16.3 Architecture and interfaces"]
N4["16.5 Verification and operations planning"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["16.1 The system and its lifecycle"]
N2["16.2 Stakeholders and needs"]
N3["16.3 Architecture and interfaces"]
N4["16.5 Verification and operations planning"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[Learning outcomes and connection]
|
v
[16.1 The system and its lifecycle]
|
v
[16.2 Stakeholders and needs]
|
v
[16.3 Architecture and interfaces]
|
v
[16.5 Verification and operations planning]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes and connection
After this chapter you can (1) identify stakeholders and their needs for a response platform; (2) decompose needs into requirements, architecture and interfaces; (3) build a requirements trace from need to acceptance test; and (4) plan verification and operations as lifecycle stages rather than afterthoughts. It builds on Chapter 5 and prepares Chapters 20, 21, 44 and 48.
16.1 The system and its lifecycle
An incident-response capability is a socio-technical system: people, procedures, tools, data and the organisations they serve. Systems engineering manages it across a lifecycle — concept, requirements, design, implementation, integration, verification, validation, operation, retirement. Verification asks "did we build it right?" (against requirements); validation asks "did we build the right thing?" (against stakeholder needs in realistic conditions). The NASA Systems Engineering Handbook and NIST SP 800-160 Vol. 1 Rev. 1 describe these processes, the latter for trustworthy secure systems specifically.
16.2 Stakeholders and needs
Stakeholders of a response platform include analysts (fast, clear queues), approvers (clear decision information), service owners (minimal disruption, notification), legal and records staff (preserved, defensible evidence), privacy officers (minimisation), auditors (accountability), platform operators (maintainable, observable) and, indirectly, the public served. Needs conflict: analysts want everything visible, privacy officers want minimisation. Systems engineering makes conflicts explicit and resolves them by decision, not by accident. The HVSS trace in the worked example shows one such conflict: analysts' visibility against the privacy officer's need N5.
16.3 Architecture and interfaces
Architecture allocates requirements to components and defines interfaces between them. Each interface needs an owner on both sides, a specification (data, timing, error behaviour) and a test. Most integration failures occur at interfaces nobody owned: the identity provider changed a log field; the paging provider rate-limited the platform during a surge.
In the HVSS trace, the IdP → API tenant claim is one such interface. The identity team owns the claim it issues, the case-API team owns how it is checked, and AT-07 tests both with a forged claim.
16.4 Worked example (synthetic): one platform, several teams
HVSS is deploying one response platform to its central security team and to three client organisations with their own responders. Extract of the trace:
| Need (stakeholder) | Requirement | Component | Interface | Acceptance test |
|---|---|---|---|---|
| N1 Client responders see only their cases (client CISO) | R7 Case queries shall return only cases of the caller's tenant | case API | IdP → API tenant claim | AT-07 cross-tenant query returns 0 rows; negative test with forged claim rejected |
| N2 Evidence defensible later (legal) | R4 Raw events retained unaltered 400 days with manifest | evidence store | ingest → store | AT-04 manifest verification on sampled items |
| N3 Approver decides in minutes (duty manager) | R2 Request shown to approver ≤ 60 s for 99% | workflow, paging | workflow → pager | AT-02 seeded requests, latency distribution |
| N4 Minimal disruption (service owners) | R12 Every containment action reversible with one recorded action | containment service | workflow → endpoint/IdP | AT-12 reverse after execute restores prior state |
The trace exposes a gap: N5 "privacy officer: analysts do not browse personal data without a case" had no requirement; R15 "data views require an open case ID and are logged" was added with its test.
16.5 Verification and operations planning
Plan verification while writing requirements; a requirement you cannot verify must be rewritten. Plan operations equally early: who monitors the platform, who patches it, how changes are approved (Chapter 37). A response platform that fails during an incident because nobody was on call for it is a systems-engineering failure, not bad luck.
For HVSS, AT-02 is planned when R2 is written: seeded containment requests, a measured latency distribution, and the 99% within 60 s target against which it is judged. The operations plan should also name who is on call for the platform and its paging interface when three client tenants depend on them.
16.6 Errors and limits
- Treating stakeholders as one "user".
- Interfaces without owners on both sides.
- Validation skipped because verification passed.
- Operations considered only at hand-over.
The HVSS deployment to one central team and three clients would expose each error early. Treating the central team and three client organisations as one user would have produced no tenant-isolation requirement like R7. Leaving the IdP → API tenant claim without an owner on the identity side would let a claim format change break AT-07 unnoticed. Passing AT-02 in a test environment would still not prove that a real duty manager decides within minutes when paged.
Exercises — chapter 16
EX031 — Extend the trace. Objective: trace needs to tests. Inputs: the trace table. Steps: add two rows: one for the platform operator's need and one for the auditor's; include requirement, component, interface and acceptance test. Expected evidence: two rows. Rubric: 3 = specific, testable, interface named; 2 = one weak; 1 = vague; 0 = none.
EX032 — Verification vs validation. Objective: distinguish them. Inputs: AT-02 passes in the lab with 99.5% of requests under 60 s. Steps: explain why N3 might still not be met in operation and design a validation activity. Expected evidence: explanation and design. Rubric: 3 = identifies that display ≠ decision (approver may need context, may be asleep, may not have device), proposes an exercise measuring time to informed decision; 2 = partial; 1 = generic; 0 = none.
Chapter synthesis
Systems engineering treats the response capability as a lifecycle system of people and tools, makes stakeholder conflicts explicit, assigns interfaces owners, traces needs to tests and distinguishes building it right from building the right thing.
Continue studying — chapter 16 of 50
← Chapter 15 · Course chapter index · Chapter 17 →
Continue to the next authored lesson.