29 KiB
| title | subtitle | author | version | lang | toc | toc-depth | numbersections | papersize | geometry | fontsize | linestretch | mainfont | sansfont | monofont | header-includes | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pflichtenheft | Desktop-Fakturierungsanwendung — Gruppe A: Prozess / Dokumentenzyklus |
|
1.2 | de-DE | true | 3 | false | a4 | margin=3cm | 12pt | 1.5 | Times New Roman | Arial | DejaVu Sans Mono | \usepackage{fancyhdr} \usepackage{lastpage} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Team 1 – Gruppe A} \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 | +=========================+=========================+=========================+ | Strubel, Lucas | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd | +-------------------------+-------------------------+-------------------------+ | Gruppe A (Prozess) | Modulverantwortlicher | Modulverantwortlicher | +-------------------------+-------------------------+-------------------------+ | 13.06.2026 | 13.06.2026 | 13.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 Prozess / Dokumentenzyklus.
Dokumentenhistorie
| Version | Datum | Autor | Grund der Änderung |
|---|---|---|---|
| 1.0 | 09.06.2026 | Lucas Strubel | Initiale Erstellung |
| 1.1 | 13.06.2026 | Lucas Strubel | Einfügen der UML-Diagramme (Klassen- und Sequenzdiagramm) |
| 1.2 | 15.06.2026 | Lucas Strubel | Modultestplan in eigenständiges Dokument (Modultestplan.md) ausgegliedert |
\newpage
1. Einleitung
1.1 Zweck des Dokuments
Dieses Pflichtenheft (System Requirements Specification, SRS) beschreibt aus Sicht des Auftragnehmers, wie die Komponente Prozess / Dokumentenzyklus 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 (eigenständiges Dokument Modultestplan.md).
1.2 Ziel
Ziel dieses Pflichtenhefts ist die vollständige und testbare Spezifikation der Erzeugung, Verknüpfung und Statusführung der vier kaufmännischen Belegtypen (Angebot, Auftragsbestätigung, Lieferschein, Rechnung), der geführten Rechnungserstellung sowie der Rechnungsstornierung.
1.3 Geltungsbereich
Dieses Dokument gilt für die Komponente Gruppe A — Prozess / Dokumentenzyklus. Die Gesamtanwendung wird arbeitsteilig in vier Komponenten entwickelt; jede Untergruppe pflegt ein eigenes Pflichtenheft:
| Gruppe | Komponente | Eigenes Pflichtenheft |
|---|---|---|
| A | Prozess / Dokumentenzyklus | dieses Dokument |
| B | Verwaltung von Produkten | separat |
| C | Verwaltung von Kunden | separat |
| D | Programmoberfläche | separat |
Die Komponente A nutzt Kunden (Gruppe C) und Produkte (Gruppe B) lesend über definierte interne Schnittstellen (Kapitel 6.2) und wird über die Programmoberfläche (Gruppe D) bedient. Stammdatenpflege (Anlegen/Ändern/Löschen von Kunden und Produkten) ist nicht Gegenstand dieses Dokuments.
1.4 Definitionen und Abkürzungen
Fachbegriffe (Angebot, Auftragsbestätigung, Lieferschein, Rechnung, Dokumentenzyklus, 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
- § 14 UStG — Pflichtangaben einer Rechnung
- GoBD — Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern
- DSGVO — EU-Verordnung 2016/679
- Vorlesungsunterlagen Software Engineering 1 (SoSe 2026), Foliensatz „Lasten- und Pflichtenheft"
2. Systemüberblick
2.1 Kurzbeschreibung
Die Anwendung ist eine Einzelplatz-Stand-Alone-Desktop-Anwendung mit lokaler Datenhaltung (keine Cloud, kein Server). Die Bedienung erfolgt über eine minimale grafische Benutzeroberfläche (Gruppe D), über die die Funktionalität des Dokumentenzyklus zugänglich gemacht wird. Erzeugte Belege werden lokal als PDF exportiert und können optional gedruckt oder per Standard-E-Mail-Client versendet werden.
Die Komponente Prozess / Dokumentenzyklus stellt die fachliche Kernlogik bereit: Belegerzeugung, automatische Summen- und Steuerberechnung, Vergabe eindeutiger Belegnummern, Verknüpfung aufeinanderfolgender Belege, Statusführung und Stornierung.
2.2 Abgrenzung (Was gehört dazu / was nicht)
Im Umfang dieser Komponente:
- Erstellen von Angebot, Auftragsbestätigung, Lieferschein, Rechnung
- Übernahme von Daten aus Vorgängerbelegen (Dokumentenzyklus-Konsistenz)
- Automatische Berechnung von Netto-, Steuer- und Bruttobeträgen (Snapshot-Prinzip)
- Vergabe fortlaufender, lückenloser Belegnummern
- Geführte (schrittweise) Rechnungserstellung
- Statusführung und Stornierung von Rechnungen
- PDF-Export der Belege
Nicht im Umfang dieser Komponente:
- Anlegen/Ändern/Löschen von Kunden (Gruppe C) und Produkten (Gruppe B)
- Aufbau und Layout der GUI (Gruppe D)
- E-Rechnungsformate (ZUGFeRD/XRechnung), Mahnwesen, Buchhaltung (LH-Nichtziele)
2.3 Grobe Systemfunktionen
Erstellen von Belegen → Berechnen der Summen → Vergeben der Belegnummer → Persistieren → PDF-Export → Statuswechsel (inkl. Storno).
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), die den Dokumentenzyklus eigenverantwortlich durchführt.
Angrenzende Systeme/Komponenten: lokales Dateisystem (Persistenz, PDF), optional Drucker und Standard-E-Mail-Client sowie intern die Komponenten Kundenverwaltung (C) und Produktverwaltung (B).
4. Funktionale Anforderungen
Die Anforderungen sind nach Belegtyp gruppiert und mit den Satzschablonen des Foliensatzes formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei und verifizierbar.
Belegnummern (übergreifend, GR-01): Belegnummern sind eindeutig und werden vom System generiert (nicht durch den Anwender eingegeben). Sie werden als
Stringgeführt, nicht alsint, weil die Nummern ein festes Format mit führenden Nullen und Präfix besitzen (z. B.R-2026-000124); ein ganzzahliger Typ würde führende Nullen verlieren. Pro Belegtyp wird ein eigener, fortlaufender und lückenloser Zähler auf Basis der höchsten bisher vergebenen Nummer geführt. Präfixe:AN-(Angebot),AB-(Auftragsbestätigung),LS-(Lieferschein),R-(Rechnung).
4.1 Angebot (aus BA-09)
F-01: Das System MUSS es der Anwender:in ERMÖGLICHEN, ein Angebot für einen existierenden Kunden mit mindestens einer Position aus dem Produktkatalog zu erstellen.
F-02: WENN ein Angebot gespeichert wird, DANN MUSS das System eine eindeutige
Angebotsnummer (Präfix AN-), das Erstelldatum und ein Gültigkeitsdatum setzen.
F-03: Das System MUSS für jedes Angebot die Netto-, Steuer- und Bruttosumme automatisch aus den Positionen berechnen (siehe F-23).
F-04: Das System MUSS es ERMÖGLICHEN, ein gespeichertes Angebot als PDF in das lokale Dateisystem zu exportieren.
4.2 Auftragsbestätigung (aus BA-10)
F-05: Das System MUSS es ERMÖGLICHEN, eine Auftragsbestätigung zu erstellen, wobei Kunde, Positionen und Mengen aus einem vorhandenen Angebot übernommen werden können (siehe F-22).
F-06: WENN eine Auftragsbestätigung gespeichert wird, DANN MUSS das System eine
eindeutige AB-Nummer (Präfix AB-) vergeben und — sofern aus einem Angebot erzeugt — eine
Rückreferenz auf das Angebot speichern.
F-07: Das System MUSS es ERMÖGLICHEN, eine Auftragsbestätigung als PDF zu exportieren.
4.3 Lieferschein (aus BA-11)
F-08: Das System MUSS es ERMÖGLICHEN, einen Lieferschein mit Lieferdatum, Positionen und Liefermengen zu erstellen; Kunde und Positionen können aus einer Auftragsbestätigung übernommen werden (siehe F-22).
F-09: WENN ein Lieferschein gespeichert wird, DANN MUSS das System eine eindeutige
Lieferscheinnummer (Präfix LS-) vergeben und — sofern aus einer Auftragsbestätigung
erzeugt — eine Rückreferenz speichern.
F-10: Das System MUSS es ERMÖGLICHEN, einen Lieferschein als PDF zu exportieren.
4.4 Rechnung (aus BA-12)
F-11: Das System MUSS es ERMÖGLICHEN, eine Rechnung für einen Kunden mit mindestens einer Position zu erstellen.
F-12: WENN eine Rechnung gespeichert wird, DANN MUSS das System eine fortlaufende,
lückenlose Rechnungsnummer (Präfix R-) auf Basis der höchsten bisher vergebenen Nummer
vergeben (GR-01).
F-13: Das System MUSS in jeder Rechnung die Pflichtangaben gemäß § 14 UStG führen: Rechnungsnummer, Rechnungsdatum, Leistungsdatum, Kundendaten, Positionen mit Einzel- und Gesamtbeträgen, Steuersatz und Steuerbetrag sowie Netto-, Steuer- und Bruttosumme.
F-14: WENN bei der Rechnungserstellung kein abweichendes Zahlungsziel angegeben ist, DANN MUSS das System ein Standard-Zahlungsziel von 14 Kalendertagen ab Rechnungsdatum setzen (GR-06).
F-15: Das System MUSS es ERMÖGLICHEN, eine Rechnung als PDF zu exportieren.
4.5 Geführte Rechnungserstellung (aus BA-13)
F-16: Das System MUSS es ERMÖGLICHEN, die Rechnungserstellung schrittweise durchzuführen: (1) Kunde auswählen, (2) mindestens eine Produktposition mit Menge erfassen, (3) Rechnungsdatum und Zahlungsziel bestätigen, (4) Zusammenfassung prüfen, (5) speichern.
F-17: WENN die Schritteingabe abgeschlossen ist, DANN MUSS das System vor dem Speichern eine Zusammenfassung mit Kunde, allen Positionen, Mengen, Netto-/Steuer-/Bruttosumme, Rechnungsdatum und Zahlungsziel anzeigen.
F-18: WENN ein Pflichtfeld fehlt (kein Kunde, keine Position, kein Rechnungsdatum), DANN MUSS das System das Speichern ablehnen und das fehlende Pflichtfeld benennen (Q-09).
4.6 Rechnung stornieren (aus BA-14)
F-19: Das System MUSS es ERMÖGLICHEN, eine gespeicherte Rechnung im Status OFFEN zu
stornieren.
F-20: WENN eine Rechnung storniert wird, DANN MUSS das System ihren Status auf
STORNIERT setzen, sie nicht mehr in der Liste offener Rechnungen führen und den Vorgang
mit Datum protokollieren.
F-21: WENN eine Rechnung den Status STORNIERT hat, DANN MUSS das System jede weitere
inhaltliche Änderung ablehnen.
Abgrenzung Stornierung vs. Stornorechnung: Die In-place-Stornierung (F-19/F-20) ist ausschließlich für Rechnungen im Status
OFFENzulässig. Eine bereitsVERSENDETe Rechnung wird nicht in-place storniert, sondern gemäß F-24 über eine neue Storno-/Korrekturrechnung korrigiert.
4.7 Übergreifende Prozessregeln
F-22 (Dokumentenzyklus-Konsistenz, GR-05): WENN ein Beleg aus einem Vorgängerbeleg erzeugt wird, DANN MUSS das System Kunde, Positionen und Mengen übernehmen und eine eindeutige Rückreferenz auf den Vorgänger speichern.
F-23 (Steuer-/Summenberechnung, GR-03): WENN eine Position gespeichert wird, DANN MUSS das System Netto-, Steuer- und Bruttobetrag automatisch berechnen, wobei der zum Zeitpunkt der Belegerstellung gültige Steuersatz und Einzelpreis des Produkts als unveränderlicher Snapshot in der Position abgelegt werden.
F-24 (Unveränderlichkeit, GR-02 / Q-07): WENN ein Beleg den Status VERSENDET hat,
DANN MUSS das System jede inhaltliche Änderung ablehnen; Korrekturen erfolgen ausschließlich
über neue Belege (Storno-/Korrekturrechnung).
5. Nicht-funktionale Anforderungen
NF-PERF-01 (aus Q-03): Das System MUSS die Erstellung und den PDF-Export eines beliebigen Belegtyps INNERHALB VON 2 SEKUNDEN abschließen, bei Belegen mit bis zu 50 Positionen und einem Datenbestand gemäß Q-01 (bis 5.000 Kunden/Produkte).
NF-INT-01 (aus Q-07 / GR-02): Das System MUSS nach dem Status VERSENDET einer Rechnung
jede inhaltliche Änderung ablehnen; zulässig bleiben ausschließlich Storno- bzw.
Korrekturvorgänge über neue Belege.
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 Belegformularen so markieren und benennen, dass mindestens 80 % der Testpersonen die fehlende Eingabe ohne externe Hilfe im ersten Korrekturversuch ergänzen können.
NF-SEC-01 (aus Q-06): Das System MUSS alle Beleg- und personenbezogenen Daten ausschließlich lokal im Dateisystem speichern, sodass keine Übertragung an externe Dienste erfolgt (Nachweis durch Netzwerk-Monitoring während eines repräsentativen Nutzungslaufs).
6. Daten und Schnittstellen
Dieses Kapitel ist direkter Input für den Modultestplan (eigenständiges Dokument Modultestplan.md). Datentypen werden bereits als Java-Typen angegeben.
6.1 Datenobjekte und Datentypen
Designgrundsätze:
- Geldbeträge werden als
java.math.BigDecimalmit Scale 2 und kaufmännischer Rundung (RoundingMode.HALF_UP) geführt — nicht alsdouble(Gleitkomma-Rundungsfehler wären für Beträge unzulässig). - Belegnummern werden als
Stringgeführt (festes Format mit Präfix und führenden Nullen, z. B."R-2026-000124") — nicht alsint. - Datumswerte werden als
java.time.LocalDategeführt. - Mengen werden als
int(Stückzahl) geführt. - Steuersätze werden als Faktor im Typ
BigDecimalgeführt (z. B.0.19).
enum DokumentStatus
{ ENTWURF, OFFEN, VERSENDET, STORNIERT }
Bedeutung und Übergänge: ENTWURF = Beleg in Erstellung (Initialstatus); OFFEN =
gespeichert und gültig; VERSENDET = an den Kunden übergeben (ab dann unveränderlich, F-24);
STORNIERT = storniert. Zulässige Übergänge: ENTWURF → OFFEN (beim Speichern),
OFFEN → VERSENDET (Markierung „versendet"), OFFEN → STORNIERT (Stornierung, F-19).
Klasse Dokumentposition
| Attribut | Java-Typ | Beschreibung |
|---|---|---|
| produktReferenz | String |
Produktnummer des referenzierten Produkts (Gruppe B) |
| bezeichnung | String |
Snapshot der Produktbezeichnung zum Erstellzeitpunkt |
| menge | int |
Stückzahl (> 0) |
| einzelpreisNetto | BigDecimal |
Snapshot Netto-Einzelpreis (Scale 2) |
| steuersatz | BigDecimal |
Snapshot Steuersatz, z. B. 0.19 |
| positionssummeNetto | BigDecimal |
einzelpreisNetto * menge (Scale 2) |
Abstrakte Klasse Dokument
| Attribut | Java-Typ | Beschreibung |
|---|---|---|
| belegnummer | String |
eindeutig, vom System generiert |
| datum | LocalDate |
Erstelldatum |
| kundenReferenz | String |
Kundennummer (Gruppe C) |
| positionen | List<Dokumentposition> |
mind. 1 Position |
| status | DokumentStatus |
Lebenszyklus-Status |
| vorgaengerNr | String (optional, null) |
Rückreferenz auf Vorgängerbeleg (GR-05) |
| summeNetto | BigDecimal |
Summe aller Positionssummen (Scale 2) |
| summeSteuer | BigDecimal |
Summe der Steuerbeträge (Scale 2) |
| summeBrutto | BigDecimal |
summeNetto + summeSteuer (Scale 2) |
Spezialisierungen (erben von Dokument)
| Klasse | Zusätzliche Attribute (Java-Typ) |
|---|---|
Angebot |
gueltigBis: LocalDate |
Auftragsbestaetigung |
— (nutzt vorgaengerNr → Angebot) |
Lieferschein |
lieferdatum: LocalDate |
Rechnung |
leistungsdatum: LocalDate, zahlungsziel: LocalDate, storniertAm: LocalDate (optional), storniertVon: String (optional) |
6.2 Schnittstellen
Externe Schnittstellen:
| ID | Schnittstelle | Zweck |
|---|---|---|
| IF-01 | Lokales Dateisystem | Persistenz der Belege, Ablage exportierter PDF-Dokumente |
| IF-02 | Druckersystem (optional) | Direkter Druck eines Belegs |
| IF-03 | Standard-E-Mail-Client (optional) | Versand eines Belegs als PDF-Anhang |
| IF-04 | Datenexport (CSV) | Export der Belegdaten als CSV in offenem Format (Q-08) |
Anforderungen an die externen Schnittstellen
IF-01: Das System MUSS eine Schnittstelle zum lokalen Dateisystem bereitstellen, die es ERMÖGLICHT, Belege dauerhaft zu speichern und exportierte PDF-Dokumente abzulegen.
IF-02: Das System SOLLTE eine Schnittstelle zum Druckersystem bereitstellen, die es der Anwender:in ERMÖGLICHT, einen Beleg direkt zu drucken (optional).
IF-03: Das System SOLLTE eine Schnittstelle zum Standard-E-Mail-Client bereitstellen, die es der Anwender:in ERMÖGLICHT, einen Beleg als PDF-Anhang zu versenden (optional).
IF-04: Das System MUSS eine Export-Schnittstelle bereitstellen, die es der Anwender:in ERMÖGLICHT, die Belegdaten in einem offenen Format (CSV) in das lokale Dateisystem zu exportieren (Q-08).
Interne Schnittstellen: Die Schnittstellen werden hier fachlich beschrieben (Zweck, ausgetauschte Daten, Richtung); konkrete Methodensignaturen und Datentypen sind dem Komponentenentwurf bzw. dem Modultestplan (eigenständiges Dokument Modultestplan.md) vorbehalten.
Genutzte Schnittstellen (Komponente A ruft auf):
| Schnittstelle | Partner | Richtung | Fachlicher Zweck |
|---|---|---|---|
| Kundenzugriff (lesend) | Gruppe C | C → A | Kunde per Kundennummer abrufen; Kundensuche (Name/Nr.) |
| Produktzugriff (lesend) | Gruppe B | B → A | Produkt per Produktnummer abrufen; Produktsuche |
Liefert die Stammdatenabfrage keinen Treffer, wird dies dem Aufrufer eindeutig signalisiert (kein Treffer).
Bereitgestellte Schnittstellen (Komponente A wird aufgerufen):
| Schnittstelle | Partner | Richtung | Fachlicher Zweck |
|---|---|---|---|
| Referenzprüfung Kunden | Gruppe C | A → C | Anzahl der Belege, die einen Kunden referenzieren (Löschsperre GR-04 / C-F-10) |
| Referenzprüfung Produkte | Gruppe B | A → B | Ob ein Produkt in Belegen referenziert ist (Löschsperre B-F-10) |
Komponenteninterne Dienste (rein A-intern, fachlich beschrieben):
- Belegnummernvergabe (GR-01): liefert je Belegtyp und Jahr die nächste fortlaufende,
lückenlose Belegnummer im festen Format mit Präfix und führenden Nullen (z. B.
R-2026-000124). - Belegpersistenz (IF-01): speichert Belege im lokalen Dateisystem, liefert einen Beleg zur Belegnummer und alle Belege; Belege werden nie gelöscht (GoBD).
- PDF-Export (IF-01): exportiert einen Beleg als PDF in das lokale Dateisystem.
- Ereignisbenachrichtigung (Observer, Paket
gemeinsam): meldet Datenänderungen am Belegbestand an abonnierte Modulansichten (Gruppe D).
7. Systemarchitektur (logisch, grob)
Die Komponente folgt einer einfachen Schichtung: die GUI (Gruppe D) ruft den
DokumentService (realisiert durch StandardDokumentService) auf, der die Fachlogik
kapselt und die Dienste BelegnummernGenerator, KundenService, ProduktService und
PdfExporter nutzt. Belege werden über ein DokumentRepository im lokalen Dateisystem
persistiert (realisiert als JSON-Ablage). Nach jeder schreibenden Operation meldet der
DokumentService die Datenänderung über einen EreignisBus (Observer-Muster, Paket
gemeinsam; melde(DatenBereich.DOKUMENTE)); die Modulansichten der Gruppe D abonnieren
diesen Bus und aktualisieren sich automatisch.
7.1 Klassendiagramm
Beschreibung zu Abbildung 1: Das Klassendiagramm zeigt die abstrakte Oberklasse
Dokument mit den Spezialisierungen Angebot, Auftragsbestaetigung, Lieferschein und
Rechnung (Vererbung). Ein Dokument besteht aus einer bis vielen Dokumentposition-
Objekten (Komposition zwischen Dokument und Dokumentposition, Multiplizität 1..*). Jede
Dokumentposition referenziert ein Produkt (Gruppe B), ein Dokument referenziert einen
Kunde (Gruppe C) — jeweils über die Stammdatennummer (lose Kopplung). Der DokumentService
orchestriert die Erstellung und nutzt den BelegnummernGenerator (Vergabe lückenloser
Belegnummern), die Schnittstellen KundenService/ProduktService (Stammdaten), das
DokumentRepository (Persistenz der Belege im lokalen Dateisystem), den
PdfExporter (PDF-Export) sowie den EreignisBus (Benachrichtigung der Modulansichten
nach Datenänderungen, Observer-Muster). Der Status eines Belegs wird über das Enum
DokumentStatus abgebildet.
7.2 Sequenzdiagramm
Beschreibung zu Abbildung 2: Das Sequenzdiagramm stellt den Ablauf Rechnung erstellen
dar. Die Anwender:in löst über die GUI (Gruppe D)
erstelleRechnung(kundenNr, positionen, rechnungsdatum, zahlungsziel) am
DokumentService aus (ist zahlungsziel = null, greift das Standard-Zahlungsziel). Dieser
ermittelt über KundenService.findeKunde(...) und ProduktService.findeProdukt(...) die
Stammdaten und legt sie als Snapshot je Position ab (Einzelpreis und Steuersatz, F-23),
fordert vom BelegnummernGenerator mit naechsteNummer(RECHNUNG, jahr) eine lückenlose
Rechnungsnummer an (GR-01), setzt das Standard-Zahlungsziel (+14 Tage, GR-06) und berechnet
beim Setzen der Positionen die Netto-, Steuer- und Bruttosumme des Belegs (F-23). Anschließend
persistiert er den Beleg über das DokumentRepository
und meldet die Änderung über EreignisBus.melde(DOKUMENTE) an die abonnierten Modulansichten.
Abschließend wird die gespeicherte Rechnung an die GUI zurückgegeben. Der PDF-Export ist ein
separater Vorgang (im Diagramm unten dargestellt): über exportierePdf(...) lädt der
DokumentService den Beleg erneut aus dem DokumentRepository und exportiert ihn mittels
PdfExporter.exportiere(...) in das lokale Dateisystem (F-15, IF-01).
8. Testbare Abnahmekriterien
AC-A-01 (zu F-01–F-04, NF-PERF-01) — Angebot erstellen und exportieren
Vorbedingung: Ein Kunde und 5 Produkte sind erfasst.
Aktion: Anwender:in erstellt ein Angebot mit 5 Positionen und exportiert es als PDF.
Erwartet: Das Angebot ist mit Angebotsnummer (AN-…) und korrekten Summen gespeichert; der
PDF-Export ist in ≤ 2 Sekunden abgeschlossen.
AC-A-02 (zu F-05–F-07, F-22) — Auftragsbestätigung aus Angebot
Vorbedingung: Ein Angebot liegt vor.
Aktion: Anwender:in erstellt eine Auftragsbestätigung mit Übernahme aller Positionen.
Erwartet: Die AB ist mit eindeutiger Nummer (AB-…), übernommenen Positionen/Mengen und
Rückreferenz auf das Angebot gespeichert und als PDF exportierbar.
AC-A-03 (zu F-08–F-10, F-22) — Lieferschein erstellen
Vorbedingung: Eine Auftragsbestätigung liegt vor.
Aktion: Anwender:in erstellt einen Lieferschein mit Lieferdatum.
Erwartet: Der Lieferschein ist mit eindeutiger Nummer (LS-…), Lieferdatum und allen
Positionsdaten gespeichert und als PDF exportierbar.
AC-A-04 (zu F-11–F-15, F-23) — Rechnung mit Pflichtangaben und Standard-Zahlungsziel
Vorbedingung: Kunde und mind. eine Position liegen vor; letzte Rechnungsnummer = R-2026-000123.
Aktion: Anwender:in erstellt eine Rechnung mit Rechnungsdatum 09.06.2026 ohne abweichendes
Zahlungsziel.
Erwartet: Die Rechnung trägt die Nummer R-2026-000124, ein Zahlungsziel 23.06.2026
(+14 Tage), alle Pflichtangaben gem. § 14 UStG sowie korrekte Netto-/Steuer-/Bruttosummen.
AC-A-05 (zu F-16–F-18, NF-USE-01/02) — Geführte Rechnungserstellung Vorbedingung: Mind. ein Kunde und ein Produkt vorhanden. Aktion: Anwender:in durchläuft die geführte Erstellung (Kunde → Position+Menge → Datum/ Zahlungsziel → Zusammenfassung → speichern). Erwartet: Vor dem Speichern erscheint eine Zusammenfassung mit Kunde, Position, Menge, Summen, Rechnungsdatum und Zahlungsziel; fehlt ein Pflichtfeld, wird das Speichern abgelehnt und das fehlende Feld benannt.
AC-A-06 (zu F-19–F-21) — Rechnung stornieren
Vorbedingung: Eine Rechnung im Status OFFEN existiert.
Aktion: Anwender:in storniert die Rechnung.
Erwartet: Status wird STORNIERT, die Rechnung erscheint nicht mehr in der Liste offener
Rechnungen, der Vorgang ist mit Datum protokolliert; weitere Änderungen werden abgelehnt.
AC-A-07 (zu F-23, F-24, NF-INT-01) — Snapshot und Unveränderlichkeit
Vorbedingung: Eine Rechnung mit einem Produkt ist erstellt; danach wird der Produktpreis
geändert; eine zweite Rechnung im Status VERSENDET existiert.
Aktion: Vergleich der ersten Rechnung mit dem geänderten Produktpreis; Änderungsversuch an
der versendeten Rechnung.
Erwartet: Die erste Rechnung behält den ursprünglichen Preis (Snapshot); der Änderungsversuch
an der versendeten Rechnung wird abgelehnt.
9. Traceability LH ↔ PH
Jede für Gruppe A relevante Lastenheft-Anforderung ist mindestens einer Pflichtenheft-Anforderung zugeordnet.
| LH-Anforderung | Beschreibung (LH) | PH-Anforderung(en) |
|---|---|---|
| BA-09 | Angebot erstellen | F-01, F-02, F-03, F-04 |
| BA-10 | Auftragsbestätigung erstellen | F-05, F-06, F-07, F-22 |
| BA-11 | Lieferschein erstellen | F-08, F-09, F-10, F-22 |
| BA-12 | Rechnung erstellen | F-11, F-12, F-13, F-14, F-15 |
| BA-13 | Geführte Rechnungserstellung | F-16, F-17, F-18 |
| BA-14 | Rechnung stornieren | F-19, F-20, F-21 |
| GR-01 | Lückenlose Rechnungsnummern | F-12 (Belegnummern-Regel) |
| GR-02 | Unveränderlichkeit versendeter Dokumente | F-24, F-21, NF-INT-01 |
| GR-03 | Steuerberechnung (Snapshot) | F-23, F-03, F-13 |
| GR-05 | Dokumentenzyklus-Konsistenz | F-22, F-06, F-09 |
| GR-06 | Standard-Zahlungsziel 14 Tage | F-14 |
| Q-01 | Datenbestand-Referenzgröße (Lastannahme) | NF-PERF-01 (Bedingung) |
| Q-03 | Performance PDF-Erstellung ≤ 2 s | NF-PERF-01 |
| Q-05 | Usability Ersterstellung Rechnung | NF-USE-01 |
| Q-06 | Datensicherheit: 100 % lokale Datenhaltung | NF-SEC-01, IF-01 |
| Q-07 | Unveränderlichkeit versendeter Rechnungen | NF-INT-01, F-24 |
| Q-08 | Datenexport (offenes Format, CSV) | IF-04 |
| Q-09 | Pflichtfeldhinweise ≥ 80 % | NF-USE-02, F-18 |
Hinweis: GR-04 (Löschsperre für verknüpfte Kunden) liegt in der Verantwortung von Gruppe C; Komponente A nutzt Kundendaten nur lesend (IF/
KundenService) und ist von dieser Regel betroffen, spezifiziert sie aber nicht.
Hinweis: Q-02 (Such-/Auflistungs-Performance) betrifft die Module Kunden-/Produktverwaltung (Gruppen C/B); Q-04 (Anwendungsstart) ist eine querschnittliche Start-/Integrationsanforderung. Beide werden von Komponente A nicht spezifiziert; der Gesamtnachweis erfolgt im team-weiten Anforderungsabgleich.
10. Anhänge
10.1 Abkürzungen
| Abkürzung | Bedeutung |
|---|---|
| F | Funktionale Anforderung (Pflichtenheft) |
| NF | Nicht-funktionale Anforderung (Pflichtenheft) |
| IF | Schnittstelle (Interface) |
| AC | Abnahmekriterium |
| BA | Benutzeranforderung (Lastenheft) |
| GR | Geschäftsregel (Lastenheft) |
| Q | Qualitätsanforderung (Lastenheft) |
| SRS | System Requirements Specification (Pflichtenheft) |
10.2 Glossar
Es gilt das Glossar des Lastenhefts (§ 8.1) unverändert.
10.3 Referenzen
Siehe Kapitel 1.5.