templates-de: German document templates, moved in from ownCloud

The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/ with no version control. They are the German-language counterpart of the templates renamed to English in 247b831 — this repo already describes itself as holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a second home for templates would have been a duplicate. Structure preserved as found (business/, engineering/, projekt/, qualitaet/). No file renamed, no template content changed. Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5 31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx already in this repo. Path references fixed in templates-de/README.md, which pointed at locations that no longer exist: the ownCloud cp examples now clone from Gitea, the generator script name follows the vorlagen/ -> templates/ rename (generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow names templates/ and templates-de/ instead of the removed ownCloud copy, and the master template is referenced at ../templates-word/.
2026-07-31 09:55:33 +02:00
parent 5a1ee8cc43
commit 8ea3f3d8f4
26 changed files with 1480 additions and 1 deletions
@@ -0,0 +1,92 @@
+# Project Initiation Document (PID)
+
+| Feld            | Wert                          |
+|-----------------|-------------------------------|
+| Projektname     | [Name]                        |
+| Auftraggeber    | [Firma / Ansprechpartner]     |
+| Auftragnehmer   | Stefan Lohmaier               |
+| Datum           | [YYYY-MM-DD]                  |
+| Version         | [1.0]                         |
+| Status          | [Entwurf / Freigegeben]       |
+
+---
+
+## 1. Projektziel
+
+[Was soll erreicht werden? Ein bis drei Saetze.]
+
+## 2. Scope
+
+### In Scope
+
+- [Lieferumfang Punkt 1]
+- [Lieferumfang Punkt 2]
+
+### Out of Scope
+
+- [Was explizit nicht enthalten ist]
+- [Abgrenzung zu anderen Teilprojekten]
+
+## 3. Randbedingungen
+
+| Randbedingung           | Beschreibung                              |
+|-------------------------|-------------------------------------------|
+| Zielplattform           | [z.B. ARM Cortex-R5, Renesas RH850]      |
+| ASIL                    | [QM / A / B / C / D]                     |
+| Normen                  | [ASPICE 4.0, ISO 26262:2018]             |
+| Programmiersprache      | [C / C++ / Rust]                          |
+| Coding Standard         | [MISRA C:2012 / MISRA C:2023]            |
+| Laufzeitumgebung        | [Bare-Metal / AUTOSAR Classic / Linux]    |
+| Kundenvorgaben          | [Spezifische Anforderungen des Kunden]    |
+
+## 4. Lieferergebnisse
+
+| Nr. | Lieferergebnis                    | Format        | Termin      |
+|-----|-----------------------------------|---------------|-------------|
+| 1   | Software Requirements Specification | GitLab Issues | [Datum]     |
+| 2   | Architektur-Dokumentation         | GitLab Wiki   | [Datum]     |
+| 3   | Quellcode                         | Git Repository| [Datum]     |
+| 4   | Unit Tests + Coverage Report      | CI-Artefakt   | [Datum]     |
+| 5   | MISRA Compliance Report           | CI-Artefakt   | [Datum]     |
+| 6   | Testbericht                       | Markdown/PDF  | [Datum]     |
+| 7   | Release-Paket                     | Git Tag + Artefakte | [Datum] |
+
+## 5. Meilensteine
+
+| Meilenstein              | Datum       | Kriterium                                |
+|--------------------------|-------------|------------------------------------------|
+| Projektstart             | [Datum]     | PID freigegeben                          |
+| Requirements Complete    | [Datum]     | Alle Anforderungen reviewed              |
+| Architecture Complete    | [Datum]     | Architektur reviewed und freigegeben     |
+| Code Complete            | [Datum]     | Implementierung abgeschlossen, Tests gruen |
+| Verification Complete    | [Datum]     | Coverage-Ziele erreicht, MISRA compliant |
+| Release                  | [Datum]     | Alle Exit-Kriterien erfuellt             |
+
+## 6. Risiken (initial)
+
+| ID   | Risiko                           | Wahrscheinlichkeit | Auswirkung | Massnahme                        |
+|------|----------------------------------|---------------------|------------|----------------------------------|
+| R-01 | [Risikobeschreibung]             | [H/M/L]            | [H/M/L]   | [Gegenmassnahme]                 |
+| R-02 | [Risikobeschreibung]             | [H/M/L]            | [H/M/L]   | [Gegenmassnahme]                 |
+
+## 7. Beteiligte Rollen
+
+| Rolle                    | Person / Organisation  | Verantwortung                     |
+|--------------------------|------------------------|-----------------------------------|
+| Projektleiter            | Stefan Lohmaier        | Gesamtverantwortung               |
+| Software-Entwickler      | Stefan Lohmaier        | Implementierung, Unit Tests       |
+| QA-Verantwortlicher      | [Name / extern]        | QA-Aktivitaeten, Audits          |
+| Safety-Verantwortlicher  | [Name / extern]        | ISO 26262 Compliance             |
+| Reviewer                 | [Name / extern]        | Code- und Dokument-Reviews       |
+| Auftraggeber             | [Name]                 | Anforderungen, Abnahme           |
+
+## 8. Freigabe
+
+| Rolle               | Name                | Datum       | Unterschrift / GitLab-Verweis |
+|----------------------|---------------------|-------------|-------------------------------|
+| Auftragnehmer        | Stefan Lohmaier     | [Datum]     |                               |
+| Auftraggeber         | [Name]              | [Datum]     |                               |
+
+---
+
+*Aenderungen an diesem Dokument werden im GitLab-Wiki versioniert.*
@@ -0,0 +1,85 @@
+# Projektplan (PM-Plan)
+
+| Feld            | Wert                          |
+|-----------------|-------------------------------|
+| Projekt         | [Projektname]                 |
+| Datum           | [YYYY-MM-DD]                  |
+| Version         | [1.0]                         |
+| Status          | [Entwurf / Freigegeben]       |
+| Bezug           | PID Version [X.Y]             |
+
+---
+
+## 1. Projektphasen und Meilensteine
+
+| Phase                  | Start       | Ende        | Meilenstein                          |
+|------------------------|-------------|-------------|--------------------------------------|
+| Anforderungsanalyse    | [Datum]     | [Datum]     | Requirements Complete                |
+| Architektur            | [Datum]     | [Datum]     | Architecture Complete                |
+| Implementierung        | [Datum]     | [Datum]     | Code Complete                        |
+| Integration & Test     | [Datum]     | [Datum]     | Integration Complete                 |
+| Verifikation           | [Datum]     | [Datum]     | Verification Complete                |
+| Release                | [Datum]     | [Datum]     | Release                              |
+
+Phasen koennen ueberlappen (iterativ). Meilenstein-Kriterien sind im QA-Plan definiert.
+
+## 2. Ressourcen und Rollen
+
+| Rolle                    | Person              | Verfuegbarkeit    | Aufgaben                        |
+|--------------------------|---------------------|-------------------|---------------------------------|
+| Projektleiter / Entwickler | Stefan Lohmaier   | [X Tage/Woche]   | Planung, Implementierung, Tests |
+| Reviewer                 | [Name / extern]     | [nach Bedarf]     | Code- und Dokument-Reviews      |
+| QA                       | [Name / extern]     | [nach Bedarf]     | QA-Audits, Prozessueberwachung  |
+| Auftraggeber             | [Name]              | [nach Bedarf]     | Anforderungsklaerung, Abnahme   |
+
+## 3. Kommunikationsplan
+
+| Aktivitaet               | Haeufigkeit  | Teilnehmer               | Medium              |
+|--------------------------|--------------|---------------------------|---------------------|
+| Status-Update            | [Woechentlich] | Auftraggeber, PL        | E-Mail / Call       |
+| Technische Abstimmung    | [Nach Bedarf]  | Entwickler, Auftraggeber | Call / GitLab Issue |
+| Meilenstein-Review       | [Pro Phase]    | Alle Beteiligten         | Meeting             |
+| QA-Report                | [Pro Phase]    | QA, PL, Auftraggeber     | Dokument (Wiki)     |
+
+## 4. Eskalationspfad
+
+| Stufe | Situation                                    | Eskalation an              | Frist       |
+|-------|----------------------------------------------|----------------------------|-------------|
+| 1     | Technische Blockade                          | Auftraggeber (technisch)   | 2 Arbeitstage |
+| 2     | Terminverschiebung > 1 Woche                 | Projektverantwortlicher    | 1 Arbeitstag  |
+| 3     | Scope-Aenderung oder Safety-Concern          | Management Auftraggeber    | sofort      |
+
+## 5. Aenderungsmanagement
+
+Aenderungen an Anforderungen, Scope oder Zeitplan werden als Change Request behandelt:
+
+1. Change Request als GitLab Issue erfassen (Label: `change-request`)
+2. Auswirkungsanalyse: betroffene Anforderungen, Code, Tests, Zeitplan
+3. Bewertung und Freigabe durch Auftraggeber
+4. Bei Freigabe: betroffene Work Products aktualisieren, Traceability nachfuehren
+5. Dokumentation der Aenderung im Issue (Begruendung, Auswirkung, Entscheidung)
+
+Keine Aenderung ohne dokumentierte Freigabe.
+
+## 6. Risikomanagement
+
+### Vorgehen
+
+- Initiale Risiken im PID erfasst
+- Risikoliste wird pro Meilenstein-Review aktualisiert
+- Neue Risiken werden als GitLab Issues erfasst (Label: `risk`)
+- Jedes Risiko hat: Beschreibung, Wahrscheinlichkeit, Auswirkung, Massnahme, Verantwortlicher
+
+### Risiko-Bewertung
+
+| Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel  | Hoch    |
+|----------------------------------|---------|---------|---------|
+| Hoch                             | Mittel  | Hoch    | Kritisch|
+| Mittel                           | Niedrig | Mittel  | Hoch    |
+| Niedrig                          | Niedrig | Niedrig | Mittel  |
+
+Kritische Risiken werden sofort eskaliert (siehe Eskalationspfad Stufe 3).
+
+---
+
+*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
@@ -0,0 +1,106 @@
+# Quality Assurance Plan (QA-Plan)
+
+| Feld            | Wert                          |
+|-----------------|-------------------------------|
+| Projekt         | [Projektname]                 |
+| Datum           | [YYYY-MM-DD]                  |
+| Version         | [1.0]                         |
+| Status          | [Entwurf / Freigegeben]       |
+| ASIL            | [QM / A / B / C / D]         |
+
+---
+
+## 1. QA-Aktivitaeten pro Phase
+
+| Phase                  | QA-Aktivitaet                                          | Verantwortlich |
+|------------------------|--------------------------------------------------------|----------------|
+| Anforderungsanalyse    | Review der Anforderungen (Vollstaendigkeit, Konsistenz, Testbarkeit) | QA / Reviewer |
+| Architektur            | Architektur-Review (Modularitaet, Safety-Konzept)      | QA / Reviewer  |
+| Implementierung        | Code-Review (MR-Approval), MISRA-Pruefung (CI)        | Reviewer / CI  |
+| Integration & Test     | Test-Review, Coverage-Pruefung, Traceability-Check     | QA / CI        |
+| Verifikation           | Gesamtpruefung: alle Kriterien erfuellt?               | QA             |
+| Release                | Release-Audit: alle Work Products vollstaendig?        | QA             |
+
+## 2. Zu pruefende Work Products
+
+| Work Product                     | Review-Art       | Pruefkriterien                              |
+|----------------------------------|------------------|---------------------------------------------|
+| PID                              | Peer Review      | Vollstaendig, konsistent mit Vertrag        |
+| PM-Plan                          | Peer Review      | Realistisch, Risiken adressiert             |
+| Software Requirements            | Technical Review | Eindeutig, testbar, ASIL zugeordnet         |
+| Architektur-Dokumentation        | Technical Review | Modular, Schnittstellen definiert, Safety-Konzept |
+| Quellcode                        | Peer Review (MR) | MISRA-konform, getestet, lesbar             |
+| Unit Tests                       | Peer Review      | Abdeckung, Randfaelle, Traceability         |
+| Testberichte                     | Peer Review      | Pass/Fail dokumentiert, Coverage erreicht   |
+| MISRA Compliance Report          | Peer Review      | Abweichungen dokumentiert und genehmigt     |
+| Traceability-Matrix              | QA-Pruefung      | Keine Luecken, bidirektional                |
+
+## 3. Review-Arten
+
+| Review-Art          | Teilnehmer                    | Formalitaet | Wann                            |
+|---------------------|-------------------------------|-------------|----------------------------------|
+| Peer Review         | 1 Reviewer                    | Niedrig     | Jeder MR, Dokument-Aenderungen  |
+| Technical Review    | 2+ Reviewer, inkl. Tech Lead  | Mittel      | Architektur, Safety-Code, Plaene |
+| Inspektion          | Moderator + 2+ Reviewer       | Hoch        | Safety-kritische Artefakte (ASIL C/D) |
+
+Peer Reviews laufen ueber GitLab MR-Approvals. Technical Reviews und Inspektionen werden zusaetzlich mit Review-Protokoll dokumentiert.
+
+## 4. Entry/Exit-Kriterien
+
+### Entry-Kriterien (Beginn einer Phase)
+
+| Phase                | Entry-Kriterien                                        |
+|----------------------|--------------------------------------------------------|
+| Architektur          | Requirements reviewed und freigegeben                  |
+| Implementierung      | Architektur reviewed und freigegeben                   |
+| Integration & Test   | Code-Reviews abgeschlossen, Unit Tests gruen           |
+| Verifikation         | Alle Tests durchgefuehrt, Coverage gemessen            |
+| Release              | Alle Exit-Kriterien der Verifikation erfuellt          |
+
+### Exit-Kriterien (Abschluss einer Phase)
+
+| Phase                | Exit-Kriterien                                         |
+|----------------------|--------------------------------------------------------|
+| Anforderungen        | Alle Requirements reviewed, ASIL zugeordnet, testbar   |
+| Architektur          | Architektur reviewed, Schnittstellen definiert          |
+| Implementierung      | MISRA-konform, Unit Tests gruen, Coverage-Ziel erreicht |
+| Integration & Test   | Integrationstests gruen, keine offenen Critical Findings |
+| Verifikation         | Traceability vollstaendig, alle Findings geschlossen oder bewertet |
+| Release              | Alle Work Products vollstaendig, QA-Freigabe erteilt   |
+
+## 5. Non-Conformity-Prozess
+
+1. Abweichung wird erkannt (Review, Audit, Test)
+2. Non-Conformity Report erstellen (GitLab Issue, Label: `non-conformity`)
+3. Schweregrad zuweisen: Critical / Major / Minor
+4. Ursachenanalyse durchfuehren
+5. Korrekturmassnahme definieren und umsetzen
+6. Wirksamkeitspruefung nach Umsetzung
+7. Issue schliessen mit Verweis auf Korrekturnachweis
+
+**Eskalation:** Critical Non-Conformities werden sofort an den Auftraggeber gemeldet.
+
+## 6. Reporting an Management
+
+| Report                    | Haeufigkeit      | Inhalt                                    |
+|---------------------------|------------------|-------------------------------------------|
+| QA-Status-Report          | Pro Meilenstein  | Offene Findings, NC-Status, Coverage-Stand |
+| Meilenstein-Bewertung     | Pro Phase-Ende   | Entry/Exit-Kriterien geprueft             |
+| Release-Bewertung         | Vor Release      | Gesamtbewertung aller QA-Kriterien        |
+
+## 7. QA-Metriken
+
+| Metrik                          | Ziel                    | Messung                          |
+|---------------------------------|-------------------------|----------------------------------|
+| Requirement Coverage            | 100%                   | Anforderungen mit verlinktem Test |
+| Code Coverage (Statement)       | >= [X]%                | gcov/lcov in CI                  |
+| Code Coverage (Branch)          | >= [X]%                | gcov/lcov in CI                  |
+| MC/DC Coverage (falls ASIL C/D) | >= [X]%                | MCDC-Star / kommerziell          |
+| MISRA Violations                | 0 (oder alle genehmigt)| Cppcheck MISRA-Addon in CI       |
+| Offene Findings (Critical)      | 0 vor Release          | GitLab Issues                    |
+| Offene Non-Conformities         | 0 Critical/Major       | GitLab Issues                    |
+| Review-Abdeckung                | 100% MRs reviewed      | GitLab MR-Approvals              |
+
+---
+
+*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
@@ -0,0 +1,132 @@
+# Software Development Plan (SWE-Plan)
+
+| Feld            | Wert                          |
+|-----------------|-------------------------------|
+| Projekt         | [Projektname]                 |
+| Datum           | [YYYY-MM-DD]                  |
+| Version         | [1.0]                         |
+| Status          | [Entwurf / Freigegeben]       |
+| ASIL            | [QM / A / B / C / D]         |
+
+---
+
+## 1. Entwicklungsmethode
+
+[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.]
+
+Grundstruktur folgt dem V-Modell (ISO 26262 Part 6):
+- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung
+- Rechte Seite: Unit Test → Integrations-Test → System-Test
+- Iterationen innerhalb der Phasen moeglich
+
+Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan).
+
+## 2. Programmiersprache und Standards
+
+| Aspekt              | Festlegung                                          |
+|---------------------|-----------------------------------------------------|
+| Sprache             | [C (C99/C11) / C++ (C++14/17) / Rust]              |
+| Coding Standard     | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023]     |
+| Projekt-Guidelines  | [Verweis auf Coding-Guidelines im Wiki]             |
+| Namenskonvention    | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] |
+
+### MISRA-Handhabung
+
+- Alle Required- und Mandatory-Regeln werden eingehalten
+- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert
+- Abweichungen werden per MISRA Deviation Record dokumentiert
+- Projektweite Abweichungen per MISRA Deviation Permit genehmigt
+- MISRA-Pruefung laeuft automatisch in der CI-Pipeline
+
+## 3. Build-Umgebung
+
+| Komponente         | Tool / Version                                      |
+|--------------------|-----------------------------------------------------|
+| Build-System       | [CMake X.Y / SCons X.Y / Make]                      |
+| Compiler           | [GCC ARM X.Y / Clang X.Y]                           |
+| Zielplattform      | [z.B. ARM Cortex-R5, Cortex-M4]                     |
+| Host-Plattform     | [Linux x86_64 / macOS ARM64]                         |
+| CI-Runner          | [GitLab Runner, Docker Image: ...]                   |
+
+Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation.
+
+## 4. Branching-Strategie
+
+```
+main              — Stabiler, freigegebener Stand
+develop           — Aktueller Entwicklungsstand
+feature/SWR-XXX   — Feature-Branch pro Anforderung
+bugfix/BUG-XXX    — Bugfix-Branch
+release/vX.Y      — Release-Vorbereitung
+hotfix/vX.Y.Z     — Kritische Fixes nach Release
+```
+
+- Feature-Branches von `develop` abzweigen
+- Merge nach `develop` nur per MR mit Approval
+- `main` und `release/*` sind geschuetzt (kein direkter Push)
+- Branch-Name enthaelt Issue-Nummer
+
+Details: siehe `gitlab-aspice-setup.md`.
+
+## 5. Review-Verpflichtungen
+
+| Artefakt                    | Review-Art        | Mindest-Approvals |
+|-----------------------------|-------------------|--------------------|
+| Quellcode (MR)              | Peer Review       | 1                  |
+| Safety-relevanter Code      | Technical Review  | 2                  |
+| Architektur-Dokument        | Technical Review  | 2                  |
+| Anforderungen               | Technical Review  | 1                  |
+| Testfaelle                  | Peer Review       | 1                  |
+
+Jeder MR muss vor dem Merge reviewed und approved sein. Self-Merges sind nicht erlaubt (Ausnahme: 1-Person-Projekt mit dokumentiertem Self-Review).
+
+## 6. Definition of Done
+
+Ein Feature / eine Anforderung gilt als "Done" wenn:
+
+- [ ] Code ist implementiert und kompiliert fehlerfrei
+- [ ] MISRA-Check in CI ist gruen (keine neuen Violations)
+- [ ] Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings
+- [ ] Unit Tests sind geschrieben und gruen
+- [ ] Coverage-Ziel ist erreicht (siehe Abschnitt 8)
+- [ ] MR ist reviewed und approved
+- [ ] Anforderung ist mit Test verlinkt (Traceability)
+- [ ] Dokumentation ist aktualisiert (falls betroffen)
+
+## 7. Integration und Test-Strategie
+
+| Teststufe           | Verantwortlich | Umgebung       | Automatisierung |
+|---------------------|----------------|----------------|-----------------|
+| Unit Test           | Entwickler     | Host (x86)     | CI-Pipeline     |
+| Integrations-Test   | Entwickler     | Host / SiL     | CI / manuell    |
+| System-Test         | Test / QA      | SiL / HiL      | teilweise       |
+| Abnahme-Test        | Auftraggeber   | HiL / Fahrzeug | manuell         |
+
+- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86)
+- Integrationstests pruefen Zusammenspiel der Module
+- System-Tests pruefen gegen System-Anforderungen
+- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert
+
+## 8. Coverage-Ziele
+
+| ASIL | Statement Coverage | Branch Coverage | MC/DC    |
+|------|--------------------|-----------------|----------|
+| QM   | >= 80% empfohlen   | —               | —        |
+| A    | >= 80%             | empfohlen       | —        |
+| B    | >= 80%             | >= 80%          | —        |
+| C    | >= 90%             | >= 80%          | empfohlen|
+| D    | >= 90%             | >= 90%          | >= 80%   |
+
+Konkrete Zielwerte fuer dieses Projekt:
+
+| Metrik              | Zielwert   |
+|---------------------|------------|
+| Statement Coverage  | >= [X]%    |
+| Branch Coverage     | >= [X]%    |
+| MC/DC               | >= [X]% (falls anwendbar) |
+
+Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert.
+
+---
+
+*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
@@ -0,0 +1,121 @@
+# Testplan
+
+| Feld            | Wert                          |
+|-----------------|-------------------------------|
+| Projekt         | [Projektname]                 |
+| Datum           | [YYYY-MM-DD]                  |
+| Version         | [1.0]                         |
+| Status          | [Entwurf / Freigegeben]       |
+| ASIL            | [QM / A / B / C / D]         |
+| Bezug           | SWE-Plan Version [X.Y]       |
+
+---
+
+## 1. Testziele
+
+- Nachweis, dass die Software die spezifizierten Anforderungen erfuellt
+- Nachweis der strukturellen Code-Abdeckung gemaess ASIL-Vorgaben
+- Nachweis der Robustheit gegenueber Fehlbedienung und Grenzwerten
+- Identifikation von Defekten vor der Integration / Auslieferung
+
+## 2. Teststrategie
+
+| Teststufe           | Testziel                                    | Methode          | Automatisierung |
+|---------------------|---------------------------------------------|------------------|-----------------|
+| Unit Test           | Einzelne Funktionen / Module korrekt        | White-Box        | CI (automatisch)|
+| Integrations-Test   | Zusammenspiel der Module                    | Grey-Box         | CI / SiL        |
+| System-Test         | Erfuellung der System-Anforderungen         | Black-Box        | SiL / HiL       |
+| Regressionstest     | Keine Seiteneffekte durch Aenderungen       | Automatisiert     | CI              |
+
+### Unit Tests
+
+- Framework: [CppUTest / Google Test / Unity+CMock]
+- Laufen auf Host-Plattform (x86)
+- Jede Anforderung hat mindestens einen zugehoerigen Testfall
+- Negative Tests und Grenzwerte sind Pflicht
+
+### Integrationstests
+
+- Pruefen Schnittstellen zwischen Modulen
+- Laufen auf Host oder SiL-Umgebung
+- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet
+
+### System-Tests
+
+- Pruefen gegen System-Anforderungen
+- Laufen auf SiL oder HiL
+- Testfaelle werden aus System-Requirements abgeleitet
+
+## 3. Coverage-Ziele
+
+| Metrik              | Zielwert       | Messung          |
+|---------------------|----------------|------------------|
+| Statement Coverage  | >= [X]%        | gcov/lcov        |
+| Branch Coverage     | >= [X]%        | gcov/lcov        |
+| MC/DC               | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell |
+
+Referenz: ISO 26262 Part 6, Table 9.
+
+| ASIL | Statement | Branch  | MC/DC        |
+|------|-----------|---------|--------------|
+| QM   | empfohlen | —       | —            |
+| A    | Pflicht   | empfohlen | —          |
+| B    | Pflicht   | Pflicht | —            |
+| C    | Pflicht   | Pflicht | empfohlen    |
+| D    | Pflicht   | Pflicht | Pflicht      |
+
+## 4. Testumgebung
+
+| Komponente          | Beschreibung                                       |
+|---------------------|----------------------------------------------------|
+| Host-Plattform      | [Linux x86_64 / macOS ARM64]                       |
+| Cross-Compiler      | [GCC ARM X.Y]                                      |
+| Test-Framework      | [CppUTest / Google Test / Unity]                   |
+| SiL-Framework       | [Python + pytest, Kommunikation: UART/CAN/TCP]     |
+| HiL-System          | [dSPACE Scalexio / vom Kunden gestellt / entfaellt] |
+| CI-Runner           | [GitLab Runner, Docker Image: ...]                  |
+
+## 5. Testdaten
+
+- Testdaten werden im Repository unter `tests/data/` versioniert
+- Grenzwerte aus Anforderungen ableiten
+- Ungueltige Eingaben explizit testen
+- Testdaten fuer Regressionen aus Bug-Reports ableiten
+
+## 6. Pass/Fail-Kriterien
+
+### Einzelner Testfall
+
+- **Pass:** Erwartetes Ergebnis stimmt mit tatsaechlichem ueberein
+- **Fail:** Abweichung vom erwarteten Ergebnis
+
+### Teststufe gesamt
+
+| Kriterium                              | Bedingung fuer Pass                    |
+|----------------------------------------|----------------------------------------|
+| Alle Testfaelle ausgefuehrt            | Ja                                     |
+| Alle Testfaelle bestanden              | Ja (oder Fails bewertet und genehmigt) |
+| Coverage-Ziel erreicht                 | Ja                                     |
+| Keine offenen Critical Findings        | Ja                                     |
+| Traceability vollstaendig              | Jede Anforderung hat mindestens einen Test |
+
+Fehlgeschlagene Tests, die nicht behoben werden, muessen per Non-Conformity oder Change Request dokumentiert und bewertet werden.
+
+## 7. Traceability
+
+Jeder Testfall muss auf mindestens eine Anforderung rueckfuehrbar sein.
+
+```
+Anforderung (GitLab Issue, Label: req::software)
+  → Testfall (GitLab Issue, Label: test::unit / test::integration / test::system)
+    → Testergebnis (CI-Artefakt / JUnit-XML)
+```
+
+Umsetzung:
+- Testfall-Issue verlinkt auf Anforderungs-Issue ("relates to" oder "verified by")
+- Im Testcode: Kommentar mit Anforderungs-ID (`// Verifies: SWR-042`)
+- Traceability-Report wird per Skript aus GitLab API generiert
+
+---
+
+*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*