diff --git a/Pflichtenheft_GruppeA.md b/Pflichtenheft_GruppeA.md index 3c149a3..f097431 100644 --- a/Pflichtenheft_GruppeA.md +++ b/Pflichtenheft_GruppeA.md @@ -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 -![Abbildung 1: UML-Klassendiagramm Dokumentenzyklus (Gruppe A)](diagramme/klassendiagramm_dokumentenzyklus.png) - **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. +![Abbildung 1: UML-Klassendiagramm Dokumentenzyklus (Gruppe A)](diagramme/klassendiagramm_dokumentenzyklus.png) + ### 7.2 Sequenzdiagramm -![Abbildung 2: UML-Sequenzdiagramm „Rechnung erstellen" (Gruppe A)](diagramme/sequenz_rechnung_erstellen.png) - **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). ---- +![Abbildung 2: UML-Sequenzdiagramm „Rechnung erstellen" (Gruppe A)](diagramme/sequenz_rechnung_erstellen.png) ## 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 diff --git a/Pflichtenheft_GruppeA.pdf b/Pflichtenheft_GruppeA.pdf index 4ebd020..f5a92e4 100644 Binary files a/Pflichtenheft_GruppeA.pdf and b/Pflichtenheft_GruppeA.pdf differ