Chapter 45 — Independent design review
Lesson map
Lesson 45 published. Map, example, EX133.
flowchart TD
N0["Learning outcomes"]
N1["45.1 Why independent review"]
N2["45.2 Review package"]
N3["45.3 Findings"]
N4["45.4 Severity"]
N5["45.5 Responses"]
N6["45.6 Record"]
N7["45.7 Culture"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX133"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["45.1 Why independent review"]
N2["45.2 Review package"]
N3["45.3 Findings"]
N4["45.4 Severity"]
N5["45.5 Responses"]
N6["45.6 Record"]
N7["45.7 Culture"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX133"]
[Learning outcomes]
|
v
[45.1 Why independent review]
|
v
[45.2 Review package]
|
v
[45.3 Findings]
|
v
[45.4 Severity]
|
v
[45.5 Responses]
|
v
[45.6 Record]
|
v
[45.7 Culture]
|
v
[Worked example] --> [Exercise EX133]
Learning outcomes
You will (1) prepare a design for independent review; (2) respond to review findings; (3) classify findings by severity; (4) record decisions and changes.
45.1 Why independent review
Designers miss their own assumptions. An engineer from another team, unconnected to the project, reviews Amara's capstone design.
Amara has lived with the design for weeks, so certain choices feel obvious to her even when they rest on untested beliefs, such as assuming depots use only one logon protocol. A reviewer from another team brings different habits and no stake in the design looking good. Choosing someone unconnected also means the review cannot be dismissed later as a friendly sign-off, which matters when the capstone is assessed.
45.2 Review package
Diagram, data flows, requirements, rule logic, test plan, risk register and rollout plan, sent a week ahead.
Sending everything a week ahead gives the reviewer time to read carefully rather than reacting during a meeting. Each document answers a different question: the diagram shows structure, data flows show volumes and formats, the rule logic shows what will fire, and the risk register shows what Amara already worries about. A missing document would itself be a finding, since the reviewer cannot check what is absent.
45.3 Findings
The reviewer raises: (1) the approved-device list is maintained by hand and will drift; (2) the rule ignores logons over a protocol the depots also use; (3) the playbook lacks a step to check for the same account on other depots; (4) the volume estimate came from a quiet day.
Each finding targets a different weakness. A hand-maintained list will slowly diverge from reality as devices change. Ignoring a second protocol leaves a path attackers could use. Without checking other depots, an analyst might contain one site while the same account is active elsewhere. A quiet-day estimate understates the load the design must handle. None of these was in Amara's own risk register, which shows why the review was worth doing.
45.4 Severity
Findings are classed as blocking, major or minor. Finding 2 is blocking: a coverage gap. Findings 1 and 4 are major; finding 3 is minor.
Blocking means the design cannot proceed until the finding is fixed, because building it would knowingly leave the gap the project exists to close. Major findings must be fixed before go-live but need not stop the build. Minor findings can be scheduled. Classing severity openly lets Amara put effort where it matters and lets assessors see that the most serious issue was handled first.
45.5 Responses
Amara extends the rule to the second protocol; links the approved list to the asset inventory with a weekly reconciliation; re-estimates volume from a busy-day capture; adds the playbook step.
Each response addresses the finding's cause rather than its symptom. Linking the list to the inventory makes drift visible every week, instead of relying on someone remembering to update it. A busy-day capture tests the design against realistic load. Extending the rule closes the gap without changing its basic structure, so earlier tests remain relevant with additions for the new protocol.
45.6 Record
A review log lists each finding, severity, response and status. The reviewer confirms closure of the blocking finding before build.
The log makes the review traceable: anyone can see what was found, how seriously it was taken and what was done. Requiring the reviewer to confirm closure of the blocking finding prevents the designer from simply declaring it fixed. The log goes into the evidence dossier, where assessors can check that every finding was answered. Major findings are rechecked before go-live.
45.7 Culture
Reviews are about the design, not the designer; Amara thanks the reviewer and asks to review someone else's design next term.
If reviews felt like personal criticism, designers would hide weaknesses and argue with findings rather than fixing them. Treating the design as the subject lets both sides be candid. Offering to review someone else's work next term completes the exchange and shows Amara values the practice rather than merely enduring it. The reviewer, in turn, notes two design ideas worth borrowing for their own team's work, which shows that reviews teach in both directions.
Preparing as a designer
Before the review Amara lists the assumptions she is least sure of and sends them with the package, inviting the reviewer to test them first.
After the review
The review log is kept with the capstone report so assessors can see how the design changed and why.
Worked example
The busy-day re-estimate shows 3.2 times the earlier volume, still within the lake's capacity but above the firewall CPU limit on two large depots. Amara changes those depots to log only connection starts, which keeps CPU under 2%.
Synthetic case. The review is invented.
Errors and limits
One reviewer cannot catch everything; reviews reduce but do not remove design risk.
Exercises
- EX133 — Blocking finding. Which finding was blocking, and why? Rubric: 3 = ignored second protocol: coverage gap; 2 = partial; 1 = wrong; 0 = none.
- EX134 — Drift fix. How was approved-list drift addressed? Rubric: 3 = linked to asset inventory with weekly reconciliation; 2 = partial; 1 = vague; 0 = none.
- EX135 — Busy-day estimate. What did the busy-day re-estimate change? Rubric: 3 = 3.2× volume; two depots log connection starts only to keep CPU < 2%; 2 = partial; 1 = vague; 0 = none.
Synthesis
Independent review finds assumptions designers cannot see; classify, respond and record each finding.
Continue studying — chapter 45 of 50
← Chapter 44 (draft) · Course chapter index · Chapter 46 (draft) →