Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 System boundary"]
N2["16.2 Interfaces"]
N3["16.3 Life cycle"]
N4["16.4 Configuration management"]
N5["16.5 Verification planning"]
N6["Ownership of components"]
N7["Interfaces as risk points"]
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 System boundary"]
N2["16.2 Interfaces"]
N3["16.3 Life cycle"]
N4["16.4 Configuration management"]
N5["16.5 Verification planning"]
N6["Ownership of components"]
N7["Interfaces as risk points"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 System boundary]
|
v
[16.2 Interfaces]
|
v
[16.3 Life cycle]
|
v
[16.4 Configuration management]
|
v
[16.5 Verification planning]
|
v
[Ownership of components]
|
v
[Interfaces as risk points]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) define system boundaries and interfaces; (2) manage requirements through the life cycle; (3) plan verification.
16.1 System boundary
The system includes public PCs, the golden image, the management server, the restore mechanism and monitoring. Patron personal devices and the internet are outside.
Drawing the line tells Fernhill what the project must control and what it can only influence. A patron's phone plugged in to charge is outside the boundary, but the PC's response to it is inside. Websites are outside, yet the browser and the restore that clears downloads are inside. Mateo puts the boundary on the context diagram so that every later discussion starts from the same picture.
16.2 Interfaces
Interfaces include the PC-to-server management channel, the print service and the network segment rules.
Two more complete the list on Mateo's diagram: the session booking system, which tells each PC who may log in, and the feed of restore results and events to the central store. Each interface has a short description of what crosses it, in which direction, how it is protected and who owns each end. Problems found in testing almost always sat at one of these five points.
16.3 Life cycle
Requirements are defined, designed, implemented, verified, operated and retired. Each stage has outputs.
For Fernhill the outputs are concrete documents and artefacts that someone can open and check. Moving to the next stage needs the previous outputs to exist and be reviewed: no design before agreed requirements, no branch release before verification evidence. The stages can overlap on small changes, but the outputs are still produced, which keeps the record complete for the next person who inherits the system. Retirement is planned from the start.
16.4 Configuration management
NIST SP 800-128 describes security-focused configuration management: baselines, change control and monitoring. The golden image is the baseline.
For Fernhill the three parts are simple. The baseline is the approved image release. Change control is the review and staged release process. Monitoring is the daily comparison of each PC with its manifest and the restore results. A change made directly on a PC without going through the image is drift, and the nightly restore removes it. Changes that should stay must go through the image.
16.5 Verification planning
Each requirement gets a verification method: test, inspection or analysis.
Tests suit settings that can be checked by a script, such as USB storage being blocked. Inspection suits documents and physical facts, such as firmware passwords recorded in the key store. Analysis suits properties that cannot be tested directly, such as the exposure calculation. Mateo chooses the method when writing each requirement, because a requirement nobody knows how to verify is usually written too vaguely. The method is recorded beside the requirement in the verification table, together with who performs it.
Ownership of components
Each component in the system boundary has an owner: Marta owns the image, the technician owns daily restore checks, the network supplier owns segmentation and the session system vendor owns booking. Owners approve changes affecting their components. Mateo records owners in the context diagram so that gaps are visible.
The diagram is reviewed whenever a component or interface changes.
Interfaces as risk points
Most integration problems appear at interfaces, so each interface has a test in the verification plan.
Life cycle outputs
Each life cycle stage produces outputs: requirement list, design records, implementation repository, verification evidence, operations runbooks and, eventually, a retirement plan for old hardware. Mateo lists these outputs at the start so nothing is forgotten. Retirement matters too: old PCs must have disks wiped before disposal, following the same care as the restore design.
Configuration items
Each image release, script and policy file is a configuration item with a version and owner, following SP 800-128.
Worked example
Mateo draws a context diagram with the system boundary and five interfaces, then a table linking each requirement to a verification method.
Synthetic case. Synthetic.
Errors and limits
Unclear boundaries lead to gaps where nobody owns a component.
Exercises
- EX046 — Boundary. What lies outside the system boundary? Rubric: 3 = patron devices, internet; 2 = partial; 1 = vague; 0 = none.
- EX047 — Baseline. What serves as the configuration baseline? Rubric: 3 = golden image; 2 = partial; 1 = vague; 0 = none.
- EX048 — Verification methods. Name three verification methods. Rubric: 3 = test, inspection, analysis; 2 = two; 1 = one; 0 = none.
Synthesis
Systems engineering keeps boundaries, interfaces and verification explicit.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →