SE1_Team_1

29 KiB

Raw Permalink 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.2

de-DE

true

false

margin=3cm

12pt

1.5

Times New Roman

Arial

Menlo

\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.

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:

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.

// Gruppe A — Dokumentenzyklus (genutzt von F-06 bis F-15)
public interface DokumentService {
    Rechnung erstelleRechnung(String kundenNr, List<Positionsangabe> 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 (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

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

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.

29 KiB Raw Permalink Blame History Unescape Escape