--- title: "Pflichtenheft" subtitle: "Desktop-Fakturierungsanwendung — Gruppe D: Programmoberfläche" author: - Team 1 – Gruppe D version: "1.1" 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.1} \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 | +-----------------------------+-------------------------+-------------------------+ | 13.06.2026 | 13.06.2026 | 13.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 | \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 - 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 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 (Was gehört dazu / was nicht) **Im Umfang dieser Komponente:** - Hauptfenster mit Navigation zu den Modulen Kunden, Produkte und Dokumente - Listen-, Such- und Formularansichten für Kunden (Gruppe C) und Produkte (Gruppe B) - Dokumentliste mit Statusanzeige und Belegaktionen (PDF-Export, Druck, E-Mail) der Gruppe A - 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) **Nicht im Umfang dieser Komponente:** - Fachlogik des Dokumentenzyklus: Belegerzeugung, Summenberechnung, Nummernvergabe, Statusführung, Storno-Logik, PDF-Erzeugung (Gruppe A) - Fachlogik und Persistenz der Stammdaten: Validierungsregeln, Nummernvergabe, Löschsperren (Gruppen B und C) - E-Rechnungsformate, Mahnwesen, Buchhaltung, mobile Clients (LH-Nichtziele) ### 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. ### 2.4 UML-Bezug Ein gemeinsames Use-Case-Diagramm aller Gruppen gibt den Überblick über die Akteure und Ziele. Die für Gruppe D relevanten Use Cases sind: *Rechnung erstellen (geführt)* und *Rechnung stornieren* (jeweils Dialogführung) sowie der Bedienzugang zu allen Use Cases der Gruppen A–C. 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) **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 den Satzschablonen des Foliensatzes 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. ```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`) verwaltet die Navigation (F-01, F-02): es nimmt die drei Modulansichten (`KundenPanel`, `ProduktPanel`, `DokumentListenPanel`) entgegen und schaltet sie über ein `CardLayout` um. Der `StammdatenController` bedient Listen-, Such- und Formularansichten für Kunden und Produkte und nutzt dazu `KundenService` (Gruppe C) und `ProduktService` (Gruppe B). Der `RechnungsWizardController` führt die Schrittfolge des Enums `WizardSchritt` über das `RechnungsWizardModel` (Komposition) und delegiert das Speichern an den `DokumentService` (Gruppe A). Der `DokumentListenController` stellt die Dokumentliste mit Statusfilter dar und bietet die Belegaktionen an (F-06–F-08, F-14, F-15). Die Modulansichten abonnieren den gemeinsamen `EreignisBus` (Observer-Muster) und aktualisieren sich nach Datenänderungen selbsttätig. 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 | Abgedeckte PH-Anf. | Vorbedingung | Eingabe | Erwartetes Ergebnis | |-------|--------------------|--------------|---------|---------------------| | TC-01 | F-09 | Wizard neu gestartet | `aktuellerSchritt` lesen | `KUNDE_WAEHLEN` (erster Schritt) | | TC-02 | F-09 | Schritt 1 mit gewähltem Kunden | `weiter()` 4-mal mit gültigen Eingaben | Schrittfolge: `POSITIONEN_ERFASSEN` → `DATEN_BESTAETIGEN` → `ZUSAMMENFASSUNG` → `SPEICHERN` | | TC-03 | F-10 | Schritt 1, kein Kunde gewählt (`kundenNr = null`) | `weiter()` | Wechsel verhindert; `Meldung(FEHLER, "Kunde", …)` erzeugt | | TC-04 | F-10 | Schritt 2, leere Positionsliste | `weiter()` | Wechsel verhindert; Meldung benennt „Position" | | TC-05 | F-10 | Schritt 2, Position mit `menge = 0` | `weiter()` | Wechsel verhindert; Meldung benennt „Menge" | | TC-06 | F-11 | Schritt 3 erreicht; Kunde `K-000017`, 1 Position erfasst | `zurueck()` bis Schritt 1 | `kundenNr` und `positionen` unverändert erhalten | | TC-07 | F-12 | Schritt 4; Stub `DokumentService` liefert Summen 200.00/38.00/238.00 | Zusammenfassung erzeugen | Zusammenfassung enthält Kunde, Positionen, Mengen, 200.00/38.00/238.00, Rechnungsdatum, Zahlungsziel | | TC-08 | F-13 | Schritt 5; gültiges Modell | `speichern()` | genau **ein** Aufruf `erstelleRechnung(...)` am Mock; Erfolgsmeldung enthält gelieferte Rechnungsnummer | | TC-09 | F-13 (Fehlerfall) | Stub `erstelleRechnung` wirft Validierungsfehler „Rechnungsdatum" | `speichern()` | keine Erfolgsmeldung; `Meldung(FEHLER, "Rechnungsdatum", …)` dargestellt (F-05/F-16) | | TC-10 | F-14 | Dokumentliste mit Rechnungen in `OFFEN`, `VERSENDET`, `STORNIERT` | verfügbare Aktionen je Rechnung ermitteln | *Stornieren* nur bei Status `OFFEN` aktiviert | | TC-11 | F-15 | Rechnung `R-2026-000124` im Status `OFFEN` | `storniere()` ohne Bestätigung; danach mit Bestätigung | ohne Bestätigung: kein Service-Aufruf; mit Bestätigung: genau ein Aufruf `storniere("R-2026-000124")` | | TC-12 | F-08 | Beleg im Status `VERSENDET` | Änderungsaktionen ermitteln | alle inhaltlichen Änderungsaktionen deaktiviert; PDF-Export aktiviert | | TC-13 | F-06 | Belege mit Status `OFFEN` (2×) und `STORNIERT` (1×) | Statusfilter `OFFEN` anwenden | Liste enthält genau die 2 offenen Belege | | TC-14 | F-03 | Stub `KundenService.suche("Muster")` liefert 1 Treffer | Suchbegriff „Muster" eingeben | 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.