Arc42 Write S02 Constraints

Für 2.2 Organisatorische Randbedingungen

1. Wie ist das Team organisiert? (Größe, Verteilung, Erfahrung)
2. Welche Entwicklungsprozesse gelten? (Scrum, Kanban, SAFe etc.)
3. Gibt es Zeitvorgaben oder Budget-Constraints?
4. Gibt es regulatorische Anforderungen? (DSGVO, ISO 27001, PCI-DSS etc.)
5. Gibt es unternehmensweite Architektur-Vorgaben? (Enterprise Architecture, Referenzarchitekturen)

Für 2.3 Konventionen

1. Gibt es Coding-Standards? (Style Guides, Linting-Regeln)
2. Welche Dokumentationskonventionen gelten? (Sprache, Format)
3. Gibt es Versionierungsvorgaben? (Branching-Modell, Semantic Versioning)
4. Gibt es Naming-Conventions? (Packages, Klassen, APIs)
5. Gibt es Test-Vorgaben? (Mindest-Coverage, Test-Arten)

Codebase-Analyse-Hinweise

• Technische Constraints: Aus Build-Files (pom.xml → Java-Version, package.json → Node/TS-Version), Compiler-Einstellungen, Docker base images
• Konventionen: Aus .editorconfig, .eslintrc, checkstyle.xml, .prettierrc, Commit-Message-Templates, .gitignore
• Lizenzen: Aus LICENSE, Dependency-Lizenzen in Lock-Files
• CI/CD: Aus .github/workflows/, Jenkinsfile, .gitlab-ci.yml
• Organisatorische Constraints: Meist NICHT aus Code ableitbar → Rückfrage nötig

Templates

02-01-Technisch.md

# Technische Randbedingungen

| Randbedingung | Beschreibung | Hintergrund/Motivation |
|--------------|-------------|----------------------|
| Programmiersprache: <Sprache> | <Version, Details> | <Warum diese Vorgabe?> |
| Framework: <Name> | <Version, Details> | <Warum?> |
| Datenbank: <Name> | <Version, Details> | <Warum?> |
| Laufzeitumgebung: <Name> | <Details> | <Warum?> |
| Betriebssystem: <Name> | <Details> | <Warum?> |

02-02-Organisatorisch.md

# Organisatorische Randbedingungen

| Randbedingung | Beschreibung | Hintergrund/Motivation |
|--------------|-------------|----------------------|
| Teamstruktur | <Beschreibung> | <Auswirkung auf Architektur> |
| Entwicklungsprozess | <z.B. Scrum, 2-Wochen-Sprints> | <Auswirkung> |
| Zeitrahmen | <z.B. MVP bis Q3/2026> | <Auswirkung> |
| Regulierung | <z.B. DSGVO-Konformität erforderlich> | <Auswirkung auf Architektur> |

02-03-Konventionen.md

# Konventionen

| Konvention | Beschreibung | Verbindlichkeit |
|-----------|-------------|-----------------|
| Coding-Standard | <z.B. Google Java Style Guide> | verbindlich |
| Versionierung | <z.B. Semantic Versioning 2.0> | verbindlich |
| Dokumentation | <z.B. arc42, deutsch, Markdown> | verbindlich |
| Branching | <z.B. Git Flow> | empfohlen |
| Test-Coverage | <z.B. >= 80% Zeilencoverage> | verbindlich |

Best Practices (aus arc42-Tipps)

• Konsequenzen klären: Zu jeder Randbedingung die Auswirkung auf die Architektur dokumentieren
• Kategorien trennen: Technische, organisatorische und politische Constraints getrennt halten
• Organisationsweite Constraints berücksichtigen: Nicht nur projekt-spezifische, auch übergreifende der Organisation
• Verhandlungsbarkeit angeben: Welche Constraints sind fix, welche verhandelbar?
• Einfache Tabellen: Tabellenformat ist das effektivste Format für Constraints

Querverweise

• → Sektion 4 (Lösungsstrategie): Strategie muss sich im Rahmen der Constraints bewegen
• → Sektion 8 (Konzepte): Konzepte müssen Constraints respektieren
• → Sektion 9 (Entscheidungen): Entscheidungen dürfen Constraints nicht verletzen