--- title: "Pflichtenheft" subtitle: "Desktop-Fakturierungsanwendung — Gruppe C: Verwaltung von Kunden" author: - Team 1 – Gruppe C version: "1.0" lang: de-DE toc: true toc-depth: 3 numbersections: false papersize: a4 geometry: "margin=3cm" fontsize: 12pt linestretch: 1.5 mainfont: "Times New Roman" sansfont: "Arial" monofont: "DejaVu Sans Mono" header-includes: | \usepackage{fancyhdr} \usepackage{lastpage} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Team 1 – Gruppe C} \fancyhead[C]{Pflichtenheft} \fancyhead[R]{Version 1.0} \fancyfoot[C]{\thepage\ /\ \pageref{LastPage}} \renewcommand{\headrulewidth}{0.4pt} \renewcommand{\footrulewidth}{0pt} --- \newpage +-----------------------------+-------------------------+-------------------------+ | Autor | Prüfer | Freigebender | +=============================+=========================+=========================+ | Ahadyar, Mahsuna\ | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd | | Kilic, Kübra\ | | | | Weidmann, Mara | | | +-----------------------------+-------------------------+-------------------------+ | Gruppe C (Kunden) | Modulverantwortlicher | Modulverantwortlicher | +-----------------------------+-------------------------+-------------------------+ | 10.06.2026 | 10.06.2026 | 10.06.2026 | +-----------------------------+-------------------------+-------------------------+ **Freigabevermerk:** Dieses Dokument ist nach Prüfung und Freigabe durch den Modulverantwortlichen verbindliche Spezifikationsgrundlage für die Implementierung und den Modultest der Komponente *Verwaltung von Kunden*. ## Dokumentenhistorie | Version | Datum | Autor | Grund der Änderung | |---------|------------|--------------------------------------------|---------------------| | 1.0 | 10.06.2026 | Mahsuna Ahadyar, Kübra Kilic, Mara Weidmann | Initiale Erstellung | \newpage ## 1. Einleitung ### 1.1 Zweck des Dokuments Dieses Pflichtenheft (System Requirements Specification, SRS) beschreibt aus Sicht des Auftragnehmers, **wie** die Komponente *Verwaltung von Kunden* der Desktop-Fakturierungsanwendung die Anforderungen des Lastenhefts (v1.3) erfüllt. Es konkretisiert die fachlichen Anforderungen in testbare Systemanforderungen und dient als direkte Grundlage für Design, Implementierung sowie den Komponenten- bzw. Modultestplan (Kapitel 10). ### 1.2 Ziel Ziel dieses Pflichtenhefts ist die vollständige und testbare Spezifikation der Verwaltung von Kundenstammdaten: Anlegen, Ändern, Löschen (mit referenzieller Integrität gemäß GR-04) sowie Suchen und Auflisten von Kunden, einschließlich der Vergabe eindeutiger Kundennummern, der Validierung der Eingaben und der Bereitstellung der Kundendaten für den Dokumentenzyklus (Gruppe A). ### 1.3 Geltungsbereich Dieses Dokument gilt für die Komponente **Gruppe C — Verwaltung von Kunden**. Die Gesamtanwendung wird arbeitsteilig in vier Komponenten entwickelt; jede Untergruppe pflegt ein eigenes Pflichtenheft: | Gruppe | Komponente | Eigenes Pflichtenheft | |--------|-------------------------|-----------------------| | A | Prozess / Dokumentenzyklus | separat | | B | Verwaltung von Produkten | separat | | C | Verwaltung von Kunden | **dieses Dokument** | | D | Programmoberfläche | separat | Die Komponente C **stellt** Kundenstammdaten lesend für den Dokumentenzyklus (Gruppe A) über eine definierte interne Schnittstelle bereit (Kapitel 6.2) und wird über die Programmoberfläche (Gruppe D) bedient. Die Erzeugung von Belegen und die Übernahme der Kundendaten in Dokumente (Gruppe A) sowie die Produktverwaltung (Gruppe B) sind **nicht** Gegenstand dieses Dokuments. ### 1.4 Definitionen und Abkürzungen Fachbegriffe (Kunde, Dokumentenzyklus, GoBD, DSGVO, CRUD, …) sind im Glossar des Lastenhefts (§ 8.1) definiert und gelten unverändert. Dokumentspezifische Abkürzungen siehe Kapitel 11. ### 1.5 Referenzen - Lastenheft „Desktop-Fakturierungsanwendung", Team 1, Version 1.3, 09.06.2026 - Project Charter, Team 1, Version 1.3, 14.05.2026 - Pflichtenheft Gruppe A „Prozess / Dokumentenzyklus", Version 1.0, 09.06.2026 - DSGVO — EU-Verordnung 2016/679 (personenbezogene Kundendaten) - GoBD — Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern - Vorlesungsunterlagen Software Engineering 1 (SoSe 2026), Foliensatz „Lasten- und Pflichtenheft" --- ## 2. Systemüberblick ### 2.1 Kurzbeschreibung Die Anwendung ist eine **Einzelplatz-Stand-Alone-Desktop-Anwendung** mit **lokaler Datenhaltung** (keine Cloud, kein Server). Die Bedienung erfolgt über eine **minimale grafische Benutzeroberfläche** (Gruppe D), über die die Funktionalität der Kundenverwaltung zugänglich gemacht wird. Die Komponente *Verwaltung von Kunden* stellt die Stammdatenpflege der Kunden bereit: Anlegen, Ändern und Löschen von Kunden, Vergabe eindeutiger Kundennummern, Validierung der Eingaben, referenzielle Integrität gegenüber dem Dokumentenbestand (GR-04), Suche und sortierte Auflistung sowie der lesende Zugriff für die Dokumenterstellung (Gruppe A) und der Export der Kundenstammdaten in einem offenen Format. ### 2.2 Abgrenzung (Was gehört dazu / was nicht) **Im Umfang dieser Komponente:** - Anlegen von Kunden mit Pflicht- und optionalen Feldern - Vergabe eindeutiger, vom System generierter Kundennummern - Ändern von Kundendaten (Name, Anschrift, Kontaktdaten, USt-IdNr.) - Löschen von Kunden inkl. Löschsperre bei verknüpften Dokumenten (GR-04) - Suchen und sortiertes Auflisten von Kunden (Volltextsuche Name/Kundennummer) - Bereitstellung des lesenden Zugriffs für Gruppe A (`KundenService`) - Export der Kundenstammdaten in einem offenen, dokumentierten Format (Anteil an Q-08) **Nicht im Umfang dieser Komponente:** - Erstellung und Statusführung von Belegen, Übernahme der Kundendaten in Belege (Gruppe A) - Verwaltung von Produkten (Gruppe B) - Aufbau und Layout der GUI (Gruppe D) - Mahnwesen, Buchhaltung, Kundenportale (LH-Nichtziele) ### 2.3 Grobe Systemfunktionen Erfassen eines Kunden → Validieren der Eingaben → Vergeben der Kundennummer → Persistieren → Suchen/Auflisten → Ändern → Löschen (mit Referenzprüfung, GR-04) → Export. ### 2.4 UML-Bezug Ein gemeinsames Use-Case-Diagramm aller Gruppen gibt den Überblick über die Akteure und Ziele. Die für Gruppe C relevanten Use Cases sind: *Kunde anlegen*, *Kundendaten ändern*, *Kunde löschen* und *Kunden suchen und auflisten*. Die detaillierte logische Architektur dieser Komponente folgt in Kapitel 7. --- ## 3. Stakeholder und Kontext Stakeholder und Systemkontext sind im Lastenheft (§ 2, § 3) beschrieben und gelten unverändert. Für diese Komponente ist der maßgebliche Akteur: - **Anwender:in** — natürliche Person (Selbstständige:r, Freiberufler:in, Kleinstunternehmer:in), die ihre Kundenstammdaten eigenverantwortlich pflegt. Angrenzende Systeme/Komponenten: lokales Dateisystem (Persistenz, Datenexport) sowie intern die Komponenten Dokumentenzyklus (A, lesender Konsument der Kundendaten) und Programmoberfläche (D). Da Kundendaten **personenbezogene Daten** im Sinne der DSGVO sind, gilt die lokale Datenhaltung (Q-06) für diese Komponente in besonderem Maße. --- ## 4. Funktionale Anforderungen Die Anforderungen sind nach CRUD-Operationen gruppiert und mit den Satzschablonen des Foliensatzes formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei und verifizierbar. > **Kundennummern (übergreifend):** Kundennummern sind **eindeutig** und werden > **vom System generiert** (nicht durch den Anwender eingegeben). Sie werden als > `String` geführt, **nicht** als `int`, weil die Nummern ein festes Format mit > Präfix und führenden Nullen besitzen (z. B. `K-000017`); ein ganzzahliger Typ > würde führende Nullen verlieren. Die Nummer wird fortlaufend auf Basis der höchsten > bisher vergebenen Nummer ermittelt und ist nach der Vergabe **unveränderlich**. > Anders als bei Rechnungsnummern (GR-01, Gruppe A) besteht keine > Lückenlosigkeits-Pflicht. ### 4.1 Kunde anlegen (aus BA-01) **F-01:** Das System MUSS es der Anwender:in ERMÖGLICHEN, einen neuen Kunden mit den Pflichtfeldern Name und Anschrift (Straße, PLZ, Ort) sowie den optionalen Feldern E-Mail, Telefon und USt-IdNr. anzulegen. **F-02:** WENN ein Kunde gespeichert wird, DANN MUSS das System eine eindeutige Kundennummer (Präfix `K-`, fortlaufend, führende Nullen) vergeben und anzeigen. **F-03:** WENN ein Pflichtfeld fehlt (kein Name, keine vollständige Anschrift), DANN MUSS das System das Speichern ablehnen und das fehlende Pflichtfeld benennen (Q-09). **F-04:** WENN eine E-Mail-Adresse angegeben wird, DANN MUSS das System deren Format prüfen (mindestens ein `@` mit Zeichen davor und dahinter) und bei ungültigem Format das Speichern ablehnen. ### 4.2 Kundendaten ändern (aus BA-02) **F-05:** Das System MUSS es der Anwender:in ERMÖGLICHEN, die Felder Name, Anschrift, E-Mail, Telefon und USt-IdNr. eines bestehenden Kunden zu ändern und persistent zu speichern; die Pflichtfeldprüfung (F-03) gilt unverändert. **F-06:** WENN ein Kunde geändert wird, DANN MUSS das System sicherstellen, dass bereits versendete Dokumente unverändert bleiben; dies ist gewährleistet, weil Gruppe A die Kundendaten zum Erstellzeitpunkt in den Beleg übernimmt (GR-02). Die Komponente C speichert ausschließlich den jeweils aktuellen Stand. **F-07:** Das System MUSS die Kundennummer nach der Vergabe vor jeder Änderung schützen; ein Änderungsversuch an der Kundennummer MUSS abgelehnt werden. ### 4.3 Kunde löschen (aus BA-03, GR-04) **F-08:** Das System MUSS es der Anwender:in ERMÖGLICHEN, einen Kunden ohne verknüpfte Dokumente nach einer Bestätigungsabfrage dauerhaft zu löschen. **F-09 (GR-04):** WENN der zu löschende Kunde aktive oder archivierte Dokumente referenziert, DANN MUSS das System den Löschvorgang ablehnen und einen Hinweis mit der **Anzahl der verknüpften Dokumente** anzeigen. **F-10:** WENN ein Löschvorgang ausgelöst wird, DANN MUSS das System vor dem Löschen über die Schnittstelle `KundenReferenzPruefung` (Gruppe A, Kapitel 6.2) die Anzahl der Dokumente ermitteln, die den Kunden referenzieren. ### 4.4 Kunden suchen und auflisten (aus BA-04) **F-11:** Das System MUSS es der Anwender:in ERMÖGLICHEN, alle Kunden in einer nach Name sortierten Liste anzuzeigen. **F-12:** Das System MUSS es der Anwender:in ERMÖGLICHEN, Kunden über eine Volltextsuche nach Name oder Kundennummer zu filtern; die Suche MUSS Teilzeichenketten finden und Groß-/Kleinschreibung ignorieren. **F-13:** WENN eine Suche ausgeführt wird, DANN MUSS das System das gefilterte Ergebnis innerhalb der Vorgabe aus Q-02 anzeigen (siehe NF-PERF-01). ### 4.5 Übergreifende Regeln und Dienste **F-14 (Bereitstellung für Gruppe A):** Das System MUSS eine lesende Schnittstelle `KundenService` bereitstellen, die es der Komponente Dokumentenzyklus (Gruppe A) ERMÖGLICHT, einen Kunden anhand seiner Kundennummer abzurufen; existiert kein Kunde zur Nummer, MUSS `null` zurückgegeben werden. **F-15 (Datenexport, Anteil an Q-08):** Das System MUSS es der Anwender:in ERMÖGLICHEN, alle Kundenstammdaten vollständig in ein offenes, dokumentiertes Format (CSV, UTF-8, Semikolon-getrennt, mit Kopfzeile) in das lokale Dateisystem zu exportieren. --- ## 5. Nicht-funktionale Anforderungen **NF-PERF-01 (aus Q-01/Q-02):** Das System MUSS Such- und Auflistungsergebnisse der Kundenverwaltung INNERHALB VON 1 SEKUNDE anzeigen, bei einem Datenbestand von bis zu 5.000 Kunden (Q-01) auf einem typischen Endanwender-PC. **NF-EXP-01 (aus Q-08, anteilig):** Das System MUSS den vollständigen Export der Kundenstammdaten (F-15) INNERHALB VON 30 SEKUNDEN abschließen, bei einem Datenbestand gemäß Q-01. **NF-USE-01 (aus Q-09):** Das System MUSS fehlende Pflichtangaben im Formular „Kunde anlegen/ändern" so markieren und benennen, dass mindestens 80 % der Testpersonen die fehlende Eingabe ohne externe Hilfe im ersten Korrekturversuch ergänzen können (Nachweis durch Usability-Test mit mind. 5 Testpersonen). **NF-SEC-01 (aus Q-06, anteilig / DSGVO):** Das System MUSS 100 % der personenbezogenen Kundendaten ausschließlich lokal auf dem Anwender-PC ablegen; eine Übertragung an externe Dienste findet NICHT statt (Nachweis durch Netzwerk-Monitoring während eines repräsentativen Nutzungslaufs). --- ## 6. Daten und Schnittstellen Dieses Kapitel ist direkter Input für den Modultestplan (Kapitel 10). Datentypen werden bereits als Java-Typen angegeben. ### 6.1 Datenobjekte und Datentypen **Designgrundsätze (konsistent zu Gruppe A):** - **Kundennummern** werden als `String` geführt (festes Format mit Präfix und führenden Nullen, z. B. `"K-000017"`) — **nicht** als `int`. - **Postleitzahlen** werden als `String` geführt — **nicht** als `int`, weil führende Nullen erhalten bleiben müssen (z. B. `"01067"` Dresden). - Optionale Felder sind als `null` zulässig; Pflichtfelder dürfen weder `null` noch leer sein. #### Klasse `Kunde` | Attribut | Java-Typ | Beschreibung | |---------------|---------------|--------------| | kundennummer | `String` | eindeutig, vom System generiert, unveränderlich (F-02, F-07) | | name | `String` | Pflichtfeld, nicht leer (Firmen- oder Personenname) | | strasse | `String` | Pflichtfeld (Anschrift) | | plz | `String` | Pflichtfeld (Anschrift, führende Nullen) | | ort | `String` | Pflichtfeld (Anschrift) | | eMail | `String` (optional, `null`) | Format gemäß F-04 | | telefon | `String` (optional, `null`) | Freitext | | ustIdNr | `String` (optional, `null`) | Umsatzsteuer-Identifikationsnummer | ### 6.2 Schnittstellen **Externe Schnittstellen:** | ID | Schnittstelle | Zweck | |-------|---------------------------|-------| | IF-01 | Lokales Dateisystem | Persistenz der Kundenstammdaten | | IF-04 | Datenexport-Schnittstelle | Export der Kundenstammdaten als CSV (F-15, Q-08) | **Interne Schnittstellen (zu anderen Komponenten), als Java-Interfaces skizziert:** ```java // Von Gruppe C IMPLEMENTIERT, von Gruppe A genutzt (lesender Zugriff) public interface KundenService { Kunde findeKunde(String kundennummer); // null, wenn nicht vorhanden } // Von Gruppe A BEREITGESTELLT, von Gruppe C genutzt (Löschsperre GR-04, F-10) public interface KundenReferenzPruefung { // Anzahl aktiver und archivierter Dokumente, die den Kunden referenzieren int anzahlVerknuepfterDokumente(String kundennummer); } ``` **Komponenteninterne Dienste:** ```java public interface KundennummernGenerator { // liefert die nächste fortlaufende Kundennummer, z. B. "K-000017" String naechsteNummer(); } public interface KundenRepository { Kunde speichere(Kunde kunde); void loesche(String kundennummer); List alleSortiertNachName(); List suche(String suchbegriff); // Name ODER Kundennummer } ``` > IF-Satzschablone (Beispiel IF-04): *Das System MUSS eine Export-Schnittstelle > bereitstellen, die es der Anwender:in ERMÖGLICHT, alle Kundenstammdaten als > CSV-Datei (UTF-8, Semikolon-getrennt) in das lokale Dateisystem > (`java.nio.file.Path`) zu exportieren.* --- ## 7. Systemarchitektur (logisch, grob) Die Komponente folgt einer einfachen Schichtung: die GUI (Gruppe D) ruft den `KundenVerwaltungsService` auf, der die Fachlogik (Validierung, Nummernvergabe, Löschsperre GR-04) kapselt und die Dienste `KundennummernGenerator`, `KundenRepository` und `KundenReferenzPruefung` (Gruppe A) nutzt. Gegenüber Gruppe A implementiert die Komponente das Interface `KundenService`. Kunden werden über das `KundenRepository` im lokalen Dateisystem persistiert (realisiert als JSON-Ablage). Nach jeder schreibenden Operation (Anlegen, Ändern, Löschen) meldet der `KundenVerwaltungsService` die Änderung über einen **`EreignisBus`** (Observer-Muster, Paket `gemeinsam`; `melde(DatenBereich.KUNDEN)`), den die Kundenansicht der Gruppe D abonniert und sich daraufhin automatisch aktualisiert. ### 7.1 Klassendiagramm ![Abbildung 1: UML-Klassendiagramm Kundenverwaltung (Gruppe C)] **Beschreibung zu Abbildung 1:** Das Klassendiagramm zeigt die Entitätsklasse `Kunde` mit ihren Attributen (Kapitel 6.1). Der `KundenVerwaltungsService` orchestriert Anlegen, Ändern, Löschen und Suche: er nutzt den `KundennummernGenerator` (Vergabe eindeutiger Kundennummern, F-02), das `KundenRepository` (Persistenz, IF-01) und die von Gruppe A bereitgestellte Schnittstelle `KundenReferenzPruefung` (Löschsperre GR-04, F-09/F-10). Zusätzlich realisiert der `KundenVerwaltungsService` das Interface `KundenService` (lesender Zugriff für Gruppe A, F-14) und meldet Datenänderungen über den `EreignisBus` (Observer-Muster) an die abonnierte Kundenansicht der Gruppe D. Dokumente (Gruppe A) referenzieren einen `Kunde` ausschließlich über die Kundennummer (lose Kopplung). ### 7.2 Sequenzdiagramm ![Abbildung 2: UML-Sequenzdiagramm „Kunde löschen mit Löschsperre (GR-04)" (Gruppe C)] **Beschreibung zu Abbildung 2:** Das Sequenzdiagramm stellt den Ablauf *Kunde löschen* dar. Die Anwender:in löst über die GUI (Gruppe D) `loescheKunde(kundennummer)` am `KundenVerwaltungsService` aus. Dieser ermittelt zuerst über `KundenReferenzPruefung.anzahlVerknuepfterDokumente(kundennummer)` (Gruppe A) die Anzahl der Dokumente, die den Kunden referenzieren. Ist die Anzahl größer als 0, wird der Löschvorgang abgelehnt und ein Hinweis mit der Anzahl der verknüpften Dokumente an die GUI zurückgegeben (F-09, GR-04). Ist die Anzahl 0, fordert das System die Bestätigung der Anwender:in an (F-08) und löscht den Kunden anschließend über `KundenRepository.loesche(kundennummer)` dauerhaft aus dem lokalen Datenbestand. --- ## 8. Testbare Abnahmekriterien **AC-C-01 (zu F-01–F-03, NF-PERF-01)** — *Kunde anlegen und auffinden* Vorbedingung: Anwendung gestartet, Modul Kundenverwaltung geöffnet; höchste vergebene Kundennummer = `K-000016`. Aktion: Anwender:in erfasst einen neuen Kunden mit Pflichtfeldern (Name, Straße, PLZ, Ort) und speichert. Erwartet: Das System vergibt die Kundennummer `K-000017` und zeigt sie an; der Kunde erscheint in der Suchergebnisliste innerhalb von ≤ 1 Sekunde (Q-02). **AC-C-02 (zu F-03, F-04, NF-USE-01)** — *Pflichtfeld- und Formatprüfung* Vorbedingung: Formular „Kunde anlegen" geöffnet. Aktion: Anwender:in lässt den Ort leer und versucht zu speichern; anschließend trägt sie eine ungültige E-Mail-Adresse („max.mustermann") ein und versucht erneut zu speichern. Erwartet: Beide Speicherversuche werden abgelehnt; das fehlende Pflichtfeld „Ort" bzw. das ungültige E-Mail-Format wird benannt. **AC-C-03 (zu F-05–F-07)** — *Kundendaten ändern* Vorbedingung: Ein Kunde mit mindestens einer verknüpften, versendeten Rechnung existiert. Aktion: Anwender:in ändert einen Adressbestandteil und speichert. Erwartet: Die Änderung ist persistent gespeichert; die bereits versendete Rechnung (Gruppe A) zeigt weiterhin die ursprüngliche Anschrift; die Kundennummer ist unverändert. **AC-C-04 (zu F-08–F-10, GR-04)** — *Löschsperre für verknüpfte Kunden* Vorbedingung: Kunde `K-000010` referenziert 3 Dokumente; Kunde `K-000011` ist unverknüpft. Aktion: Anwender:in versucht, `K-000010` zu löschen; anschließend löscht sie `K-000011` nach Bestätigung. Erwartet: Das Löschen von `K-000010` wird abgelehnt, der Hinweis nennt die Anzahl „3" verknüpfter Dokumente; `K-000011` ist dauerhaft entfernt und erscheint nicht mehr in der Liste. **AC-C-05 (zu F-11–F-13, NF-PERF-01)** — *Kunden suchen und auflisten* Vorbedingung: Mindestens 100 Kunden sind im System. Aktion: Anwender:in sucht einen Kunden anhand eines Teils des Namens und anschließend anhand der Kundennummer. Erwartet: Beide Trefferlisten erscheinen in ≤ 1 Sekunde (Q-02), sind nach Name sortiert und enthalten den gesuchten Kunden (auch bei abweichender Groß-/Kleinschreibung). **AC-C-06 (zu F-15, NF-EXP-01, NF-SEC-01)** — *Kundenstammdaten exportieren* Vorbedingung: Mindestens 100 Kunden sind im System. Aktion: Anwender:in exportiert die Kundenstammdaten; während des Nutzungslaufs läuft ein Netzwerk-Monitoring. Erwartet: Eine CSV-Datei (UTF-8, Semikolon-getrennt, mit Kopfzeile) mit allen Kunden und allen Attributen liegt im gewählten Zielordner; der Export dauert ≤ 30 Sekunden; das Monitoring zeigt keine Datenübertragung an externe Dienste. --- ## 9. Traceability LH ↔ PH Jede für Gruppe C relevante Lastenheft-Anforderung ist mindestens einer Pflichtenheft-Anforderung zugeordnet. | LH-Anforderung | Beschreibung (LH) | PH-Anforderung(en) | |----------------|-------------------------------------------|---------------------------| | BA-01 | Kunden anlegen | F-01, F-02, F-03, F-04 | | BA-02 | Kundendaten ändern | F-05, F-06, F-07 | | BA-03 | Kunden löschen | F-08, F-09, F-10 | | BA-04 | Kunden suchen und auflisten | F-11, F-12, F-13 | | GR-02 | Unveränderlichkeit versendeter Dokumente | F-06 (Abgrenzung) | | GR-04 | Referenzielle Integrität Kunden | F-09, F-10 | | Q-01 | Datenbestand 5.000 Kunden | NF-PERF-01 | | Q-02 | Suche/Auflistung ≤ 1 s | NF-PERF-01, F-13 | | Q-06 | Lokale Speicherung (DSGVO) | NF-SEC-01 | | Q-08 | Datenexport ≤ 30 s | F-15, NF-EXP-01 | | Q-09 | Pflichtfeldhinweise ≥ 80 % | NF-USE-01, F-03 | > Hinweis: Die Übernahme der Kundendaten in Belege (Snapshot zum Erstellzeitpunkt) liegt > in der Verantwortung von Gruppe A; Komponente C liefert lediglich den jeweils aktuellen > Datenstand über `KundenService`. PZ-01 (CRUD-Verwaltung der Kundenstammdaten) wird > durch BA-01–BA-04 vollständig abgedeckt. --- ## 10. Modultestplan Die folgenden Testfälle sind deterministisch (feste Ein-/Ausgaben) und mit JUnit 5 umsetzbar. Die Schnittstelle `KundenReferenzPruefung` (Gruppe A) wird im Modultest durch einen Stub/Mock ersetzt. | TC | Abgedeckte PH-Anf. | Vorbedingung | Eingabe | Erwartetes Ergebnis | |-------|--------------------|--------------|---------|---------------------| | TC-01 | F-01, F-02 | Höchste Kundennummer `K-000016` | Kunde („Muster GmbH", „Hauptstr. 1", „68163", „Mannheim") speichern | Kunde persistiert; Kundennummer = `K-000017` | | TC-02 | F-02 (Format) | Zähler = 7 | `naechsteNummer()` | liefert `K-000007` (führende Nullen, `String`) | | TC-03 | F-03, NF-USE-01 | Kunde ohne Ort | `speichere()` | Speichern abgelehnt; Validierungsfehler benennt „Ort" | | TC-04 | F-03 | Kunde mit leerem Namen (`""`) | `speichere()` | Speichern abgelehnt; Validierungsfehler benennt „Name" | | TC-05 | F-04 | Kunde mit E-Mail `"max.mustermann"` | `speichere()` | Speichern abgelehnt (ungültiges E-Mail-Format) | | TC-06 | F-04 | Kunde mit E-Mail `"max@beispiel.de"` | `speichere()` | Kunde gespeichert (gültiges Format) | | TC-07 | F-05 | Kunde `K-000017` mit Ort „Mannheim" | Ort auf „Heidelberg" ändern, speichern | gespeicherter Kunde hat ort = „Heidelberg" | | TC-08 | F-07 | Kunde `K-000017` | Änderungsversuch der Kundennummer auf `K-999999` | wirft `IllegalArgumentException` / Änderung abgelehnt | | TC-09 | F-08 | Stub: `anzahlVerknuepfterDokumente` → `0` | `loescheKunde("K-000011")` mit Bestätigung | Kunde entfernt; nicht mehr in `alleSortiertNachName()` | | TC-10 | F-09, F-10, GR-04 | Stub: `anzahlVerknuepfterDokumente("K-000010")` → `3` | `loescheKunde("K-000010")` | Löschen abgelehnt; Kunde weiterhin vorhanden; Hinweis enthält Anzahl `3` | | TC-11 | F-11 | Kunden „Zimmer", „Albrecht", „Maier" | `alleSortiertNachName()` | Reihenfolge: „Albrecht", „Maier", „Zimmer" | | TC-12 | F-12 | Kunde „Muster GmbH" | `suche("MUSTER")` | Trefferliste enthält „Muster GmbH" (case-insensitive, Teilstring) | | TC-13 | F-12, F-14 | Kunde `K-000017` vorhanden; `K-999999` nicht | `suche("K-000017")`; `findeKunde("K-999999")` | Treffer enthält `K-000017`; `findeKunde` liefert `null` | | TC-14 | F-15 | 3 Kunden im Bestand | `exportiereCsv(ziel)` | CSV-Datei mit Kopfzeile + 3 Datenzeilen, Semikolon-getrennt, UTF-8 | Damit sind 14 Testfälle (> 10) spezifiziert, die alle funktionalen Kernregeln (F-02, F-03, F-04, F-07, F-09, F-12, F-14, F-15) sowie die zentrale Geschäftsregel GR-04 und die Qualitätsvorgaben (Q-02, Q-08, Q-09) abdecken. --- ## 11. Anhänge ### 11.1 Abkürzungen | Abkürzung | Bedeutung | |-----------|-----------| | F | Funktionale Anforderung (Pflichtenheft) | | NF | Nicht-funktionale Anforderung (Pflichtenheft) | | IF | Schnittstelle (Interface) | | AC | Abnahmekriterium | | TC | Testfall (Test Case) | | BA | Benutzeranforderung (Lastenheft) | | GR | Geschäftsregel (Lastenheft) | | Q | Qualitätsanforderung (Lastenheft) | | CSV | Comma-Separated Values (offenes Exportformat) | | USt-IdNr. | Umsatzsteuer-Identifikationsnummer | | SRS | System Requirements Specification (Pflichtenheft) | ### 11.2 Glossar Es gilt das Glossar des Lastenhefts (§ 8.1) unverändert. ### 11.3 Referenzen Siehe Kapitel 1.5.