Gruppe A: Version des Pflichtenhefts zur Abgabe
parent
c89e9a5c6f
commit
6aaa409f49
|
|
@ -34,11 +34,10 @@ header-includes: |
|
|||
| Autor | Prüfer | Freigebender |
|
||||
+=========================+=========================+=========================+
|
||||
| Strubel, Lucas | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd |
|
||||
| Kaiser, Luca | | |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| Gruppe A (Prozess) | Modulverantwortlicher | Modulverantwortlicher |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| 09.06.2026 | 09.06.2026 | 09.06.2026 |
|
||||
| 13.06.2026 | 13.06.2026 | 13.06.2026 |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
|
||||
**Freigabevermerk:** Dieses Dokument ist nach Prüfung und Freigabe durch den
|
||||
|
|
@ -49,8 +48,8 @@ und den Modultest der Komponente *Prozess / Dokumentenzyklus*.
|
|||
|
||||
| Version | Datum | Autor | Grund der Änderung |
|
||||
|---------|------------|-----------------------------|---------------------|
|
||||
| 1.0 | 09.06.2026 | Lucas Strubel, Luca Kaiser | Initiale Erstellung |
|
||||
| 1.1 | 13.06.2026 | Lucas Strubel, Luca Kaiser | Einfügen der UML-Diagramme (Klassen- und Sequenzdiagramm) |
|
||||
| 1.0 | 09.06.2026 | Lucas Strubel | Initiale Erstellung |
|
||||
| 1.1 | 13.06.2026 | Lucas Strubel | Einfügen der UML-Diagramme (Klassen- und Sequenzdiagramm) |
|
||||
|
||||
\newpage
|
||||
|
||||
|
|
@ -100,8 +99,6 @@ Dokumentspezifische Abkürzungen siehe Kapitel 11.
|
|||
- DSGVO — EU-Verordnung 2016/679
|
||||
- Vorlesungsunterlagen Software Engineering 1 (SoSe 2026), Foliensatz „Lasten- und Pflichtenheft"
|
||||
|
||||
---
|
||||
|
||||
## 2. Systemüberblick
|
||||
|
||||
### 2.1 Kurzbeschreibung
|
||||
|
|
@ -136,15 +133,6 @@ Belegnummern, Verknüpfung aufeinanderfolgender Belege, Statusführung und Storn
|
|||
Erstellen von Belegen → Berechnen der Summen → Vergeben der Belegnummer → Persistieren →
|
||||
PDF-Export → Statuswechsel (inkl. Storno).
|
||||
|
||||
### 2.4 UML-Bezug
|
||||
Ein gemeinsames Use-Case-Diagramm aller Gruppen gibt den Überblick über die Akteure und
|
||||
Ziele. Die für Gruppe A relevanten Use Cases sind: *Angebot erstellen*,
|
||||
*Auftragsbestätigung erstellen*, *Lieferschein erstellen*, *Rechnung erstellen (geführt)*
|
||||
und *Rechnung stornieren*. Die detaillierte logische Architektur dieser Komponente folgt
|
||||
in Kapitel 7.
|
||||
|
||||
---
|
||||
|
||||
## 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:
|
||||
|
|
@ -156,8 +144,6 @@ Angrenzende Systeme/Komponenten: lokales Dateisystem (Persistenz, PDF), optional
|
|||
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
|
||||
|
|
@ -240,7 +226,7 @@ eine **Zusammenfassung** mit Kunde, allen Positionen, Mengen, Netto-/Steuer-/Bru
|
|||
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 (GR/Q-09).
|
||||
DANN MUSS das System das Speichern ablehnen und das fehlende Pflichtfeld benennen (Q-09).
|
||||
|
||||
### 4.6 Rechnung stornieren (aus BA-14)
|
||||
|
||||
|
|
@ -254,6 +240,11 @@ 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
|
||||
|
|
@ -269,8 +260,6 @@ der Belegerstellung gültige Steuersatz und Einzelpreis des Produkts als unverä
|
|||
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
|
||||
|
|
@ -290,7 +279,9 @@ mind. 5 Testpersonen).
|
|||
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
|
||||
|
||||
|
|
@ -308,11 +299,16 @@ bereits als Java-Typen angegeben.
|
|||
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 `BigDecimal` als Faktor geführt (z. B. `0.19`).
|
||||
- **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 |
|
||||
|-------------------|---------------|--------------|
|
||||
|
|
@ -342,7 +338,7 @@ bereits als Java-Typen angegeben.
|
|||
| `Angebot` | `gueltigBis: LocalDate` |
|
||||
| `Auftragsbestaetigung` | — (nutzt `vorgaengerNr` → Angebot) |
|
||||
| `Lieferschein` | `lieferdatum: LocalDate` |
|
||||
| `Rechnung` | `leistungsdatum: LocalDate`, `zahlungsziel: LocalDate`, `storniertAm: LocalDate` (optional) |
|
||||
| `Rechnung` | `leistungsdatum: LocalDate`, `zahlungsziel: LocalDate`, `storniertAm: LocalDate` (optional), `storniertVon: String` (optional) |
|
||||
|
||||
### 6.2 Schnittstellen
|
||||
|
||||
|
|
@ -353,41 +349,53 @@ bereits als Java-Typen angegeben.
|
|||
| 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) |
|
||||
|
||||
**Interne Schnittstellen (zu anderen Komponenten), als Java-Interfaces skizziert:**
|
||||
**Anforderungen an die externen Schnittstellen**
|
||||
|
||||
```java
|
||||
// Lesender Zugriff auf Kundenstammdaten (Gruppe C)
|
||||
public interface KundenService {
|
||||
Kunde findeKunde(String kundennummer); // null, wenn nicht vorhanden
|
||||
}
|
||||
**IF-01:** Das System MUSS eine Schnittstelle zum lokalen Dateisystem bereitstellen, die es
|
||||
ERMÖGLICHT, Belege dauerhaft zu speichern und exportierte PDF-Dokumente abzulegen.
|
||||
|
||||
// Lesender Zugriff auf Produktstammdaten (Gruppe B)
|
||||
public interface ProduktService {
|
||||
Produkt findeProdukt(String produktnummer);
|
||||
}
|
||||
**IF-02:** Das System SOLLTE eine Schnittstelle zum Druckersystem bereitstellen, die es der
|
||||
Anwender:in ERMÖGLICHT, einen Beleg direkt zu drucken (optional).
|
||||
|
||||
// PDF-Export eines Belegs (IF-01)
|
||||
public interface PdfExporter {
|
||||
void exportiere(Dokument dokument, Path zielDatei);
|
||||
}
|
||||
```
|
||||
**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).
|
||||
|
||||
**Belegnummern-Schnittstelle (komponenteninterner Dienst):**
|
||||
**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).
|
||||
|
||||
```java
|
||||
public interface BelegnummernGenerator {
|
||||
// liefert die nächste lückenlose Nummer für den Belegtyp (GR-01)
|
||||
String naechsteNummer(Belegtyp typ, int jahr);
|
||||
}
|
||||
```
|
||||
**Interne Schnittstellen:** Die Schnittstellen werden hier **fachlich** beschrieben
|
||||
(Zweck, ausgetauschte Daten, Richtung); konkrete Methodensignaturen
|
||||
und Datentypen sind dem Komponentenentwurf bzw. dem Modultestplan (Kapitel 10) vorbehalten.
|
||||
|
||||
> IF-Satzschablone (Beispiel IF-01): *Das System MUSS eine Datei-Schnittstelle
|
||||
> bereitstellen, die es dem lokalen Dateisystem ERMÖGLICHT, Belege zu persistieren und PDF-
|
||||
> Dokumente abzulegen. Die Schnittstelle MUSS gängige Dateipfade (`java.nio.file.Path`)
|
||||
> verwenden.*
|
||||
*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)
|
||||
|
||||
|
|
@ -402,8 +410,6 @@ 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`-
|
||||
|
|
@ -411,29 +417,33 @@ Objekten (Komposition zwischen `Dokument` und `Dokumentposition`, Multiplizität
|
|||
`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), den
|
||||
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)`
|
||||
am `DokumentService` aus. Dieser ermittelt über `KundenService.findeKunde(...)` und
|
||||
`ProduktService.findeProdukt(...)` die Stammdaten (Snapshot), berechnet je Position und in
|
||||
Summe Netto-, Steuer- und Bruttobetrag (F-23), fordert vom `BelegnummernGenerator` mit
|
||||
`naechsteNummer(RECHNUNG, jahr)` eine lückenlose Rechnungsnummer an (GR-01), setzt das
|
||||
Standard-Zahlungsziel (+14 Tage, GR-06), persistiert den Beleg über das `DokumentRepository`
|
||||
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
|
||||
|
||||
|
|
@ -484,8 +494,6 @@ 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
|
||||
|
|
@ -504,16 +512,22 @@ Pflichtenheft-Anforderung zugeordnet.
|
|||
| 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. Modultestplan
|
||||
|
||||
|
|
@ -577,8 +591,6 @@ Damit sind 13 Testfälle (> 10) spezifiziert, die alle funktionalen Kernregeln (
|
|||
F-18, F-22, F-23, F-24) sowie die zentralen Geschäftsregeln (GR-01, GR-02, GR-03, GR-05,
|
||||
GR-06) abdecken.
|
||||
|
||||
---
|
||||
|
||||
## 11. Anhänge
|
||||
|
||||
### 11.1 Abkürzungen
|
||||
|
|
|
|||
Binary file not shown.
Loading…
Reference in New Issue