Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 A system of systems"]
N2["16.2 Interface control"]
N3["16.3 Life cycle of data"]
N4["16.4 Requirements traceability"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 A system of systems"]
N2["16.2 Interface control"]
N3["16.3 Life cycle of data"]
N4["16.4 Requirements traceability"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 A system of systems]
|
v
[16.2 Interface control]
|
v
[16.3 Life cycle of data]
|
v
[16.4 Requirements traceability]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) view data governance as part of a system of systems; (2) manage interfaces and requirements across teams; (3) use life cycle thinking for data.
16.1 A system of systems
Tidewater's data environment includes meters, the vendor head-end, billing, customer service, the control system, the warehouse and regulatory reporting. Each is owned by a different team or company. Kofi uses systems engineering to view them as one system whose behaviour emerges from interactions. A quality problem often appears far from its cause, as when a meter firmware issue shows up as a billing complaint. Systems thinking helps him trace effects across boundaries rather than fixing symptoms locally. Kofi traces three recent complaints this way.
16.2 Interface control
Kofi writes interface control documents for key data exchanges: the meter readings file from the vendor and the daily volume feed from the control system. Each document defines fields, units, formats, timing, error handling and who to contact. When the vendor changes a field, the document requires notice and testing. He explains that interface documents turn informal assumptions into agreed requirements, which are the basis for holding partners accountable when data do not arrive as expected. Both partners sign the documents formally.
16.3 Life cycle of data
Kofi maps the life cycle of meter data: creation in the meter, transmission, validation, use in billing, analysis, archiving and deletion. At each stage he notes the owner, quality rules, security controls and retention. ISO/IEC 38505-1 encourages governing bodies to consider data value, risk and constraints across the life cycle. Kofi finds that deletion is the least defined stage; nobody had decided when hourly readings should be deleted or aggregated after billing evidence periods end. The board is asked to make that decision.
16.4 Requirements traceability
Kofi builds a traceability matrix linking governance requirements, such as accurate billing and retention limits, to system requirements, tests and evidence. Each regulatory obligation traces to at least one control and one test. Gaps appear where obligations have no test, such as deleting hourly data after seven years. He adds requirements and tests for the gaps. Prof. Varga notes that traceability lets engineers answer auditors' questions with evidence rather than reassurance. The matrix is updated whenever a regulation or system changes, and reviewed every quarter.
Worked example
Kofi treats Tidewater's data as a system of systems, writes interface control documents, maps the data life cycle and finds deletion undefined, and builds a traceability matrix.
Synthetic case. Systems are synthetic; ISO/IEC 38505-1:2017 is real.
Errors and limits
Interface documents fail if partners are not bound by them; reference them in contracts.
Exercises
- EX046 — Distant symptom. How can a meter firmware issue appear? Rubric: 3 = as a billing complaint;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX047 — Interface fields. What does an interface control document define? Rubric: 3 = fields, units, formats, timing, error handling, contacts;; 2 = most;; 1 = few;; 0 = none.
- EX048 — Weakest stage. Which life cycle stage was least defined? Rubric: 3 = deletion;; 2 = partly correct;; 1 = other;; 0 = none.
Continue studying — lesson 16 (chapter 16 of 50)
← Chapter 15 · Course chapter index · Chapter 17 →
Continue to the next authored lesson.