SE1_Team_1

28 KiB

Raw Blame History

title

subtitle

author

version

lang

toc

toc-depth

numbersections

papersize

geometry

fontsize

linestretch

mainfont

sansfont

monofont

header-includes

Pflichtenheft

Desktop-Fakturierungsanwendung — Gruppe D: Programmoberfläche

Team 1 – Gruppe D

1.0

de-DE

true

false

margin=3cm

12pt

1.5

Times New Roman

Arial

DejaVu Sans Mono

\usepackage{fancyhdr} \usepackage{lastpage} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Team 1 – Gruppe D} \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 | +=============================+=========================+=========================+ | Güngör, Mirkan\ | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd | | König, Moritz\ | | | | Bouhki, Mohammed | | | +-----------------------------+-------------------------+-------------------------+ | Gruppe D (Oberfläche) | 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 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

\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.0, 09.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.

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<PositionsEingabe>`	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:

// Gruppe A — Dokumentenzyklus (genutzt von F-06 bis F-15)
public interface DokumentService {
    Rechnung erstelleRechnung(String kundenNr, List<PositionsEingabe> positionen,
                              LocalDate rechnungsdatum, LocalDate zahlungsziel);
    void storniere(String rechnungsnummer);
    List<Dokument> 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<Kunde> suche(String suchbegriff);
}

// Gruppe B — Produktverwaltung (genutzt von F-03, F-04, Wizard-Schritt 2)
public interface ProduktService {
    Produkt findeProdukt(String produktnummer);
    List<Produkt> 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 (Hauptfenster, Modulansichten, Wizard-Dialog) enthalten ausschließlich Darstellung; die Controller (HauptController, StammdatenController, RechnungsWizardController, DokumentListenController) kapseln Dialogführung und Vollständigkeitsprüfungen und rufen die Service-Schnittstellen der Gruppen A–C auf. Das UI-Zustandsmodell (RechnungsWizardModel, Meldung) ist frei von GUI-Framework-Klassen und damit im Modultest ohne Oberfläche prüfbar.

7.1 Klassendiagramm

![Abbildung 1: UML-Klassendiagramm Programmoberfläche (Gruppe D)]

Beschreibung zu Abbildung 1: Das Klassendiagramm zeigt die Controller-Schicht der Oberfläche. Der HauptController verwaltet die Navigation (F-01, F-02) und erzeugt die Modul-Controller. 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). Fehler- und Erfolgsmeldungen werden einheitlich über die Klasse Meldung dargestellt (F-16, F-17).

7.2 Sequenzdiagramm

![Abbildung 2: UML-Sequenzdiagramm „Geführte Rechnungserstellung (Wizard)" (Gruppe D)]

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.

28 KiB Raw Blame History Unescape Escape