--- title: "Pflichtenheft" subtitle: "Desktop-Fakturierungsanwendung — Gruppe D: Programmoberfläche" author: - Team 1 – Gruppe D version: "1.2" 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: "Menlo" header-includes: | \usepackage{fancyhdr} \usepackage{lastpage} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Team 1 – Gruppe D} \fancyhead[C]{Pflichtenheft} \fancyhead[R]{Version 1.2} \fancyfoot[C]{\thepage\ /\ \pageref{LastPage}} \renewcommand{\headrulewidth}{0.4pt} \renewcommand{\footrulewidth}{0pt} --- \newpage +-----------------------------+-------------------------+-------------------------+ | Autor | Prüfer | Freigebender | +=============================+=========================+=========================+ | Güngör, Mirkan\ | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd | | König, Moritz\ | | | | Bouhki, Mohammed | | | +-----------------------------+-------------------------+-------------------------+ | Gruppe D (Oberfläche) | Modulverantwortlicher | Modulverantwortlicher | +-----------------------------+-------------------------+-------------------------+ | 24.06.2026 | 24.06.2026 | 24.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 *Programmoberfläche*. ## Dokumentenhistorie | Version | Datum | Autor | Grund der Änderung | |---------|------------|----------------------------------------------|---------------------| | 1.0 | 10.06.2026 | Mirkan Güngör, Moritz König, Mohammed Bouhki | Initiale Erstellung | | 1.1 | 13.06.2026 | Mirkan Güngör, Moritz König, Mohammed Bouhki | Einfügen der UML-Diagramme und Aktualisierung der Referenzen | | 1.2 | 24.06.2026 | Mirkan Güngör, Moritz König, Mohammed Bouhki | Überarbeitung nach Prüferfeedback: Referenzen, Abgrenzung und Klassendiagramm | \newpage ## 1. Einleitung ### 1.1 Zweck des Dokuments Dieses Pflichtenheft (System Requirements Specification, SRS) beschreibt aus Sicht des Auftragnehmers, **wie** die Komponente *Programmoberfläche* 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 grafischen Benutzeroberfläche: Hauptfenster und Navigation, Listen-, Such- und Formularansichten für die Stammdatenmodule (Gruppen B und C), Belegansichten und -aktionen des Dokumentenzyklus (Gruppe A), die geführte (schrittweise) Rechnungserstellung als Dialogfolge (Wizard), die Stornierung mit Bestätigungsdialog sowie die einheitliche Pflichtfeld-Markierung und Fehleranzeige. ### 1.3 Geltungsbereich Dieses Dokument gilt für die Komponente **Gruppe D — Programmoberfläche**. 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 | separat | | D | Programmoberfläche | **dieses Dokument** | Die Komponente D enthält **keine Fachlogik**: Sie ruft die Dienste der Komponenten Dokumentenzyklus (A, `DokumentService`), Produktverwaltung (B) und Kundenverwaltung (C) über deren definierte Schnittstellen auf und stellt deren Funktionalität dar. Die Benutzeranforderungen BA-13 (geführte Rechnungserstellung) und BA-14 (Rechnung stornieren) werden arbeitsteilig spezifiziert: Gruppe A beschreibt die **Fachlogik** (F-16–F-21 im Pflichtenheft A), dieses Dokument beschreibt die **Dialogführung und Darstellung**. ### 1.4 Definitionen und Abkürzungen Fachbegriffe (Dokumentenzyklus, Rechnung, GoBD, DSGVO, …) 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.1, 13.06.2026 - Pflichtenheft Gruppe B „Verwaltung von Produkten", Version 1.0, 10.06.2026 - Pflichtenheft Gruppe C „Verwaltung von Kunden", Version 1.0, 10.06.2026 --- ## 2. Systemüberblick ### 2.1 Kurzbeschreibung Die Anwendung ist eine **Einzelplatz-Stand-Alone-Desktop-Anwendung** mit **lokaler Datenhaltung** (keine Cloud, kein Server). Die Komponente *Programmoberfläche* stellt die **minimale grafische Benutzeroberfläche** bereit, über die die gesamte Funktionalität der Anwendung zugänglich gemacht wird: Navigation zwischen den Modulen, Listen- und Formularansichten der Stammdaten, Belegansichten mit Aktionen (PDF-Export, optional Druck und E-Mail-Versand) sowie die geführte Rechnungserstellung als Schritt-für-Schritt-Dialog. Das GUI-Framework wird gemäß dem im Project Charter dokumentierten Technologie-Stack gewählt; dieses Pflichtenheft spezifiziert die Oberfläche framework-neutral, die Controller-Logik jedoch bereits mit Java-Typen (Kapitel 6). ### 2.2 Abgrenzung der Komponente **Im Umfang dieser Komponente:** - Hauptfenster mit Navigation zu den Modulen Kunden, Produkte und Dokumente - Listen-, Such- und Formularansichten für Kunden und Produkte - Dokumentliste mit Statusanzeige und Belegaktionen (PDF-Export, Druck, E-Mail) - Geführte Rechnungserstellung als Wizard mit 5 Schritten inkl. Zusammenfassung (BA-13, UI-Sicht) - Stornierung einer Rechnung mit Bestätigungsdialog (BA-14, UI-Sicht) - Einheitliche Pflichtfeld-Markierung, Fehler- und Erfolgsmeldungen (Q-09) - Startverhalten der Anwendung (Q-04) ### 2.3 Grobe Systemfunktionen Anwendung starten → Hauptfenster anzeigen → Modul wählen → Liste/Suche anzeigen → Formular oder Wizard bedienen → Eingaben an die Fachkomponenten delegieren → Ergebnis, Fehler- oder Erfolgsmeldung anzeigen. ## 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) **ohne technische Vorkenntnisse** (PZ-03); die Oberfläche ist das einzige Bedienelement der Anwendung. Angrenzende Systeme/Komponenten: intern die Komponenten Dokumentenzyklus (A), Produktverwaltung (B) und Kundenverwaltung (C); extern — über die Dienste der Gruppe A — Drucker und Standard-E-Mail-Client (optional). --- ## 4. Funktionale Anforderungen Die Anforderungen sind nach Oberflächenbereichen gruppiert und mit einheitlichen Satzschablonen formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei und verifizierbar. Alle fachlichen Operationen werden an die Komponenten A–C delegiert; die Anforderungen dieses Kapitels betreffen ausschließlich Darstellung und Dialogführung. ### 4.1 Hauptfenster und Navigation **F-01:** Das System MUSS nach dem Programmstart ein Hauptfenster anzeigen, das eine Navigation zu den drei Modulen *Kundenverwaltung*, *Produktverwaltung* und *Dokumente* bereitstellt. **F-02:** WENN die Anwender:in ein Modul auswählt, DANN MUSS das System die zugehörige Modulansicht anzeigen, ohne dass ungespeicherte Eingaben eines Formulars unbemerkt verloren gehen (Nachfrage bei ungespeicherten Änderungen). ### 4.2 Stammdaten-Ansichten (Kunden, Produkte) **F-03:** Das System MUSS für die Module Kunden- und Produktverwaltung jeweils eine sortierte Listenansicht mit einem Suchfeld anzeigen; Suchanfragen werden an die Dienste der Gruppen C bzw. B delegiert und die Trefferliste wird innerhalb der Vorgabe aus Q-02 aktualisiert (siehe NF-PERF-02). **F-04:** Das System MUSS für Anlegen und Ändern von Kunden und Produkten Formulare mit allen Pflicht- und optionalen Feldern (gemäß Pflichtenheft B Kap. 6.1 und Pflichtenheft C Kap. 6.1) anzeigen; Pflichtfelder MÜSSEN als solche gekennzeichnet sein. **F-05:** WENN eine Fachkomponente das Speichern oder Löschen ablehnt (z. B. fehlendes Pflichtfeld, Löschsperre GR-04), DANN MUSS das System die zurückgemeldete Fehlermeldung sichtbar anzeigen und das betroffene Eingabefeld markieren (Q-09). ### 4.3 Dokumenten-Ansichten **F-06:** Das System MUSS eine Dokumentliste anzeigen, die je Beleg Belegnummer, Typ, Datum, Kunde, Bruttosumme und Status (`ENTWURF`, `OFFEN`, `VERSENDET`, `STORNIERT`) darstellt und nach Status filterbar ist. **F-07:** Das System MUSS je Beleg die Aktionen *PDF exportieren*, optional *Drucken* und optional *Per E-Mail versenden* anbieten; die Ausführung wird an die Dienste der Gruppe A delegiert. **F-08:** WENN ein Beleg den Status `VERSENDET` oder `STORNIERT` hat, DANN MUSS das System alle inhaltlichen Änderungsaktionen für diesen Beleg deaktivieren (GR-02; Logik bei Gruppe A, Darstellung hier). ### 4.4 Geführte Rechnungserstellung (aus BA-13, UI-Sicht) **F-09:** Das System MUSS die Rechnungserstellung als Dialogfolge (Wizard) mit genau fünf Schritten anbieten: (1) Kunde auswählen, (2) mindestens eine Produktposition mit Menge erfassen, (3) Rechnungsdatum und Zahlungsziel bestätigen, (4) Zusammenfassung prüfen, (5) speichern. **F-10:** WENN ein Schritt unvollständig ist (kein Kunde gewählt, keine Position erfasst, kein Rechnungsdatum), DANN MUSS das System den Wechsel zum nächsten Schritt verhindern und die fehlende Eingabe benennen (Q-09). **F-11:** Das System MUSS es der Anwender:in ERMÖGLICHEN, innerhalb des Wizards zum vorherigen Schritt zurückzukehren, ohne dass bereits erfasste Eingaben verloren gehen. **F-12:** WENN Schritt 4 erreicht wird, DANN MUSS das System eine Zusammenfassung mit Kunde, allen Positionen, Mengen, Netto-/Steuer-/Bruttosumme, Rechnungsdatum und Zahlungsziel anzeigen; die Summen werden vom `DokumentService` (Gruppe A) berechnet und hier unverändert dargestellt. **F-13:** WENN die Anwender:in in Schritt 5 speichert, DANN MUSS das System genau einen Speicheraufruf an den `DokumentService` (Gruppe A) auslösen und anschließend eine Erfolgsmeldung mit der vergebenen Rechnungsnummer anzeigen. ### 4.5 Rechnung stornieren (aus BA-14, UI-Sicht) **F-14:** Das System MUSS die Aktion *Stornieren* ausschließlich für Rechnungen im Status `OFFEN` anbieten. **F-15:** WENN die Anwender:in die Stornierung auslöst, DANN MUSS das System einen Bestätigungsdialog mit Rechnungsnummer und Bruttosumme anzeigen; erst nach Bestätigung wird die Stornierung an den `DokumentService` (Gruppe A) delegiert und das Ergebnis (neuer Status `STORNIERT`) in der Dokumentliste dargestellt. ### 4.6 Meldungen und Eingabehilfen (übergreifend) **F-16 (Q-09):** Das System MUSS fehlende oder ungültige Pflichtangaben in allen Formularen einheitlich darstellen: das betroffene Feld wird optisch markiert UND die Meldung benennt das Feld namentlich. **F-17:** Das System MUSS nach jeder erfolgreichen Aktion (Speichern, Löschen, Export, Storno) eine Erfolgsmeldung anzeigen und nach jeder abgelehnten Aktion die Begründung der Fachkomponente darstellen. --- ## 5. Nicht-funktionale Anforderungen **NF-PERF-01 (aus Q-04):** Das System MUSS nach dem Programmstart INNERHALB VON 5 SEKUNDEN vollständig bedienbereit sein (Hauptfenster sichtbar, Navigation reagiert), bei einem Datenbestand gemäß Q-01 (bis 5.000 Kunden/Produkte). **NF-PERF-02 (aus Q-02, UI-Anteil):** Das System MUSS Such- und Auflistungsergebnisse in den Stammdaten-Ansichten INNERHALB VON 1 SEKUNDE nach Eingabe darstellen, bei einem Datenbestand gemäß Q-01 (gemeinsam mit den Diensten der Gruppen B und C). **NF-USE-01 (aus Q-05):** Die geführte Erstellung einer vollständigen Rechnung an einen bestehenden Kunden MUSS von einer erstmaligen Anwender:in OHNE EXTERNE HILFE IN WENIGER ALS 10 MINUTEN im ersten Versuch abgeschlossen werden können (Nachweis durch Usability-Test mit mind. 5 Testpersonen). **NF-USE-02 (aus Q-09):** Das System MUSS fehlende Pflichtangaben in den Formularen der Kunden-, Produkt- und Dokumentenerstellung 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). --- ## 6. Daten und Schnittstellen Dieses Kapitel ist direkter Input für den Modultestplan (Kapitel 10). Die Komponente D führt **keine eigenen Fachdatenobjekte**; sie arbeitet ausschließlich mit den Datenobjekten der Gruppen A–C und einem eigenen UI-Zustandsmodell. Datentypen werden bereits als Java-Typen angegeben. ### 6.1 Datenobjekte und Datentypen (UI-Zustandsmodell) **Designgrundsätze:** - Die GUI hält **keinen persistenten Zustand**; alle fachlichen Daten werden über die Service-Schnittstellen der Gruppen A–C gelesen und geschrieben. - Die Wizard-Logik (Schrittfolge, Vollständigkeitsprüfung je Schritt) ist von der Darstellung getrennt und damit **GUI-frei testbar** (Kapitel 10). - Beträge und Summen werden unverändert als `BigDecimal` (Scale 2) der Gruppe A dargestellt; die GUI rechnet selbst nicht. #### `enum WizardSchritt` `{ KUNDE_WAEHLEN, POSITIONEN_ERFASSEN, DATEN_BESTAETIGEN, ZUSAMMENFASSUNG, SPEICHERN }` #### Klasse `RechnungsWizardModel` | Attribut | Java-Typ | Beschreibung | |-----------------|----------------------------|--------------| | aktuellerSchritt | `WizardSchritt` | aktueller Dialogschritt (F-09) | | kundenNr | `String` (optional, `null`) | gewählter Kunde (Schritt 1) | | positionen | `List` | erfasste Positionen (Schritt 2) | | rechnungsdatum | `LocalDate` | vorbelegt mit Tagesdatum (Schritt 3) | | zahlungsziel | `LocalDate` (optional, `null`) | leer = Standard-Zahlungsziel der Gruppe A (GR-06) | #### Klasse `PositionsEingabe` | Attribut | Java-Typ | Beschreibung | |----------------|------------|--------------| | produktnummer | `String` | gewähltes Produkt (Gruppe B) | | menge | `int` | Stückzahl (> 0) | #### Klasse `Meldung` | Attribut | Java-Typ | Beschreibung | |-----------|--------------------|--------------| | typ | `MeldungsTyp` (`enum { ERFOLG, FEHLER }`) | Darstellung (F-16, F-17) | | feldname | `String` (optional, `null`) | betroffenes Eingabefeld bei Validierungsfehlern | | text | `String` | anzuzeigender Meldungstext | ### 6.2 Schnittstellen **Externe Schnittstellen:** keine direkten — Drucker (IF-02) und E-Mail-Client (IF-03) werden über die Dienste der Gruppe A angebunden; die GUI bietet lediglich die auslösenden Aktionen an (F-07). **Interne Schnittstellen (genutzte Dienste der anderen Komponenten), als Java-Interfaces skizziert:** Hinweis: `PositionsEingabe` ist das UI-interne Modell der Gruppe D und wird im Controller vor dem Aufruf der Gruppe-A-Schnittstelle in `Positionsangabe` umgewandelt. Die Java-nahen Signaturen konkretisieren Datentypen und Operationen für die in Kapitel 10 beschriebenen JUnit-Tests; sie legen keine konkrete Implementierung der Dienste fest. ```java // Gruppe A — Dokumentenzyklus (genutzt von F-06 bis F-15) public interface DokumentService { Rechnung erstelleRechnung(String kundenNr, List positionen, LocalDate rechnungsdatum, LocalDate zahlungsziel); void storniere(String rechnungsnummer); List alleDokumente(); void exportierePdf(String belegnummer, Path zielDatei); } // Gruppe C — Kundenverwaltung (genutzt von F-03, F-04, Wizard-Schritt 1) public interface KundenService { Kunde findeKunde(String kundennummer); List suche(String suchbegriff); } // Gruppe B — Produktverwaltung (genutzt von F-03, F-04, Wizard-Schritt 2) public interface ProduktService { Produkt findeProdukt(String produktnummer); List suche(String suchbegriff); } ``` > IF-Satzschablone (Beispiel): *Das System MUSS eine Bedien-Schnittstelle bereitstellen, > die es der Anwender:in ERMÖGLICHT, die Stornierung einer offenen Rechnung auszulösen; > die fachliche Ausführung MUSS über `DokumentService.storniere(...)` (Gruppe A) > erfolgen.* --- ## 7. Systemarchitektur (logisch, grob) Die Komponente folgt dem Muster *Model–View–Controller*: Die Views (das Hauptfenster `HauptFenster`, die Modulansichten `KundenPanel`/`ProduktPanel`/`DokumentListenPanel`, der Wizard-Dialog) enthalten die Darstellung; die Controller (`StammdatenController`, `RechnungsWizardController`, `DokumentListenController`) kapseln Dialogführung und Vollständigkeitsprüfungen und rufen die Service-Schnittstellen der Gruppen A–C auf. Das `HauptFenster` (ein `JFrame`) hält die Navigationsleiste und schaltet die Modulansichten über ein `CardLayout` um; die Verdrahtung von Panels, Controllern und Services erfolgt beim Programmstart (`Main`). Die Modulansichten abonnieren den gemeinsamen `EreignisBus` (Observer-Muster, Paket `gemeinsam`) und aktualisieren sich nach Datenänderungen der Gruppen A–C automatisch. Das UI-Zustandsmodell (`RechnungsWizardModel`, `Meldung`) ist frei von GUI-Framework-Klassen und damit im Modultest ohne Oberfläche prüfbar. ### 7.1 Klassendiagramm ![UML-Klassendiagramm Programmoberfläche (Gruppe D)](../diagramme/klassendiagramm_programmoberflaeche.png) **Beschreibung zu Abbildung 1:** Das Klassendiagramm zeigt die View- und Controller-Schicht der Oberfläche. Das `HauptFenster` (ein `JFrame`) enthält jeweils genau eine Kunden-, Produkt- und Dokumentansicht und schaltet diese über ein `CardLayout` um (F-01, F-02). Der `StammdatenController` bedient die Ansichten für Kunden und Produkte und nutzt die Schnittstellen `KundenService` und `ProduktService`. Der `RechnungsWizardController` führt die Schrittfolge des Enums `WizardSchritt` über das `RechnungsWizardModel` und delegiert Summenberechnung und Speicherung an den `DokumentService`. Der `DokumentListenController` stellt die Dokumentliste mit Statusfilter dar und bietet die Belegaktionen an (F-06–F-08, F-14, F-15). Die drei Service-Schnittstellen werden durch die im Diagramm gezeigten Fachkomponenten `StandardDokumentService`, `KundenVerwaltungsService` und `ProduktVerwaltungsService` realisiert. Die Modulansichten abonnieren den gemeinsamen `EreignisBus` und aktualisieren sich nach Datenänderungen. Fehler- und Erfolgsmeldungen werden einheitlich über die Klasse `Meldung` dargestellt (F-16, F-17). ### 7.2 Sequenzdiagramm ![UML-Sequenzdiagramm Rechnungserstellung (Gruppe D)](../diagramme/sequenz_rechnungserstellung_wizard_gruppeD.png) **Beschreibung zu Abbildung 2:** Das Sequenzdiagramm stellt die Dialogfolge *geführte Rechnungserstellung* dar. Die Anwender:in startet den Wizard; der `RechnungsWizardController` lädt in Schritt 1 die Kundenliste über `KundenService.suche(...)` (Gruppe C) und in Schritt 2 die Produktliste über `ProduktService.suche(...)` (Gruppe B). Vor jedem Schrittwechsel prüft der Controller die Vollständigkeit des `RechnungsWizardModel` (F-10); bei fehlenden Eingaben wird eine `Meldung` mit dem Feldnamen erzeugt und der Wechsel verhindert. In Schritt 4 fordert der Controller die berechneten Summen für die Zusammenfassung an (Gruppe A) und stellt sie unverändert dar (F-12). In Schritt 5 löst der Controller genau einen Aufruf `DokumentService.erstelleRechnung(...)` aus (F-13), zeigt die Erfolgsmeldung mit der vergebenen Rechnungsnummer an und schließt den Wizard. --- ## 8. Testbare Abnahmekriterien **AC-D-01 (zu F-01, F-02, NF-PERF-01)** — *Programmstart und Navigation* Vorbedingung: Datenbestand mit 5.000 Kunden und 5.000 Produkten (Q-01). Aktion: Anwender:in startet die Anwendung und wechselt nacheinander in alle drei Module. Erwartet: Das Hauptfenster ist in ≤ 5 Sekunden bedienbereit (Q-04); jede Modulansicht wird angezeigt; bei ungespeicherten Formulareingaben erscheint eine Nachfrage. **AC-D-02 (zu F-03, NF-PERF-02)** — *Stammdaten suchen über die Oberfläche* Vorbedingung: Mindestens 100 Kunden und 100 Produkte sind im System. Aktion: Anwender:in gibt in der Kunden- und der Produktansicht jeweils einen Suchbegriff ein. Erwartet: Die gefilterte, sortierte Trefferliste erscheint jeweils in ≤ 1 Sekunde (Q-02). **AC-D-03 (zu F-09–F-13, NF-USE-01)** — *Geführte Rechnungserstellung (Wizard)* Vorbedingung: Mindestens ein Kunde und ein Produkt sind im System vorhanden. Aktion: Eine erstmalige Anwender:in durchläuft den Wizard (Kunde → Position+Menge → Datum/Zahlungsziel → Zusammenfassung → speichern). Erwartet: Die Zusammenfassung zeigt Kunde, Position, Menge, Summen, Rechnungsdatum und Zahlungsziel; nach dem Speichern erscheint die Erfolgsmeldung mit Rechnungsnummer; die Durchführung gelingt ohne externe Hilfe in < 10 Minuten (Usability-Test, ≥ 5 Personen). **AC-D-04 (zu F-10, F-16, NF-USE-02)** — *Pflichtfeldhinweis im Wizard und in Formularen* Vorbedingung: Wizard-Schritt 1 geöffnet bzw. Formulare „Kunde anlegen" und „Produkt anlegen" erreichbar. Aktion: Testpersonen versuchen ohne Kundenauswahl in Schritt 2 zu wechseln bzw. ohne ein Pflichtfeld zu speichern; anschließend ergänzen sie die fehlende Angabe. Erwartet: Der Wechsel bzw. das Speichern wird zuerst verhindert, das fehlende Feld wird markiert und benannt; in ≥ 80 % der Testdurchläufe gelingt die Korrektur ohne externe Hilfe im ersten Versuch. **AC-D-05 (zu F-14, F-15)** — *Stornierung mit Bestätigungsdialog* Vorbedingung: Eine Rechnung im Status `OFFEN` und eine im Status `VERSENDET` existieren. Aktion: Anwender:in öffnet die Dokumentliste, prüft die angebotenen Aktionen und storniert die offene Rechnung nach Bestätigung. Erwartet: *Stornieren* wird nur für die offene Rechnung angeboten; der Bestätigungsdialog zeigt Rechnungsnummer und Bruttosumme; nach Bestätigung erscheint die Rechnung mit Status `STORNIERT` in der Liste. **AC-D-06 (zu F-06–F-08)** — *Dokumentliste, Statusfilter, deaktivierte Aktionen* Vorbedingung: Belege in den Status `ENTWURF`, `OFFEN`, `VERSENDET`, `STORNIERT` existieren. Aktion: Anwender:in filtert die Dokumentliste nach Status und öffnet einen versendeten Beleg. Erwartet: Der Filter zeigt ausschließlich Belege des gewählten Status; für den versendeten Beleg sind alle inhaltlichen Änderungsaktionen deaktiviert, PDF-Export bleibt verfügbar. --- ## 9. Traceability LH ↔ PH Jede für Gruppe D relevante Lastenheft-Anforderung ist mindestens einer Pflichtenheft-Anforderung zugeordnet. | LH-Anforderung | Beschreibung (LH) | PH-Anforderung(en) | |----------------|-------------------------------------------|---------------------------| | BA-13 | Geführte Rechnungserstellung (UI-Anteil) | F-09, F-10, F-11, F-12, F-13 | | BA-14 | Rechnung stornieren (UI-Anteil) | F-14, F-15 | | BA-01–BA-08 | Stammdatenpflege (Bedienzugang) | F-03, F-04, F-05 | | BA-09–BA-12 | Belegerstellung (Bedienzugang) | F-06, F-07 | | GR-02 | Unveränderlichkeit versendeter Dokumente | F-08 (Darstellung) | | PZ-03 | Bedienbarkeit ohne Vorkenntnisse | F-09–F-13, NF-USE-01 | | Q-02 | Suche/Auflistung ≤ 1 s (UI-Anteil) | NF-PERF-02, F-03 | | Q-04 | Anwendungsstart ≤ 5 s | NF-PERF-01 | | Q-05 | Usability Ersterstellung Rechnung | NF-USE-01 | | Q-09 | Pflichtfeldhinweise ≥ 80 % | NF-USE-02, F-10, F-16 | > Hinweis: Die Fachlogik zu BA-13/BA-14 (Schrittvalidierung beim Speichern, > Statuswechsel, Protokollierung) ist im Pflichtenheft der Gruppe A spezifiziert > (F-16–F-21 dort); dieses Dokument spezifiziert ausschließlich Dialogführung und > Darstellung. Die fachlichen Validierungs- und Performanceregeln der Stammdatenmodule > liegen bei den Gruppen B und C. --- ## 10. Modultestplan Die folgenden Testfälle sind deterministisch (feste Ein-/Ausgaben) und mit JUnit 5 umsetzbar. Getestet wird die GUI-freie Controller- und Modell-Schicht (Kapitel 6.1/7); die Service-Schnittstellen der Gruppen A–C werden durch Stubs/Mocks ersetzt. Die Usability-Nachweise (NF-USE-01/02) erfolgen ergänzend durch manuelle Usability-Tests (Kapitel 8) und sind nicht Teil des automatisierten Modultests. **TC-01 — Wizard startet im ersten Schritt** Abgedeckte PH-Anforderung: F-09. Vorbedingung: Wizard neu gestartet. Eingabe: `aktuellerSchritt` lesen. Erwartetes Ergebnis: `KUNDE_WAEHLEN` ist der erste Schritt. **TC-02 — Vollständige Schrittfolge** Abgedeckte PH-Anforderung: F-09. Vorbedingung: Schritt 1 mit gewähltem Kunden. Eingabe: `weiter()` viermal mit gültigen Eingaben. Erwartetes Ergebnis: Schrittfolge `POSITIONEN_ERFASSEN` -> `DATEN_BESTAETIGEN` -> `ZUSAMMENFASSUNG` -> `SPEICHERN`. **TC-03 — Wechsel ohne Kundenauswahl** Abgedeckte PH-Anforderung: F-10. Vorbedingung: Schritt 1, kein Kunde gewählt (`kundenNr = null`). Eingabe: `weiter()`. Erwartetes Ergebnis: Wechsel verhindert; `Meldung(FEHLER, "Kunde", ...)` erzeugt. **TC-04 — Wechsel ohne Position** Abgedeckte PH-Anforderung: F-10. Vorbedingung: Schritt 2, leere Positionsliste. Eingabe: `weiter()`. Erwartetes Ergebnis: Wechsel verhindert; Meldung benennt „Position". **TC-05 — Ungültige Positionsmenge** Abgedeckte PH-Anforderung: F-10. Vorbedingung: Schritt 2, Position mit `menge = 0`. Eingabe: `weiter()`. Erwartetes Ergebnis: Wechsel verhindert; Meldung benennt „Menge". **TC-06 — Zurück ohne Datenverlust** Abgedeckte PH-Anforderung: F-11. Vorbedingung: Schritt 3 erreicht; Kunde `K-000017`, eine Position erfasst. Eingabe: `zurueck()` bis Schritt 1. Erwartetes Ergebnis: `kundenNr` und `positionen` bleiben unverändert erhalten. **TC-07 — Zusammenfassung mit Summen** Abgedeckte PH-Anforderung: F-12. Vorbedingung: Schritt 4; Stub `DokumentService` liefert Summen 200.00/38.00/238.00. Eingabe: Zusammenfassung erzeugen. Erwartetes Ergebnis: Zusammenfassung enthält Kunde, Positionen, Mengen, 200.00/38.00/238.00, Rechnungsdatum und Zahlungsziel. **TC-08 — Rechnung speichern** Abgedeckte PH-Anforderung: F-13. Vorbedingung: Schritt 5; gültiges Modell. Eingabe: `speichern()`. Erwartetes Ergebnis: genau ein Aufruf `erstelleRechnung(...)` am Mock; Erfolgsmeldung enthält die gelieferte Rechnungsnummer. **TC-09 — Fachlicher Fehler beim Speichern** Abgedeckte PH-Anforderung: F-13 (Fehlerfall). Vorbedingung: Stub `erstelleRechnung` wirft Validierungsfehler „Rechnungsdatum". Eingabe: `speichern()`. Erwartetes Ergebnis: keine Erfolgsmeldung; `Meldung(FEHLER, "Rechnungsdatum", ...)` wird dargestellt (F-05/F-16). **TC-10 — Storno-Aktion nur für offene Rechnungen** Abgedeckte PH-Anforderung: F-14. Vorbedingung: Dokumentliste mit Rechnungen in `OFFEN`, `VERSENDET`, `STORNIERT`. Eingabe: verfügbare Aktionen je Rechnung ermitteln. Erwartetes Ergebnis: *Stornieren* ist nur bei Status `OFFEN` aktiviert. **TC-11 — Stornierung nur nach Bestätigung** Abgedeckte PH-Anforderung: F-15. Vorbedingung: Rechnung `R-2026-000124` im Status `OFFEN`. Eingabe: `storniere()` ohne Bestätigung; danach mit Bestätigung. Erwartetes Ergebnis: ohne Bestätigung kein Service-Aufruf; mit Bestätigung genau ein Aufruf `storniere("R-2026-000124")`. **TC-12 — Änderungsaktionen deaktivieren** Abgedeckte PH-Anforderung: F-08. Vorbedingung: Beleg im Status `VERSENDET`. Eingabe: Änderungsaktionen ermitteln. Erwartetes Ergebnis: alle inhaltlichen Änderungsaktionen deaktiviert; PDF-Export aktiviert. **TC-13 — Statusfilter der Dokumentliste** Abgedeckte PH-Anforderung: F-06. Vorbedingung: Belege mit Status `OFFEN` (2x) und `STORNIERT` (1x). Eingabe: Statusfilter `OFFEN` anwenden. Erwartetes Ergebnis: Liste enthält genau die zwei offenen Belege. **TC-14 — Stammdatensuche delegieren** Abgedeckte PH-Anforderung: F-03. Vorbedingung: Stub `KundenService.suche("Muster")` liefert einen Treffer. Eingabe: Suchbegriff „Muster" eingeben. Erwartetes Ergebnis: Controller delegiert an `KundenService.suche(...)`; Trefferliste enthält genau diesen Kunden. Damit sind 14 Testfälle (> 10) spezifiziert, die alle funktionalen Kernregeln der Dialogführung (F-09–F-15) sowie die übergreifenden Darstellungsregeln (F-03, F-06, F-08, F-16) 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) | | PZ | Projektziel (Lastenheft) | | GUI | Graphical User Interface (grafische Benutzeroberfläche) | | MVC | Model–View–Controller (Architekturmuster) | | 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.