| name | arc42-write-s02-constraints |
| description | Schreibt arc42 Sektion 2 (Randbedingungen): Technische, organisatorische und politische Constraints sowie Konventionen. Use when: Sektion 2 schreiben, Randbedingungen, Constraints, Konventionen dokumentieren, Einschränkungen erfassen. |
arc42 Sektion 2: Randbedingungen schreiben
Zweck
Alle Anforderungen, die Softwarearchitekten in ihren Entwurfs- und Implementierungsentscheidungen einschränken. Diese Constraints gehen manchmal über einzelne Systeme hinaus und gelten für ganze Organisationen.
Dateistruktur
02-Randbedingungen/
├── 02-01-Technisch.md
├── 02-02-Organisatorisch.md
└── 02-03-Konventionen.md
Interaktive Fragen an den User
Für 2.1 Technische Randbedingungen
- Welche Programmiersprachen/Frameworks sind vorgegeben?
- Gibt es vorgegebene Betriebssysteme oder Plattformen?
- Welche Datenbanken/Middleware ist vorgegeben?
- Gibt es Vorgaben zu Laufzeitumgebungen? (z.B. JVM-Version, Node-Version, Container-Runtime)
- Gibt es Einschränkungen bei der Hardware/Infrastruktur?
- Welche externen Systeme/Schnittstellen sind vorgegeben?
- Gibt es Vorgaben zu Bibliotheken oder Lizenzen? (z.B. keine GPL, nur OSS)
Für 2.2 Organisatorische Randbedingungen
- Wie ist das Team organisiert? (Größe, Verteilung, Erfahrung)
- Welche Entwicklungsprozesse gelten? (Scrum, Kanban, SAFe etc.)
- Gibt es Zeitvorgaben oder Budget-Constraints?
- Gibt es regulatorische Anforderungen? (DSGVO, ISO 27001, PCI-DSS etc.)
- Gibt es unternehmensweite Architektur-Vorgaben? (Enterprise Architecture, Referenzarchitekturen)
Für 2.3 Konventionen
- Gibt es Coding-Standards? (Style Guides, Linting-Regeln)
- Welche Dokumentationskonventionen gelten? (Sprache, Format)
- Gibt es Versionierungsvorgaben? (Branching-Modell, Semantic Versioning)
- Gibt es Naming-Conventions? (Packages, Klassen, APIs)
- 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
