Chapter 5 — Engineering communication
Lesson map
Lesson 05 published. Map, example, EX010.
flowchart TD
N0["Learning outcomes and connection"]
N1["5.1 Writing for decisions"]
N2["5.2 Requirements that can be verified"]
N3["5.3 Numbers, uncertainty and figures"]
N4["5.4 Communicating risk to different readers"]
N5["5.5 Sensitive information"]
N6["5.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX010"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["5.1 Writing for decisions"]
N2["5.2 Requirements that can be verified"]
N3["5.3 Numbers, uncertainty and figures"]
N4["5.4 Communicating risk to different readers"]
N5["5.5 Sensitive information"]
N6["5.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]
[Learning outcomes and connection]
|
v
[5.1 Writing for decisions]
|
v
[5.2 Requirements that can be verified]
|
v
[5.3 Numbers, uncertainty and figures]
|
v
[5.4 Communicating risk to different readers]
|
v
[5.5 Sensitive information]
|
v
[5.7 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX010]
Learning outcomes and connection
After this chapter you can (1) write a requirement that can be verified; (2) produce a one-page design note, a decision record and a test report that another engineer can check; (3) present risk and uncertainty to operators, managers and regulators without overstating or hiding it; and (4) handle sensitive infrastructure detail appropriately in documents. It builds on Chapters 1–4, whose numbers you now have to communicate, and prepares the design studios (Chapters 25 and 35).
5.1 Writing for decisions
Engineering documents exist so that someone can make or check a decision. Lead with the decision and its basis; put derivations after. A good design note answers, in this order: what is being decided, the options considered, the recommendation, the evidence and assumptions behind it, what would change the recommendation, and who must approve. Architecture decision records — short, dated, numbered notes recording a decision, its context and consequences — keep the reasons for a design visible years later when the original team has moved on.
5.2 Requirements that can be verified
A requirement is a statement the system must satisfy, written so that a test, analysis, inspection or demonstration can show whether it does. The NASA Systems Engineering Handbook recommends requirements that are necessary, unambiguous, verifiable, feasible and traceable. Compare: "Telemetry shall be secure" (unverifiable) with "Each telemetry message from a field RTU to the control centre shall carry a message authentication code over its contents and a monotonic counter; the receiver shall reject messages failing either check and raise an alarm within 60 s" (verifiable by test). Use "shall" for requirements, keep one requirement per sentence, and give each an identifier.
5.3 Numbers, uncertainty and figures
Report numbers with units, the method that produced them and their uncertainty or assumptions: "hold-up 14.6 h (integrated demand model, start 06:00, 85% initial level; 17.3 h if mean demand is assumed)". Prefer tables for exact values, line charts for time series, and never a chart without labelled axes and units. Avoid false precision: a battery hold-up computed from estimated loads is "about 19 h", not "18.83 h". Make figures readable in greyscale and by people with colour-vision deficiency.
At LRWA, the hold-up figure in the TMRP dossier carries its start time and initial level, so nobody quotes it for a different scenario.
5.4 Communicating risk to different readers
Operators need what to do and when; managers need consequence, cost and options; regulators need evidence of compliance and of reasoning. The same finding — "remote setpoints are accepted without authentication" — becomes, for an operator, "until patched, confirm any unexpected setpoint change by phone with the control room"; for a manager, "a forged command could start or stop pumps; fix cost 120 k, three months"; for a regulator, a mapped control gap with a dated plan. None of these versions may contradict another.
5.5 Sensitive information
Infrastructure documents often contain network addresses, device models, vulnerabilities and capacity limits. Mark documents by sensitivity, share on a need-to-know basis, and strip detail from versions intended for wide audiences. Public reports and student work should describe systems at the level of the NIST Guide to OT Security (SP 800-82 Rev. 3) — architectural patterns — not the specific weaknesses of a named operator.
In this book every LRWA figure is synthetic, but practise the habit anyway: mark design notes for internal use, keep network addresses out of slides, and produce a reduced version for audiences outside the engineering team.
5.6 Worked example: a TMRP decision record (synthetic)
ADR-007 — Authenticate field telemetry at the application layer. Date: 2026-03-04. Status: accepted. Context: RTU–SCADA traffic crosses a private LTE network operated by a third party; LTE encryption terminates at the carrier. Options: (a) rely on carrier encryption; (b) IPsec tunnels per RTU; (c) application-layer HMAC with counters. Decision: (c), with (b) where RTUs support it. Consequences: +22 bytes per message (Lab 8); key management required (Chapter 19); legacy RTUs at PS1 and PS2 need a gateway. Revisit if: the carrier contract changes or RTU firmware gains native secure protocols.
5.7 Practical activity
Rewrite three vague requirements from a synthetic brief ("the system shall be resilient", "alarms shall be timely", "logs shall be protected") into verifiable form, each with a verification method.
For each rewrite, name the evidence that would show the requirement is met: a test with a pass criterion, an analysis with stated assumptions, an inspection or a demonstration. Use LRWA's context where it helps. A resilient system might become a stated hold-up during a grid outage, timely alarms might become a latency target for a stated share of events, and protected logs might become integrity protection with anchors stored outside the control zone, as R8 later requires. Keep each statement to one requirement.
5.8 Common errors and limits
- Burying the recommendation; writing a chronology instead of an argument.
- Requirements containing "and/or", "as appropriate", "user-friendly", "secure".
- Numbers without units, method or uncertainty.
- Different stories for different audiences.
- Over-sharing sensitive detail, or under-sharing to the point that reviewers cannot check the work.
Most of these errors appear first in requirement sets. A requirement containing secure cannot be tested, so it will either be quietly dropped or claimed without evidence. Different stories for different audiences are just as damaging: if the operator note, manager summary and regulator statement in EX010 disagree about the PS4 battery, whoever reads two of them will trust none.
Exercises — chapter 5
EX009 — Make it verifiable. Objective: write testable requirements. Inputs: the three vague requirements in §5.7. Steps: rewrite each as one or more "shall" statements with an identifier and verification method (test, analysis, inspection, demonstration). Expected evidence: table. Rubric: 3 = each measurable, single, feasible, with a fitting method; 2 = one still vague; 1 = rewording only; 0 = none.
EX010 — Three audiences. Objective: communicate one finding consistently. Inputs: "PS4 telemetry battery lasts 6 h at end of life; requirement R5 is 24 h". Steps: write a two-sentence operator note, a 100-word manager summary with options, and a regulator-facing gap statement. Expected evidence: three texts. Rubric: 3 = consistent facts, audience-appropriate actions, no sensitive excess; 2 = one inconsistency; 1 = same text three times; 0 = none.
Chapter synthesis
Write to enable decisions: recommendation first, evidence and assumptions next, conditions for change last. Make every requirement verifiable and traceable; report numbers with units, methods and uncertainty; tailor the message, not the facts, to the reader; and treat infrastructure detail as sensitive information with a defined audience.
Continue studying — chapter 05 of 50
← Chapter 04 · Course chapter index · Chapter 06 →
Continue to the next authored lesson.