Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Lifecycle"]
N2["16.2 Requirements"]
N3["16.3 Traceability"]
N4["16.4 Interfaces"]
N5["Stakeholders"]
N6["Verification and validation"]
N7["Configuration items"]
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 Lifecycle"]
N2["16.2 Requirements"]
N3["16.3 Traceability"]
N4["16.4 Interfaces"]
N5["Stakeholders"]
N6["Verification and validation"]
N7["Configuration items"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Lifecycle]
|
v
[16.2 Requirements]
|
v
[16.3 Traceability]
|
v
[16.4 Interfaces]
|
v
[Stakeholders]
|
v
[Verification and validation]
|
v
[Configuration items]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) manage requirements through a lifecycle; (2) trace requirements to tests; (3) manage interfaces.
16.1 Lifecycle
Kofi follows a lifecycle: needs, requirements, design, implementation, verification, operation.
The systems engineering lifecycle runs from understanding needs, through requirements, design, implementation and verification, to operation and eventual retirement. Each stage produces documents that the next one relies on. Security must be considered at every stage, not added at the end, because a weakness designed into an architecture is far costlier to fix after deployment. Reviews between stages confirm that each output is complete and consistent before work continues.
Retirement also needs planning.
16.2 Requirements
Requirements are testable statements, such as "guest devices cannot initiate connections to any internal zone".
A requirement states what the system must do or how well, in terms that can be checked. Good requirements are specific, measurable, and free of design choices: guest devices must not reach staff servers is a requirement, while use a particular firewall model is a design decision. Each requirement has an identifier, a source such as a council policy, and a planned verification method, so nothing is lost or left untested.
16.3 Traceability
Each requirement links to design elements and tests, so coverage gaps are visible.
Traceability links each requirement to the design elements that satisfy it and the tests that verify it. A traceability matrix makes gaps visible: a requirement with no test is unverified, and a design element linked to no requirement may be unnecessary. When requirements change, the links show what design and tests must be revisited. Reviewers and auditors use the matrix to confirm that every promise in the requirements was actually kept.
16.4 Interfaces
Interfaces with other systems, such as the phone provider and CCTV supplier, are documented.
Interfaces are the points where systems meet: between zones, between the council network and suppliers, or between the firewall and the logging platform. Many failures occur at interfaces, because each side assumes something about the other. Interface specifications record what crosses the boundary, in which direction, in what format, and who is responsible for each side. Agreeing them in writing prevents gaps that neither team realises they own.
Stakeholders
Systems engineering starts with stakeholders: the people affected by the system and its changes. For Ashcombe they include IT staff, office managers, the telephony provider, the CCTV supplier, the information governance officer and residents who depend on services. Kofi interviews representatives of each group to collect needs, recording who said what. Some needs conflict, such as the CCTV supplier wanting broad remote access and governance wanting tight control; recording them explicitly allows the conflict to be resolved openly rather than discovered late.
Verification and validation
Verification asks whether the system meets its requirements; validation asks whether the requirements meet the real need. A network can pass every test and still fail users if a requirement was wrong, for example if a needed flow was missed. Kofi plans both: tests against requirements in the lab and in production, and a validation period in which office staff report anything that stopped working. Their reports feed back into the requirements, closing the loop that systems engineering depends on.
Configuration items
Systems engineering treats each managed element as a configuration item with an identity, version and owner: firewall policies, switch configurations, VPN settings and diagrams. NIST SP 800-128 describes security-focused configuration management in these terms. Kofi lists the configuration items for the new design and where each is stored, so that changes can be controlled and audits can confirm what is deployed matches what was approved. Each item is stored in version control, so every approved change has a recorded author, date and reason.
Worked example
Kofi drafts eight requirements, each with an owner and verification method.
Synthetic case. Requirements are synthetic.
Errors and limits
Vague requirements like "secure network" cannot be verified.
Exercises
- EX046 — Testable rewrite. Rewrite "guest is safe" as testable. Rubric: 3 = specific measurable statement;; 2 = partial;; 1 = vague;; 0 = none.
- EX047 — Traceability value. What does traceability reveal? Rubric: 3 = untested requirements;; 2 = gaps;; 1 = vague;; 0 = none.
- EX048 — Interface example. Name one external interface. Rubric: 3 = phone provider or CCTV supplier;; 2 = one;; 1 = vague;; 0 = none.
Synthesis
Systems engineering keeps design tied to verifiable needs.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →