Dateien nach "Unterlagen" hochladen
parent
045c0971a8
commit
e86071a403
Binary file not shown.
|
|
@ -0,0 +1,395 @@
|
|||
# Pflichtenheft - Dokumentenprozess Fakturierungssystem
|
||||
|
||||
**Gruppe F - SE1 Team 2**
|
||||
**Version:** 1.0
|
||||
**Datum:** 11.06.2026
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
- [Freigabeübersicht](#freigabeübersicht)
|
||||
- [Dokumentenhistorie](#dokumentenhistorie)
|
||||
- [1. Einleitung](#1-einleitung)
|
||||
- [1.1 Zweck dieses Dokuments](#11-zweck-dieses-dokuments)
|
||||
- [1.2 Bezug zum Project Charter](#12-bezug-zum-project-charter)
|
||||
- [1.3 Geltungsbereich](#13-geltungsbereich)
|
||||
- [2. Systemüberblick für Gruppe F](#2-systemüberblick-für-gruppe-f)
|
||||
- [3. Stakeholder und Kontext](#3-stakeholder-und-kontext)
|
||||
- [4. Funktionale Anforderungen](#4-funktionale-anforderungen)
|
||||
- [5. Nicht-funktionale Anforderungen für das Modul](#5-nicht-funktionale-anforderungen-für-das-modul)
|
||||
- [6. Daten und Schnittstellen](#6-daten-und-schnittstellen)
|
||||
- [6.1 Datenobjekte und Java-Datentypen](#61-datenobjekte-und-java-datentypen)
|
||||
- [6.2 Schnittstellen](#62-schnittstellen)
|
||||
- [7. Systemarchitektur](#7-systemarchitektur)
|
||||
- [8. Testbare Abnahmekriterien](#8-testbare-abnahmekriterien)
|
||||
- [9. Traceability zwischen Lastenheft und Pflichtenheft](#9-traceability-zwischen-lastenheft-und-pflichtenheft)
|
||||
- [10. Modultestplan](#10-modultestplan)
|
||||
- [11. Glossar](#11-glossar)
|
||||
- [12. Referenzen](#12-referenzen)
|
||||
|
||||
---
|
||||
|
||||
## Freigabeübersicht
|
||||
|
||||
| Ersteller | Prüfer | Freigebender |
|
||||
|---|---|---|
|
||||
| Gruppe F: Andreas Ivanovic, Armin Omanovic, Alexander Teller | Prof. Dr. Gerd Marmitt | SE1 Team 2 |
|
||||
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
||||
| 11.06.2026 | [Datum Review] | 30.06.2026 |
|
||||
|
||||
---
|
||||
|
||||
## Dokumentenhistorie
|
||||
|
||||
| Version | Datum | Autor | Änderung |
|
||||
|---|---:|---|---|
|
||||
| 1.0 | 11.06.2026 | Gruppe F / Alexander Teller | Initiale Erstellung des Pflichtenheft-Teils und Modultestplans für den Dokumentenprozess |
|
||||
|
||||
---
|
||||
|
||||
# 1. Einleitung
|
||||
|
||||
## 1.1 Zweck dieses Dokuments
|
||||
|
||||
Dieses Pflichtenheft beschreibt die konkrete Umsetzung des Moduls **Dokumentenprozess** im Fakturierungssystem. Es konkretisiert die Anforderungen aus dem Lastenheft und dem Project Charter für den Verantwortungsbereich der Gruppe F. Der Fokus liegt auf der fachlichen Kette:
|
||||
|
||||
```text
|
||||
Angebot -> Auftragsbestätigung -> Lieferschein -> Rechnung
|
||||
```
|
||||
|
||||
Das Dokument dient als Input für Implementierung, Komponententests und Integration mit Produktverwaltung, Kundenverwaltung und GUI.
|
||||
|
||||
## 1.2 Bezug zum Project Charter
|
||||
|
||||
Team 2 besteht aus den Gruppen E, F, G und H. Gruppe F ist laut Project Charter für den Dokumentenprozess verantwortlich. Der Dokumentenprozess umfasst die fachliche Kette **Angebot -> Auftragsbestätigung -> Lieferschein -> Rechnung**. Das Projekt nutzt **Java**, **JavaFX**, **SQLite** und **Gitty** und orientiert sich am **V-Modell**.
|
||||
|
||||
## 1.3 Geltungsbereich
|
||||
|
||||
Dieses Pflichtenheft deckt nur den Dokumentenprozess ab. Produktverwaltung, Kundenverwaltung und GUI werden nur als Schnittstellen beschrieben, weil sie durch die Gruppen G, H und E verantwortet werden.
|
||||
|
||||
Nicht Teil dieses Moduls sind:
|
||||
|
||||
- vollständige Buchhaltung
|
||||
- E-Rechnung
|
||||
- Mehrbenutzerbetrieb
|
||||
- Cloud-Betrieb
|
||||
- externe ERP-/FiBu-Anbindungen
|
||||
|
||||
---
|
||||
|
||||
# 2. Systemüberblick für Gruppe F
|
||||
|
||||
Das Modul Gruppe F stellt die Geschäftslogik für Dokumente bereit. Die GUI ruft den `DokumentService` auf. Produkt- und Kundendaten werden über Lookup-Schnittstellen gelesen. Dokumente werden persistent über ein Repository gespeichert. Aus vorhandenen Dokumenten können Folgedokumente erzeugt werden, wobei Status, Referenzen und fachliche Regeln geprüft werden.
|
||||
|
||||
---
|
||||
|
||||
# 3. Stakeholder und Kontext
|
||||
|
||||
| Stakeholder / Rolle | Interesse am Modul Dokumentenprozess |
|
||||
|---|---|
|
||||
| Auftraggeber Prof. Dr. Gerd Marmitt | Nachvollziehbare Umsetzung der Anforderungen und testbare Artefakte im V-Modell. |
|
||||
| Gruppe F | Implementierung des Dokumentenworkflows und Bereitstellung testbarer Services. |
|
||||
| Gruppe E - GUI | Benötigt Service-Methoden und DTOs für Anzeige, Eingabe und Export. |
|
||||
| Gruppe G - Produktverwaltung | Liefert Produktdaten und muss prüfen können, ob Produkte in Dokumenten referenziert sind. |
|
||||
| Gruppe H - Kundenverwaltung | Liefert Kundendaten und muss prüfen können, ob Kunden in Dokumenten referenziert sind. |
|
||||
| Endnutzer | Möchte Angebote, Aufträge, Lieferscheine und Rechnungen korrekt erzeugen und wiederfinden. |
|
||||
|
||||
---
|
||||
|
||||
# 4. Funktionale Anforderungen
|
||||
|
||||
| PH-ID | LH-Quelle | Kurzname | Konkretisierung / Systemverhalten | Priorität | Abnahmekriterium |
|
||||
|---|---|---|---|---|---|
|
||||
| PH-DP-01 | BA-DP-01, GR-04, GR-06 | Angebot anlegen | Das System MUSS über `DokumentService.erstelleAngebot(long kundenId, List<PositionCommand> positionen)` ein Angebot für genau einen vorhandenen Kunden mit mindestens einer Position erzeugen. Pro Position werden Produktbezeichnung, Einzelpreis netto und MwSt.-Satz als Snapshot übernommen. | Muss | Angebot ist gespeichert, besitzt Nummer `A-yyyy-nnnn`, Status `OFFEN`, Datum `LocalDate.now()` und korrekt berechnete Netto-, USt.- und Bruttosumme. |
|
||||
| PH-DP-02 | F-DP-02 | Angebotsnummer vergeben | Das System MUSS Angebotsnummern über `OfferNumberGenerator` je Kalenderjahr fortlaufend und eindeutig vergeben. | Muss | Zwei nacheinander erzeugte Angebote erhalten unterschiedliche und aufeinanderfolgende Nummern. |
|
||||
| PH-DP-03 | F-DP-03 | Angebot bearbeiten | Das System MUSS die Bearbeitung eines Angebots nur erlauben, solange `AngebotsStatus.OFFEN` gilt. | Muss | Bearbeitung bei `OFFEN` erfolgreich; bei `UEBERFUEHRT` wird `IllegalStateException` geworfen. |
|
||||
| PH-DP-04 | BA-DP-04, GR-01 | Auftragsbestätigung erzeugen | Das System MUSS aus genau einem offenen Angebot eine Auftragsbestätigung mit eigener Nummer `AB-yyyy-nnnn` erzeugen und alle Positionen unverändert übernehmen. | Muss | AB referenziert Angebotsnummer, Positionen und Summen entsprechen dem Angebot, Angebot wird auf `UEBERFUEHRT` gesetzt. |
|
||||
| PH-DP-05 | F-DP-05 | Doppelte Auftragsbestätigung verhindern | Das System MUSS vor der Erzeugung prüfen, ob für das Angebot bereits eine Auftragsbestätigung existiert. | Muss | Zweiter Erzeugungsversuch wird mit `DuplicateDocumentException` abgelehnt. |
|
||||
| PH-DP-06 | BA-DP-06, GR-01 | Lieferschein erzeugen | Das System MUSS aus genau einer bestätigten Auftragsbestätigung einen Lieferschein mit Nummer `LS-yyyy-nnnn` und `LocalDate lieferdatum` erzeugen. | Muss | Lieferschein referenziert AB, übernimmt Produktbezeichnung und Mengen und erhält Status `GELIEFERT`. |
|
||||
| PH-DP-07 | F-DP-07 | Lieferschein ohne Preise | Das System MUSS für Lieferscheinansicht und PDF nur Menge und Produktbezeichnung ausgeben, aber keine Einzelpreise, Netto-, USt.- oder Bruttowerte. | Muss | Export/DTO des Lieferscheins enthält keine Preisfelder. |
|
||||
| PH-DP-08 | BA-DP-08, F-DP-09, GR-01 | Rechnung erzeugen | Das System MUSS aus genau einem gelieferten Lieferschein eine Rechnung mit Nummer `R-yyyy-nnnn`, Rechnungsdatum, Referenz auf den Lieferschein und Pflichtangaben nach UStG erzeugen. | Muss | Rechnung enthält Kunde, Leistungsdatum/Lieferdatum, Positionen, fortlaufende Nummer, Netto-, USt.- und Bruttosumme. |
|
||||
| PH-DP-09 | F-DP-09 | Pflichtangaben prüfen | Das System MUSS vor dem Speichern einer Rechnung `RechnungPflichtangabenValidator.validate(Rechnung)` ausführen. | Muss | Fehlende Pflichtangaben verhindern Speicherung und liefern Validierungsfehler. |
|
||||
| PH-DP-10 | F-DP-10, GR-02 | Rechnungsnummer fortlaufend | Das System MUSS Rechnungsnummern fortlaufend, eindeutig und lückenlos vergeben, sobald eine Rechnung erfolgreich gespeichert wird. | Muss | Drei erfolgreiche Rechnungen ergeben `R-2026-0001`, `R-2026-0002`, `R-2026-0003`. |
|
||||
| PH-DP-11 | F-DP-11, GR-03 | Rechnung festschreiben | Das System MUSS eine gespeicherte Rechnung inhaltlich sperren (`festgeschrieben=true`). | Muss | Änderungsversuche an Positionen, Summen oder Pflichtangaben werden abgelehnt. |
|
||||
| PH-DP-12 | F-DP-12 | PDF-Export | Das System SOLL jedes Dokument über `PdfExportService.export(Dokument)` als PDF-Datei im lokalen Dateisystem erzeugen. | Soll | PDF-Datei existiert, ist nicht leer und enthält Dokumentnummer und Dokumenttyp. |
|
||||
| PH-DP-13 | F-DP-13 | Dokumentenübersicht pro Kunde | Das System SOLL über `DokumentRepository.findByKunde(long kundenId)` alle Dokumente eines Kunden sortiert nach Datum und Dokumenttyp bereitstellen. | Soll | Alle Angebote, ABs, Lieferscheine und Rechnungen des Kunden werden ohne fremde Kundendokumente geliefert. |
|
||||
| PH-DP-14 | GR-04 | Preis-Snapshot sichern | Das System MUSS den Produktpreis und MwSt.-Satz beim Einfügen in das Angebot als Snapshot in `Dokumentposition` speichern. | Muss | Spätere Produktänderung beeinflusst bestehende Dokumentpositionen nicht. |
|
||||
| PH-DP-15 | GR-05 | Stammdatenreferenzen prüfbar machen | Das Dokumentenmodul MUSS für Produkt- und Kundenverwaltung eine Prüffunktion `isReferenced(...)` bereitstellen. | Muss | Referenzierte Produkte/Kunden können durch andere Module als verwendet erkannt werden. |
|
||||
| PH-DP-16 | NF-TEST-02, NF-MAINT-03 | Testbare Logik ohne GUI | Die Dokumentenlogik MUSS in Service- und Domainklassen ohne JavaFX-Abhängigkeit implementiert werden. | Muss | JUnit-Tests können `DokumentService` ohne Start der GUI ausführen. |
|
||||
|
||||
---
|
||||
|
||||
# 5. Nicht-funktionale Anforderungen für das Modul
|
||||
|
||||
| PH-NF-ID | LH-Quelle | Konkretisierung | Nachweis |
|
||||
|---|---|---|---|
|
||||
| PH-NF-DP-01 | NF-PERF-01 | Dokumentenaktionen bis 1.000 Kunden/Produkte müssen innerhalb von 1 Sekunde eine Rückmeldung liefern, wenn Repositories mit Testdaten initialisiert sind. | Zeitmessung im Komponententest/Integrationstest `< 1 s` für Erzeugung eines Angebots mit 10 Positionen. |
|
||||
| PH-NF-DP-02 | NF-ARCH-01 | Dokumente müssen nach Neustart aus SQLite/Dateispeicher vollständig wiederherstellbar sein. | Dokument erstellen, Repository neu initialisieren, Dokument unverändert laden. |
|
||||
| PH-NF-DP-03 | NF-ARCH-02 | Datenhaltung des Dokumentenmoduls muss über `DokumentRepository` gekapselt sein. | Code-Review: Service nutzt Interface, keine direkten SQL-Aufrufe im Service. |
|
||||
| PH-NF-DP-04 | NF-MAINT-01, NF-MAINT-03 | Dokumentenprozess wird im Paket `de.hsma.se1.fakturierung.dokumente` umgesetzt und in Domain, Service, Repository und Export getrennt. | Repository-Struktur enthält getrennte Pakete; Abhängigkeiten laufen von UI -> Service -> Repository. |
|
||||
| PH-NF-DP-05 | NF-TEST-02, NF-TEST-03 | Die Geschäftslogik des Dokumentenmoduls muss automatisiert testbar sein. | Mindestens 10 JUnit-Testfälle für Services/Domainklassen laufen ohne GUI. |
|
||||
|
||||
---
|
||||
|
||||
# 6. Daten und Schnittstellen
|
||||
|
||||
## 6.1 Datenobjekte und Java-Datentypen
|
||||
|
||||
| Datenfeld / Objekt | Java-Datentyp | Wertebereich / Format | Beschreibung |
|
||||
|---|---|---|---|
|
||||
| `DokumentType` | `enum` | `ANGEBOT`, `AUFTRAGSBESTAETIGUNG`, `LIEFERSCHEIN`, `RECHNUNG` | Typisierung für Anzeige, Export und Repository. |
|
||||
| Dokumentnummer | `String` | Format `A-2026-0001`, `AB-2026-0001`, `LS-2026-0001`, `R-2026-0001` | Fachlicher Identifikator; nicht als `int`, da Präfix/Jahr enthalten. |
|
||||
| `kundenId` | `long` | z. B. `10001L` | Referenz auf Kundenverwaltung, keine Kopie des gesamten Kundenobjekts im Dokumentservice erforderlich. |
|
||||
| `produktId` | `long` | z. B. `20001L` | Referenz auf Produktverwaltung. |
|
||||
| `bezeichnungSnapshot` | `String` | max. 255 Zeichen | Produktbezeichnung zum Zeitpunkt der Angebotsanlage. |
|
||||
| `menge` | `int` | `> 0` | Menge pro Dokumentposition. |
|
||||
| `einzelpreisNettoSnapshot` | `BigDecimal` | `>= 0`, Skalierung 2 | Geldbetrag; `BigDecimal` statt `double` wegen Rundungsfehlern. |
|
||||
| `mwstSatzSnapshot` | `BigDecimal` | z. B. `0.19`, `0.07` | MwSt.-Satz als Dezimalwert. |
|
||||
| `datum`, `lieferdatum`, `rechnungsdatum` | `LocalDate` | ISO-Format `yyyy-MM-dd` | Fachliche Datumswerte ohne Uhrzeit. |
|
||||
| `nettoSumme`, `ustSumme`, `bruttoSumme` | `BigDecimal` | Skalierung 2, Rundung `HALF_UP` | Berechnete Summen des Dokuments. |
|
||||
| `status` | `enum` | `OFFEN`, `UEBERFUEHRT`, `BESTAETIGT`, `GELIEFERT`, `FAKTURIERT`, `FESTGESCHRIEBEN` | Steuert erlaubte Folgeaktionen. |
|
||||
| `pflichtangaben` | `RechnungPflichtangaben` | Objekt mit `leistungserbringerName`, `anschrift`, `steuerNr`, `leistungsdatum` usw. | Pflichtfelder der Rechnung. |
|
||||
|
||||
## 6.2 Schnittstellen
|
||||
|
||||
| Schnittstelle | Art | Zweck | Operationen / Daten |
|
||||
|---|---|---|---|
|
||||
| `DokumentService` | Java-Service-Interface | UI/Controller ruft Dokumentenlogik auf. | Methoden: `erstelleAngebot`, `erstelleAuftragsbestaetigung`, `erstelleLieferschein`, `erstelleRechnung`, `exportiereAlsPdf`. |
|
||||
| `DokumentRepository` | Java-Interface / SQLite-Implementierung | Persistenz von Dokumenten. | `save`, `findByNummer`, `findByKunde`, `existsFolgedokument`, `existsReferencedProdukt`, `existsReferencedKunde`. |
|
||||
| `ProductLookup` | Java-Interface zu Gruppe G | Produktdaten für Angebotspositionen lesen. | `findProduct(long produktId): Optional<ProductDto>` mit `String bezeichnung`, `BigDecimal einzelpreisNetto`, `BigDecimal mwstSatz`. |
|
||||
| `CustomerLookup` | Java-Interface zu Gruppe H | Kundendaten für Dokumentkopf und Rechnungspflichtangaben lesen. | `findCustomer(long kundenId): Optional<CustomerDto>`. |
|
||||
| `PdfExportService` | Java-Service / lokale Datei-Schnittstelle | PDF-Dateien aus Dokumentdaten erzeugen. | Rückgabe `Path`; Zielordner z. B. `/exports`. |
|
||||
|
||||
---
|
||||
|
||||
# 7. Systemarchitektur
|
||||
|
||||
Das Dokumentenmodul folgt einer dreischichtigen Struktur: Präsentation/UI ruft Services auf, Services enthalten die Geschäftslogik, Repositories kapseln die Datenhaltung. Die fachlichen Domänenklassen sind von JavaFX unabhängig und können isoliert getestet werden.
|
||||
|
||||
## Abbildung 1: UML-Klassendiagramm Gruppe F
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
direction TB
|
||||
|
||||
class DokumentService {
|
||||
+erstelleAngebot(...) Angebot
|
||||
+aktualisiereAngebot(...) Angebot
|
||||
+erstelleAuftragsbestaetigung(...) Auftragsbestaetigung
|
||||
+erstelleLieferschein(...) Lieferschein
|
||||
+erstelleRechnung(...) Rechnung
|
||||
+exportiereAlsPdf(...) Path
|
||||
}
|
||||
|
||||
class Dokument {
|
||||
<<abstract>>
|
||||
-nummer String
|
||||
-kundeId long
|
||||
-datum LocalDate
|
||||
-positionen List~Dokumentposition~
|
||||
-nettoSumme BigDecimal
|
||||
-ustSumme BigDecimal
|
||||
-bruttoSumme BigDecimal
|
||||
+berechneSummen() SummenDto
|
||||
}
|
||||
|
||||
class Dokumentposition {
|
||||
-produktId long
|
||||
-bezeichnungSnapshot String
|
||||
-menge int
|
||||
-einzelpreisNettoSnapshot BigDecimal
|
||||
-mwstSatzSnapshot BigDecimal
|
||||
+berechneNetto() BigDecimal
|
||||
+berechneUst() BigDecimal
|
||||
}
|
||||
|
||||
class Angebot {
|
||||
-angebotsNr String
|
||||
-status AngebotsStatus
|
||||
+istBearbeitbar() boolean
|
||||
}
|
||||
|
||||
class Auftragsbestaetigung {
|
||||
-auftragNr String
|
||||
-angebotNr String
|
||||
-status AuftragsStatus
|
||||
+ausAngebot(...) ...
|
||||
}
|
||||
|
||||
class Lieferschein {
|
||||
-lieferscheinNr String
|
||||
-auftragsNr String
|
||||
-lieferdatum LocalDate
|
||||
-status LieferStatus
|
||||
}
|
||||
|
||||
class Rechnung {
|
||||
-rechnungsNr String
|
||||
-lieferscheinNr String
|
||||
-rechnungsdatum LocalDate
|
||||
-status RechnungsStatus
|
||||
-festgeschrieben boolean
|
||||
}
|
||||
|
||||
class DokumentRepository {
|
||||
<<interface>>
|
||||
+save(Dokument) Dokument
|
||||
+findByNummer(String) Optional~Dokument~
|
||||
+existsFolgedokument(String) boolean
|
||||
+findByKunde(long) List~Dokument~
|
||||
}
|
||||
|
||||
class NumberGenerator {
|
||||
+nextAngebotsNr(int) String
|
||||
+nextAuftragsNr(int) String
|
||||
+nextLieferscheinNr(int) String
|
||||
+nextRechnungsNr(int) String
|
||||
}
|
||||
|
||||
class PdfExportService {
|
||||
+export(Dokument) Path
|
||||
+exportRechnung(Rechnung) Path
|
||||
-templateEngine String
|
||||
}
|
||||
|
||||
Dokument "1" *-- "1..*" Dokumentposition : enthält
|
||||
Dokument <|-- Angebot
|
||||
Dokument <|-- Auftragsbestaetigung
|
||||
Dokument <|-- Lieferschein
|
||||
Dokument <|-- Rechnung
|
||||
|
||||
DokumentService ..> Dokument : nutzt
|
||||
DokumentService ..> DokumentRepository : nutzt
|
||||
DokumentService ..> NumberGenerator : nutzt
|
||||
DokumentService ..> PdfExportService : PDF-Export
|
||||
|
||||
Angebot --> Auftragsbestaetigung : 1:1 erzeugt aus
|
||||
Auftragsbestaetigung --> Lieferschein : 1:1 erzeugt
|
||||
Lieferschein --> Rechnung : 1:1 erzeugt aus
|
||||
```
|
||||
|
||||
**Beschreibung zu Abbildung 1:** Das Klassendiagramm zeigt die zentrale abstrakte Klasse `Dokument` mit den Spezialisierungen `Angebot`, `Auftragsbestaetigung`, `Lieferschein` und `Rechnung`. Die Klasse `Dokumentposition` speichert Produktdaten als Snapshot. Der `DokumentService` nutzt Repositories, Nummerngenerator und PDF-Export, ohne selbst technische Persistenzdetails zu kennen.
|
||||
|
||||
## Abbildung 2: UML-Sequenzdiagramm Rechnung aus Lieferschein
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor Anwender
|
||||
participant UI as DokumentenUI
|
||||
participant DS as DokumentService
|
||||
participant LR as LieferscheinRepo
|
||||
participant NG as NumberGenerator
|
||||
participant RR as RechnungRepo
|
||||
participant PDF as PdfExportService
|
||||
|
||||
Anwender->>UI: Klick: Rechnung erzeugen(lsNr)
|
||||
UI->>DS: erstelleRechnung(lsNr)
|
||||
DS->>LR: findByNummer(lsNr)
|
||||
LR-->>DS: Lieferschein(status=GELIEFERT)
|
||||
|
||||
alt Lieferschein fehlt oder Status != GELIEFERT
|
||||
DS-->>UI: Fehlermeldung, keine Rechnungsnummer vergeben, keine Rechnung gespeichert
|
||||
UI-->>Anwender: Anzeige der Fehlermeldung
|
||||
else Lieferschein ist geliefert
|
||||
DS->>NG: nextRechnungsNr(jahr)
|
||||
NG-->>DS: R-2026-0001
|
||||
DS->>DS: pruefeStatusUndVorgaenger()
|
||||
DS->>DS: berechneNettoUstBrutto()
|
||||
DS->>RR: save(rechnung)
|
||||
RR-->>DS: gespeicherte Rechnung
|
||||
DS->>PDF: exportRechnung(rechnung)
|
||||
PDF-->>DS: pdfPfad
|
||||
DS-->>UI: Bestaetigung + Nummer + pdfPfad
|
||||
UI-->>Anwender: Anzeige der Rechnung
|
||||
end
|
||||
```
|
||||
|
||||
**Beschreibung zu Abbildung 2:** Das Sequenzdiagramm beschreibt den Ablauf zur Rechnungserzeugung aus einem Lieferschein. Zuerst wird der Lieferschein geladen und sein Status geprüft. Danach wird eine Rechnungsnummer vergeben, die Rechnung berechnet, gespeichert, optional als PDF exportiert und an die GUI zurückgegeben. Falls der Lieferschein fehlt oder nicht den Status `GELIEFERT` besitzt, wird keine Rechnung erzeugt.
|
||||
|
||||
---
|
||||
|
||||
# 8. Testbare Abnahmekriterien
|
||||
|
||||
| AC-ID | Abgedeckte PH-Anforderungen | Testbares Abnahmekriterium |
|
||||
|---|---|---|
|
||||
| AC-DP-01 | PH-DP-01, PH-DP-02, PH-DP-14 | Aus vorhandenem Kunden und zwei Produkten wird ein Angebot erzeugt. Erwartet werden korrekte Nummer, Status `OFFEN`, zwei Positionen, Preis-Snapshots und korrekte Summen. |
|
||||
| AC-DP-02 | PH-DP-03 | Ein offenes Angebot kann geändert werden. Ein überführtes Angebot kann nicht mehr geändert werden. |
|
||||
| AC-DP-03 | PH-DP-04, PH-DP-05 | Aus einem offenen Angebot wird genau eine Auftragsbestätigung erzeugt. Ein zweiter Versuch wird abgelehnt. |
|
||||
| AC-DP-04 | PH-DP-06, PH-DP-07 | Aus einer bestätigten AB wird ein Lieferschein erzeugt. Der Lieferschein enthält Mengen und Bezeichnungen, aber keine Preise. |
|
||||
| AC-DP-05 | PH-DP-08, PH-DP-09, PH-DP-10, PH-DP-11 | Aus einem gelieferten Lieferschein wird eine festgeschriebene Rechnung mit Pflichtangaben, lückenloser Nummer und korrekten Summen erzeugt. |
|
||||
| AC-DP-06 | PH-DP-12 | Ein Dokument kann als PDF exportiert werden; die Datei existiert und enthält Dokumentnummer und Dokumenttyp. |
|
||||
| AC-DP-07 | PH-DP-13 | Alle Dokumente eines Kunden werden kundenbezogen aufgelistet. |
|
||||
| AC-DP-08 | PH-DP-15 | Produkt- und Kundenverwaltung können prüfen, ob Stammdaten in Dokumenten referenziert werden. |
|
||||
|
||||
---
|
||||
|
||||
# 9. Traceability zwischen Lastenheft und Pflichtenheft
|
||||
|
||||
| LH-Anforderung | Kurzbeschreibung | PH-Anforderungen | Abnahmekriterium | Modultestfälle |
|
||||
|---|---|---|---|---|
|
||||
| BA-DP-01 | Angebot für Kunden anlegen | PH-DP-01, PH-DP-14 | AC-DP-01 | MT-DP-01, MT-DP-02, MT-DP-13 |
|
||||
| F-DP-02 | Angebotsnummer eindeutig/fortlaufend | PH-DP-02 | AC-DP-01 | MT-DP-03 |
|
||||
| F-DP-03 | Angebot nur bis Überführung bearbeiten | PH-DP-03 | AC-DP-02 | MT-DP-04 |
|
||||
| BA-DP-04 | Auftragsbestätigung aus Angebot | PH-DP-04 | AC-DP-03 | MT-DP-05 |
|
||||
| F-DP-05 | Maximal eine AB pro Angebot | PH-DP-05 | AC-DP-03 | MT-DP-06 |
|
||||
| BA-DP-06 | Lieferschein aus AB | PH-DP-06 | AC-DP-04 | MT-DP-07 |
|
||||
| F-DP-07 | Lieferschein ohne Preise | PH-DP-07 | AC-DP-04 | MT-DP-08 |
|
||||
| BA-DP-08 | Rechnung aus Lieferschein | PH-DP-08 | AC-DP-05 | MT-DP-09 |
|
||||
| F-DP-09 | Rechnungspflichtangaben | PH-DP-09 | AC-DP-05 | MT-DP-10 |
|
||||
| F-DP-10 | Rechnungsnummer fortlaufend/lückenlos | PH-DP-10 | AC-DP-05 | MT-DP-11 |
|
||||
| F-DP-11 | Rechnung unveränderlich | PH-DP-11 | AC-DP-05 | MT-DP-12 |
|
||||
| F-DP-12 | PDF-Export | PH-DP-12 | AC-DP-06 | MT-DP-14 |
|
||||
| F-DP-13 | Dokumentenübersicht Kunde | PH-DP-13 | AC-DP-07 | MT-DP-15 |
|
||||
| GR-01 | Dokumentenkette | PH-DP-04, PH-DP-06, PH-DP-08 | AC-DP-03 bis AC-DP-05 | MT-DP-05, MT-DP-07, MT-DP-09 |
|
||||
| GR-02 | Rechnungsnummern eindeutig | PH-DP-10 | AC-DP-05 | MT-DP-11 |
|
||||
| GR-03 | Rechnung nicht änderbar | PH-DP-11 | AC-DP-05 | MT-DP-12 |
|
||||
| GR-04 | Preisübernahme Snapshot | PH-DP-14 | AC-DP-01 | MT-DP-13 |
|
||||
| GR-05 | Stammdatenschutz | PH-DP-15 | AC-DP-08 | MT-DP-16 |
|
||||
| GR-06 | Summenberechnung | PH-DP-01, PH-DP-08 | AC-DP-01, AC-DP-05 | MT-DP-02, MT-DP-09 |
|
||||
|
||||
---
|
||||
|
||||
# 10. Modultestplan
|
||||
|
||||
Die folgenden Testfälle sind so formuliert, dass sie direkt mit JUnit 5 umgesetzt werden können. Für den isolierten Modultest werden Produkt- und Kundendaten durch Fake-Lookups bereitgestellt. Die GUI wird nicht gestartet.
|
||||
|
||||
| Test-ID | Name | Abgedeckte PH-Anforderungen | Vorbedingung | Testschritte | Erwartetes Ergebnis | Umsetzungshinweis |
|
||||
|---|---|---|---|---|---|---|
|
||||
| MT-DP-01 | Angebot anlegen - Happy Path | PH-DP-01 | Kunde 10001 und Produkte 20001/20002 existieren. | `erstelleAngebot(10001, [2x Produkt 20001, 1x Produkt 20002])` | Angebot gespeichert, Status `OFFEN`, 2 Positionen, Nummer beginnt mit `A-2026-`. | JUnit: `assertEquals`, `FakeProductLookup`, `InMemoryDokumentRepository` |
|
||||
| MT-DP-02 | Summenberechnung Angebot | PH-DP-01, PH-DP-08 | Positionen: 2 x 100,00 EUR mit 19 %, 1 x 50,00 EUR mit 7 %. | `angebot.berechneSummen()` | Netto 250,00; USt. 41,50; Brutto 291,50. | JUnit: BigDecimal-Vergleich mit `compareTo` oder skalierter Assertion |
|
||||
| MT-DP-03 | Fortlaufende Angebotsnummern | PH-DP-02 | Leerer Nummernkreis 2026. | Zwei Angebote erzeugen. | Nummern `A-2026-0001` und `A-2026-0002`. | JUnit: `assertNotEquals`, `assertTrue(endsWith)` |
|
||||
| MT-DP-04 | Angebot nach Überführung sperren | PH-DP-03 | Angebot wurde in AB überführt. | `aktualisiereAngebot(...)` aufrufen. | `IllegalStateException`; Positionen unverändert. | JUnit: `assertThrows` |
|
||||
| MT-DP-05 | Auftragsbestätigung erzeugen | PH-DP-04 | Offenes Angebot mit 2 Positionen existiert. | `erstelleAuftragsbestaetigung(angebotsNr)` | AB mit eigener Nummer, Angebotsreferenz und identischen Positionen gespeichert. | JUnit: Objektvergleich Positionen |
|
||||
| MT-DP-06 | Doppelte AB verhindern | PH-DP-05 | Für Angebot existiert bereits eine AB. | `erstelleAuftragsbestaetigung(angebotsNr)` erneut. | `DuplicateDocumentException`; keine zweite AB im Repository. | JUnit: `assertThrows`, Repository-Count |
|
||||
| MT-DP-07 | Lieferschein erzeugen | PH-DP-06 | AB im Status `BESTAETIGT` existiert. | `erstelleLieferschein(auftragsNr, lieferdatum)` | LS mit Nummer, Lieferdatum, AB-Referenz und Status `GELIEFERT` gespeichert. | JUnit: `assertEquals` |
|
||||
| MT-DP-08 | Lieferschein enthält keine Preise | PH-DP-07 | Lieferschein aus AB existiert. | `LieferscheinDto.from(lieferschein)` oder Exportmodell erzeugen. | DTO enthält Menge und Bezeichnung, aber keine Preis-/Steuerfelder. | JUnit: Getter/DTO-Feldprüfung |
|
||||
| MT-DP-09 | Rechnung erzeugen - Happy Path | PH-DP-08, PH-DP-09 | LS im Status `GELIEFERT` mit Kunde und Positionen existiert. | `erstelleRechnung(lieferscheinNr)` | Rechnung mit `R-...`, Pflichtangaben, Summen und Status `FESTGESCHRIEBEN` gespeichert. | JUnit: `assertAll` |
|
||||
| MT-DP-10 | Pflichtangaben fehlen | PH-DP-09 | Kunde ohne Rechnungsanschrift/Steuernummer in Testdaten. | `erstelleRechnung(lieferscheinNr)` | Validierungsfehler; keine Rechnung gespeichert. | JUnit: `assertThrows(ValidationException.class)` |
|
||||
| MT-DP-11 | Rechnungsnummern lückenlos | PH-DP-10 | Drei unterschiedliche gelieferte Lieferscheine existieren. | Drei Rechnungen erzeugen. | Nummern enden auf `0001`, `0002`, `0003` ohne Lücke. | JUnit: Listenvergleich |
|
||||
| MT-DP-12 | Rechnung unveränderlich | PH-DP-11 | Rechnung wurde gespeichert/festgeschrieben. | Änderung von Position oder Summe versuchen. | Änderung wird abgelehnt; geladene Rechnung bleibt unverändert. | JUnit: `assertThrows`, erneutes Laden |
|
||||
| MT-DP-13 | Preis-Snapshot bleibt stabil | PH-DP-14 | Angebot wurde mit Produktpreis 100,00 erzeugt. | Danach Produktpreis auf 120,00 setzen. Angebot erneut laden. | Positionspreis im Angebot bleibt 100,00. | JUnit mit `FakeProductLookup`-Preiswechsel |
|
||||
| MT-DP-14 | PDF-Export erzeugt Datei | PH-DP-12 | Angebot oder Rechnung existiert. | `exportiereAlsPdf(dokumentNr)` | Rückgabe `Path`; Datei existiert und Größe `> 0 Byte`. | JUnit mit temporärem Verzeichnis `@TempDir` |
|
||||
| MT-DP-15 | Dokumentenübersicht pro Kunde | PH-DP-13 | Dokumente für Kunde 1 und Kunde 2 existieren. | `findByKunde(1)` | Nur Dokumente von Kunde 1, sortiert nach Datum. | JUnit: `assertTrue(allMatch)` |
|
||||
| MT-DP-16 | Stammdatenreferenz prüfen | PH-DP-15 | Produkt 20001 ist in Angebot referenziert, Produkt 99999 nicht. | `isProductReferenced(20001)` und `isProductReferenced(99999)` | Ergebnis `true` bzw. `false`. | JUnit: `assertTrue`, `assertFalse` |
|
||||
|
||||
---
|
||||
|
||||
# 11. Glossar
|
||||
|
||||
| Begriff | Bedeutung |
|
||||
|---|---|
|
||||
| Angebot | Preisangebot an einen Kunden, Ausgangspunkt der Dokumentenkette. |
|
||||
| Auftragsbestätigung | Verbindliche Bestätigung der Annahme eines Angebots. |
|
||||
| Lieferschein | Dokumentiert Lieferung; enthält keine Preise. |
|
||||
| Rechnung | Festgeschriebenes Dokument mit Zahlungsforderung und Pflichtangaben. |
|
||||
| Snapshot | Kopie von Produktpreis, Produktbezeichnung und MwSt.-Satz zum Zeitpunkt der Angebotsanlage. |
|
||||
| Traceability | Rückverfolgbarkeit von Lastenheft-Anforderung zu Pflichtenheft-Anforderung und Testfall. |
|
||||
|
||||
---
|
||||
|
||||
# 12. Referenzen
|
||||
|
||||
- Project Charter - Fakturierungssystem, Version 1.0, 15.04.2026.
|
||||
- Lastenheft - Fakturierungssystem, Version 1.0 alpha, 12.05.2026.
|
||||
- Vorlesung Software Engineering 1: Lastenheft, Pflichtenheft, Traceability, V-Modell und Komponententests.
|
||||
Loading…
Reference in New Issue