brief-to-architecture

ASR-Analyse

Ein Briefing ist keine Spezifikation. Es ist ein Haufen von Wünschen, Annahmen und halb ausformulierten Randbedingungen – und darin verborgen liegen die wenigen Anforderungen, die tatsächlich die Form und die Kosten des Systems bestimmen. Dieses Skill findet diese, macht sie präzise und prüft sie aufeinander, bevor jemand einen Aufwand oder einen Entwurf zusagt.

Eine architektonisch signifikante Anforderung (ASR) ist eine Anforderung mit messbarem Einfluss auf die Architektur: Ihre Erfüllung erzwingt eine strukturelle Entscheidung, schränkt eine Technologie ein, setzt eine schwer erreichbare Qualitätslatte oder interagiert mit anderen Anforderungen so, dass die Optionen begrenzt werden. Die meisten Anforderungen in einem Briefing sind nicht architektonisch signifikant. Die Aufgabe besteht darin, die wenigen entscheidenden von den vielen zu trennen und zu begründen, warum jede von ihnen wichtig ist.

Der qualitätsattributbezogene Teil dieser Arbeit ist verankert in ISO/IEC 25010, dem internationalen Standard für Produktqualitätsmodelle. Die Verwendung eines Standardsatzes von Qualitätsmerkmalen hält die Analyse vollständig (jedes Mal werden dieselben Dimensionen geprüft) und gibt allen Beteiligten eine gemeinsame Sprache. Siehe references/quality-model.md.

Der Ablauf

Ein Briefing durchläuft sechs Schritte. Jeder erzeugt ein Artefakt, das der nächste Schritt verwendet.

1. Extrahieren, nicht transkribieren. Lies die rohe Eingabe und extrahiere die tatsächlichen Anforderungen, einschließlich derer, die als Funktionen, Beschwerden oder beiläufige Bemerkungen formuliert sind. Ein Satz wie „unser Black-Friday-Traffic ist 40× höher als normal“ ist keine Funktionsanfrage; es ist eine Performance- und Skalierbarkeitsanforderung im Verborgenen. Interpretiere. Siehe references/asr-framework.md zur Erkennung architektonischer Signifikanz.

2. Klassifizieren. Sortiere jede extrahierte Anforderung in einen von drei Eimern:

   • Funktional – was das System tun muss.
   • Qualitätsattribut – wie gut es es tun muss (Performance, Zuverlässigkeit, Sicherheit, Wartbarkeit, …). Verwende die ISO/IEC 25010-Merkmale, um jedes Mal die gleichen Bereiche abzudecken – references/quality-model.md.
   • Randbedingung – eine feste, nicht verhandelbare Grenze (eine vorgeschriebene Technologie, eine Vorschrift, eine Frist, ein bestehendes System). Randbedingungen stehen nicht zur Diskussion; sie prägen alles andere.

3. Schärfen. Schreibe jede signifikante Anforderung so um, dass sie eindeutig und testbar ist, und gib ihre architektonische Implikation an – die strukturelle Konsequenz, wenn man sie ernst nimmt. Entferne Lösungen, die der Autor eingeschmuggelt hat („verwende Kafka“ ist ein vorgeschlagener Mechanismus, keine Anforderung; die Anforderung dahinter ist der Durchsatz oder die Entkopplung). Eine Anforderung, die man nicht testen kann, kann man nicht abschätzen.

4. Auf zwei Achsen priorisieren. Nicht jede ASR verdient gleich viel Aufmerksamkeit. Bewerte jede nach:

   • Geschäftswert – wie sehr das Ergebnis für den Kunden zählt.
   • Architektonische Auswirkung – wie stark sie den Entwurf einschränkt und wie teuer eine Rücknahme ist. (Hohe Auswirkung bedeutet Irreversibilität und Schadensradius, nicht Aufwand.) Die Anforderungen, die auf beiden Achsen hoch sind, entscheiden wirklich über die Architektur. Investiere deine Analyse dort. Siehe references/scenarios-and-priorities.md.

5. Machbarkeit prüfen. Prüfe vor jedem Entwurf, ob die priorisierten Anforderungen koexistieren können. Die gefährlichsten Briefings sind intern widersprüchlich: ein Latenzziel, ein Konsistenzziel und eine Kostenobergrenze, die nicht alle gleichzeitig wahr sein können. Siehe references/feasibility-check.md für eine konkrete Methode, einschließlich der arithmetischen für numerische Anforderungen.

6. Szenarien spezifizieren und Strategien auswählen. Schreibe für die priorisierten Qualitätsattribute messbare Qualitätsszenarien (ein Auslöser, die Bedingungen und eine messbare Reaktion), wähle dann die Designstrategien aus, die jedes erfüllen würden, mit ihren Kosten. Siehe references/scenarios-and-priorities.md und references/design-strategies.md.

Disziplin, die die Analyse vertrauenswürdig macht

• Erkenne die Gerüche. Briefings haben wiederkehrende Fehlermuster: vage Superlative, versteckte Annahmen, Zahlen ohne Einheit oder Quelle, widersprüchliche Anforderungen. references/brief-smells.md ist ein Katalog davon und was zu fragen ist, wenn man eines sieht.
• Kennzeichne jede Annahme. Wenn das Briefing schweigt und du eine Lücke füllst, beschrifte sie: Ist es eine gefüllte Lücke (Information fehlt, du hast einen Standardwert geliefert), eine Interpretation (mehrdeutig, du hast eine Lesart gewählt) oder eine Umfangseinschränkung (du hast etwas bewusst ausgeschlossen)? Ein Aufwand, der auf unbeschrifteten Annahmen basiert, ist eine Schätzung im Anzug.
• Ende mit den Fragen, die die Form ändern. Das Ergebnis einer guten Analyse enthält die zwei oder drei Fragen, deren Antworten die Architektur am meisten verändern würden. Darum sollte es im nächsten Kundengespräch gehen.
• Eine Aufwandsschätzung ist nur so verteidigbar wie die Analyse darunter. Deshalb kommt die Analyse zuerst: Sie macht die Zahl, die du dem Kunden nennst, zu etwas, hinter dem du stehen kannst.

So verwendest du dieses Skill

• Ein Briefing von Anfang bis Ende analysieren → führe den obigen Sechs-Schritte-Ablauf aus.
• Entscheiden, was architektonisch signifikant ist → references/asr-framework.md.
• Qualitätsattribute auswählen und abdecken → references/quality-model.md (ISO/IEC 25010).
• Testbare Qualitätsszenarien schreiben und priorisieren → references/scenarios-and-priorities.md.
• Designansätze pro Qualitätsattribut auswählen → references/design-strategies.md.
• Widersprüche und unmögliche Kombinationen erkennen → references/feasibility-check.md.
• Ein Briefing kritisch lesen → references/brief-smells.md.
• Das schriftliche Ergebnis gestalten → references/output-template.md.