552 lines
29 KiB
Markdown
552 lines
29 KiB
Markdown
---
|
||
title: "Pflichtenheft"
|
||
subtitle: "Desktop-Fakturierungsanwendung — Gruppe A: Prozess / Dokumentenzyklus"
|
||
author:
|
||
- Team 1 – Gruppe A
|
||
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: "DejaVu Sans Mono"
|
||
header-includes: |
|
||
\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
|
||
> `String` geführt, **nicht** als `int`, 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 `OFFEN` zulässig. Eine bereits `VERSENDET`e 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.BigDecimal` mit **Scale 2** und kaufmännischer
|
||
Rundung (`RoundingMode.HALF_UP`) geführt — **nicht** als `double` (Gleitkomma-Rundungsfehler
|
||
wären für Beträge unzulässig).
|
||
- **Belegnummern** werden als `String` geführt (festes Format mit Präfix und führenden
|
||
Nullen, z. B. `"R-2026-000124"`) — **nicht** als `int`.
|
||
- **Datumswerte** werden als `java.time.LocalDate` geführt.
|
||
- **Mengen** werden als `int` (Stückzahl) geführt.
|
||
- **Steuersätze** werden als Faktor im Typ `BigDecimal` gefü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.
|