--- title: "Pflichtenheft" subtitle: "Desktop-Fakturierungsanwendung — Gruppe B: Verwaltung von Produkten" author: - Team 1 – Gruppe B 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 B} \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 | +=============================+=========================+=========================+ | Berhane, Meron\ | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd | | SchulzeAmeling, Jan-Micah\ | | | | Volz, Jessica | | | +-----------------------------+-------------------------+-------------------------+ | Gruppe B (Produkte) | 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 Produkten*. ## Dokumentenhistorie | Version | Datum | Autor | Grund der Änderung | |---------|------------|----------------------------------------------------|---------------------| | 1.0 | 10.06.2026 | Meron Berhane, Jan-Micah SchulzeAmeling, Jessica Volz | Initiale Erstellung | | 1.1 | 10.06.2026 | Meron Berhane |UML-Klassen- und Sequenzdiagramm Gruppe B ergänzt| \newpage ## 1. Einleitung ### 1.1 Zweck des Dokuments Dieses Pflichtenheft (System Requirements Specification, SRS) beschreibt aus Sicht des Auftragnehmers, **wie** die Komponente *Verwaltung von Produkten* 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 Produktstammdaten: Anlegen, Ändern, Löschen (mit Löschsperre) sowie Suchen und Auflisten von Produkten, einschließlich der Vergabe eindeutiger Produktnummern, der Validierung der Eingaben und der Bereitstellung der Produktdaten für den Dokumentenzyklus (Gruppe A). ### 1.3 Geltungsbereich Dieses Dokument gilt für die Komponente **Gruppe B — Verwaltung von Produkten**. 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 | **dieses Dokument** | | C | Verwaltung von Kunden | separat | | D | Programmoberfläche | separat | Die Komponente B **stellt** Produktstammdaten 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, die Snapshot-Bildung von Preisen und Steuersätzen in Dokumentpositionen (GR-03) sowie die Kundenverwaltung (Gruppe C) sind **nicht** Gegenstand dieses Dokuments. ### 1.4 Definitionen und Abkürzungen Fachbegriffe (Produkt, Dokumentposition, Snapshot, 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 - GoBD — Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern - DSGVO — EU-Verordnung 2016/679 - 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 Produktverwaltung zugänglich gemacht wird. Die Komponente *Verwaltung von Produkten* stellt die Stammdatenpflege des Produktkatalogs bereit: Anlegen, Ändern und Löschen von Produkten, Vergabe eindeutiger Produktnummern, Validierung der Eingaben, Suche und sortierte Auflistung sowie der lesende Zugriff für die Dokumenterstellung (Gruppe A) und der Export der Produktstammdaten in einem offenen Format. ### 2.2 Abgrenzung (Was gehört dazu / was nicht) **Im Umfang dieser Komponente:** - Anlegen von Produkten mit Pflicht- und optionalen Feldern - Vergabe eindeutiger, vom System generierter Produktnummern - Ändern von Produktdaten (Bezeichnung, Preis, Steuersatz, …) - Löschen von Produkten inkl. Löschsperre bei referenzierten Produkten - Suchen und sortiertes Auflisten von Produkten - Bereitstellung des lesenden Zugriffs für Gruppe A (`ProduktService`) - Export der Produktstammdaten in einem offenen, dokumentierten Format (Anteil an Q-08) **Nicht im Umfang dieser Komponente:** - Erstellung und Statusführung von Belegen (Gruppe A) - Snapshot-Bildung von Preis/Steuersatz in Dokumentpositionen (GR-03, Gruppe A) - Verwaltung von Kunden (Gruppe C) - Aufbau und Layout der GUI (Gruppe D) - Lagerverwaltung, Bestandsführung, Webshop-Anbindung (LH-Nichtziele) ### 2.3 Grobe Systemfunktionen Erfassen eines Produkts → Validieren der Eingaben → Vergeben der Produktnummer → Persistieren → Suchen/Auflisten → Ändern → Löschen (mit Referenzprüfung) → Export. ### 2.4 UML-Bezug Ein gemeinsames Use-Case-Diagramm aller Gruppen gibt den Überblick über die Akteure und Ziele. Die für Gruppe B relevanten Use Cases sind: *Produkt anlegen*, *Produktdaten ändern*, *Produkt löschen* und *Produkte 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 den Produktkatalog eigenverantwortlich pflegt. Angrenzende Systeme/Komponenten: lokales Dateisystem (Persistenz, Datenexport) sowie intern die Komponenten Dokumentenzyklus (A, lesender Konsument der Produktdaten) und Programmoberfläche (D). --- ## 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. > **Produktnummern (übergreifend):** Produktnummern 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. `P-000042`); 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 Produkt anlegen (aus BA-05) **F-01:** Das System MUSS es der Anwender:in ERMÖGLICHEN, ein neues Produkt mit den Pflichtfeldern Bezeichnung, Netto-Einzelpreis und Steuersatz sowie den optionalen Feldern Beschreibung und Einheit anzulegen. **F-02:** WENN ein Produkt gespeichert wird, DANN MUSS das System eine eindeutige Produktnummer (Präfix `P-`, fortlaufend, führende Nullen) vergeben und anzeigen. **F-03:** WENN ein Produkt gespeichert wird, DANN MUSS das System die Eingaben validieren: der Netto-Einzelpreis MUSS größer oder gleich `0.00` sein und der Steuersatz MUSS einem der zulässigen Werte `{0.00, 0.07, 0.19}` entsprechen; andernfalls MUSS das Speichern abgelehnt werden. **F-04:** WENN ein Pflichtfeld fehlt (keine Bezeichnung, kein Einzelpreis, kein Steuersatz), DANN MUSS das System das Speichern ablehnen und das fehlende Pflichtfeld benennen (Q-09). ### 4.2 Produktdaten ändern (aus BA-06) **F-05:** Das System MUSS es der Anwender:in ERMÖGLICHEN, die Felder Bezeichnung, Beschreibung, Netto-Einzelpreis, Steuersatz und Einheit eines bestehenden Produkts zu ändern und persistent zu speichern. **F-06:** WENN ein Produkt geändert wird, DANN MUSS das System sicherstellen, dass ausschließlich **neue** Dokumente den geänderten Wert verwenden; bereits erstellte Dokumente bleiben unverändert, da Gruppe A Preis und Steuersatz als Snapshot in der Dokumentposition ablegt (GR-02, GR-03). Die Komponente B speichert ausschließlich den jeweils aktuellen Stand. **F-07:** Das System MUSS die Produktnummer nach der Vergabe vor jeder Änderung schützen; ein Änderungsversuch an der Produktnummer MUSS abgelehnt werden. ### 4.3 Produkt löschen (aus BA-07) **F-08:** Das System MUSS es der Anwender:in ERMÖGLICHEN, ein nicht referenziertes Produkt nach einer Bestätigungsabfrage dauerhaft zu löschen. **F-09:** WENN das zu löschende Produkt in mindestens einer Dokumentposition referenziert wird, DANN MUSS das System den Löschvorgang ablehnen und einen Hinweis anzeigen, dass das Produkt in Dokumenten verwendet wird. **F-10:** WENN ein Löschvorgang ausgelöst wird, DANN MUSS das System vor dem Löschen über die Schnittstelle `ProduktReferenzPruefung` (Gruppe A, Kapitel 6.2) prüfen, ob das Produkt in Dokumentpositionen referenziert ist. ### 4.4 Produkte suchen und auflisten (aus BA-08) **F-11:** Das System MUSS es der Anwender:in ERMÖGLICHEN, alle Produkte in einer nach Bezeichnung sortierten Liste anzuzeigen. **F-12:** Das System MUSS es der Anwender:in ERMÖGLICHEN, Produkte über eine Suche nach Bezeichnung oder Produktnummer 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 `ProduktService` bereitstellen, die es der Komponente Dokumentenzyklus (Gruppe A) ERMÖGLICHT, ein Produkt anhand seiner Produktnummer abzurufen; existiert kein Produkt zur Nummer, MUSS `null` zurückgegeben werden. **F-15 (Datenexport, Anteil an Q-08):** Das System MUSS es der Anwender:in ERMÖGLICHEN, alle Produktstammdaten 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 Produktverwaltung INNERHALB VON 1 SEKUNDE anzeigen, bei einem Datenbestand von bis zu 5.000 Produkten (Q-01) auf einem typischen Endanwender-PC. **NF-EXP-01 (aus Q-08, anteilig):** Das System MUSS den vollständigen Export der Produktstammdaten (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 „Produkt 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):** Das System MUSS alle Produktdaten ausschließlich lokal auf dem Anwender-PC ablegen; eine Übertragung an externe Dienste findet NICHT statt. --- ## 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):** - **Geldbeträge** werden als `java.math.BigDecimal` mit **Scale 2** und kaufmännischer Rundung (`RoundingMode.HALF_UP`) geführt — **nicht** als `double` (Gleitkomma-Rundungs­fehler wären für Beträge unzulässig). - **Produktnummern** werden als `String` geführt (festes Format mit Präfix und führenden Nullen, z. B. `"P-000042"`) — **nicht** als `int`. - **Steuersätze** werden als `BigDecimal` als Faktor geführt (z. B. `0.19`); zulässige Werte: `0.00`, `0.07`, `0.19`. #### Klasse `Produkt` | Attribut | Java-Typ | Beschreibung | |-------------------|---------------|--------------| | produktnummer | `String` | eindeutig, vom System generiert, unveränderlich (F-02, F-07) | | bezeichnung | `String` | Pflichtfeld, nicht leer | | beschreibung | `String` (optional, `null`) | Freitext | | einzelpreisNetto | `BigDecimal` | Pflichtfeld, Scale 2, ≥ 0.00 | | steuersatz | `BigDecimal` | Pflichtfeld, Faktor aus `{0.00, 0.07, 0.19}` | | einheit | `String` (optional, `null`) | z. B. `"Stück"`, `"Stunde"` | ### 6.2 Schnittstellen **Externe Schnittstellen:** | ID | Schnittstelle | Zweck | |-------|---------------------------|-------| | IF-01 | Lokales Dateisystem | Persistenz der Produktstammdaten | | IF-04 | Datenexport-Schnittstelle | Export der Produktstammdaten als CSV (F-15, Q-08) | **Interne Schnittstellen (zu anderen Komponenten), als Java-Interfaces skizziert:** ```java // Von Gruppe B IMPLEMENTIERT, von Gruppe A genutzt (lesender Zugriff) public interface ProduktService { Produkt findeProdukt(String produktnummer); // null, wenn nicht vorhanden } // Von Gruppe A BEREITGESTELLT, von Gruppe B genutzt (Löschsperre, F-10) public interface ProduktReferenzPruefung { boolean istProduktReferenziert(String produktnummer); } ``` **Komponenteninterne Dienste:** ```java public interface ProduktnummernGenerator { // liefert die nächste fortlaufende Produktnummer, z. B. "P-000042" String naechsteNummer(); } public interface ProduktRepository { Produkt speichere(Produkt produkt); void loesche(String produktnummer); List alleSortiertNachBezeichnung(); List suche(String suchbegriff); // Bezeichnung ODER Produktnummer } ``` > IF-Satzschablone (Beispiel IF-04): *Das System MUSS eine Export-Schnittstelle > bereitstellen, die es der Anwender:in ERMÖGLICHT, alle Produktstammdaten 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 `ProduktVerwaltungsService` auf, der die Fachlogik (Validierung, Nummernvergabe, Löschsperre) kapselt und die Dienste `ProduktnummernGenerator`, `ProduktRepository` und `ProduktReferenzPruefung` (Gruppe A) nutzt. Gegenüber Gruppe A implementiert die Komponente das Interface `ProduktService`. Produkte werden über das `ProduktRepository` im lokalen Dateisystem persistiert (realisiert als JSON-Ablage). Nach jeder schreibenden Operation (Anlegen, Ändern, Löschen) meldet der `ProduktVerwaltungsService` die Änderung über einen **`EreignisBus`** (Observer-Muster, Paket `gemeinsam`; `melde(DatenBereich.PRODUKTE)`), den die Produktansicht der Gruppe D abonniert und sich daraufhin automatisch aktualisiert. ### 7.1 Klassendiagramm ![Abbildung 1: UML-Klassendiagramm Produktverwaltung (Gruppe B)](diagramme/klassendiagramm_produktverwaltung_gruppeB) **Beschreibung zu Abbildung 1:** Das Klassendiagramm zeigt die Entitätsklasse `Produkt` mit ihren Attributen (Kapitel 6.1). Der `ProduktVerwaltungsService` orchestriert Anlegen, Ändern, Löschen und Suche: er nutzt den `ProduktnummernGenerator` (Vergabe eindeutiger Produktnummern, F-02), das `ProduktRepository` (Persistenz, IF-01) und die von Gruppe A bereitgestellte Schnittstelle `ProduktReferenzPruefung` (Löschsperre, F-09/F-10). Zusätzlich realisiert der `ProduktVerwaltungsService` das Interface `ProduktService` (lesender Zugriff für Gruppe A, F-14) und meldet Datenänderungen über den `EreignisBus` (Observer-Muster) an die abonnierte Produktansicht der Gruppe D. Dokumentpositionen (Gruppe A) referenzieren ein `Produkt` ausschließlich über die Produktnummer (lose Kopplung). ### 7.2 Sequenzdiagramm ![Abbildung 2: UML-Sequenzdiagramm „Produkt löschen mit Löschsperre“ (Gruppe B)](diagramme/sequenz_produkt_loeschen_gruppeB.png) **Beschreibung zu Abbildung 2:** Das Sequenzdiagramm stellt den Ablauf *Produkt löschen* dar. Die Anwender:in löst über die GUI (Gruppe D) `loescheProdukt(produktnummer)` am `ProduktVerwaltungsService` aus. Dieser prüft zuerst über `ProduktReferenzPruefung.istProduktReferenziert(produktnummer)` (Gruppe A), ob das Produkt in Dokumentpositionen verwendet wird. Liefert die Prüfung `true`, wird der Löschvorgang abgelehnt und ein Hinweis an die GUI zurückgegeben (F-09). Liefert sie `false`, fordert das System die Bestätigung der Anwender:in an (F-08) und löscht das Produkt anschließend über `ProduktRepository.loesche(produktnummer)` dauerhaft aus dem lokalen Datenbestand. --- ## 8. Testbare Abnahmekriterien **AC-B-01 (zu F-01–F-04)** — *Produkt anlegen* Vorbedingung: Modul Produktverwaltung geöffnet; höchste vergebene Produktnummer = `P-000041`. Aktion: Anwender:in erfasst ein Produkt mit Bezeichnung „Beratungsstunde", Einzelpreis `80.00`, Steuersatz `0.19` und speichert. Erwartet: Das Produkt ist persistent gespeichert und trägt die Produktnummer `P-000042`; die Nummer wird angezeigt. **AC-B-02 (zu F-04, NF-USE-01)** — *Pflichtfeldprüfung* Vorbedingung: Formular „Produkt anlegen" geöffnet. Aktion: Anwender:in lässt den Einzelpreis leer und versucht zu speichern. Erwartet: Das Speichern wird abgelehnt; das Feld „Einzelpreis (netto)" wird als fehlendes Pflichtfeld markiert und benannt. **AC-B-03 (zu F-05, F-06, GR-02/GR-03)** — *Produkt ändern, Snapshot-Verhalten* Vorbedingung: Ein Produkt (`50.00` €) ist in einer früheren Rechnung (Gruppe A) erfasst. Aktion: Anwender:in ändert den Einzelpreis auf `80.00` € und erstellt anschließend eine neue Rechnung mit diesem Produkt. Erwartet: Die Änderung ist gespeichert; die alte Rechnung behält den ursprünglichen Preis (Snapshot bei Gruppe A), die neue Rechnung übernimmt `80.00` €. **AC-B-04 (zu F-08–F-10)** — *Löschsperre für referenzierte Produkte* Vorbedingung: Produkt `P-000010` wird in einer Dokumentposition referenziert; Produkt `P-000011` ist unverknüpft. Aktion: Anwender:in versucht, `P-000010` zu löschen; anschließend löscht sie `P-000011` nach Bestätigung. Erwartet: Das Löschen von `P-000010` wird mit Hinweis abgelehnt; `P-000011` ist dauerhaft entfernt und erscheint nicht mehr in der Liste. **AC-B-05 (zu F-11–F-13, NF-PERF-01)** — *Produkt suchen und auflisten* Vorbedingung: Mindestens 100 Produkte sind im System. Aktion: Anwender:in sucht ein Produkt anhand eines Teils der Bezeichnung. Erwartet: Die sortierte Trefferliste erscheint in ≤ 1 Sekunde (Q-02); die Suche findet das Produkt auch bei abweichender Groß-/Kleinschreibung. **AC-B-06 (zu F-15, NF-EXP-01)** — *Produktstammdaten exportieren* Vorbedingung: Mindestens 100 Produkte sind im System. Aktion: Anwender:in exportiert die Produktstammdaten. Erwartet: Eine CSV-Datei (UTF-8, Semikolon-getrennt, mit Kopfzeile) mit allen Produkten und allen Attributen liegt im gewählten Zielordner; der Export dauert ≤ 30 Sekunden. --- ## 9. Traceability LH ↔ PH Jede für Gruppe B relevante Lastenheft-Anforderung ist mindestens einer Pflichtenheft-Anforderung zugeordnet. | LH-Anforderung | Beschreibung (LH) | PH-Anforderung(en) | |----------------|-------------------------------------------|---------------------------| | BA-05 | Produkte anlegen | F-01, F-02, F-03, F-04 | | BA-06 | Produktdaten ändern | F-05, F-06, F-07 | | BA-07 | Produkte löschen | F-08, F-09, F-10 | | BA-08 | Produkte suchen und auflisten | F-11, F-12, F-13 | | GR-02 | Unveränderlichkeit versendeter Dokumente | F-06 (Abgrenzung) | | Q-01 | Datenbestand 5.000 Produkte | NF-PERF-01 | | Q-02 | Suche/Auflistung ≤ 1 s | NF-PERF-01, F-13 | | Q-06 | Lokale Speicherung | NF-SEC-01 | | Q-08 | Datenexport ≤ 30 s | F-15, NF-EXP-01 | | Q-09 | Pflichtfeldhinweise ≥ 80 % | NF-USE-01, F-04 | > Hinweis: GR-03 (Steuerberechnung/Snapshot) liegt in der Verantwortung von Gruppe A; > Komponente B liefert lediglich den jeweils aktuellen Preis und Steuersatz über > `ProduktService` und spezifiziert die Snapshot-Bildung nicht. PZ-01 (CRUD-Verwaltung > der Produktstammdaten) wird durch BA-05–BA-08 vollständig abgedeckt. --- ## 10. Modultestplan Die folgenden Testfälle sind deterministisch (feste Ein-/Ausgaben) und mit JUnit 5 umsetzbar. Geldbeträge werden als `BigDecimal` mit Scale 2 erwartet (`assertEquals(new BigDecimal("80.00"), …)` bzw. `compareTo`). Die Schnittstelle `ProduktReferenzPruefung` (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 Produktnummer `P-000041` | Produkt („Beratungsstunde", 80.00, 0.19) speichern | Produkt persistiert; Produktnummer = `P-000042` | | TC-02 | F-02 (Format) | Zähler = 7 | `naechsteNummer()` | liefert `P-000007` (führende Nullen, `String`) | | TC-03 | F-03 | gültiges Produkt | Einzelpreis `-1.00` | Speichern abgelehnt (Validierungsfehler „Einzelpreis") | | TC-04 | F-03 | gültiges Produkt | Steuersatz `0.15` | Speichern abgelehnt (unzulässiger Steuersatz) | | TC-05 | F-04, NF-USE-01 | Produkt ohne Bezeichnung | `speichere()` | Speichern abgelehnt; Validierungsfehler benennt „Bezeichnung" | | TC-06 | F-05 | Produkt `P-000042` mit Preis 80.00 | Preis auf 95.00 ändern, speichern | gespeichertes Produkt hat einzelpreisNetto = 95.00 | | TC-07 | F-07 | Produkt `P-000042` | Änderungsversuch der Produktnummer auf `P-999999` | wirft `IllegalArgumentException` / Änderung abgelehnt | | TC-08 | F-08 | Produkt unverknüpft (Stub: `istProduktReferenziert` → `false`) | `loescheProdukt("P-000011")` mit Bestätigung | Produkt entfernt; nicht mehr in `alleSortiertNachBezeichnung()` | | TC-09 | F-09, F-10 | Stub: `istProduktReferenziert("P-000010")` → `true` | `loescheProdukt("P-000010")` | Löschen abgelehnt; Produkt weiterhin vorhanden; Hinweis erzeugt | | TC-10 | F-11 | Produkte „Zaun", „Anker", „Mast" | `alleSortiertNachBezeichnung()` | Reihenfolge: „Anker", „Mast", „Zaun" | | TC-11 | F-12 | Produkt „Beratungsstunde" | `suche("BERATUNG")` | Trefferliste enthält „Beratungsstunde" (case-insensitive, Teilstring) | | TC-12 | F-12 | Produkt `P-000042` | `suche("P-000042")` | Trefferliste enthält genau dieses Produkt | | TC-13 | F-14 | Kein Produkt `P-999999` vorhanden | `findeProdukt("P-999999")` | liefert `null` | | TC-14 | F-15 | 3 Produkte 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 relevanten Geschäftsregeln und Qualitätsvorgaben (GR-02-Abgrenzung, 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) | | 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.