611 lines
29 KiB
Markdown
611 lines
29 KiB
Markdown
---
|
||
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<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.
|
||
|
||
```java
|
||
// 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.
|