Lastenheft_Secure-CaseTracker-Application-Track_02_Modul-und-Komponentenarchitektur.md

Lastenheft: Secure CaseTracker Application Track 02 - Modul- und Komponentenarchitektur

Metadaten / Metadata

• Stand / Date: 2026-07-07
• Übungsfirma / Training company: EuFPA - Europäische Firma Programmiert Alles
• Lehrjahr / Training year: ab dem 3. Lehrjahr
• Spezialisierung / Specialization: AE - Anwendungsentwicklung
• Zielsprachen / Target languages: C#, Go, Java, Python, Rust, Swift
• Spec-Kit-Nutzung / Spec Kit use: eigenständiger späterer Spec-Kit-Intake
• Sandbox-Bezug / Sandbox relation: Vorbereitung für spätere Arbeit in absdd-image-sandbox

Lernziel / Learning Goal

DE: Komponenten, Modulgrenzen, Abhängigkeiten, Trust Boundaries und ADR-Kandidaten werden entworfen.

EN: Learners can work on this specialization task and document decisions, risks, evidence paths, and boundaries.

Fachrichtungsbezug / Specialization Fit

Fachrichtung	Eignung	Reflexionsfrage
AE	hoch (Schwerpunkt)	Welcher Komponenten- und Modulschnitt setzt Trust Boundaries und Abhängigkeitsregeln sauber um?
SI	mittel	Welche Betriebs- oder Deployment-Annahme folgt aus dem Modulschnitt?
DPA	mittel	Welche Datenflüsse überschreiten welche Modul- oder Vertrauensgrenze?
DV	mittel bis hoch	Welche Schnittstelle zwischen den Komponenten ändert sich?

Rahmenlehrplanbezug / Curriculum Relation

DE: Die Aufgabe unterstützt die Spezialisierung im 3. Lehrjahr. Sie verbindet Projektarbeit, sichere Entwicklung, Qualitätssicherung, Betrieb oder Datenbewertung mit auditfähiger Dokumentation.

EN: The task supports third-year specialization. It connects project work, secure development, quality assurance, operation, or data assessment with audit-ready documentation.

DE: Konkrete Lernfelder (Quelle: Rahmenlehrplan-Lernfeld-Mapping.md): primär LF 11a („Funktionalität in Anwendungen realisieren"); berührt LF 5 („Software zur Verwaltung von Daten anpassen"). Vertiefte Erklärung und Verständnisfragen: lernbegleiter/Secure-CaseTracker-Application-Track_02_Modul-und-Komponentenarchitektur.Lernbegleiter.md.

EN: Concrete learning fields (source: Rahmenlehrplan-Lernfeld-Mapping.md): primary LF 11a ("Funktionalität in Anwendungen realisieren"); touched LF 5 ("Software zur Verwaltung von Daten anpassen"). Deeper explanation and comprehension questions: lernbegleiter/Secure-CaseTracker-Application-Track_02_Modul-und-Komponentenarchitektur.Lernbegleiter.md.

Bezug zur Richtlinie Sichere Entwicklung / Relation to Secure Development Guideline

• Prinzipien: sichere Architektur, sichere Programmierung, Testbarkeit, Datenschutz, N/A-Begründung und auditfähige Evidenz.
• Checklisten: CL_01, CL_03, CL_08, CL_10, CL_12.
• Mitgeltende Dokumente: Richtlinie Secure Development Life Cycle, Leitlinie für sichere Programmierung, Testmanagement, Zugangssteuerung und Lieferkettenbezug nach Bedarf.
• Presets: security-governance, architecture-governance, isaqb-architecture-governance, a11y-governance, cross-platform-governance, agent-parity-governance.

Aufgabenstellung / Task

DE: Erarbeite für eine modulare und sichere Komponentenarchitektur eine fokussierte Spezifikation für die Spezialisierung AE - Anwendungsentwicklung. Berücksichtige: Komponenten, Modulgrenzen, Abhängigkeiten, Trust Boundaries und ADR-Kandidaten werden entworfen.

EN: Prepare the corresponding specialization-focused feature specification. Keep the later implementation separate from this intake.

Anforderungen / Requirements

• R-01: Der fachliche Umfang ist klar beschrieben.
• R-02: Sicherheits-, Datenschutz-, Betriebs- oder Datenannahmen sind getrennt dokumentiert.
• R-03: Test-, Review- oder Evidenzpfade sind benannt.
• R-04: Alle Applicable, N/A und Open Punkte werden mit Evidenzpfad oder Begründung dokumentiert.
• R-05: Die Lösung bleibt vergleichbar für C#, Go, Java, Python, Rust und Swift, soweit das Lernziel sprachneutral ist.

Sicherheits- und Datenschutzanforderungen / Security and Privacy Requirements

• Keine echten personenbezogenen Daten verwenden.
• Eingaben, Dateien, Konfiguration, Logs, Abhängigkeiten und Auswertungen als mögliche Vertrauensgrenzen prüfen.
• Positive Sicherheits-, Qualitäts- oder Compliance-Aussagen nur mit Nachweis treffen.
• Nicht anwendbare Standards als N/A mit kurzer technischer Begründung dokumentieren.

Sprachneutrale Anforderungen / Language-Neutral Requirements

• Der Architekturvertrag (Komponenten, Modulgrenzen, Abhängigkeitsregeln) bleibt für alle Zielsprachen vergleichbar.
• Sprachspezifische Modul- oder DI-Frameworks dürfen gewählt werden, müssen aber begründet werden.
• MSL-Status ersetzt keine Prüfung von Trust Boundaries, Eingabevalidierung und Abhängigkeiten an den Modulgrenzen.

Erwartete Artefakte / Expected Artifacts

• fokussierte spec.md für diese Aufgabe.
• plan.md mit Spezialisierungs-, Sicherheits-, Test- und Nachweispfaden.
• tasks.md mit umsetzbaren Review-, Test- und Dokumentationsschritten.
• Projektspezifische Markdown-Nachweise oder begründete N/A-Einträge.
• Erwartete Evidenz: Komponentenübersicht, Trust-Boundary-Liste, ADR-Kandidaten, Abhängigkeitsregeln.

Akzeptanzkriterien / Acceptance Criteria

• Das Ergebnis ist für Auszubildende im 3. Lehrjahr verständlich.
• Die Spezialisierung AE ist klar sichtbar.
• Fachliche Entscheidung, Sicherheitsbezug und erwarteter Nachweis sind getrennt sichtbar.
• Offene Punkte sind als Open mit Folgeaktion notiert.
• Markdown bleibt DE-first, EN-second, CEFR B2 und WCAG-2.2-AA-orientiert.

Optimaler Specify-Prompt / Optimal Specify Prompt

/speckit-specify Nutze docs/learning-units/Lastenheft_Secure-CaseTracker-Application-Track_02_Modul-und-Komponentenarchitektur.md als verbindliche Eingabedatei. Erstelle eine fokussierte Feature-Spezifikation für eine modulare und sichere Komponentenarchitektur der EuFPA-Lernreihe Secure CaseTracker Application Track. Erzeuge keine Implementierung und starte keinen Sammellauf für die gesamte Lernreihe.