AISE502/moodle/week_02.html

<!-- ==========================================================================
     AISE502 · Moodle course page · Week 2
     Section title (Edit section → Section name): Week 2: The Twelve Dimensions – and How Requirements Become Measurable
     Three blocks follow, matching the FHGR section template. Paste each block into the
     corresponding 'Text and media area' (editor → source code view), or all three into one.
     The slide set of lecture 2 is added by the lecturer as a file resource below block 2.
     Generated by src/build_moodle.py from src/content/week_02.json – edit the JSON, not this file.
     ========================================================================== -->

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

<!-- BLOCK 2 · Theory -->
<h4>🧑‍🏫 Theory</h4>
<p><strong>Lecture 2: The Twelve Dimensions – and How Requirements Become Measurable</strong> · 2 lessons lecture + 2 lessons exercise<br>
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.</p>
<ul>
  <li>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.</li>
  <li>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.</li>
  <li>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.</li>
  <li>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).</li>
  <li>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).</li>
  <li>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.</li>
  <li>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.</li>
  <li>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.</li>
</ul>
<p>📎 <strong>Materials:</strong> Slide set of Lecture 2 <em>(added below by the lecturer)</em> · 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.</p>

<!-- BLOCK 3 · Self-study and assignments -->
<h4>🧑‍💻 Self-study and assignments</h4>
<p><strong>📖 Reading before the lecture:</strong> 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.</p>
<p><strong>Also before the lecture:</strong></p>
<ul>
  <li>Bring the raw stakeholder wishes collected at the kickoff – unfiltered and unweighted; this week they become scenarios.</li>
  <li>Have the kickoff outputs in place: team, repository and tooling (including agentic coding tools), domain understanding, first ontology sketch.</li>
</ul>
<p><strong>🧩 Exercise session:</strong> 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.</p>
<p><strong>🛠️ Project work this week</strong> · Milestone M1 – Requirements and Ontology (weeks 1–3)</p>
<ul>
  <li>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.</li>
  <li>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).</li>
  <li>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).</li>
  <li>Keep the domain model and ontology of the investment domain moving – both belong to the M1 requirements dossier.</li>
</ul>
<p><em>No deliverable is due this week.</em></p>