Chapter 35 — Design studio II
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 The brief"]
N2["35.2 Reconciling conflicts"]
N3["35.3 The design package"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX103"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["35.1 The brief"]
N2["35.2 Reconciling conflicts"]
N3["35.3 The design package"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 The brief]
|
v
[35.2 Reconciling conflicts]
|
v
[35.3 The design package]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) lead a multi-disciplinary design for a larger system; (2) reconcile conflicting stakeholder requirements; (3) produce a design package suitable for independent review.
35.1 The brief
Design Studio II is larger: Sofia leads a team of six, including two students from other engineering disciplines, to design the security architecture of Corvia's planned account-based ticketing, where passengers tap bank cards or phones and fares are calculated in the back office rather than stored on cards. The brief includes privacy, payment, accessibility and operational requirements. Sofia's role is to coordinate, not to decide everything. She sets up a shared decision log, assigns each team member an area and holds short daily check-ins so conflicts surface early.
35.2 Reconciling conflicts
Requirements collide. Fraud analysts want detailed journey histories kept for two years; the privacy lead wants ninety days; customer service wants histories visible to agents for disputes; the accessibility lead wants simple account recovery for passengers who lose phones, which fraud analysts fear will enable account takeover. Sofia runs a session where each side states the underlying need. The result: detailed data for ninety days, aggregated fraud features for two years, agent views showing only the disputed journeys and recovery through verified bank-card taps rather than security questions. Each compromise is recorded with its rationale.
35.3 The design package
The final package contains the context statement, requirements with verification methods, the component and data-flow models, threat model, alternatives analysis, control specifications, degradation levels, open issues and the decision log. Sofia checks that every requirement traces to controls and tests. The package goes to an independent reviewer from another university, who identifies two gaps: no plan for key compromise in the tokenisation service and an unclear owner for passenger data deletion requests. Sofia's team adds both. Producing a package others can review is the deliverable, more than any single diagram.
Worked example
Sofia leads a six-person studio on account-based ticketing, reconciles four conflicting requirements through stated needs and assembles a reviewable package that closes two gaps found by an external reviewer.
Synthetic case. The studio, team and reviewer are synthetic.
Errors and limits
Studio compromises may not survive real negotiations. Package completeness does not guarantee design quality.
Exercises
- EX103 — Leader's role. What is Sofia's main role as studio lead? Rubric: 3 = coordinate, surface conflicts and keep a decision log, not decide everything;; 2 = coordinate;; 1 = decide all;; 0 = none.
- EX104 — Retention compromise. What retention compromise did the team reach? Rubric: 3 = detailed data 90 days, aggregated fraud features two years;; 2 = both;; 1 = one;; 0 = none.
- EX105 — Reviewer gaps. What two gaps did the independent reviewer find? Rubric: 3 = no key-compromise plan for tokenisation; unclear owner for deletion requests;; 2 = both;; 1 = one;; 0 = none.
Synthesis
Large designs succeed when needs behind conflicting requirements are surfaced and the result is packaged for independent review.
Continue studying — chapter 35 of 50
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →