arc42-write-s01-introduction

name	arc42-write-s01-introduction
description	Schreibt arc42 Sektion 1 (Einführung und Ziele): Aufgabenstellung, Qualitätsziele, Stakeholder. Use when: Sektion 1 schreiben, Einführung, Ziele, Requirements Overview, Quality Goals, Stakeholder erstellen, Anforderungsüberblick dokumentieren.

arc42 Sektion 1: Einführung und Ziele schreiben

Zweck

Diese Sektion beschreibt die relevanten Anforderungen und treibenden Kräfte, die Softwarearchitekten und das Entwicklungsteam berücksichtigen müssen:

• Grundlegende Business-Ziele, wesentliche Features und funktionale Anforderungen
• Qualitätsziele für die Architektur
• Relevante Stakeholder und deren Erwartungen

Dateistruktur

01-Einfuehrung-und-Ziele/
├── 01-01-Aufgabenstellung.md
├── 01-02-Qualitaetsziele.md
└── 01-03-Stakeholder.md

Interaktive Fragen an den User

Für 1.1 Aufgabenstellung

1. Was ist der Zweck des Systems? Was wird gebaut und warum?
2. Welche Business-Ziele verfolgt das System? Welche Geschäftsprozesse werden unterstützt?
3. Was sind die wichtigsten Features/Use-Cases? Top 5-10 wesentliche Funktionen
4. Gibt es bestehende Anforderungsdokumente? (Verweis oder Link)
5. Wer sind die Nutzer des Systems? Welche Rollen gibt es?

Für 1.2 Qualitätsziele

1. Was sind die Top 3-5 Qualitätseigenschaften für die Architektur? (z.B. Performance, Sicherheit, Skalierbarkeit, Wartbarkeit, Verfügbarkeit)
2. Wie misst man den Erfolg dieser Qualitätsziele? Konkrete Szenarien oder Metriken
3. Welche Qualitätseigenschaften sind am wichtigsten für die Stakeholder?
4. Gibt es Qualitätskonflikte? (z.B. Performance vs. Sicherheit)

Für 1.3 Stakeholder

1. Wer muss die Architektur kennen? (z.B. Entwickler, Architekten, PO)
2. Wer muss von der Architektur überzeugt werden? (z.B. Management, Kunden)
3. Wer arbeitet mit der Architektur oder dem Code? (z.B. Entwickler, DevOps)
4. Wer braucht die Dokumentation? (z.B. Neue Teammitglieder, Auditoren)
5. Wer trifft Entscheidungen über das System? (z.B. CTO, PO, Architekt)

Codebase-Analyse-Hinweise

Bei Codebase-Analyse kannst du folgendes ableiten:

• Aufgabenstellung: Aus README.md, package.json description, Maven <name>/<description>, API-Endpunkten
• Qualitätsziele: Aus Test-Coverage-Konfiguration (Performance-Tests → Performance wichtig), Security-Libraries (→ Sicherheit wichtig), Monitoring-Setup (→ Verfügbarkeit wichtig)
• Stakeholder: Meist NICHT aus Code ableitbar → Rückfrage nötig

Templates

01-01-Aufgabenstellung.md

# Aufgabenstellung

## Kurzbeschreibung

<1-3 Sätze: Was ist das System und wozu dient es?>

## Business-Ziele

- <Ziel 1>
- <Ziel 2>
- <Ziel 3>

## Wesentliche funktionale Anforderungen

| ID | Anforderung | Beschreibung |
|----|------------|--------------|
| F1 | <Name> | <Kurzbeschreibung> |
| F2 | <Name> | <Kurzbeschreibung> |

## Verweise

- <Link zu Anforderungsdokumenten, Jira, Confluence etc.>

01-02-Qualitaetsziele.md

# Qualitätsziele

Die folgenden Qualitätsziele haben höchste architektonische Relevanz:

| Priorität | Qualitätsziel | Szenario |
|-----------|--------------|----------|
| 1 | <z.B. Performance> | <Konkretes Szenario: "Das System antwortet auf 95% der Anfragen innerhalb von 200ms"> |
| 2 | <z.B. Sicherheit> | <Konkretes Szenario> |
| 3 | <z.B. Wartbarkeit> | <Konkretes Szenario> |

> Detaillierte Qualitätsanforderungen und -szenarien finden sich in [Sektion 10](../10-Qualitaetsanforderungen/).

01-03-Stakeholder.md

# Stakeholder

| Rolle | Beschreibung | Erwartung an Architektur |
|-------|-------------|------------------------|
| <Rolle 1> | <Kurzbeschreibung> | <Was erwartet diese Rolle?> |
| <Rolle 2> | <Kurzbeschreibung> | <Was erwartet diese Rolle?> |

Best Practices (aus arc42-Tipps)

• Kompakt halten: Anforderungsüberblick soll ein kurzer Extrakt sein, kein vollständiges Requirements-Dokument
• Business-Ziele hervorheben: Nicht nur Features listen, sondern den Geschäftswert betonen
• Qualitätsziele konkret machen: Keine Buzzwords wie "performant" — stattdessen messbare Szenarien
• Maximal 3-5 Qualitätsziele: Nur die architektonisch relevantesten, Details in Sektion 10
• Stakeholder breit suchen: Nicht nur offensichtliche Rollen, auch indirekte Betroffene berücksichtigen
• Erwartungen dokumentieren: Zu jedem Stakeholder die konkreten Erwartungen an Architektur und Dokumentation angeben
• Qualitätsziele mit Lösungsstrategie verbinden: Verweis auf Sektion 4, wie die Ziele erreicht werden

Querverweise

• → Sektion 4 (Lösungsstrategie): Qualitätsziele aus 1.2 müssen durch strategische Ansätze in S4 adressiert werden
• → Sektion 10 (Qualitätsanforderungen): Detaillierte Szenarien zu den Qualitätszielen aus 1.2
• → Sektion 12 (Glossar): Domänenbegriffe aus der Aufgabenstellung sollten im Glossar definiert sein