🎯 Learning objectives

• I can name the twelve profile dimensions D1–D12, their five groups and the recurring question behind each.
• I can give a response measure and a measurement instrument for each dimension – no instrument, no dimension.
• I know the three admission conditions for a dimension and the ISO/IEC 25010:2023 changes relevant to AI systems.
• I can distinguish quality attribute requirements from functional requirements and explain why only the former drive structure.
• I can explain what an architecturally significant requirement (ASR) is and why it must be elicited in a QAW.
• I can construct a six-part quality attribute scenario with a numeric response measure, also for an AI component.
• I can derive the twelve weights from a utility tree: (H,H) leaves under an attribute give High.
• I can assemble R(a) from weights, workload shape S(a) and hard constraints K(a), treating constraints as knock-out filters.

🧑‍🏫 Theory

Lecture 2: The Twelve Dimensions – and How Requirements Become Measurable · 2 lessons lecture + 2 lessons exercise
This lecture completes the twelve profile dimensions D1–D12, each with its measurement instrument, then builds the demand side R(a): scenarios, QAW, utility tree, workload shape and hard constraints.

• Twelve dimensions: load and speed (D1–D3), correctness and trust (D4–D6), change and delivery (D7–D9), economics and organisation (D10–D11), AI integrability (D12); each admitted only with standard anchoring, discrimination and instrumentation.
• No instrument, no dimension: D1–D6 measure throughput at k× replication, sustained ingest rate, p50/p95/p99 latency, invariant violations (target 0 for ledgers), SLO attainment and blast radius, audit-trail reconstruction time.
• D7–D11 measure change dispersion and boundary violations, time from empty repository to first release, deployment frequency and change failure rate, cost per request, deployments per developer per day.
• D12 needs a queue, a port and a measurement point, instrumented by the eval harness; ISO/IEC 25010:2023 (Safety, Flexibility, Security with resistance) supplies the names without private extensions (assumption A6).
• ASRs are vague and implicit: a Quality Attribute Workshop (QAW) elicits them; the six-part scenario with a response measure makes them testable and needs no extension for AI components (assumption A6).
• The utility tree (ATAM) rates each leaf H/M/L on business importance and achievement difficulty; (H,H) leaves under an attribute make that dimension High – a veto claim in the match.
• R(a) = (w1, …, w12; S(a); K(a)) – weights, measured workload shape, constraints as knock-out filters, never weights; for the advisory platform C10: High on D6, D7, D9, D10, D12.
• Maxim 6. An architecture decision without a response measure is an opinion; with a response measure and a fitness function it is a testable hypothesis.

📎 Materials: Slide set of Lecture 2 (added below by the lecturer) · Script: Part I – Sections 2 (The Coordinate System: Twelve Profile Dimensions) and 3 (Constructing the Demand Side: The Requirements Profile R(a)). Section 2: completed this week.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part I – Sections 2 (The Coordinate System: Twelve Profile Dimensions) and 3 (Constructing the Demand Side: The Requirements Profile R(a)). Section 2: completed this week.

Also before the lecture:

• Bring the raw stakeholder wishes collected at the kickoff – unfiltered and unweighted; this week they become scenarios.
• Have the kickoff outputs in place: team, repository and tooling (including agentic coding tools), domain understanding, first ontology sketch.

🧩 Exercise session: Requirements workshop I: in stakeholder roles the team runs a compressed QAW, refines the top scenarios into the six-part form with numeric response measures and begins the utility tree.

🛠️ Project work this week · Milestone M1 – Requirements and Ontology (weeks 1–3)

• Run a compressed QAW in stakeholder roles (retail customer, compliance officer, operations engineer, product owner): brainstorm, consolidate and prioritise scenarios from your raw stakeholder wishes.
• Refine the top candidates into six-part scenarios, each with a numeric response measure: at least eight scenarios, at least three for the AI components (answer correctness, token cost per request, provider migration).
• Assemble a first utility tree and identify the (H,H) leaves – they become the weights of your requirements profile R(platform) in week 3 (Deliverable A1).
• Keep the domain model and ontology of the investment domain moving – both belong to the M1 requirements dossier.

No deliverable is due this week.