3028868
/
SE1_Team_2
5
5
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
SE1_Team_2/Unterlagen/Pflichtenheft_GruppeF_Dokum...

26 KiB
Raw Blame History

Pflichtenheft - Dokumentenprozess Fakturierungssystem

Gruppe F - SE1 Team 2
Version: 1.0
Datum: 11.06.2026

Inhaltsverzeichnis

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:

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

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

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.