◇ OpenCyber Academy
Engineering · Chapter 21 · English

Chapter 21 — Data governance: requirements

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 21 — Data governance: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Testable statements"]
  N3["21.3 Conflicts"]
  N4["21.4 Priorities"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Testable statements"]
  N3["21.3 Conflicts"]
  N4["21.4 Priorities"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
    |
    v
[21.1 Sources of requirements]
    |
    v
[21.2 Testable statements]
    |
    v
[21.3 Conflicts]
    |
    v
[21.4 Priorities]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) derive governance requirements from regulation and business need; (2) write them as testable statements; (3) agree priorities with owners.

21.1 Sources of requirements

Kofi gathers requirements for the leakage indicator from four sources: the regulator's reporting guidance, Tidewater's own leakage reduction targets, data protection law for customer data used in billing volumes, and the needs of network engineers who use leakage by district to plan repairs. He lists each source with the clause or meeting where the need was stated. He explains that requirements without a recorded source are hard to defend when budgets are cut or priorities change. The source list is stored with the requirements.

21.2 Testable statements

He rewrites vague needs as testable statements. Leakage should be reliable becomes: the monthly leakage figure is calculated from volumes that reconcile within one percent with independent totals, and every input has a named owner. Data should be timely becomes: the daily volume feed arrives by 06:00 on at least 95 percent of days. Each statement names a measure, a threshold and an owner who answers for it. These statements later become the tests in the verification laboratories. Vague wording is returned to its author.

21.3 Conflicts

Some requirements conflict. Network engineers want leakage by street, which would need customer-level billing volumes, while the data protection officer wants analysts to see aggregated data only. Kofi proposes district-level aggregation with a minimum of fifty properties per area, which supports repair planning without exposing individual consumption. The compromise is recorded with the reasons and approved by both owners. He notes that conflicts handled openly produce better designs than conflicts discovered after systems are built. The data protection officer signs the final note.

21.4 Priorities

With twenty-four requirements listed, Kofi asks owners to rank them using impact on the regulator's figure and on customers. Owner assignment, reconciliation and timeliness rank highest. Documentation standards rank lower. He uses the ranking to plan the specialist chapters, tackling the highest-impact requirements first. Prof. Varga reminds him that unranked requirement lists encourage teams to do the easiest items first, which can leave the most important risks unaddressed for months while effort goes elsewhere. The ranked list is published on the governance intranet page.

Worked example

Kofi gathers leakage indicator requirements from four sources, rewrites them as testable statements, resolves a street-level conflict with district aggregation and ranks twenty-four requirements with owners.

Synthetic case. Requirements are synthetic.

Errors and limits

A threshold without a measurement method is not testable; define both.

Exercises

Continue studying — lesson 21 (chapter 21 of 50)

← Chapter 20 · Course chapter index · Chapter 22 →

Continue to the next authored lesson.