% !TEX encoding = UTF-8 Unicode
% ============================================================================
% AISE502 -- AI in Software Engineering II
% Lecture 2 slides, typeset with the official FHGR beamer theme
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
% Slide content is unchanged; only the presentation layer is the FHGR template.
% ============================================================================
\documentclass[aspectratio=169]{beamer}

\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}

% ============================================
% PACKAGES
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
% listings, hyperref, environ and xparse -- only the extras are needed here.
% ============================================
\usepackage[british]{babel}
\usepackage{booktabs}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{tcolorbox}
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}

% ============================================
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
% The names used throughout the slides are kept, so no slide text changes;
% they now resolve to the FHGR brand colours defined by the theme.
% ============================================
\colorlet{bankblue}{blue}          % FHGR blue   (4B92A4)
\colorlet{bankgreen}{green}        % FHGR green  (817E65)
\colorlet{bankred}{red}            % FHGR red    (C60219)
\colorlet{codegray}{gray}          % FHGR gray   (595959)
\colorlet{backcolour}{linen}       % FHGR linen  (E1D3B5)
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens

% Attribution labels in English (theme default is German)
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}

% ============================================
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
% ============================================
\newtcolorbox{keypoint}{
    colback=bankblue!7!white,
    colframe=bankblue,
    title=Key Concept,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{examplebox}[1][]{
    colback=bankgreen!10!white,
    colframe=bankgreen,
    title={Example: #1},
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{definitionbox}[1][]{
    colback=linen!40!white,
    colframe=camel!85!black,
    title={Definition: #1},
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{thinkbox}{
    colback=lightGray!35!white,
    colframe=darkGray,
    title=Discussion,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{hinweisbox}{
    colback=bankred!5!white,
    colframe=bankred,
    title=Important Note,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{ailinse}[1][]{
    colback=aiviolet!7!white,
    colframe=aiviolet,
    title={AI Lens: #1},
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{projektbox}{
    colback=bankblue!4!white,
    colframe=bankblue!70!black,
    title=Project Link: Portfolio Intelligence Platform,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

% Measurement line used on every dimension slide
\newcommand{\measured}[2]{%
\vspace{0.12cm}
\begin{tcolorbox}[colback=gray!8!white, colframe=gray!70!black, boxrule=0.6pt, arc=2pt, top=1pt, bottom=1pt, left=4pt, right=4pt]
\footnotesize \textbf{Measured:} #1\\ \textbf{Instrument:} #2
\end{tcolorbox}}

% ============================================
% TITLE METADATA
% ============================================
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
\subtitle{Lecture 2: The Twelve Dimensions -- and How Requirements Become Measurable\\[0.4ex]{\small Script: Part I, Sections 2--3}}
\author{Dr.\ Florian Herzog}
\shortname{AISE502}
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}

\begin{document}

% ============================================
% TITLE SLIDE
% ============================================
\FHGRTitlePage

% ============================================
% AGENDA
% ============================================
\begin{frame}{Agenda}
\small
\begin{enumerate}\setlength\itemsep{1pt}
    \item Recap: the framework and the nine questions
    \item Load and speed: D1--D3
    \item Correctness and trust: D4--D6
    \item Change and delivery: D7--D9
    \item Economics and organisation: D10--D11
    \item The new dimension: D12 (AI integrability)
    \item Why exactly these twelve -- ISO/IEC 25010:2023
    \item From wishes to scenarios: ASR, QAW, the six-part form
    \item The utility tree: from scenarios to weights
    \item Workload shape, hard constraints -- $R(a)$ assembled
\end{enumerate}
\end{frame}

% ============================================
% RECAP
% ============================================
\section{Recap}

\begin{frame}{Recap: where we are}
\footnotesize
\textbf{Last week:}
\begin{itemize}\setlength\itemsep{1pt}
    \item Maxim 1: patterns are neither good nor bad -- only the \textbf{fit} is
    \item the framework: $R(a) \to C(p) \to \mathrm{fit}(a,p) \to$ ADR $\to$ measurement contract
    \item six assumptions A1--A6; the chain \emph{demand $\to$ supply $\to$ match $\to$ record $\to$ test}
    \item nine recurring on-call questions $\to$ five groups of dimensions
\end{itemize}

\vspace{0.2cm}
\textbf{Today} we build the coordinate system and the demand side:
\begin{itemize}\setlength\itemsep{1pt}
    \item the twelve dimensions \textbf{D1--D12}, one by one -- each with vocabulary and \textbf{instrument}
    \item then the method that turns stakeholder wishes into \textbf{weights}: scenarios, QAW, utility tree
\end{itemize}

\vspace{0.2cm}
\begin{keypoint}
Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no dimension.}
\end{keypoint}
\end{frame}

% ============================================
% D1-D3 LOAD AND SPEED
% ============================================
\section{Load and Speed: D1--D3}

\begin{frame}{D1 -- Read scalability \hfill \normalsize\textcolor{gray}{group: load and speed}}
\emph{\textcolor{bankblue}{What happens at 08:00 on grade-release day, when the whole semester refreshes at once?}}

\vspace{0.2cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item the ability to serve a growing volume of \textbf{read} requests -- requests that look at data without changing it
    \item most interactive systems are \textbf{read-dominated by orders of magnitude}: thousands check a result for every one who appeals it
    \item reads are friendly: they can be served from \textbf{copies} -- replicas and \emph{caches} (fast stores holding ready-made answers)
    \item Stack Overflow: $\sim 1.3$ billion page views/month from a handful of servers; Instagram: a monolith -- \textbf{the single write path is the hard part}
\end{itemize}

\measured{throughput at $k\times$ replication (does doubling servers double throughput?); cache hit ratio; p95 read latency}{step-profile load tests; production RED metrics (Rate, Errors, Duration)}
\end{frame}

\begin{frame}{D2 -- Write scalability and elasticity}
\emph{\textcolor{bankblue}{Black Friday: checkout traffic jumps to dozens of times the baseline for one weekend -- and is gone on Monday.}}

\vspace{0.2cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item the D1 question for requests that \textbf{change} state -- the harder half: a write cannot be served from a copy; every order must reach the \emph{one authoritative record}, durably and in order
    \item \textbf{elasticity} adds the time axis: how quickly capacity follows load -- up \emph{and back down}
    \item reference point: Shopify's BFCM weekend, peaks $\sim 280$ million requests/minute, carried by replicated ``pods'' of a monolith
    \item the opposite end: \textbf{scale-to-zero} -- costing nothing while unused (the serverless promise)
\end{itemize}

\measured{sustained ingest rate (durably absorbed writes/s); time-to-capacity after a load step; cost of idling at zero}{load tests with load steps; elasticity-lag measurement}
\end{frame}

\begin{frame}{D3 -- Latency and predictability}
\emph{\textcolor{bankblue}{How long does one click take -- and how long does it take on a bad day?}}

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item \textbf{latency}: time between request and response; \textbf{predictability}: the distribution matters, not the average
    \item \textbf{averages lie}: a system can average $120$\,ms while every twentieth request takes four seconds -- and the most active users hit those most often
    \item vocabulary: \textbf{p50/p95/p99} percentiles; \textbf{tail-latency ratio} p99/p50; \textbf{cold start} $=$ extra delay when the serving component must first wake up
    \item stakes: Amazon $\sim 1\,\%$ of sales lost per additional $100$\,ms; Akamai: up to $7\,\%$ of conversions
\end{itemize}

\measured{p50/p95/p99 response times; cold-start frequency; tail-latency ratio}{distributed tracing (OpenTelemetry) -- following one request across every component; latency budgets as CI gates}
\end{frame}

% ============================================
% D4-D6 CORRECTNESS AND TRUST
% ============================================
\section{Correctness and Trust: D4--D6}

\begin{frame}{D4 -- Consistency and transactional integrity}
\emph{\textcolor{bankblue}{An e-banking transfer: can the same payment ever be booked twice -- or vanish halfway?}}

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item can concurrency and partial failure \textbf{corrupt the data} -- can the numbers silently stop being true?
    \item classic failure, the \textbf{lost update}: two processes read the same balance, both write -- the second silently overwrites the first
    \item vocabulary: \textbf{invariant} (must always hold: debit $=$ credit); \textbf{transactional integrity} (all or nothing); \textbf{staleness} (seconds a copy may lag)
    \item a single database hands you transactions \emph{for free}; every distribution boundary takes part of that away
\end{itemize}

\measured{anomaly rate under concurrent load; invariant-violation count (\textbf{target 0} for ledgers); staleness bound}{Jepsen-style tests (concurrent ops $+$ injected failures); reconciliation jobs}
\end{frame}

\begin{frame}{D5 -- Availability and fault isolation}
\emph{\textcolor{bankblue}{One component crashes at noon: does the whole app go dark, or does one widget show a spinner?}}

\vspace{0.2cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item availability: share of time the system does its job; fault isolation: \textbf{how much of the product dies when one part dies}
    \item \textbf{blast radius}: \% of functionality lost per component failure -- in a single process it is $100\,\%$ \emph{by construction}; \textbf{MTTR}: mean time to recovery
    \item operations vocabulary: \textbf{SLO} (``$99.9\,\%$ of requests succeed this month''), \textbf{error budget} (the tolerated $0.1\,\%$), \textbf{burn rate}
    \item run continuously in the pipeline, such an automated check of an architectural property is a \textbf{fitness function} -- a term we will use constantly
\end{itemize}

\measured{SLO attainment; error-budget burn; blast radius; MTTR}{chaos experiments -- deliberately kill components under load and measure what users lose}
\end{frame}

\begin{frame}{D6 -- Security and auditability}
\emph{\textcolor{bankblue}{The regulator asks: prove what happened to this one transaction, end to end.}}

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item keeping attackers out is necessary \emph{everywhere}; what discriminates between \textbf{structures} is \textbf{auditability} -- the ability to reconstruct history
    \item \textbf{audit trail}: complete, tamper-evident record of who changed what, when, on whose authority -- a \emph{legal duty} in supervised industries (FINMA, PCI DSS)
    \item \textbf{audit scope}: the portion of the system auditors must examine -- confining sensitive flows to a small region shrinks the scope, and the bill
    \item some structures record every change as an event \emph{as their normal mode}; others reassemble history from scattered log files
\end{itemize}

\measured{time to reconstruct a complete audit trail for one transaction; \% of state changes journaled (append-only)}{audit drills -- run like fire drills; immutable logs; PCI/FINMA scope reviews}
\end{frame}

% ============================================
% D7-D9 CHANGE AND DELIVERY
% ============================================
\section{Change and Delivery: D7--D9}

\begin{frame}{D7 -- Evolvability and maintainability}
\emph{\textcolor{bankblue}{A feature request arrives: how many places in the code must change?}}

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item prices the \textbf{next} change -- which, over a lifetime dominated by evolution (A5), dominates most others
    \item central measure, worth memorising: \textbf{change dispersion} $=$ modules touched by an average feature -- \emph{one is excellent, seventeen is an architecture problem}
    \item underlying variable: \textbf{coupling} -- metrics: CBO (coupling between objects), Martin's \emph{instability}
    \item \textbf{declared-boundary violations} (code bypassing declared module boundaries): target 0, enforceable in CI with ArchUnit / Spring Modulith
\end{itemize}

\measured{change dispersion over the version history; coupling metrics (CBO, instability); boundary violations (target 0)}{ArchUnit / Spring Modulith verification as CI gates; CK metric suite}
\end{frame}

\begin{frame}{D8 -- Simplicity and time-to-market}
\emph{\textcolor{bankblue}{Two students must ship a working MVP in one semester. Does the structure let them?}}

\vspace{0.2cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item how much machinery must \emph{exist, be understood, and be kept alive} before the first unit of value reaches a user
    \item a structure that requires a container orchestrator, a message broker, and a dozen repositories before ``hello, world'' has \textbf{failed this dimension for that team} -- however well it would carry Shopify's Black Friday
    \item this is where A2 bites hardest: the structures that win D8 tend to concede D2 or D11 -- a small team's rational choice \emph{differs} from a platform company's
\end{itemize}

\measured{time from empty repository to first production release; onboarding time to first merged contribution; count of distinct runtime technologies}{delivery calendar; team surveys; tech-radar count}
\end{frame}

\begin{frame}{D9 -- Testability and deployability}
\emph{\textcolor{bankblue}{Can a developer know within seconds that a change is safe -- and release it this afternoon without coordinating with three teams?}}

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item two abilities, \textbf{deliberately fused}: fast, trustworthy verification \emph{and} independent, low-risk release
    \item vocabulary: \textbf{hermetic test} (fully self-contained -- no shared staging, no live external service); \textbf{deployment frequency}; \textbf{change failure rate} (share of releases that break something)
    \item why fused: DORA 2017 found precisely this pair -- test without an integrated environment, deploy independently -- predicted delivery performance \emph{more strongly than automation itself}; both are surface expressions of \textbf{coupling}
\end{itemize}

\measured{test feedback time; \% hermetic tests; deployment frequency; change failure rate}{pipeline telemetry; DORA capability items}
\end{frame}

% ============================================
% D10-D11 ECONOMICS AND ORGANISATION
% ============================================
\section{Economics and Organisation: D10--D11}

\begin{frame}{D10 -- Operating cost efficiency}
\emph{\textcolor{bankblue}{The cloud bill tripled. Which part of the structure spends the money -- and what was it doing at 03:00?}}

\vspace{0.2cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item prices the running system -- \textbf{machines and people}
    \item vocabulary: \textbf{cost per request}; \textbf{idle cost} (capacity doing nothing -- the 03:00 question); \textbf{TCO}; \textbf{FTE}
    \item the hidden term matters most: a self-managed container platform is dominated not by compute prices but by \textbf{platform-team FTEs} -- the ``microservice premium'' materialises as staffing
    \item Prime Video's $> 90\,\%$ cost cut: the same dimension, seen from the infrastructure side
\end{itemize}

\measured{TCO split build/platform/run; cost per request; idle cost; platform-team FTEs}{FinOps reporting -- making cloud spend visible and attributable per team and feature}
\end{frame}

\begin{frame}{D11 -- Team scaling (Conway fit)}
\emph{\textcolor{bankblue}{The team grows from three to thirty. Do releases speed up -- or does everyone wait on everyone?}}

\vspace{0.2cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item \textbf{Conway's law}, in one sentence: a system's structure ends up mirroring the communication structure of the organisation that builds it
    \item consequence: \emph{every architecture decision is a team-structure decision} -- whether the architect intends it or not
    \item operational core: how many teams can design, build, and \textbf{release without waiting for each other}?
    \item DORA: \emph{deployments per developer per day} \textbf{rises} with team count in loosely coupled organisations -- and \textbf{falls} in tightly coupled ones
\end{itemize}

\measured{deployments per developer per day as the team count grows; number of teams releasing without cross-team coordination}{DORA scaling analysis; Team Topologies review}
\end{frame}

% ============================================
% D12 THE NEW DIMENSION
% ============================================
\section{The New Dimension: D12}

\begin{frame}{D12 -- AI integrability}
\emph{\textcolor{bankblue}{The new feature's core is an LLM call: eight seconds, paid per request, sometimes confidently wrong. How hard does the structure fight it?}}

\vspace{0.1cm}
\footnotesize
How cheaply can the structure host a component that is \textbf{slow, fallible, priced per call}? It needs three things:
\begin{itemize}\setlength\itemsep{2pt}
    \item a \textbf{queue}: a waiting line, so an eight-second call -- or a provider outage -- does not block everything behind it
    \item a \textbf{port}: a narrow, contract-shaped interface isolating the non-determinism, so deterministic tests can substitute a \emph{fake}
    \item a \textbf{measurement point}: cost and quality of \emph{every single call} observable -- providers price per \textbf{token}, so cost accrues \emph{per request}
\end{itemize}

\measured{seconds-scale latency tolerance; isolability of non-determinism behind contracts; token-cost observability per request}{\textbf{eval harness}: versioned test inputs with expected qualities; pass rate $\geq$ threshold as a CI gate -- the AI counterpart of a regression suite}
\end{frame}

\begin{frame}{One system, one profile}
\begin{examplebox}[a retail e-banking application, walked through the five groups]
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
    \item \textbf{Load and speed:} payday-morning peaks; reads $\gg$ writes; two seconds tolerated, not ten $\to$ D1, D3 matter; D2 modest
    \item \textbf{Correctness and trust:} a double-booked transfer is existential; the audit trail is a legal duty $\to$ D4, D6 \emph{as high as they go}; D5 high
    \item \textbf{Change and delivery:} monthly, formally reviewed releases -- but decades of regulatory change $\to$ D7 high, D9 moderate
    \item \textbf{Economics and organisation:} platform organisation exists anyway; dozens of teams $\to$ D10 medium, D11 high
    \item \textbf{AI:} a chat assistant is attractive -- but a confidently wrong answer about a balance is a \emph{safety} problem $\to$ D12 medium, hard guardrails
\end{itemize}
\end{examplebox}

\vspace{0.05cm}
\footnotesize The judgements are debatable; the point is not: \textbf{a real system has a \emph{profile}} -- demanding on a few dimensions, relaxed on others. Writing it down rigorously is the second half of today.
\end{frame}

% ============================================
% WHY EXACTLY THESE TWELVE
% ============================================
\section{Why Exactly These Twelve}

\begin{frame}{Quality attributes, not functions}
\footnotesize
\begin{columns}[T]
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{Functional requirement}}
\begin{itemize}
    \item \emph{what} the system shall do
    \item compute interest, post a booking, render a feed
    \item largely \textbf{structure-neutral} (A3)
\end{itemize}
\end{column}
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{Quality attribute requirement}}
\begin{itemize}
    \item \emph{how well}, under which conditions, at what cost
    \item the misleading classic term: ``non-functional''
    \item this is what \textbf{structure determines}
\end{itemize}
\end{column}
\end{columns}

\vspace{0.3cm}
\begin{examplebox}[the same function, three structures]
``Post a booking'' can run inside a layered monolith, as a \emph{saga} across microservices, or as an event-sourced log. The \textbf{function is identical} -- the consistency guarantee, the latency distribution, the audit trail, and the cost of the next change are \textbf{radically different}.
\end{examplebox}

\vspace{0.15cm}
All twelve dimensions are quality attributes or workload/constraint characteristics -- \textbf{never features}.
\end{frame}

\begin{frame}{The names: ISO/IEC 25010:2023}
\footnotesize
The naming standard for quality attributes -- nine characteristics, each with sub-characteristics:

\vspace{0.15cm}
\begin{center}
\footnotesize
functional suitability $\cdot$ performance efficiency $\cdot$ compatibility $\cdot$ interaction capability $\cdot$ reliability $\cdot$ \textbf{security} $\cdot$ maintainability $\cdot$ \textbf{flexibility} $\cdot$ \textbf{safety}
\end{center}

\vspace{0.15cm}
Three 2023 changes matter directly for this module:
\begin{itemize}\setlength\itemsep{1pt}
    \item \textbf{Safety} became a new top-level characteristic (fail safe, hazard warning) -- exactly what a confidently-wrong AI component requires
    \item \emph{portability} became \textbf{Flexibility}, with an explicit new \emph{scalability} sub-characteristic
    \item \textbf{Security} gained \emph{resistance} -- sustaining operation under attack: the normative hook for prompt-injection robustness
\end{itemize}

\vspace{0.15cm}
\begin{keypoint}
The 2023 vocabulary covers AI-bearing systems \textbf{without private extensions} -- A6 starts with the quality model itself.
\end{keypoint}
\end{frame}

\begin{frame}{Three admission conditions}
\small
A candidate became one of the twelve only if it passed all three:

\vspace{0.15cm}
\begin{enumerate}\setlength\itemsep{2pt}
    \item \textbf{Standard anchoring} -- maps to ISO/IEC 25010:2023 vocabulary (reaching beyond it -- cost, organisation -- is stated explicitly)
    \item \textbf{Discrimination} -- must distinguish at least two of the seven patterns; a dimension on which all patterns score alike carries no matching information
    \item \textbf{Instrumentation} -- must have a defined \textbf{response measure and measurement instrument}: every rating is a testable prediction, not an adjective
\end{enumerate}

\vspace{0.15cm}
\begin{hinweisbox}
\footnotesize \textbf{No instrument, no dimension} -- this excludes ``elegance'' and ``future-proofness''. And ISO 25010 is a \emph{taxonomy}, not a \emph{metric}: do not argue about the box a concern belongs to -- write it as a \textbf{scenario with a response measure} and the question dissolves.
\end{hinweisbox}
\end{frame}

\begin{frame}{The reference card (1/2): D1--D6}
\begin{center}
\scriptsize
\begin{tabular}{@{}p{0.6cm}p{2.9cm}p{4.6cm}p{4.4cm}@{}}
\toprule
\textbf{\#} & \textbf{Dimension} & \textbf{Response measure (examples)} & \textbf{Instrument} \\
\midrule
D1 & Read scalability & throughput at $k\times$ replication; cache hit ratio & load tests; RED metrics \\
D2 & Write scalability \& elasticity & sustained ingest rate; time-to-capacity; scale-to-zero cost & load steps; elasticity lag \\
D3 & Latency \& predictability & p50/p95/p99; cold starts; tail ratio p99/p50 & distributed tracing; latency budgets in CI \\
D4 & Consistency \& integrity & anomaly rate; invariant violations ($0$ for ledgers); staleness bound & Jepsen-style tests; reconciliation jobs \\
D5 & Availability \& fault isolation & SLO attainment; error-budget burn; blast radius; MTTR & SLOs; chaos experiments \\
D6 & Security \& auditability & time to reconstruct an audit trail; \% changes journaled & audit drills; immutable logs; scope reviews \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.1cm}
\footnotesize\textcolor{codegray}{Full version with ISO anchors: the script's canonical reference card (Table 3).}
\end{frame}

\begin{frame}{The reference card (2/2): D7--D12}
\begin{center}
\scriptsize
\begin{tabular}{@{}p{0.6cm}p{2.9cm}p{4.6cm}p{4.4cm}@{}}
\toprule
\textbf{\#} & \textbf{Dimension} & \textbf{Response measure (examples)} & \textbf{Instrument} \\
\midrule
D7 & Evolvability \& maintainability & change dispersion; coupling (CBO, instability); boundary violations ($0$) & ArchUnit / Spring Modulith in CI \\
D8 & Simplicity \& time-to-market & empty repo $\to$ first release; onboarding time; technology count & delivery calendar; surveys \\
D9 & Testability \& deployability & test feedback time; \% hermetic tests; deployment frequency; change failure rate & pipeline telemetry; DORA items \\
D10 & Operating cost efficiency & TCO build/platform/run; cost per request; idle cost; platform FTEs & FinOps reporting \\
D11 & Team scaling (Conway) & deployments per developer per day; teams releasing without coordination & DORA scaling; Team Topologies \\
D12 & AI integrability & seconds-scale latency tolerance; isolable non-determinism; token-cost observability & eval-harness pass rate in CI; cost budgets \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

% ============================================
% DEMAND SIDE: ASR, QAW, SCENARIOS
% ============================================
\section{From Wishes to Scenarios}

\begin{frame}{The demand side: what we are building}
\begin{center}
\Large
$R(a) \;=\; \bigl(\underbrace{w_1, \dots, w_{12}}_{\text{priority weights}};\;\; \underbrace{S(a)}_{\text{workload shape}};\;\; \underbrace{K(a)}_{\text{hard constraints}}\bigr)$
\end{center}

\vspace{0.4cm}
None of these is written down by intuition -- each is \textbf{produced} by a defined method:

\vspace{0.2cm}
\begin{center}
\small
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Step} & \textbf{Method} & \textbf{Produces} \\
\midrule
1 & elicitation (QAW) & a prioritised pool of candidate \textbf{ASRs} \\
2 & six-part scenarios & the candidates in \textbf{falsifiable form} \\
3 & utility tree & the twelve \textbf{weights} $w_1, \dots, w_{12}$ \\
4 & inventory & workload shape $S(a)$, constraints $K(a)$ \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

\begin{frame}{Architecturally significant requirements (ASR)}
\begin{definitionbox}[Architecturally significant requirement]
A requirement with a \textbf{profound effect on the architecture} -- one whose late accommodation would be disproportionately expensive -- and typically \textbf{difficult to achieve}.
\end{definitionbox}

\vspace{0.3cm}
\small
Empirical finding (Chen et al.\ 2013; 90 practitioners, $> 500$ organisations):
\begin{itemize}
    \item ASRs are typically \textbf{poorly specified, vague, and implicit}
    \item they hide inside business goals: \emph{``we plan to enter three new markets next year''} $\;\to\;$ a scalability ASR \emph{and} a compliance ASR
    \item they cannot be read off a requirements document -- they must be \textbf{elicited}
\end{itemize}
\end{frame}

\begin{frame}{Eliciting ASRs: the Quality Attribute Workshop (QAW)}
\small
The SEI's established format -- its essence is two design choices:

\vspace{0.2cm}
\begin{columns}[T]
\begin{column}{0.44\textwidth}
\textcolor{bankblue}{\textbf{1. Who is in the room}}
\begin{itemize}\setlength\itemsep{1pt}
    \item \emph{not} the development team alone
    \item the stakeholders whose concerns the architecture must balance:
    \item users, operators, auditors, regulators, product owners
\end{itemize}
\end{column}
\begin{column}{0.52\textwidth}
\textcolor{bankblue}{\textbf{2. The sequence}}
\begin{enumerate}\setlength\itemsep{1pt}
    \item business and mission drivers first
    \item identify architectural drivers
    \item scenario \textbf{brainstorming}
    \item consolidation
    \item \textbf{prioritisation by stakeholder vote}
    \item refinement of the top candidates into the measurable six-part form
\end{enumerate}
\end{column}
\end{columns}

\vspace{0.3cm}
\emph{Produced:} the raw material of $R(a)$ -- prioritised candidate ASRs, \textbf{not yet measurable}.
\end{frame}

\begin{frame}{The measurable form: the six-part scenario}
\begin{definitionbox}[Quality attribute scenario]
\footnotesize
\begin{enumerate}\setlength\itemsep{0pt}
    \item \textbf{Source of stimulus} -- who or what triggers it: a user, another system, an attacker
    \item \textbf{Stimulus} -- the arriving event: a request, a failure, a load spike
    \item \textbf{Environment} -- the operating condition: normal, overload, degraded
    \item \textbf{Artifact} -- the part of the system stimulated
    \item \textbf{Response} -- the desired observable reaction
    \item \textbf{Response measure} -- the quantity, \textbf{with number and unit}, by which success is judged
\end{enumerate}
\end{definitionbox}

\vspace{0.05cm}
\begin{hinweisbox}
\small The \textbf{response measure} is the non-negotiable part: ``the system shall be scalable'' names an \emph{aspiration}; a scenario with a response measure names a \emph{test}.
\end{hinweisbox}
\end{frame}

\begin{frame}{Worked scenario 1: availability in a payment service}
\begin{examplebox}[banking]
\footnotesize
\emph{Source:} a heartbeat monitor. \emph{Stimulus:} reports the failure of one application server. \emph{Environment:} normal operation, mid-day load. \emph{Artifact:} the payment service. \emph{Response:} requests are redirected to replicas; operations staff notified; in-flight transactions complete or roll back atomically. \emph{\textbf{Response measure:}} failover $< 30$\,s; \textbf{zero} transactions lost or double-posted.
\end{examplebox}

\vspace{0.15cm}
\footnotesize
``The payment service shall be highly available'' hides \textbf{three architectural decisions} the scenario exposes:
\begin{itemize}\setlength\itemsep{1pt}
    \item replicas (redundancy tactic) \quad $\cdot$ \quad failure detection (heartbeat tactic)
    \item transactional atomicity \emph{across} the failover -- a guarantee some patterns provide structurally, others do not
\end{itemize}

\vspace{0.1cm}
The response measure is \textbf{directly executable} as a chaos experiment: kill an instance under load, measure.\\
\textbf{One artefact, three roles:} requirement, design driver, test specification.
\end{frame}

\begin{frame}{Worked scenario 2: safety in an AI advisory platform}
\begin{examplebox}[Axis B]
\footnotesize
\emph{Source:} a customer. \emph{Stimulus:} submits a request for which the LLM generates a \textbf{factually wrong} recommendation. \emph{Environment:} normal operation. \emph{Artifact:} the advisory platform. \emph{Response:} the deterministic validation layer detects and blocks the answer and escalates to a human advisor. \emph{\textbf{Response measure:}} detection rate $\geq 99\,\%$ on the \emph{versioned evaluation set}, $< 2$\,s added latency.
\end{examplebox}

\vspace{0.15cm}
\footnotesize Two things are notable:
\begin{itemize}\setlength\itemsep{1pt}
    \item the six-part form needed \textbf{no extension} for a non-deterministic component -- \textbf{A6 at work}: the stimulus is probabilistic (the model \emph{will} sometimes hallucinate), and the requirement is placed \textbf{on the system around the model}, not on the model
    \item the response measure \emph{presupposes an artefact}: a versioned evaluation set -- the \textbf{eval harness} (D12)
\end{itemize}

\vspace{0.1cm}
\textcolor{codegray}{In ISO/IEC 25010:2023 terms: a \emph{Safety} scenario (fail safe, hazard warning).}
\end{frame}

% ============================================
% UTILITY TREE
% ============================================
\section{The Utility Tree}

\begin{frame}{The utility tree: prioritising scenarios}
\small A workshop produces more scenarios than any analysis can carry. The \textbf{utility tree} (ATAM) prioritises them top-down; every leaf is rated H/M/L on \textbf{business importance} (what does failure cost us?) and \textbf{achievement difficulty} (how hard, architecturally?).

\vspace{0.15cm}
\begin{center}
\resizebox{0.72\textwidth}{!}{%
\begin{tikzpicture}[
    sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\scriptsize\sffamily, line width=0.8pt, inner sep=4pt},
    root/.style={sysbox, fill=bankblue!20, draw=bankblue, font=\small\sffamily\bfseries, minimum height=1.1cm, minimum width=1.9cm},
    attr/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=2.6cm, minimum height=0.85cm},
    leafhh/.style={sysbox, fill=bankred!15, draw=bankred, text width=6.6cm},
    leaf/.style={sysbox, fill=gray!12, draw=gray!60!black, text width=6.6cm},
    arr/.style={-{Stealth[length=2.2mm]}, thick, gray!60!black}
]
    \node[root] (util) at (0,0) {Utility};
    \node[attr] (cons) at (3.6,2.7)  {Consistency \&\\integrity};
    \node[attr] (avail) at (3.6,0.9) {Availability};
    \node[attr] (perf) at (3.6,-0.9) {Performance};
    \node[attr] (mod) at (3.6,-2.7)  {Modifiability};
    \node[leafhh] (l1) at (9.2,2.7)  {\textbf{(H,\,H)} No booking lost or double-posted under concurrent node failure; invariant violations $= 0$};
    \node[leafhh] (l2) at (9.2,0.9)  {\textbf{(H,\,H)} Failover of the payment service $< 30$\,s with zero transaction loss};
    \node[leaf]  (l3) at (9.2,-0.9)  {(H,\,M) Card authorisation p95 $< 2$\,s at $3\times$ baseline load};
    \node[leaf]  (l4) at (9.2,-2.7)  {(M,\,H) New regulatory report integrated in $\leq 10$ person-days, touching $\leq 2$ modules};
    \draw[arr] (util) -- (cons);
    \draw[arr] (util) -- (avail);
    \draw[arr] (util) -- (perf);
    \draw[arr] (util) -- (mod);
    \draw[arr] (cons) -- (l1);
    \draw[arr] (avail) -- (l2);
    \draw[arr] (perf) -- (l3);
    \draw[arr] (mod) -- (l4);
\end{tikzpicture}%
}
\end{center}

\centering\small The \textcolor{bankred}{\textbf{(H,\,H) leaves}} -- important \emph{and} hard -- are the architecturally critical points.
\end{frame}

\begin{frame}{From leaves to weights}
\small The utility tree is the \textbf{methodical derivation of the weights}:

\vspace{0.15cm}
\begin{keypoint}
\small Dimension $D_i$ receives $w_i(a) = \textbf{High}$ exactly when the class's characteristic utility tree has \textbf{(H,\,H) leaves} under the corresponding attribute. Medium and Low follow from the remaining leaf ratings.
\end{keypoint}

\vspace{0.2cm}
\footnotesize What a weight \emph{asserts}:
\begin{itemize}\setlength\itemsep{2pt}
    \item \textbf{High} is not enthusiasm -- it is a claim with teeth: binding scenarios exist whose failure is \emph{existential}. High weights carry \textbf{veto power} in the match (week 3).
    \item Every High must survive the question: \emph{``show me the (H,\,H) leaf.''}
    \item \textbf{Low} is equally deliberate: not ``we do not care'' but \emph{``we will not pay structure for this''}
    \item \textbf{Medium} is the tradeable middle.
\end{itemize}
\end{frame}

\begin{frame}{What High and Low look like (selection)}
\scriptsize
\begin{center}
\begin{tabular}{@{}p{2.6cm}p{5.3cm}p{5.2cm}@{}}
\toprule
\textbf{Dimension} & \textbf{High: example} & \textbf{Low: example} \\
\midrule
D1 Read scalability & a public social/content feed: thousands of reads per write & an ERP used by clerks: load bounded by headcount \\
D2 Write scal.\ \& elasticity & Black Friday checkout: $10$--$50\times$ seasonal write peaks & a BI warehouse loaded once, nightly \\
D4 Consistency & a payments ledger: one double booking is existential & a social feed: a stale like-count harms nobody \\
D8 Simplicity \& TTM & an internal back-office tool: its value is shipping this quarter & a core ledger: care beats speed \\
D11 Team scaling & a platform built by thirty teams & a two-person project: nothing to mirror \\
D12 AI integrability & the AI-native advisory platform: hosting fallible components \emph{is} the product & a classical accounting module \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.15cm}
\footnotesize Note the \textbf{D4 row}: ledger and feed are near-perfect \emph{mirror images} -- a structure optimised for one is close to pessimal for the other. Part III uses exactly this pair as its anchor.
\end{frame}

% ============================================
% SHAPE, CONSTRAINTS, R(a) ASSEMBLED
% ============================================
\section{Workload Shape, Constraints, and $R(a)$}

\begin{frame}{The last two components: shape and constraints}
\footnotesize
\textbf{Workload shape $S(a)$} -- how load arrives:
\begin{itemize}\setlength\itemsep{1pt}
    \item \emph{interactive} $\cdot$ \emph{continuous stream} $\cdot$ \emph{scheduled batch} $\cdot$ explicitly \emph{hybrid} -- with its signature: read/write ratio, load pattern, latency budget, data volume, change rate
    \item \textbf{measured, not guessed}: ratios from access logs, patterns from telemetry
    \item patterns have native shapes too -- the match enforces this as a \emph{gate}: a batch pipeline cannot carry an interactive core
\end{itemize}

\vspace{0.15cm}
\textbf{Hard constraints $K(a)$} -- an explicit inventory:
\begin{itemize}\setlength\itemsep{1pt}
    \item regulatory obligations (BCBS 239, PCI DSS, EU AI Act), team size and skills, budget, mandated platforms
\end{itemize}

\vspace{0.15cm}
\begin{hinweisbox}
\textbf{Constraints are knock-out filters, never weights.} A violating pattern is excluded \emph{before} any scoring -- never averaged away: an architecture that cannot produce the legally required audit trail is \textbf{not a candidate}.
\end{hinweisbox}
\end{frame}

\begin{frame}{Worked construction: $R(\text{C10})$ -- the advisory platform (your project!)}
\footnotesize
\begin{center}
\footnotesize
\begin{tabular}{@{}lp{9.6cm}@{}}
\toprule
\textbf{High} & D6 auditability (provenance) $\cdot$ D7 evolvability (model/prompt churn) $\cdot$ D9 testability (evals) $\cdot$ D10 cost \emph{per request} $\cdot$ D12 AI \\
\textbf{Medium} & D1, D3, D4, D5, D8 \\
\textbf{Low} & D2, D11 \\
\textbf{Shape} & \emph{hybrid}: interactive advisory dialogue $+$ batch pipelines (indexing, eval runs) \\
\textbf{Constraints} & EU AI Act (logging, documentation, human oversight); GDPR \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.2cm}
Two Mediums surprise students:
\begin{itemize}\setlength\itemsep{1pt}
    \item \textbf{D3}: users accept seconds for an advisory answer -- the concern is \emph{cost per request}, not speed
    \item \textbf{D4}: a hybrid -- knowledge index eventually consistent, transaction and audit path strictly ACID
\end{itemize}

\vspace{0.1cm}
Every High traces to (H,\,H) scenarios; the constraints are knock-out conditions for the match.
\end{frame}

\begin{frame}{This week's exercise: your QAW}
\begin{projektbox}
\footnotesize Run a \textbf{compressed QAW} in stakeholder roles (retail customer, compliance officer, operations engineer, product owner):
\begin{itemize}\setlength\itemsep{1pt}
    \item brainstorm, consolidate, prioritise scenarios; refine the top candidates into the \textbf{six-part form} -- each with a \emph{numeric} response measure
    \item assemble a \textbf{utility tree}; identify the \textbf{(H,\,H) leaves}
\end{itemize}
\textbf{Deliverable:} $\geq 8$ scenarios, $\geq 3$ addressing the AI components (answer correctness, token cost per request, provider migration).
\end{projektbox}

\vspace{0.15cm}
\begin{hinweisbox}
\small Not a warm-up: the (H,\,H) leaves become the \textbf{weights of your requirements profile} (A1, next week) -- matched in your week-6 ADR, defended in week 14.
\end{hinweisbox}
\end{frame}

% ============================================
% SUMMARY
% ============================================
\section{Summary}

\begin{frame}{Summary}
\footnotesize
\begin{enumerate}\setlength\itemsep{2pt}
    \item Twelve dimensions in five groups -- each a recurring question, \textbf{named and instrumented}: \emph{no instrument, no dimension}
    \item ISO/IEC 25010:2023 supplies the names -- and since 2023 covers AI systems without private extensions
    \item ASRs are vague and implicit $\to$ \textbf{elicited} in a QAW; they discriminate only as \textbf{six-part scenarios} -- the response measure (number $+$ unit) is non-negotiable
    \item The \textbf{utility tree} derives the weights: (H,\,H) leaves $\to$ High; \textbf{High $=$ veto claim}
    \item $R(a) = (w_1, \dots, w_{12};\, S(a);\, K(a))$ -- weights, measured shape, knock-out constraints
\end{enumerate}

\vspace{0.2cm}
\begin{keypoint}
\textbf{Maxim 6.} An architecture decision without a response measure is an \emph{opinion}; with a response measure and a fitness function it is a \emph{testable hypothesis}.
\end{keypoint}
\end{frame}

\begin{frame}{Next week}
\begin{columns}[T]
\begin{column}{0.55\textwidth}
\textcolor{bankblue}{\textbf{Lecture 3 -- the supply side and the match}}
\begin{itemize}
    \item the seven candidate patterns, previewed
    \item capability profiles $C(p)$ via \textbf{tactics}
    \item the three-stage, non-compensatory \textbf{fit} procedure
    \item worked mini-match: the advisory platform (C10!) against three candidates
    \item recording decisions: \textbf{ADR / MADR}
\end{itemize}
\end{column}
\begin{column}{0.42\textwidth}
\textcolor{bankblue}{\textbf{Reading}}
\begin{itemize}
    \item this week: script Part I, Sections 2--3
    \item ahead: Part I, Sections 4--6
\end{itemize}

\vspace{0.3cm}
\textcolor{bankblue}{\textbf{Exercise}}
\begin{itemize}
    \item Requirements workshop I: QAW $+$ utility tree
    \item \textbf{A1 due end of week 3}
\end{itemize}
\end{column}
\end{columns}
\end{frame}

% ============================================
% END
% ============================================
\FHGRClosingPage[][{\color{white}\parbox{0.9\paperwidth}{\centering Thank you!\\[3ex]
{\normalsize\mdseries Dr.\ Florian Herzog\\[0.9ex]
Fachhochschule Graub\"unden, Chur\\[2.4ex]
{\small AISE502 -- AI in Software Engineering II}}}}]

\end{document}