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

Kundenverwaltung: Modultests konsolidiert + Modultestbericht (Phase 6/7) 

- Phase 6: 11 Modultests in KundeModultestTest zusammengefuehrt
  (1:1 zu MT-KV-01...11, je @DisplayName), alle gruen
- Bisherige Testklassen entfernt (KundeServiceTest, KundeValidatorTest,
  KundeRepositoryJsonTest); Abdeckung vollstaendig uebernommen -> 1 KV-Testdatei
- NF-TEST-03 erfuellt: 85 % Line Coverage der Logikschicht (kunde.service)
- Phase 7: Modultestbericht Kundenverwaltung v1.0 (Ergebnisse, Coverage,
  Abdeckungsuebersicht) als Abgabe-Artefakt erstellt
- Fahrplan Kundenverwaltung auf v1.2 aktualisiert (Phasen 6+7 abgeschlossen,
  OP-4 ergaenzt, Export-Marker bereinigt)
- PDFs der aktualisierten Dokumente ergaenzt
feature/kundenverwaltung
3027248 2026-06-26 01:00:49 +02:00
parent 2048508f61
commit 7a5c32bf0e
7 changed files with 2554 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

207
Unterlagen/Fahrplan_Kundenverwaltung_GruppeH/Fahrplan_Kundenverwaltung_GruppeH_1.0.md 100644
View File

@ -0,0 +1,207 @@
# Fahrplan – Modul Kundenverwaltung (Gruppe H)
**Projekt:** Fakturierungssystem · SE1 Team 2 – Hochschule Mannheim
**Modul / Gruppe:** Kundenverwaltung (Gruppe H) · Package `de.hsmannheim.faktura.kunde`
**Verantwortlich (dieses Dokument):** Christopher Lampert [3027248]
**Gruppe H:** Oleg Akimenko [3028868] (Gruppenleiter), Christopher Lampert [3027248], Kenan Pekarovic [3027541]
**Stand:** 25.06.2026
**Bezug:** Lastenheft v1.1, Pflichtenheft v1.0, Project Charter v1.1, Modultestplan (KV-Teil)
> **Harte Deadline:** Montag, **29.06.2026, 09:00 Uhr** – Abgabe der Artefakte pro Team.
> **Präsentation:** Montag, 29.06.2026 im regulären Vorlesungsblock (20–25 Min/Team, 4 Vortragende, je Gruppe ein Vertreter).
> **Projektphase laut Charter:** M7 „Puffer & Abnahme" (27.–30.06.2026).
---
## 0. So benutzt du diesen Fahrplan
Jeder Schritt hat einen Status. Aktualisiere ihn, dann kannst du mir jederzeit sagen „ich bin bei P4-3" und ich habe sofort den Kontext.
**Statuslegende:**
`[ ]` offen · `[~]` in Arbeit · `[x]` fertig · `[!]` blockiert / offener Punkt
**Aktuelle Position:** _Phase 0 (Setup) – noch nicht begonnen_
*(Diese Zeile bei jeder Session aktualisieren.)*
---
## 1. Ziel & Abgrenzung
**Im Scope (nur Gruppe H):** Anlegen, Bearbeiten, Suchen und Löschen von Kunden samt Validierung, Persistenz und Modultests – also die fachlichen Anforderungen **F-KV-01 bis F-KV-04** (Herkunft BA-KV-01…04) sowie die mitwirkenden Regeln **GR-05** (Stammdatenschutz) und **NF-ARCH-01** (Persistenz).
**Nicht im Scope (andere Gruppen):** Produktverwaltung (G), Dokumentenprozess (F), GUI (E). Diese werden hier **nur über die Schnittstellen** berührt (siehe Abschnitt 2).
**Leitprinzip:** Alles richtet sich nach den vier Projektdokumenten. Abweichungen werden **nicht still aufgelöst**, sondern als offener Punkt in Abschnitt 8 markiert.
---
## 2. Kompatibilitätsvertrag mit den anderen Modulen
Damit die Kundenverwaltung sauber mit den Teilen der anderen Teilnehmer zusammenspielt, müssen diese vier Berührungspunkte exakt eingehalten werden. **Bevor implementiert wird, sollten diese Signaturen mit Gruppe E und F gegengeprüft sein.**
| # | Wer braucht es | Was die Kundenverwaltung liefern muss | Quelle |
|---|----------------|----------------------------------------|--------|
| K1 | **GUI (Gruppe E)** über IF-01 | `KundeService` mit `anlegen(Kunde): long`, `bearbeiten(Kunde): void`, `suchen(String): List<Kunde>`, `loeschen(long): void` | Pflichtenheft Klassendiagramm (Kap. 7.2), Komponentendiagramm (Kap. 7.1: `KundeAnsicht → KundeService`) |
| K2 | **Datenhaltung** über IF-02 | `KundeRepository`-Interface (speichern/findeById/findeAlle/loeschen), JSON-Persistenz dahinter gekapselt | IF-02, NF-ARCH-01/02 |
| K3 | **Dokumentenprozess (Gruppe F)** | Kunde ist über `kundeId` (long) referenzierbar; F nutzt `FakeCustomerLookup` und `isCustomerReferenced(...)` in seinen Tests (MT-DP-16). KV muss einen Kunden per ID auflösbar machen. | Modultestplan DP (MT-DP-01, MT-DP-16); Pflichtenheft Datenobjekte (kundeId als Referenz in allen Belegen) |
| K4 | **Löschsperre GR-05** | Vor dem Löschen prüft `KundeService`, ob der Kunde in einem Beleg referenziert ist → Abfrage gegen `BelegRepository` (Gruppe F). Bei Referenz: Löschen ablehnen. | GR-05; F-KV-04; MT-KV-11 |
**Daten-Kontrakt „Kunde" (Pflichtenheft Kap. 6.1.2) – verbindlich:**
| Attribut | Java-Typ | Pflicht | Constraint |
|----------|----------|---------|------------|
| kundeId | `long` | Pflicht | Fortlaufender, eindeutiger Primärschlüssel |
| firmenname | `String` | Pflicht\* | Pflicht, sofern kein Nachname |
| nachname | `String` | Pflicht\* | Pflicht, sofern kein Firmenname |
| vorname | `String` | Optional | – |
| strasse | `String` | Pflicht | Straße + Hausnummer |
| plz | `String` | Pflicht | String (führende Nullen erhalten) |
| ort | `String` | Pflicht | – |
| telefon | `String` | Optional | – |
| email | `String` | Optional | Formatvalidierung, falls angegeben |
| ustIdNr | `String` | Optional | USt-IdNr. |
| lieferadresse | `String` | Optional | abweichende Lieferadresse |
| ansprechpartner | `String` | Optional | – |
\* **Constraint:** `firmenname != null || nachname != null` (mindestens eines befüllt).
---
## 3. Technische Vorgaben (aus Pflichtenheft Kap. 2.3)
- **Sprache:** Java LTS ≥ 17
- **Persistenz:** lokale **JSON-Datei** (z. B. Jackson), hinter `KundeRepository` gekapselt → austauschbar (NF-ARCH-02)
- **Tests:** **JUnit 5 (Jupiter)** – GUI-unabhängige Logiktests (NF-TEST-02)
- **Architektur:** 3-Schichten (ui → service → repository); KV berührt nur `service` + `repository`
- **Versionierung:** Git / Gitty, Code-Review je Merge (NF-VER-02)
- **Relevante NF-Ziele:** NF-USE-01 (Kunde anlegen < 2 min), NF-PERF-01 (Aktion < 1 s bei 1.000 Kunden), NF-PERF-02 (Liste < 2 s), NF-SEC-01 (kein Klartext von außen), NF-SEC-02 (DSGVO-Löschen)
---
## 4. Die Phasen (Schritt für Schritt)
### Phase 0 – Setup & Abstimmung
- `[ ]` **P0-1** Git/Gitty: Branch für Gruppe H anlegen; Paketstruktur `de.hsmannheim.faktura.kunde` (Unterpakete `model`, `service`, `repository`)
- `[ ]` **P0-2** Build-Setup: Java ≥ 17, JUnit 5, JSON-Lib (Jackson) als Abhängigkeit eintragen
- `[ ]` **P0-3** Schnittstellen K1–K4 (Abschnitt 2) mit Gruppe E (GUI) und Gruppe F (Belege) gegenprüfen und bestätigen
- `[ ]` **P0-4** Offenen Punkt OP-1 (BelegRepository vs. ProduktRepository, siehe Abschnitt 8) mit Team klären
### Phase 1 – Datenmodell
- `[ ]` **P1-1** Klasse `Kunde` mit allen 12 Attributen aus dem Daten-Kontrakt (Abschnitt 2), Typen exakt wie spezifiziert (`plz` als `String`!)
- `[ ]` **P1-2** Konstruktor/Builder + Getter/Setter; `equals`/`hashCode` über `kundeId`
- `[ ]` **P1-3** JSON-Serialisierbarkeit sicherstellen (Jackson-Annotationen falls nötig)
### Phase 2 – Persistenz (IF-02 / NF-ARCH-01/02)
- `[ ]` **P2-1** Interface `KundeRepository`: `speichern(Kunde): long`, `findeById(long): Optional<Kunde>`, `findeAlle(): List<Kunde>`, `loeschen(long): void`
- `[ ]` **P2-2** JSON-Implementierung `KundeRepositoryJson`: Laden/Speichern aus lokaler Datei
- `[ ]` **P2-3** Fortlaufende ID-Vergabe (`kundeId`) – eindeutig, kein Reuse
- `[ ]` **P2-4** Persistenz-Roundtrip prüfen (speichern → neu laden → identisch) → Grundlage für MT-KV-06
### Phase 3 – Validierung
- `[ ]` **P3-1** Pflichtfeldprüfung: `strasse`, `plz`, `ort` vorhanden
- `[ ]` **P3-2** Constraint `firmenname != null || nachname != null`
- `[ ]` **P3-3** E-Mail-Formatprüfung (nur falls `email` angegeben)
- `[ ]` **P3-4** Aussagekräftige Fehlermeldung/Exception bei Verstoß (keine Speicherung)
### Phase 4 – Logik: `KundeService` (F-KV-01…04)
- `[ ]` **P4-1** `anlegen(Kunde): long` → validiert, vergibt ID, persistiert · **F-KV-01 / BA-KV-01**
- `[ ]` **P4-2** `bearbeiten(Kunde): void` → lädt, validiert, persistiert · **F-KV-02 / BA-KV-02**
- `[ ]` **P4-3** `suchen(String): List<Kunde>` → Treffer über Name (firmenname/nachname) **und** Kundennummer · **F-KV-03 / BA-KV-03**
- `[ ]` **P4-4** `loeschen(long): void` → Sicherheitsabfrage, **GR-05-Referenzprüfung** über `BelegRepository`, nur bei zulässiger Löschung entfernen · **F-KV-04 / BA-KV-04**
- `[ ]` **P4-5** NF-SEC-02: Löschen nur ohne aktive Aufbewahrungspflicht (z. B. keine aktive Rechnung)
### Phase 5 – Schnittstelle zum Dokumentenprozess (K3)
- `[ ]` **P5-1** Kunden-Auflösung per `kundeId` bereitstellen (was Gruppe F im Echtbetrieb statt `FakeCustomerLookup` nutzt)
- `[ ]` **P5-2** Mit Gruppe F abstimmen, wie `isCustomerReferenced(kundeId)` aufgerufen wird (Richtung: KV fragt BelegRepository – siehe OP-1)
### Phase 6 – Modultests (JUnit 5, MT-KV-01…11)
Jeder Test bildet exakt einen Eintrag aus dem Modultestplan ab:
- `[ ]` **P6-01** MT-KV-01 Kunde mit allen Pflichtattributen anlegen → gespeichert · BA-KV-01
- `[ ]` **P6-02** MT-KV-02 ohne Firmenname/Nachname → abgelehnt · BA-KV-01
- `[ ]` **P6-03** MT-KV-03 ohne Straße → abgelehnt · BA-KV-01
- `[ ]` **P6-04** MT-KV-04 ungültige E-Mail „kunde@" → abgelehnt · BA-KV-01
- `[ ]` **P6-05** MT-KV-05 Telefonnummer ändern → gespeichert · BA-KV-02
- `[ ]` **P6-06** MT-KV-06 Persistenz nach Neuladen → unverändert · BA-KV-02, NF-ARCH-01
- `[ ]` **P6-07** MT-KV-07 Suche über Namen „Muster" → gefunden · BA-KV-03
- `[ ]` **P6-08** MT-KV-08 Suche über Kundennummer → gefunden · BA-KV-03
- `[ ]` **P6-09** MT-KV-09 Suche ohne Treffer → leeres Ergebnis/Hinweis · BA-KV-03
- `[ ]` **P6-10** MT-KV-10 nicht referenzierten Kunden löschen → entfernt · BA-KV-04
- `[ ]` **P6-11** MT-KV-11 referenzierten Kunden löschen → abgewiesen · BA-KV-04, GR-05
- `[ ]` **P6-12** Alle 11 Tests grün; Coverage-Schwelle (NF-TEST-03: 60 %) für `kunde`-Paket erreicht
### Phase 7 – Abgabe-Artefakt: Modultestbericht
- `[ ]` **P7-1** Testlauf dokumentieren: je MT-KV-Fall **Ergebnis (bestanden/fehlgeschlagen)**, Datum, Tester
- `[ ]` **P7-2** Abdeckungsübersicht aus dem Modultestplan (BA-KV-01→MT-KV-01…04 usw.) als Nachweis übernehmen
- `[ ]` **P7-3** Mit Team klären: **max. 4 Dateien** insgesamt → KV-Bericht entweder eigene Datei **oder** in gemeinsame Test-Datei integriert (Koordination mit G/F/E)
### Phase 8 – Integration mit anderen Modulen
- `[ ]` **P8-1** GUI (E): `KundeAnsicht` ruft `KundeService` – Smoke-Test Anlegen/Suchen/Löschen aus der Oberfläche
- `[ ]` **P8-2** Belege (F): echter Kunde im Angebot referenzierbar; GR-05-Löschsperre greift im integrierten System (MT-DP-16 ↔ MT-KV-11)
- `[ ]` **P8-3** Gesamtsystem startet, KV-CRUD lauffähig (AK-02 Charter)
### Phase 9 – Präsentation (KV-Anteil)
Pflichtinhalte laut Aufgabenstellung – als KV-Vertreter (1 Person je Gruppe) vorbereiten:
- `[ ]` **P9-1** Demo-Anteil: Kunde anlegen → suchen → bearbeiten → Löschsperre zeigen (referenzierter Kunde)
- `[ ]` **P9-2** **KI-Einsatz:** wo eingesetzt, wie gut hat es funktioniert (konkrete KV-Beispiele)
- `[ ]` **P9-3** **Was nächstes Mal anders:** ehrliche Lessons learned aus der KV-Umsetzung
- `[ ]` **P9-4** **Modultestplan-Ergebnisse** der KV präsentieren (Abdeckung + Pass-Quote)
- `[ ]` **P9-5** **Traceability-Stichprobe vorbereiten:** Kette **BA-KV-0x → F-KV-0x → MT-KV-xx → AT-KV-xx** auswendig/griffbereit (Prof prüft stichprobenartig)
### Phase 10 – Abgabe & Generalprobe
- `[ ]` **P10-1** Code gemergt, Reviews abgeschlossen (NF-VER-02), Tests grün im Hauptbranch
- `[ ]` **P10-2** Testbericht + Folien im Team konsolidiert (max. 4 Test-Dateien, genau 1 Foliendatei)
- `[ ]` **P10-3** **Abgabe bis Mo 29.06. 09:00 Uhr**
- `[ ]` **P10-4** Generalprobe Vortrag + Zeitmessung (20–25 Min Team-Budget)
---
## 5. Traceability-Matrix Kundenverwaltung (für die Stichprobenprüfung)
| Anforderung (LH) | Pflichtenheft | Modultests | Akzeptanztest (LH) |
|------------------|---------------|------------|--------------------|
| BA-KV-01 Kunde anlegen | F-KV-01 | MT-KV-01 … MT-KV-04 | AT-KV-01, AT-KV-02 |
| BA-KV-02 Kunde bearbeiten | F-KV-02 | MT-KV-05, MT-KV-06 | AT-KV-03, AT-KV-04 |
| BA-KV-03 Kunde suchen | F-KV-03 | MT-KV-07 … MT-KV-09 | AT-KV-05, AT-KV-06 |
| BA-KV-04 Kunde löschen | F-KV-04 | MT-KV-10, MT-KV-11 | AT-KV-07, AT-KV-08 |
| GR-05 Stammdatenschutz | F-KV-04 (i.V.m. GR-05) | MT-KV-11 | – |
| NF-ARCH-01 Persistenz | NF-ARCH-01 | MT-KV-06 | AT-NF-… |
---
## 6. Zeitplan bis Montag (Vorschlag)
| Tag | Fokus |
|-----|-------|
| **Do 25.06** | Phase 0 + Phase 1 (Setup, Schnittstellen abstimmen, Datenmodell) |
| **Fr 26.06** | Phase 2 + Phase 3 + Phase 4 (Persistenz, Validierung, Service-Logik) |
| **Sa 27.06** | Phase 5 + Phase 6 (DP-Schnittstelle, alle 11 Modultests grün) |
| **So 28.06** | Phase 7 + Phase 8 + Phase 9 (Testbericht, Integration, Folien) |
| **Mo 29.06 vor 09:00** | Phase 10 (Konsolidierung, Abgabe, Generalprobe) |
---
## 7. Definition of Done (Kundenverwaltung)
- `[ ]` F-KV-01 bis F-KV-04 implementiert und über `KundeService` aufrufbar (K1)
- `[ ]` Persistenz über `KundeRepository`/JSON, Daten überleben Neustart (NF-ARCH-01)
- `[ ]` Validierung greift (Pflichtfelder, firmenname||nachname, E-Mail-Format)
- `[ ]` GR-05-Löschsperre funktioniert im integrierten System
- `[ ]` MT-KV-01…11 alle grün, Coverage ≥ 60 % im `kunde`-Paket
- `[ ]` Modultestbericht erstellt und ins Team-Artefakt integriert
- `[ ]` Traceability BA→F→MT→AT lückenlos und vorführbar
- `[ ]` In Gesamtsystem integriert (GUI + Belege), Code gereviewt und gemergt
---
## 8. Offene Punkte (nicht still aufgelöst)
| ID | Dokument / Stelle | Beschreibung | Vorschlag |
|----|-------------------|--------------|-----------|
| OP-1 | Pflichtenheft Klassendiagramm (Kap. 7.2) vs. GR-05 | Diagramm zeigt `KundeService ..> ProduktRepository`; GR-05-Text fordert Referenzprüfung über `BelegRepository`. Für die Löschsperre F-KV-04/MT-KV-11 ist das **BelegRepository** maßgeblich. | Im Code gegen `BelegRepository` prüfen; Diagramm-Abhängigkeit als Doku-Inkonsistenz an Team/Prüfer melden. |
| OP-2 | Abgabe-Format | „max. 4 Dateien" für Testberichte bei 4 Modulen → Aufteilung 1 Datei/Modul **oder** 1 Sammeldatei? | Team-Entscheidung vor So 28.06; KV-Bericht entsprechend zuschneiden. |
| OP-3 | Schnittstelle K3 (Lookup-Richtung) | Genaue Aufrufrichtung zwischen KV und Gruppe F für `isCustomerReferenced` final festzurren. | In P0-3 mit Gruppe F bestätigen. |
---
*Aktualisiere bei jeder Session die Zeile „Aktuelle Position" in Abschnitt 0 und die Status-Marker. Damit kann der Fortschritt jederzeit punktgenau aufgegriffen werden.*

226
Unterlagen/Fahrplan_Kundenverwaltung_GruppeH/Fahrplan_Kundenverwaltung_GruppeH_1.1.md 100644
View File

@ -0,0 +1,226 @@
# Fahrplan – Modul Kundenverwaltung (Gruppe H) Ver. 1.1
**Projekt:** Fakturierungssystem · SE1 Team 2 – Hochschule Mannheim[cite: 2]
**Modul / Gruppe:** Kundenverwaltung (Gruppe H) · Package `de.hsmannheim.faktura.kunde`[cite: 2]
**Verantwortlich (dieses Dokument):** Christopher Lampert [3027248][cite: 2]
**Gruppe H:** Oleg Akimenko [3028868] (Gruppenleiter), Christopher Lampert [3027248], Kenan Pekarovic [3027541][cite: 2]
**Stand:** 25.06.2026[cite: 2]
**Bezug:** Lastenheft v1.1, Pflichtenheft v1.0, Project Charter v1.1, Modultestplan (KV-Teil)[cite: 2]
> **Harte Deadline:** Montag, **29.06.2026, 09:00 Uhr** – Abgabe der Artefakte pro Team.[cite: 2]
> **Präsentation:** Montag, 29.06.2026 im regulären Vorlesungsblock (20–25 Min/Team, 4 Vortragende, je Gruppe ein Vertreter).[cite: 2]
> **Projektphase laut Charter:** M7 „Puffer & Abnahme" (27.–30.06.2026).[cite: 2]
---
## 0. So benutzt du diesen Fahrplan
Jeder Schritt hat einen Status.[cite: 2] Aktualisiere ihn, dann kannst du mir jederzeit sagen „ich bin bei P4-3" und ich habe sofort den Kontext.[cite: 2]
**Statuslegende:**
`[ ]` offen · `[~]` in Arbeit · `[x]` fertig · `[!]` blockiert / offener Punkt[cite: 2]
**Aktuelle Position:** *Phase 6 (Modultests konsolidieren) – Nächster Schritt*[cite: 1]
### 🚀 Aktueller Umsetzungsstand (für den neuen Chat-Kontext)
Wir haben die **Phasen 0 bis 5** der Kundenverwaltung erfolgreich umgesetzt und die Artefakte bereits über einen Merge Request auf den `main`-Branch hochgeladen.[cite: 1] Alle entwickelten Klassen sind funktionsfähig und durch JUnit-5-Tests abgedeckt.[cite: 1]
#### 📁 Erstellte Dateien & Paketstruktur (`de.hsmannheim.faktura.kunde`)
* **Wurzelverzeichnis:** `pom.xml` (Maven-Setup für Java 17, JUnit 5 und Jackson) sowie `.gitignore` erweitert (ignoriert jetzt `target/` und `.idea/`).[cite: 1]
* **`model`:** `Kunde.java` (Spezifikationskonformes POJO mit allen 12 Feldern, PLZ als `String`).[cite: 1]
* **`repository`:**
* `KundeRepository.java` (Interface für Datenhaltung).[cite: 1]
* `KundeContainer.java` (Hilfsklasse für JSON-Bündelung).[cite: 1]
* `KundeRepositoryJson.java` (Jackson-Implementierung mit fortlaufendem ID-Zähler gegen ID-Wiederverwendung).[cite: 1]
* **`service`:**
* `KundeService.java` (Zentrale Logik für CRUD-Operationen, inklusive der neuen Methode `finde(long)` für die Beleg-Schnittstelle).[cite: 1]
* `KundeValidator.java` (Prüfung von Pflichtfeldern, E-Mail-Format und der Bedingung `firmenname || nachname`).[cite: 1]
* `BelegReferenzPruefer.java` (Funktionales Interface zur Entkopplung der GR-05-Löschsperre von Gruppe F).[cite: 1]
* `ValidierungsException.java` & `LoeschsperreException.java` (Unchecked Exceptions für Fehlermeldungen).[cite: 1]
* **`src/test/java`:**
* `KundeRepositoryJsonTest.java` (Persistenz-Roundtrip-Test).[cite: 1]
* `KundeValidatorTest.java` (Validierungs-Tests).[cite: 1]
* `KundeServiceTest.java` (8 grüne Logik-Tests inklusive simulierter Löschsperre).[cite: 1]
---
## 1. Ziel & Abgrenzung
**Im Scope (nur Gruppe H):** Anlegen, Bearbeiten, Suchen und Löschen von Kunden samt Validierung, Persistenz und Modultests – also die fachlichen Anforderungen **F-KV-01 bis F-KV-04** (Herkunft BA-KV-01…04) sowie die mitwirkenden Regeln **GR-05** (Stammdatenschutz) und **NF-ARCH-01** (Persistenz).[cite: 2]
**Nicht im Scope (andere Gruppen):** Produktverwaltung (G), Dokumentenprozess (F), GUI (E).[cite: 2] Diese werden hier **nur über die Schnittstellen** berührt (siehe Abschnitt 2).[cite: 2]
**Leitprinzip:** Alles richtet sich nach den vier Projektdokumenten.[cite: 2] Abweichungen werden **nicht still aufgelöst**, sondern als offener Punkt in Abschnitt 8 markiert.[cite: 2]
---
## 2. Kompatibilitätsvertrag mit den anderen Modulen
Damit die Kundenverwaltung sauber mit den Teilen der anderen Teilnehmer zusammenspielt, müssen diese vier Berührungspunkte exakt eingehalten werden.[cite: 2] **Bevor implementiert wird, sollten diese Signaturen mit Gruppe E und F gegengeprüft sein.**[cite: 2]
| # | Wer braucht es | Was die Kundenverwaltung liefern muss | Quelle |
|---|----------------|----------------------------------------|--------|
| K1 | **GUI (Gruppe E)** über IF-01 | `KundeService` mit `anlegen(Kunde): long`, `bearbeiten(Kunde): void`, `suchen(String): List<Kunde>`, `loeschen(long): void` | Pflichtenheft Klassendiagramm (Kap. 7.2), Komponentendiagramm (Kap. 7.1: `KundeAnsicht → KundeService`)[cite: 2] |
| K2 | **Datenhaltung** über IF-02 | `KundeRepository`-Interface (speichern/findeById/findeAlle/loeschen), JSON-Persistenz dahinter gekapselt | IF-02, NF-ARCH-01/02[cite: 2] |
| K3 | **Dokumentenprozess (Gruppe F)** | Kunde ist über `kundeId` (long) referenzierbar; F nutzt `FakeCustomerLookup` und `isCustomerReferenced(...)` in seinen Tests (MT-DP-16).[cite: 2] KV muss einen Kunden per ID auflösbar machen.[cite: 2] | Modultestplan DP (MT-DP-01, MT-DP-16); Pflichtenheft Datenobjekte (kundeId als Referenz in allen Belegen)[cite: 2] |
| K4 | **Löschsperre GR-05** | Vor dem Löschen prüft `KundeService`, ob der Kunde in einem Beleg referenziert ist → Abfrage gegen `BelegRepository` (Gruppe F).[cite: 2] Bei Referenz: Löschen ablehnen.[cite: 2] | GR-05; F-KV-04; MT-KV-11[cite: 2] |
**Daten-Kontrakt „Kunde" (Pflichtenheft Kap. 6.1.2) – verbindlich:**[cite: 2]
| Attribut | Java-Typ | Pflicht | Constraint |
|----------|----------|---------|------------|
| kundeId | `long` | Pflicht | Fortlaufender, eindeutiger Primärschlüssel[cite: 2] |
| firmenname | `String` | Pflicht\* | Pflicht, sofern kein Nachname[cite: 2] |
| nachname | `String` | Pflicht\* | Pflicht, sofern kein Firmenname[cite: 2] |
| vorname | `String` | Optional | –[cite: 2] |
| strasse | `String` | Pflicht | Straße + Hausnummer[cite: 2] |
| plz | `String` | Pflicht | String (führende Nullen erhalten)[cite: 2] |
| ort | `String` | Pflicht | –[cite: 2] |
| telefon | `String` | Optional | –[cite: 2] |
| email | `String` | Optional | Formatvalidierung, falls angegeben[cite: 2] |
| ustIdNr | `String` | Optional | USt-IdNr.[cite: 2] |
| lieferadresse | `String` | Optional | abweichende Lieferadresse[cite: 2] |
| ansprechpartner | `String` | Optional | –[cite: 2] |
\* **Constraint:** `firmenname != null || nachname != null` (mindestens eines befüllt).[cite: 2]
---
## 3. Technische Vorgaben (aus Pflichtenheft Kap. 2.3)
- **Sprache:** Java LTS ≥ 17[cite: 2]
- **Persistenz:** lokale **JSON-Datei** (z. B. Jackson), hinter `KundeRepository` gekapselt → austauschbar (NF-ARCH-02)[cite: 2]
- **Tests:** **JUnit 5 (Jupiter)** – GUI-unabhängige Logiktests (NF-TEST-02)[cite: 2]
- **Architektur:** 3-Schichten (ui → service → repository); KV berührt nur `service` + `repository`[cite: 2]
- **Versionierung:** Git / Gitty, Code-Review je Merge (NF-VER-02)[cite: 2]
- **Relevante NF-Ziele:** NF-USE-01 (Kunde anlegen < 2 min), NF-PERF-01 (Aktion < 1 s bei 1.000 Kunden), NF-PERF-02 (Liste < 2 s), NF-SEC-01 (kein Klartext von außen), NF-SEC-02 (DSGVO-Löschen)[cite: 2]
---
## 4. Die Phasen (Schritt für Schritt)
### Phase 0 – Setup & Abstimmung
- `[x]` **P0-1** Git/Gitty: Branch für Gruppe H angelegt und Paketstruktur erstellt.[cite: 1]
- `[x]` **P0-2** Build-Setup: Maven mit Java 17, JUnit 5 und Jackson in `pom.xml` aufgesetzt.[cite: 1]
- `[ ]` **P0-3** Schnittstellen K1–K4 mit Gruppe E und F gegenprüfen *(vom User aufgeschoben, wird bei Integration relevant)*.[cite: 1]
- `[ ]` **P0-4** Offenen Punkt OP-1 mit Team klären *(vom User aufgeschoben, Code ist durch Interface entkoppelt)*.[cite: 1]
### Phase 1 – Datenmodell
- `[x]` **P1-1** Klasse `Kunde` mit allen 12 Attributen erstellt (`plz` als `String`).[cite: 1]
- `[x]` **P1-2** Getter/Setter und `equals`/`hashCode` über `kundeId` implementiert.[cite: 1]
- `[x]` **P1-3** JSON-Serialisierbarkeit via Jackson durch leeren Konstruktor sichergestellt.[cite: 1]
### Phase 2 – Persistenz (IF-02 / NF-ARCH-01/02)
- `[x]` **P2-1** Interface `KundeRepository` mit CRUD-Signaturen definiert.[cite: 1]
- `[x]` **P2-2** `KundeRepositoryJson` lädt/speichert lokale JSON-Datei via Jackson.[cite: 1]
- `[x]` **P2-3** Fortlaufende ID-Vergabe über mitgespeicherten Zähler gelöst (kein ID-Reuse nach Löschung).[cite: 1]
- `[x]` **P2-4** Persistenz-Roundtrip im `KundeRepositoryJsonTest` erfolgreich geprüft.[cite: 1]
### Phase 3 – Validierung
- `[x]` **P3-1** Pflichtfeldprüfung für `strasse`, `plz`, `ort` in `KundeValidator` eingebaut.[cite: 1]
- `[x]` **P3-2** Constraint `firmenname != null || nachname != null` umgesetzt.[cite: 1]
- `[x]` **P3-3** E-Mail-Formatprüfung per Regex integriert.[cite: 1]
- `[x]` **P3-4** `ValidierungsException` erstellt; wird vor dem Speichern geworfen, um ungültige Daten zu blockieren.[cite: 1]
### Phase 4 – Logik: `KundeService` (F-KV-01…04)
- `[x]` **P4-1** `anlegen(Kunde)` validiert, erzwingt ID-Vergabe und persistiert.[cite: 1] · **F-KV-01 / BA-KV-01**[cite: 2]
- `[x]` **P4-2** `bearbeiten(Kunde)` prüft Existenz, validiert und speichert.[cite: 1] · **F-KV-02 / BA-KV-02**[cite: 2]
- `[x]` **P4-3** `suchen(String)` filtert über Name (case-insensitive) und Kundennummer.[cite: 1] · **F-KV-03 / BA-KV-03**[cite: 2]
- `[x]` **P4-4** `loeschen(long)` prüft Existenz und wirft bei aktiver Referenz eine `LoeschsperreException`.[cite: 1] · **F-KV-04 / BA-KV-04**[cite: 2]
- `[x]` **P4-5** GR-05-Löschsperre über das Interface `BelegReferenzPruefer` vollständig vorbereitet und isoliert getestet.[cite: 1]
### Phase 5 – Schnittstelle zum Dokumentenprozess (K3)
- `[x]` **P5-1** `KundeService.finde(long): Optional<Kunde>` als Schnittstelle für Gruppe F bereitgestellt.[cite: 1]
- `[ ]` **P5-2** Mit Gruppe F genaue Aufrufrichtung für `isCustomerReferenced` abstimmen *(offen/aufgeschoben)*.[cite: 1]
### Phase 6 – Modultests (JUnit 5, MT-KV-01…11)
*Die fachliche Logik ist durch die 8 Tests in `KundeServiceTest` bereits abgedeckt.[cite: 1] In dieser Phase müssen die bestehenden Tests kopiert, verfeinert und exakt in die 11 im Modultestplan geforderten Testmethoden-Namen überführt werden:*[cite: 1]
- `[ ]` **P6-01** MT-KV-01 Kunde mit allen Pflichtattributen anlegen → gespeichert · BA-KV-01[cite: 1]
- `[ ]` **P6-02** MT-KV-02 ohne Firmenname/Nachname → abgelehnt · BA-KV-01[cite: 1]
- `[ ]` **P6-03** MT-KV-03 ohne Straße → abgelehnt · BA-KV-01[cite: 1]
- `[ ]` **P6-04** MT-KV-04 ungültige E-Mail „kunde@" → abgelehnt · BA-KV-01[cite: 1]
- `[ ]` **P6-05** MT-KV-05 Telefonnummer ändern → gespeichert · BA-KV-02[cite: 1]
- `[ ]` **P6-06** MT-KV-06 Persistenz nach Neuladen → unverändert · BA-KV-02, NF-ARCH-01[cite: 1]
- `[ ]` **P6-07** MT-KV-07 Suche über Namen „Muster" → gefunden · BA-KV-03[cite: 1]
- `[ ]` **P6-08** MT-KV-08 Suche über Kundennummer → gefunden · BA-KV-03[cite: 1]
- `[ ]` **P6-09** MT-KV-09 Suche ohne Treffer → leeres Ergebnis/Hinweis · BA-KV-03[cite: 1]
- `[ ]` **P6-10** MT-KV-10 nicht referenzierten Kunden löschen → entfernt · BA-KV-04[cite: 1]
- `[ ]` **P6-11** MT-KV-11 referenzierten Kunden löschen → abgewiesen · BA-KV-04, GR-05[cite: 1]
- `[ ]` **P6-12** Alle 11 Tests grün; Coverage-Schwelle (NF-TEST-03: 60 %) für `kunde`-Paket im IntelliJ-Coverage-Tool nachweisen.[cite: 1]
### Phase 7 – Abgabe-Artefakt: Modultestbericht
- `[ ]` **P7-1** Testlauf dokumentieren: je MT-KV-Fall **Ergebnis (bestanden/fehlgeschlagen)**, Datum, Tester[cite: 2]
- `[ ]` **P7-2** Abdeckungsübersicht aus dem Modultestplan (BA-KV-01→MT-KV-01…04 usw.) als Nachweis übernehmen[cite: 2]
- `[ ]` **P7-3** Mit Team klären: **max. 4 Dateien** insgesamt → KV-Bericht entweder eigene Datei **oder** in gemeinsame Test-Datei integriert (Koordination mit G/F/E)[cite: 2]
### Phase 8 – Integration mit anderen Modulen
- `[ ]` **P8-1** GUI (E): `KundeAnsicht` ruft `KundeService` – Smoke-Test Anlegen/Suchen/Löschen aus der Oberfläche[cite: 2]
- `[ ]` **P8-2** Belege (F): echter Kunde im Angebot referenzierbar; GR-05-Löschsperre greift im integrierten System (MT-DP-16 ↔ MT-KV-11)[cite: 2]
- `[ ]` **P8-3** Gesamtsystem startet, KV-CRUD lauffähig (AK-02 Charter)[cite: 2]
### Phase 9 – Präsentation (KV-Anteil)
Pflichtinhalte laut Aufgabenstellung – als KV-Vertreter (1 Person je Gruppe) vorbereiten:[cite: 2]
- `[ ]` **P9-1** Demo-Anteil: Kunde anlegen → suchen → bearbeiten → Löschsperre zeigen (referenzierter Kunde)[cite: 2]
- `[ ]` **P9-2** **KI-Einsatz:** wo eingesetzt, wie gut hat es funktioniert (konkrete KV-Beispiele)[cite: 2]
- `[ ]` **P9-3** **Was nächstes Mal anders:** ehrliche Lessons learned aus der KV-Umsetzung[cite: 2]
- `[ ]` **P9-4** **Modultestplan-Ergebnisse** der KV präsentieren (Abdeckung + Pass-Quote)[cite: 2]
- `[ ]` **P9-5** **Traceability-Stichprobe vorbereiten:** Kette **BA-KV-0x → F-KV-0x → MT-KV-xx → AT-KV-xx** auswendig/griffbereit (Prof prüft stichprobenartig)[cite: 2]
### Phase 10 – Abgabe & Generalprobe
- `[ ]` **P10-1** Code gemergt, Reviews abgeschlossen (NF-VER-02), Tests grün im Hauptbranch[cite: 2]
- `[ ]` **P10-2** Testbericht + Folien im Team konsolidiert (max. 4 Test-Dateien, genau 1 Foliendatei)[cite: 2]
- `[ ]` **P10-3** **Abgabe bis Mo 29.06. 09:00 Uhr**[cite: 2]
- `[ ]` **P10-4** Generalprobe Vortrag + Zeitmessung (20–25 Min Team-Budget)[cite: 2]
---
## 5. Traceability-Matrix Kundenverwaltung (für die Stichprobenprüfung)
| Anforderung (LH) | Pflichtenheft | Modultests | Akzeptanztest (LH) |
|------------------|---------------|------------|--------------------|
| BA-KV-01 Kunde anlegen | F-KV-01 | MT-KV-01 … MT-KV-04 | AT-KV-01, AT-KV-02[cite: 2] |
| BA-KV-02 Kunde bearbeiten | F-KV-02 | MT-KV-05, MT-KV-06 | AT-KV-03, AT-KV-04[cite: 2] |
| BA-KV-03 Kunde suchen | F-KV-03 | MT-KV-07 … MT-KV-09 | AT-KV-05, AT-KV-06[cite: 2] |
| BA-KV-04 Kunde löschen | F-KV-04 | MT-KV-10, MT-KV-11 | AT-KV-07, AT-KV-08[cite: 2] |
| GR-05 Stammdatenschutz | F-KV-04 (i.V.m. GR-05) | MT-KV-11 | –[cite: 2] |
| NF-ARCH-01 Persistenz | NF-ARCH-01 | MT-KV-06 | AT-NF-…[cite: 2] |
---
## 6. Zeitplan bis Montag (Vorschlag)
| Tag | Fokus |
|-----|-------|
| **Do 25.06** | Phase 0 + Phase 1 (Setup, Schnittstellen abstimmen, Datenmodell)[cite: 2] |
| **Fr 26.06** | Phase 2 + Phase 3 + Phase 4 (Persistenz, Validierung, Service-Logik)[cite: 2] |
| **Sa 27.06** | Phase 5 + Phase 6 (DP-Schnittstelle, alle 11 Modultests grün)[cite: 2] |
| **So 28.06** | Phase 7 + Phase 8 + Phase 9 (Testbericht, Integration, Folien)[cite: 2] |
| **Mo 29.06 vor 09:00** | Phase 10 (Konsolidierung, Abgabe, Generalprobe)[cite: 2] |
---
## 7. Definition of Done (Kundenverwaltung)
- `[ ]` F-KV-01 bis F-KV-04 implementiert und über `KundeService` aufrufbar (K1)[cite: 2]
- `[ ]` Persistenz über `KundeRepository`/JSON, Daten überleben Neustart (NF-ARCH-01)[cite: 2]
- `[ ]` Validierung greift (Pflichtfelder, firmenname||nachname, E-Mail-Format)[cite: 2]
- `[ ]` GR-05-Löschsperre funktioniert im integrierten System[cite: 2]
- `[ ]` MT-KV-01…11 alle grün, Coverage ≥ 60 % im `kunde`-Paket[cite: 2]
- `[ ]` Modultestbericht erstellt und ins Team-Artefakt integriert[cite: 2]
- `[ ]` Traceability BA→F→MT→AT lückenlos und vorführbar[cite: 2]
- `[ ]` In Gesamtsystem integriert (GUI + Belege), Code gereviewt und gemergt[cite: 2]
---
## 8. Offene Punkte (nicht still aufgelöst)
| ID | Dokument / Stelle | Beschreibung | Vorschlag |
|----|-------------------|--------------|-----------|
| OP-1 | Pflichtenheft Klassendiagramm (Kap. 7.2) vs. GR-05 | Diagramm zeigt `KundeService ..> ProduktRepository`; GR-05-Text fordert Referenzprüfung über `BelegRepository`.[cite: 2] Für die Löschsperre F-KV-04/MT-KV-11 ist das **BelegRepository** maßgeblich.[cite: 2] | Im Code gegen `BelegRepository` prüfen; Diagramm-Abhängigkeit als Doku-Inkonsistenz an Team/Prüfer melden.[cite: 2] |
| OP-2 | Abgabe-Format | „max. 4 Dateien" für Testberichte bei 4 Modulen → Aufteilung 1 Datei/Modul **oder** 1 Sammeldatei?[cite: 2] | Team-Entscheidung vor So 28.06; KV-Bericht entsprechend zuschneiden.[cite: 2] |
| OP-3 | Schnittstelle K3 (Lookup-Richtung) | Genaue Aufrufrichtung zwischen KV und Gruppe F für `isCustomerReferenced` final festzurren.[cite: 2] | In P0-3 mit Gruppe F bestätigen.[cite: 2] |
---
*Aktualisiere bei jeder Session die Zeile „Aktuelle Position" in Abschnitt 0 und die Status-Marker.[cite: 2] Damit kann der Fortschritt jederzeit punktgenau aufgegriffen werden.*[cite: 2]

228
Unterlagen/Fahrplan_Kundenverwaltung_GruppeH/Fahrplan_Kundenverwaltung_GruppeH_1.2.md 100644
View File

@ -0,0 +1,228 @@
# Fahrplan – Modul Kundenverwaltung (Gruppe H) Ver. 1.2
**Projekt:** Fakturierungssystem · SE1 Team 2 – Hochschule Mannheim
**Modul / Gruppe:** Kundenverwaltung (Gruppe H) · Package `de.hsmannheim.faktura.kunde`
**Verantwortlich (dieses Dokument):** Christopher Lampert [3027248]
**Gruppe H:** Oleg Akimenko [3028868] (Gruppenleiter), Christopher Lampert [3027248], Kenan Pekarovic [3027541]
**Stand:** 26.06.2026
**Bezug:** Lastenheft v1.1, Pflichtenheft v1.0, Project Charter v1.1, Modultestplan (KV-Teil), Modultestbericht KV v1.0
> **Harte Deadline:** Montag, **29.06.2026, 09:00 Uhr** – Abgabe der Artefakte pro Team.
> **Präsentation:** Montag, 29.06.2026 im regulären Vorlesungsblock (20–25 Min/Team, 4 Vortragende, je Gruppe ein Vertreter).
> **Projektphase laut Charter:** M7 „Puffer & Abnahme" (27.–30.06.2026).
*Änderung gegenüber v1.1: Phase 6 (Modultests MT-KV-01…11) und Phase 7 (Modultestbericht, P7-1/P7-2) abgeschlossen; Statusmarker, „Aktuelle Position" und Umsetzungsstand aktualisiert; offener Punkt OP-4 (K1 ohne „alle Kunden"-Methode) ergänzt; fehlerhafte Export-Marker entfernt.*
---
## 0. So benutzt du diesen Fahrplan
Jeder Schritt hat einen Status. Aktualisiere ihn, dann kannst du mir jederzeit sagen „ich bin bei P8-1" und ich habe sofort den Kontext.
**Statuslegende:**
`[ ]` offen · `[~]` in Arbeit · `[x]` fertig · `[!]` blockiert / offener Punkt
**Aktuelle Position:** *Phasen 0–7 (KV-Kern + Modultestbericht) abgeschlossen – nächster Schritt: Phase 8 (Integration) bzw. Team-Abstimmung P7-3.*
### 🚀 Aktueller Umsetzungsstand (für den neuen Chat-Kontext)
Die **Phasen 0 bis 7** der Kundenverwaltung sind umgesetzt: Datenmodell, Persistenz, Validierung, Service-Logik und DP-Schnittstelle stehen, die **11 Modultests MT-KV-01…11** sind grün, und der **Modultestbericht** ist erstellt. Alle entwickelten Klassen sind funktionsfähig und durch JUnit-5-Tests abgedeckt; die Logikschicht erreicht **85 % Line Coverage** (NF-TEST-03 ≥ 60 % erfüllt).
#### 📁 Erstellte Dateien & Paketstruktur (`de.hsmannheim.faktura.kunde`)
* **Wurzelverzeichnis:** `pom.xml` (Maven-Setup für Java 17, JUnit 5 und Jackson) sowie `.gitignore` (ignoriert `target/` und `.idea/`).
* **`model`:** `Kunde.java` (spezifikationskonformes POJO mit allen 12 Feldern, PLZ als `String`).
* **`repository`:**
* `KundeRepository.java` (Interface für Datenhaltung).
* `KundeContainer.java` (Hilfsklasse für JSON-Bündelung inkl. ID-Zähler).
* `KundeRepositoryJson.java` (Jackson-Implementierung mit fortlaufendem ID-Zähler gegen ID-Wiederverwendung).
* **`service`:**
* `KundeService.java` (zentrale CRUD-Logik inkl. `finde(long)` für die Beleg-Schnittstelle K3).
* `KundeValidator.java` (Pflichtfelder, E-Mail-Format, Bedingung `firmenname || nachname`).
* `BelegReferenzPruefer.java` (funktionales Interface zur Entkopplung der GR-05-Löschsperre von Gruppe F).
* `ValidierungsException.java` & `LoeschsperreException.java` (Unchecked Exceptions).
* **`src/test/java`:**
* `KundeModultestTest.java` – konsolidierte Modultestdatei mit **genau 11 Tests** (MT-KV-01…11, 1:1 zum Modultestplan, je `@DisplayName`). Ersetzt die früheren Einzeldateien `KundeServiceTest`, `KundeValidatorTest` und `KundeRepositoryJsonTest` (deren Abdeckung vollständig übernommen wurde; vgl. P10-2 „max. 4 Test-Dateien").
* **Abgabe-Artefakt:** `Modultestbericht_Kundenverwaltung_v1_0` (Testergebnisse, Coverage-Nachweis, Abdeckungsübersicht).
---
## 1. Ziel & Abgrenzung
**Im Scope (nur Gruppe H):** Anlegen, Bearbeiten, Suchen und Löschen von Kunden samt Validierung, Persistenz und Modultests – also die fachlichen Anforderungen **F-KV-01 bis F-KV-04** (Herkunft BA-KV-01…04) sowie die mitwirkenden Regeln **GR-05** (Stammdatenschutz) und **NF-ARCH-01** (Persistenz).
**Nicht im Scope (andere Gruppen):** Produktverwaltung (G), Dokumentenprozess (F), GUI (E). Diese werden hier **nur über die Schnittstellen** berührt (siehe Abschnitt 2).
**Leitprinzip:** Alles richtet sich nach den vier Projektdokumenten. Abweichungen werden **nicht still aufgelöst**, sondern als offener Punkt in Abschnitt 8 markiert.
---
## 2. Kompatibilitätsvertrag mit den anderen Modulen
Damit die Kundenverwaltung sauber mit den Teilen der anderen Teilnehmer zusammenspielt, müssen diese vier Berührungspunkte exakt eingehalten werden. **Bevor integriert wird, sollten diese Signaturen mit Gruppe E und F gegengeprüft sein.**
| # | Wer braucht es | Was die Kundenverwaltung liefern muss | Quelle |
|---|----------------|----------------------------------------|--------|
| K1 | **GUI (Gruppe E)** über IF-01 | `KundeService` mit `anlegen(Kunde): long`, `bearbeiten(Kunde): void`, `suchen(String): List<Kunde>`, `loeschen(long): void` | Pflichtenheft Klassendiagramm (Kap. 7.2), Komponentendiagramm (Kap. 7.1: `KundeAnsicht → KundeService`) |
| K2 | **Datenhaltung** über IF-02 | `KundeRepository`-Interface (speichern/findeById/findeAlle/loeschen), JSON-Persistenz dahinter gekapselt | IF-02, NF-ARCH-01/02 |
| K3 | **Dokumentenprozess (Gruppe F)** | Kunde ist über `kundeId` (long) referenzierbar; F nutzt `FakeCustomerLookup` und `isCustomerReferenced(...)` in seinen Tests (MT-DP-16). KV muss einen Kunden per ID auflösbar machen (`finde(long): Optional<Kunde>`). | Modultestplan DP (MT-DP-01, MT-DP-16); Pflichtenheft Datenobjekte (kundeId als Referenz in allen Belegen) |
| K4 | **Löschsperre GR-05** | Vor dem Löschen prüft `KundeService`, ob der Kunde in einem Beleg referenziert ist → Abfrage gegen `BelegRepository` (Gruppe F). Bei Referenz: Löschen ablehnen. | GR-05; F-KV-04; MT-KV-11 |
**Daten-Kontrakt „Kunde" (Pflichtenheft Kap. 6.1.2) – verbindlich:**
| Attribut | Java-Typ | Pflicht | Constraint |
|----------|----------|---------|------------|
| kundeId | `long` | Pflicht | Fortlaufender, eindeutiger Primärschlüssel |
| firmenname | `String` | Pflicht\* | Pflicht, sofern kein Nachname |
| nachname | `String` | Pflicht\* | Pflicht, sofern kein Firmenname |
| vorname | `String` | Optional | – |
| strasse | `String` | Pflicht | Straße + Hausnummer |
| plz | `String` | Pflicht | String (führende Nullen erhalten) |
| ort | `String` | Pflicht | – |
| telefon | `String` | Optional | – |
| email | `String` | Optional | Formatvalidierung, falls angegeben |
| ustIdNr | `String` | Optional | USt-IdNr. |
| lieferadresse | `String` | Optional | abweichende Lieferadresse |
| ansprechpartner | `String` | Optional | – |
\* **Constraint:** `firmenname != null || nachname != null` (mindestens eines befüllt).
---
## 3. Technische Vorgaben (aus Pflichtenheft Kap. 2.3)
- **Sprache:** Java LTS ≥ 17
- **Persistenz:** lokale **JSON-Datei** (z. B. Jackson), hinter `KundeRepository` gekapselt → austauschbar (NF-ARCH-02)
- **Tests:** **JUnit 5 (Jupiter)** – GUI-unabhängige Logiktests (NF-TEST-02)
- **Architektur:** 3-Schichten (ui → service → repository); KV berührt nur `service` + `repository`
- **Versionierung:** Git / Gitty, Code-Review je Merge (NF-VER-02)
- **Relevante NF-Ziele:** NF-USE-01 (Kunde anlegen < 2 min), NF-PERF-01 (Aktion < 1 s bei 1.000 Kunden), NF-PERF-02 (Liste < 2 s), NF-SEC-01 (kein Klartext von außen), NF-SEC-02 (DSGVO-Löschen)
---
## 4. Die Phasen (Schritt für Schritt)
### Phase 0 – Setup & Abstimmung
- `[x]` **P0-1** Git/Gitty: Branch für Gruppe H angelegt und Paketstruktur erstellt.
- `[x]` **P0-2** Build-Setup: Maven mit Java 17, JUnit 5 und Jackson in `pom.xml` aufgesetzt.
- `[ ]` **P0-3** Schnittstellen K1–K4 mit Gruppe E und F gegenprüfen *(wird bei Integration relevant, Phase 8)*.
- `[ ]` **P0-4** Offenen Punkt OP-1 mit Team klären *(Code ist durch Interface entkoppelt)*.
### Phase 1 – Datenmodell
- `[x]` **P1-1** Klasse `Kunde` mit allen 12 Attributen erstellt (`plz` als `String`).
- `[x]` **P1-2** Getter/Setter und `equals`/`hashCode` über `kundeId` implementiert.
- `[x]` **P1-3** JSON-Serialisierbarkeit via Jackson durch leeren Konstruktor sichergestellt.
### Phase 2 – Persistenz (IF-02 / NF-ARCH-01/02)
- `[x]` **P2-1** Interface `KundeRepository` mit CRUD-Signaturen definiert.
- `[x]` **P2-2** `KundeRepositoryJson` lädt/speichert lokale JSON-Datei via Jackson.
- `[x]` **P2-3** Fortlaufende ID-Vergabe über mitgespeicherten Zähler gelöst (kein ID-Reuse nach Löschung).
- `[x]` **P2-4** Persistenz-Roundtrip geprüft (jetzt in MT-KV-06 enthalten).
### Phase 3 – Validierung
- `[x]` **P3-1** Pflichtfeldprüfung für `strasse`, `plz`, `ort` in `KundeValidator` eingebaut.
- `[x]` **P3-2** Constraint `firmenname != null || nachname != null` umgesetzt.
- `[x]` **P3-3** E-Mail-Formatprüfung per Regex integriert.
- `[x]` **P3-4** `ValidierungsException` erstellt; wird vor dem Speichern geworfen, um ungültige Daten zu blockieren.
### Phase 4 – Logik: `KundeService` (F-KV-01…04)
- `[x]` **P4-1** `anlegen(Kunde)` validiert, erzwingt ID-Vergabe und persistiert. · **F-KV-01 / BA-KV-01**
- `[x]` **P4-2** `bearbeiten(Kunde)` prüft Existenz, validiert und speichert. · **F-KV-02 / BA-KV-02**
- `[x]` **P4-3** `suchen(String)` filtert über Name (case-insensitive) und Kundennummer. · **F-KV-03 / BA-KV-03**
- `[x]` **P4-4** `loeschen(long)` prüft Existenz und wirft bei aktiver Referenz eine `LoeschsperreException`. · **F-KV-04 / BA-KV-04**
- `[x]` **P4-5** GR-05-Löschsperre über das Interface `BelegReferenzPruefer` vollständig vorbereitet und isoliert getestet.
### Phase 5 – Schnittstelle zum Dokumentenprozess (K3)
- `[x]` **P5-1** `KundeService.finde(long): Optional<Kunde>` als Schnittstelle für Gruppe F bereitgestellt.
- `[ ]` **P5-2** Mit Gruppe F genaue Aufrufrichtung für `isCustomerReferenced` abstimmen *(offen, Integration)*.
### Phase 6 – Modultests (JUnit 5, MT-KV-01…11) ✅ abgeschlossen
*Die fachliche Logik wurde in genau die 11 im Modultestplan geforderten Testmethoden überführt – konsolidiert in `KundeModultestTest`, jeweils mit `@DisplayName` (MT-KV-ID sichtbar im Testlauf):*
- `[x]` **P6-01** MT-KV-01 Kunde mit allen Pflichtattributen anlegen → gespeichert · BA-KV-01
- `[x]` **P6-02** MT-KV-02 ohne Firmenname/Nachname → abgelehnt · BA-KV-01
- `[x]` **P6-03** MT-KV-03 ohne Straße → abgelehnt · BA-KV-01
- `[x]` **P6-04** MT-KV-04 ungültige E-Mail „kunde@" → abgelehnt · BA-KV-01
- `[x]` **P6-05** MT-KV-05 Telefonnummer ändern → gespeichert · BA-KV-02
- `[x]` **P6-06** MT-KV-06 Persistenz nach Neuladen → unverändert · BA-KV-02, NF-ARCH-01
- `[x]` **P6-07** MT-KV-07 Suche über Namen „Muster" → gefunden · BA-KV-03
- `[x]` **P6-08** MT-KV-08 Suche über Kundennummer → gefunden · BA-KV-03
- `[x]` **P6-09** MT-KV-09 Suche ohne Treffer → leeres Ergebnis · BA-KV-03
- `[x]` **P6-10** MT-KV-10 nicht referenzierten Kunden löschen → entfernt · BA-KV-04
- `[x]` **P6-11** MT-KV-11 referenzierten Kunden löschen → abgewiesen · BA-KV-04, GR-05
- `[x]` **P6-12** Alle 11 Tests grün; Coverage nachgewiesen: **85 % Line Coverage** im Paket `…kunde.service` (NF-TEST-03 ≥ 60 % erfüllt).
### Phase 7 – Abgabe-Artefakt: Modultestbericht ✅ weitgehend abgeschlossen
- `[x]` **P7-1** Testlauf dokumentiert: je MT-KV-Fall Ergebnis (bestanden), Datum (26.06.2026), Tester.
- `[x]` **P7-2** Abdeckungsübersicht aus dem Modultestplan (BA-KV-01→MT-KV-01…04 usw.) als Nachweis übernommen.
- `[ ]` **P7-3** Mit Team klären: **max. 4 Dateien** insgesamt → KV-Bericht eigene Datei **oder** in gemeinsame Test-Datei integriert (Koordination mit G/F/E; siehe OP-2).
### Phase 8 – Integration mit anderen Modulen
- `[ ]` **P8-1** GUI (E): `KundeAnsicht` ruft `KundeService` – Smoke-Test Anlegen/Suchen/Löschen aus der Oberfläche.
- `[ ]` **P8-2** Belege (F): echter Kunde im Angebot referenzierbar; GR-05-Löschsperre greift im integrierten System (MT-DP-16 ↔ MT-KV-11).
- `[ ]` **P8-3** Gesamtsystem startet, KV-CRUD lauffähig (AK-02 Charter).
### Phase 9 – Präsentation (KV-Anteil)
Pflichtinhalte laut Aufgabenstellung – als KV-Vertreter (1 Person je Gruppe) vorbereiten:
- `[ ]` **P9-1** Demo-Anteil: Kunde anlegen → suchen → bearbeiten → Löschsperre zeigen (referenzierter Kunde).
- `[ ]` **P9-2** **KI-Einsatz:** wo eingesetzt, wie gut hat es funktioniert (konkrete KV-Beispiele).
- `[ ]` **P9-3** **Was nächstes Mal anders:** ehrliche Lessons learned aus der KV-Umsetzung.
- `[ ]` **P9-4** **Modultestplan-Ergebnisse** der KV präsentieren (Abdeckung + Pass-Quote 100 %).
- `[ ]` **P9-5** **Traceability-Stichprobe vorbereiten:** Kette **BA-KV-0x → F-KV-0x → MT-KV-xx → AT-KV-xx** auswendig/griffbereit (Prof prüft stichprobenartig).
### Phase 10 – Abgabe & Generalprobe
- `[ ]` **P10-1** Code gemergt, Reviews abgeschlossen (NF-VER-02), Tests grün im Hauptbranch.
- `[ ]` **P10-2** Testbericht + Folien im Team konsolidiert (max. 4 Test-Dateien, genau 1 Foliendatei).
- `[ ]` **P10-3** **Abgabe bis Mo 29.06. 09:00 Uhr.**
- `[ ]` **P10-4** Generalprobe Vortrag + Zeitmessung (20–25 Min Team-Budget).
---
## 5. Traceability-Matrix Kundenverwaltung (für die Stichprobenprüfung)
| Anforderung (LH) | Pflichtenheft | Modultests | Akzeptanztest (LH) |
|------------------|---------------|------------|--------------------|
| BA-KV-01 Kunde anlegen | F-KV-01 | MT-KV-01 … MT-KV-04 | AT-KV-01, AT-KV-02 |
| BA-KV-02 Kunde bearbeiten | F-KV-02 | MT-KV-05, MT-KV-06 | AT-KV-03, AT-KV-04 |
| BA-KV-03 Kunde suchen | F-KV-03 | MT-KV-07 … MT-KV-09 | AT-KV-05, AT-KV-06 |
| BA-KV-04 Kunde löschen | F-KV-04 | MT-KV-10, MT-KV-11 | AT-KV-07, AT-KV-08 |
| GR-05 Stammdatenschutz | F-KV-04 (i.V.m. GR-05) | MT-KV-11 | – |
| NF-ARCH-01 Persistenz | NF-ARCH-01 | MT-KV-06 | AT-NF-… |
---
## 6. Zeitplan bis Montag
| Tag | Fokus | Status |
|-----|-------|--------|
| **Do 25.06** | Phase 0 + Phase 1 (Setup, Schnittstellen, Datenmodell) | erledigt |
| **Fr 26.06** | Phase 2–7 (Persistenz, Validierung, Service-Logik, DP-Schnittstelle, 11 Modultests grün, Modultestbericht) | erledigt – **KV ist dem Zeitplan voraus** |
| **Sa 27.06** | Puffer + Vorbereitung Integration (Phase 8) und Folien (Phase 9) | offen |
| **So 28.06** | Phase 8 + Phase 9 (Integration, Folien, Traceability-Stichprobe) | offen |
| **Mo 29.06 vor 09:00** | Phase 10 (Konsolidierung, Abgabe, Generalprobe) | offen |
---
## 7. Definition of Done (Kundenverwaltung)
- `[x]` F-KV-01 bis F-KV-04 implementiert und über `KundeService` aufrufbar (K1).
- `[x]` Persistenz über `KundeRepository`/JSON, Daten überleben Neustart (NF-ARCH-01).
- `[x]` Validierung greift (Pflichtfelder, firmenname||nachname, E-Mail-Format).
- `[~]` GR-05-Löschsperre: isoliert getestet (MT-KV-11); im **integrierten** System noch nachzuweisen (Phase 8).
- `[x]` MT-KV-01…11 alle grün, Coverage ≥ 60 % im `kunde`-Paket (85 % Line in `…service`).
- `[~]` Modultestbericht erstellt; Integration ins Team-Sammelartefakt offen (P7-3).
- `[~]` Traceability BA→F→MT lückenlos und vorführbar; AT-KV-Akzeptanztests teamseitig.
- `[ ]` In Gesamtsystem integriert (GUI + Belege), Code gereviewt und gemergt (Phase 8 / 10).
---
## 8. Offene Punkte (nicht still aufgelöst)
| ID | Dokument / Stelle | Beschreibung | Vorschlag |
|----|-------------------|--------------|-----------|
| OP-1 | Pflichtenheft Klassendiagramm (Kap. 7.2) vs. GR-05 | Diagramm zeigt `KundeService ..> ProduktRepository`; GR-05-Text fordert Referenzprüfung über `BelegRepository`. Für die Löschsperre F-KV-04/MT-KV-11 ist das **BelegRepository** maßgeblich. | Im Code gegen `BelegRepository` prüfen (über `BelegReferenzPruefer` umgesetzt); Diagramm-Abhängigkeit als Doku-Inkonsistenz an Team/Prüfer melden. |
| OP-2 | Abgabe-Format | „max. 4 Dateien" für Testberichte bei 4 Modulen → Aufteilung 1 Datei/Modul **oder** 1 Sammeldatei? | Team-Entscheidung vor So 28.06; KV-Bericht entsprechend zuschneiden (P7-3). |
| OP-3 | Schnittstelle K3 (Lookup-Richtung) | Genaue Aufrufrichtung zwischen KV und Gruppe F für `isCustomerReferenced` final festzurren. | In P0-3 mit Gruppe F bestätigen. |
| OP-4 | Vertrag K1 vs. GUI-Übersicht (Gruppe E) | K1 enthält keine Methode zum Auflisten **aller** Kunden; `suchen("")` liefert bewusst eine leere Liste. Die `KundeAnsicht` kann die Gesamtliste so nicht über den Service beziehen. Kein Code-Fehler (K1 ist exakt umgesetzt), aber eine Vertragslücke. | Mit Gruppe E klären: entweder `List<Kunde> alle()` im `KundeService` ergänzen oder Konvention „leere Suche = alle Kunden" festlegen. Vor Phase 8 entscheiden. |
---
*Aktualisiere bei jeder Session die Zeile „Aktuelle Position" in Abschnitt 0 und die Status-Marker. Damit kann der Fortschritt jederzeit punktgenau aufgegriffen werden.*

619
Unterlagen/Lastenheft/Lastenheft_1.1.md 100644
View File

@ -0,0 +1,619 @@
---
title: "Lastenheft – Fakturierungssystem"
subtitle: "SE1 Team 2 – Hochschule Mannheim"
author: "Christopher Lampert"
date: "24.06.2026"
lang: de-DE
geometry: "left=2.2cm,right=2.2cm,top=2cm,bottom=2cm"
fontsize: 10pt
mainfont: "Latin Modern Roman"
colorlinks: true
linkcolor: "blue"
urlcolor: "blue"
toc: true
toc-depth: 3
numbersections: false
---
# Lastenheft – Fakturierungssystem
**Modul:** Software Engineering 1
**Team:** SE1 Team 2 – Hochschule Mannheim
**Version:** 1.1
**Stand:** 24.06.2026
**Autor:** Christopher Lampert
**Bezug:** Project Charter v1.1 (15.05.2026) – Fakturierungssystem
---
## Freigabeübersicht
| Rolle | Name | Datum |
|--------------|----------------------------|-------|
| Ersteller | Christopher Lampert |24.06.2026|
| Prüfer | Prof. Dr. Gerd Marmitt | |
| Freigebender | SE1 Team 2 (Gruppenleiter) | |
---
## Dokumentenhistorie
| Version | Datum | Autor | Änderung |
|---------|------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1.0 | 15.05.2026 | Christopher Lampert | Initiale Erstellung und Konsolidierung des Lastenhefts auf Basis Project Charter v1.1: Erfolgskriterien Z1–Z4 SMART; Nicht-Ziele um PDF-/E-Rechnung-Abgrenzung und Authentifizierung präzisiert; BA-PV-01 und BA-KV-01 an Datenobjekt-Pflichtattribute Kap. 6.1 angeglichen; Datenobjekte um Begriffsklärung Bezeichnung/Produktname/Artikelnummer ergänzt; neue Anforderungen BA-DP-07 (PDF-Export, fachlich) und BA-GUI-05 (PDF-Export-Schaltfläche); Modalverben in NF-Anforderungen an Prioritäten angeglichen; NF-TEST-03 Coverage-Schwelle auf 60 % angehoben; NF-MAINT-02 Akzeptanztest auf automatisierte Messung umgestellt; neuer Abschnitt 6.1.7 mit Statusübergangs-Tabelle; Begriff „Auftragsbestätigung" durchgängig verwendet; Traceability-Matrix in Kap. 8.4 entsprechend erweitert. |
| 1.1 | 25.06.2026 | Christopher Lampert | RÜberarbeitung nach Review: Freigabeübersicht um Datumsangaben ergänzt; Kap. 1.2 um eine fachliche Einleitung zur Herleitung der Projektziele erweitert; Kapitel „Begriffsklärung Lastenheft vs. Pflichtenheft“ entfernt und Kapitelstruktur angepasst; Geltungsbereich auf Zielgruppen und Leserschaft des Dokuments ausgerichtet; organisatorische Rahmenbedingungen aus dem Lastenheft entfernt (Zuordnung zum Project Charter gemäß Review-Hinweis); BA-GUI-01 lösungsneutral formuliert („Dropdown“ entfernt); BA-GUI-02 und BA-GUI-03 hinsichtlich der GUI-Darstellung abstrahiert; technische Rahmenbedingungen präzisiert; Dokumentenhistorie ergänzt sowie redaktionelle Konsistenz- und Strukturverbesserungen durchgeführt. |
---
## 1. Einleitung und Zielbestimmung
### 1.1 Zweck dieses Dokuments
Ziel dieses Lastenhefts ist die Spezifikation der fachlichen Anforderungen an ein **Fakturierungssystem** für kleine Unternehmen. Das Dokument beschreibt aus Sicht des Auftraggebers, **was** das System leisten soll, und bildet die Grundlage für:
- die Systemarchitektur und das Pflichtenheft,
- die Projektplanung im V-Modell,
- die Akzeptanztests bei der Abnahme.
### 1.2 Projektziele
Die fachlichen Projektziele leiten sich unmittelbar aus dem Geschäftsprozess der Fakturierung ab: Das System soll die durchgängige Bearbeitung von der Pflege der Produkt- und Kundenstammdaten über die Belegerstellung bis zur Rechnungsstellung ermöglichen. Die vier nachfolgenden Ziele (Z1–Z4) sind entlang der vier Pflichtmodule gegliedert und jeweils mit messbaren Erfolgskriterien sowie zugeordneten Akzeptanztests hinterlegt. Sie wurden aus Charter v1.1, Kapitel 4, übernommen und für das Lastenheft fachlich verfeinert:
| Nr. | Ziel | Erfolgskriterium |
|-----|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Z1 | Produktverwaltung | Alle CRUD-Operationen bei bis zu 1.000 Produkten innerhalb der NF-PERF-01-Antwortzeit von 1 s; Akzeptanztests AT-PV-01 bis AT-PV-08 bestanden; Geschäftsregel GR-05 (Stammdatenschutz) eingehalten. |
| Z2 | Kundenverwaltung | CRUD bei bis zu 1.000 Kunden analog Z1; Akzeptanztests AT-KV-01 bis AT-KV-08 bestanden; DSGVO-konformes Löschen (NF-SEC-02) unter Beachtung der Aufbewahrungspflicht (GR-05) demonstrierbar. |
| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung an mindestens einem Beispielkunden und -produkt durchgängig demonstrierbar; Rechnung enthält alle Pflichtangaben nach § 14 UStG; Akzeptanztests AT-DP-01 bis AT-DP-07 sowie AT-GR-01 bis AT-GR-06 bestanden. |
| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen; alle Belege über die GUI erstell- und als PDF exportierbar; NF-USE-01/02 nachgewiesen; Akzeptanztests AT-GUI-01 bis AT-GUI-08 bestanden. |
### 1.3 Nicht-Ziele
Folgende Funktionen sind **explizit nicht** Bestandteil dieses Projekts:
- Mobile Anwendung
- Cloud-System bzw. Multi-Tenant-Betrieb
- Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk)
- Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export)
- Strukturierte E-Rechnung (XRechnung, ZUGFeRD) — eine einfache PDF-Ausgabe der Belege ist hingegen **in-scope** (siehe BA-DP-07, BA-GUI-05)
- Anbindung an externe Buchhaltungs- oder ERP-Systeme
- Mehrsprachigkeit (das System wird ausschließlich in deutscher Sprache realisiert)
- Authentifizierung bzw. Benutzeranmeldung — Begründung: lokale Einbenutzer-Anwendung auf einem PC-Arbeitsplatz; Zugriffsschutz erfolgt durch das Betriebssystem-Login. NF-SEC-01 ergänzt einen Schutz der Datenhaltung auf Dateisystemebene.
---
## 2. Systemkontext und Rahmenbedingungen
### 2.1 Einsatzkontext
Das Fakturierungssystem wird als **lokal installierte Einbenutzer-Anwendung** auf einem PC-Arbeitsplatz eines kleinen Unternehmens betrieben. Es unterstützt den vollständigen Geschäftsprozess von der Angebotserstellung bis zur Rechnungsstellung.
**Typischer Nutzungsablauf:**
1. Anwender pflegt Produkt- und Kundenstammdaten.
2. Anwender erstellt ein Angebot auf Basis dieser Stammdaten.
3. Bei Auftragsannahme wird das Angebot zur Auftragsbestätigung weiterverarbeitet.
4. Nach Lieferung wird aus der Auftragsbestätigung ein Lieferschein erzeugt.
5. Abschließend wird aus dem Lieferschein eine Rechnung erstellt.
6. Belege werden bei Bedarf als PDF exportiert (Archivierung, Versand).
### 2.2 Schnittstellen zur Umgebung
Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieben wird, beschränken sich die Schnittstellen auf:
| Schnittstelle | Zweck | Art |
|----------------------------------|----------------------------------------------------|----------------------|
| Benutzerschnittstelle (GUI) | Interaktion mit dem Anwender | UI |
| Lokales Dateisystem | Persistierung der Daten (Stammdaten, Dokumente) | Datei-Schnittstelle |
| PDF-Export-Schnittstelle | Erzeugung druckbarer Dokumente als PDF | Ausgabeschnittstelle |
### 2.3 Technische Rahmenbedingungen
- Das System wird **lokal** ausgeführt (keine zwingende Internetverbindung erforderlich).
- Daten werden persistent gespeichert, sodass sie nach einem Neustart der Anwendung verlustfrei verfügbar sind.
- Versionierung der Quellcode-Artefakte erfolgt über **Gitty**.
---
## 3. Stakeholder und Benutzergruppen
### 3.1 Stakeholder
| ID | Stakeholder | Beschreibung | Interesse |
|----|-------------------|----------------------------------------|-----------------------------------------------|
| S1 | Auftraggeber | Prof. Dr. Gerd Marmitt | Lehrziele erreicht, Abnahmekriterien erfüllt |
| S2 | Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) | Erfolgreiche Umsetzung, Lernzielerreichung |
| S3 | Endnutzer | spätere Anwender (kleines Unternehmen) | Funktionierender Fakturierungsablauf |
### 3.2 Benutzerrollen
Im laufenden Betrieb des Systems wird folgende Benutzerrolle unterschieden:
| Rolle | Aufgaben | Typische Aktionen |
|---------------|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|
| **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten, löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; PDF exportieren |
Eine Authentifizierungs- oder Rechtekonzept-Rolle entfällt (siehe Kap. 1.3, Nicht-Ziele).
---
## 4. Fachliche Anforderungen (Funktionale Anforderungen)
Alle Anforderungen folgen einer der in den Vorlesungsfolien definierten Satzschablonen:
- **BA-`<Kategorie>`-`<Nummer>`** Benutzeranforderung (Lastenheft-Satzschablone)
- **GR-`<Nummer>`** Geschäftsregel (siehe Kap. 6.3)
- **NF-`<Kategorie>`-`<Nummer>`** Nicht-funktionale Anforderung (siehe Kap. 5)
Priorität: **Muss** = Pflicht für die Abnahme, **Soll** = wichtig, aber verzichtbar, **Kann** = optional bzw. Erweiterung. Die Modalverben im Anforderungstext entsprechen jeweils der Priorität (MUSS / SOLLTE / KANN).
### 4.1 Modul Produktverwaltung (Gruppe G)
**BA-PV-01 – Produkt anlegen (Muss)**
Als Anwender muss ich neue Produkte anlegen können, um Produktdaten zentral im System zu speichern. Die Anforderung gilt, wenn der Anwender die Eingabemaske geöffnet hat. Die Anforderung gilt als erfüllt, wenn die in Kap. 6.1.1 genannten Pflichtattribute (Bezeichnung, Einzelpreis netto, Mehrwertsteuersatz) gespeichert sind und das Produkt in der Produktübersicht erscheint.
Akzeptanztests: AT-PV-01 (Speicherung mit vollständigen Pflichtattributen), AT-PV-02 (Fehlermeldung bei fehlendem Pflichtfeld, insbesondere fehlendem MwSt.-Satz).
**BA-PV-02 – Produkt bearbeiten (Muss)**
Als Anwender muss ich bestehende Produktdaten bearbeiten können, um veraltete oder fehlerhafte Daten zu aktualisieren. Die Anforderung gilt, wenn ein vorhandenes Produkt zur Bearbeitung ausgewählt ist. Die Anforderung gilt als erfüllt, wenn geänderte Daten gespeichert, sofort in den Produktdetails sichtbar und nach erneutem Öffnen weiterhin vorhanden sind. Bestehende Angebote werden gemäß GR-04 nicht verändert.
Akzeptanztests: AT-PV-03 (Preis ändern; bestehende Angebote bleiben unverändert), AT-PV-04 (Persistenz nach Neuöffnen).
**BA-PV-03 – Produkt suchen (Muss)**
Als Anwender muss ich nach Produkten suchen können, um Produktdaten schnell zu finden. Die Anforderung gilt, wenn der Anwender einen Suchbegriff in das Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn Produkte über Bezeichnung oder Artikelnummer gefunden werden und bei einer ungültigen Eingabe der Hinweis „Kein Produkt gefunden" erscheint.
Akzeptanztests: AT-PV-05 (Treffer), AT-PV-06 (kein Treffer).
**BA-PV-04 – Produkt löschen (Muss)**
Als Anwender muss ich Produkte löschen können, um nicht mehr angebotene oder fälschlicherweise angelegte Datensätze zu entfernen. Die Anforderung gilt, wenn der Anwender das Löschen eines Produkts auslöst und keine Sperre durch Geschäftsregel GR-05 (Stammdatenschutz) vorliegt. Die Anforderung gilt als erfüllt, wenn nach Bestätigung einer Sicherheitsabfrage das Produkt entfernt wird und nicht mehr in Übersicht und Suche erscheint.
Akzeptanztests: AT-PV-07 (Sicherheitsabfrage; Sperre bei Referenz), AT-PV-08 (Produkt nicht mehr auffindbar).
### 4.2 Modul Kundenverwaltung (Gruppe H)
**BA-KV-01 – Kunde anlegen (Muss)**
Als Anwender muss ich neue Kunden anlegen können, um Kundendaten zentral im System zu speichern. Die Anforderung gilt, wenn der Anwender die Eingabemaske für einen neuen Kunden geöffnet hat. Die Anforderung gilt als erfüllt, wenn die in Kap. 6.1.2 genannten Pflichtattribute (Firmenname bzw. Nachname, Straße, PLZ, Ort) gespeichert sind und der Kunde anschließend in der Kundenliste erscheint. Wird eine E-Mail-Adresse angegeben, wird ihr Format validiert.
Akzeptanztests: AT-KV-01 (Speicherung mit vollständigen Pflichtattributen), AT-KV-02 (Fehlermeldung bei fehlendem Pflichtfeld bzw. ungültigem E-Mail-Format).
**BA-KV-02 – Kunde bearbeiten (Muss)**
Als Anwender muss ich bestehende Kundendaten bearbeiten können, um veraltete oder fehlerhafte Daten zu aktualisieren. Die Anforderung gilt, wenn ein vorhandener Kunde zur Bearbeitung ausgewählt ist. Die Anforderung gilt als erfüllt, wenn geänderte Daten gespeichert, sofort angezeigt und nach erneutem Öffnen des Kunden weiterhin vorhanden sind.
Akzeptanztests: AT-KV-03 (Telefonnummer ändern), AT-KV-04 (Persistenz).
**BA-KV-03 – Kunde suchen (Muss)**
Als Anwender muss ich nach Kunden suchen können, um Kundendaten schnell zu finden. Die Anforderung gilt, wenn der Anwender einen Suchbegriff in das Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn Kunden über Namen oder Kundennummer gefunden werden und bei einer ungültigen Eingabe der Hinweis „Kein Kunde gefunden" erscheint.
Akzeptanztests: AT-KV-05 (Treffer), AT-KV-06 (kein Treffer).
**BA-KV-04 – Kunde löschen (Muss)**
Als Anwender muss ich Kunden löschen können, um nicht mehr benötigte Datensätze zu entfernen. Die Anforderung gilt, wenn der Anwender das Löschen eines Kunden auslöst und keine Sperre durch Geschäftsregel GR-05 vorliegt. Die Anforderung gilt als erfüllt, wenn der Kunde nach Bestätigung entfernt wird und in Liste sowie Suche nicht mehr auffindbar ist.
Akzeptanztests: AT-KV-07 (Löschung), AT-KV-08 (nicht mehr auffindbar; Sperre bei Referenz).
### 4.3 Modul Dokumentenprozess (Gruppe F)
#### 4.3.1 Angebot
**BA-DP-01 – Angebot erstellen (Muss)**
Als Anwender muss ich ein Angebot für einen Kunden erstellen können, um Kundenpreise verbindlich anzubieten. Die Anforderung gilt, wenn mindestens ein Kunde und ein Produkt im System vorhanden sind. Die Anforderung gilt als erfüllt, wenn ein Angebot mit Kundenreferenz, Datum, mindestens einer Position und korrekt berechneter Netto- und Bruttosumme gespeichert ist.
Akzeptanztest: AT-DP-01 (Angebot mit einer Position; korrekte Summen gemäß GR-06).
**BA-DP-02 – Angebotsstatus setzen (Muss)**
Als Anwender muss ich ein Angebot als „angenommen" oder „abgelehnt" markieren können, um den Vertriebsstatus nachzuhalten. Die Anforderung gilt, wenn ein Angebot mit Status „offen" vorliegt. Die Anforderung gilt als erfüllt, wenn der gesetzte Status dauerhaft gespeichert wird und in der Übersicht sichtbar ist. Statusübergänge folgen Kap. 6.1.7.
Akzeptanztest: AT-DP-02 (Status persistent nach Neustart).
#### 4.3.2 Auftragsbestätigung
**BA-DP-03 – Auftragsbestätigung aus Angebot erzeugen (Muss)**
Als Anwender muss ich ein angenommenes Angebot in eine Auftragsbestätigung umwandeln können, um den Auftrag verbindlich zu bestätigen. Die Anforderung gilt, wenn das Angebot den Status „angenommen" hat. Die Anforderung gilt als erfüllt, wenn alle Angebotsdaten in eine neue Auftragsbestätigung übernommen werden, das Vorgängerangebot referenziert ist und der Angebotsstatus automatisch auf „überführt" gesetzt wird (gemäß Kap. 6.1.7).
Akzeptanztest: AT-DP-03 (Datenübernahme komplett; Referenz vorhanden; Angebotsstatus „überführt").
#### 4.3.3 Lieferschein
**BA-DP-04 – Lieferschein aus Auftragsbestätigung erzeugen (Muss)**
Als Anwender muss ich aus einer Auftragsbestätigung einen Lieferschein erzeugen können, um die Auslieferung der Ware zu dokumentieren. Die Anforderung gilt, wenn eine Auftragsbestätigung mit Status „bestätigt" vorliegt. Die Anforderung gilt als erfüllt, wenn ein Lieferschein mit Referenz auf die Auftragsbestätigung, Lieferdatum und allen Positionen erzeugt und gespeichert wird.
Akzeptanztest: AT-DP-04 (Lieferschein referenziert Auftragsbestätigung; Positionen vollständig).
#### 4.3.4 Rechnung
**BA-DP-05 – Rechnung aus Lieferschein erzeugen (Muss)**
Als Anwender muss ich aus einem Lieferschein eine Rechnung erzeugen können, um die Forderung gegenüber dem Kunden zu stellen. Die Anforderung gilt, wenn ein Lieferschein mit Status „geliefert" vorliegt. Die Anforderung gilt als erfüllt, wenn eine Rechnung mit allen Pflichtangaben nach § 14 UStG, eindeutiger Rechnungsnummer und Referenz auf den Lieferschein erzeugt ist.
Akzeptanztest: AT-DP-05 (Pflichtangaben vollständig; Rechnungsnummer eindeutig gemäß GR-02).
**BA-DP-06 – Automatisches Rechnungsdatum (Muss)**
Als Anwender muss ich beim Erzeugen einer Rechnung das aktuelle Rechnungsdatum automatisch gesetzt bekommen, um konsistente Buchungsdaten zu gewährleisten. Die Anforderung gilt, wenn der Anwender eine neue Rechnung anlegt. Die Anforderung gilt als erfüllt, wenn das Rechnungsdatum beim Anlegen automatisch auf das aktuelle Systemdatum gesetzt und dauerhaft gespeichert wird.
Akzeptanztest: AT-DP-06 (Rechnungsdatum entspricht Systemdatum).
#### 4.3.5 Beleg-Export
**BA-DP-07 – Beleg als PDF exportieren (Muss)**
Als Anwender muss ich Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen als PDF-Datei exportieren können, um Belege archivieren und Kunden zustellen zu können. Die Anforderung gilt, wenn ein gespeicherter Beleg ausgewählt ist. Die Anforderung gilt als erfüllt, wenn die erzeugte PDF-Datei alle im Beleg gespeicherten Inhalte in druckbarer Form enthält (bei Rechnungen einschließlich aller § 14 UStG-Pflichtangaben) und unter einem vom Anwender gewählten Pfad gespeichert wird.
Akzeptanztest: AT-DP-07 (PDF-Erzeugung je Belegtyp; Inhalt entspricht dem Beleg in der GUI; Rechnungs-PDF enthält alle § 14 UStG-Pflichtangaben).
### 4.4 Modul GUI / Programmoberfläche (Gruppe E)
**BA-GUI-01 – Angebotserfassung über grafische Maske (Muss)**
Als Anwender muss ich über eine grafische Eingabemaske Angebote erstellen können, um Kundenpreise einfach festzulegen. Die Anforderung gilt, wenn die Maske geöffnet und mindestens ein Produkt sowie ein Kunde im System vorhanden sind. Die Anforderung gilt als erfüllt, wenn Artikel aus den im System vorhandenen Produkten auswählbar sind, die berechnete Gesamtsumme ohne spürbare Verzögerung aktualisiert wird und nach dem Speichern eine Erfolgsmeldung erscheint.
Akzeptanztests: AT-GUI-01 (Live-Summenaktualisierung), AT-GUI-02 (Erfolgsmeldung).
**BA-GUI-02 – Auftragsbestätigung über GUI (Muss)**
Als Anwender muss ich Angebote über die GUI in Auftragsbestätigungen umwandeln können, ohne Daten manuell neu einzugeben. Die Anforderung gilt, wenn ein Angebot mit Status „angenommen" ausgewählt ist. Die Anforderung gilt als erfüllt, wenn alle Daten in die Auftragsbestätigungs-Maske übernommen werden, die Maske mit dem Titel „Auftragsbestätigung" angezeigt wird
und Pflichtfelder für den Liefertermin deutlich hervorgehoben werden,
solange sie leer sind.
Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
**BA-GUI-03 – Rechnungslegung und Statusanzeige (Muss)**
Als Anwender muss ich über die GUI aus einem Lieferschein eine Rechnung erzeugen und deren Status einsehen können, um den Abrechnungsfortschritt zu verfolgen. Die Anforderung gilt, wenn ein abrechnungsreifer Lieferschein vorliegt. Die Anforderung gilt als erfüllt, wenn die GUI vor dem finalen Speichern eine Druckvorschau anzeigt und der Auftragsstatus in der Übersicht
eindeutig als „Abgeschlossen"
gekennzeichnet wird.
Akzeptanztests: AT-GUI-04 (Druckvorschau), AT-GUI-05 (Status-Icon).
**BA-GUI-04 – Belegsuche mit Echtzeit-Filterung (Muss)**
Als Anwender muss ich Belege über eine Suchfunktion filtern können, um Dokumente schnell aufzurufen. Die Anforderung gilt, wenn der Anwender Suchbegriffe in das GUI-Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn die Trefferliste tabellarisch dargestellt wird, sich bei Eingabe von Name oder Nummer sofort aktualisiert und bei einer ungültigen Suche der Text „Keine Treffer gefunden" erscheint.
Akzeptanztests: AT-GUI-06 (Echtzeit-Filter), AT-GUI-07 (Hinweis bei leerer Trefferliste).
**BA-GUI-05 – PDF-Export aus der Belegansicht (Muss)**
Als Anwender muss ich auf jeder Belegansicht (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) den PDF-Export über eine Schaltfläche auslösen können, um die Funktion ohne Menünavigation zu erreichen. Die Anforderung gilt, wenn ein Beleg angezeigt wird. Die Anforderung gilt als erfüllt, wenn auf der Belegansicht eine Schaltfläche „Als PDF exportieren" sichtbar ist, beim Klick die in BA-DP-07 beschriebene Funktion ausgeführt und eine Erfolgsmeldung mit Speicherpfad angezeigt wird.
Akzeptanztest: AT-GUI-08 (Schaltfläche sichtbar und funktionsfähig; Erfolgsmeldung).
---
## 5. Qualitätsanforderungen (nicht-funktionale Anforderungen)
Modalverben im Anforderungstext entsprechen der jeweiligen Priorität (Muss → MUSS, Soll → SOLLTE, Kann → KANN).
### 5.1 Usability (NF-USE)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------|
| NF-USE-01 | Das Anlegen eines neuen Kunden MUSS von einem Anwender ohne vorherige Schulung in weniger als 2 Minuten abgeschlossen werden können, wobei höchstens 1 Fehlbedienung pro 10 Testnutzenden zulässig ist. | Muss | AT-NF-01: Usability-Test mit 5 Probanden; Erfolgsquote > 90 %, Median-Zeit < 120 s.|
| NF-USE-02 | Mindestens 80 % der Testnutzenden MÜSSEN die Aufgabe „Aus einem Angebot eine Rechnung erzeugen" im ersten Versuch ohne Hilfetext erfolgreich abschließen. | Muss | AT-NF-02: Usability-Test mit 5 Probanden; mindestens 4 von 5 erfolgreich. |
| NF-USE-03 | Das System MUSS bei jeder validierungspflichtigen Eingabe innerhalb von 1 Sekunde eine sichtbare Rückmeldung (Erfolg oder Fehler) anzeigen. | Muss | AT-NF-03: Manueller Test mit Stoppuhr; Rückmeldezeit < 1 s. |
### 5.2 Performance (NF-PERF)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------|
| NF-PERF-01 | Das System MUSS jede Benutzeraktion innerhalb von 1 Sekunde mit einer sichtbaren Rückmeldung beantworten, bei einem Datenbestand von bis zu 1.000 Produkten und 1.000 Kunden. | Muss | AT-NF-04: Lasttest mit 1.000 Datensätzen je Entität; Antwortzeit < 1 s. |
| NF-PERF-02 | Das System MUSS die Übersichtsliste von Produkten oder Kunden bei bis zu 1.000 Datensätzen innerhalb von 2 Sekunden vollständig anzeigen. | Muss | AT-NF-05: Lasttest mit 1.000 Einträgen; Anzeigedauer < 2 s. |
| NF-PERF-03 | Das System SOLLTE den Anwendungsstart vom Aufruf bis zur bedienbaren Hauptansicht in höchstens 5 Sekunden abschließen (Referenzhardware: handelsüblicher Bürorechner). | Soll | AT-NF-06: Kaltstart auf Referenzhardware < 5 s. |
### 5.3 Wartbarkeit (NF-MAINT)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|-------------------------------------------------------------------------------------------------------------|
| NF-MAINT-01 | Der Quellcode MUSS modular nach den vier Modulen Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI getrennt sein (eigene Pakete bzw. Verzeichnisse). | Muss | AT-NF-07: Statische Prüfung der Repository-Struktur. |
| NF-MAINT-02 | Mindestens 80 % der öffentlichen Klassen und Methoden SOLLTEN über kurze Dokumentationskommentare (Zweck, Parameter, Rückgabe) verfügen. | Soll | AT-NF-08: Automatisierte Auswertung (JavaDoc-/Doxygen-Report) zeigt > 80 %; Stichprobe als Sekundärprüfung. |
| NF-MAINT-03 | Das System MUSS einer dokumentierten, dreischichtigen Architektur (Präsentation, Logik, Datenhaltung) folgen. | Muss | AT-NF-09: Review des Architekturdokuments; nachweisbare Schichtentrennung. |
### 5.4 Testbarkeit (NF-TEST)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|---------------------------------------------------------------------------------|
| NF-TEST-01 | Jede Anforderung mit Priorität „Muss" MUSS mindestens einem Akzeptanztest in der Traceability-Matrix zugeordnet sein. | Muss | AT-NF-10: Vollständigkeitsprüfung der Traceability-Matrix vor Abnahme. |
| NF-TEST-02 | Die Geschäftslogik (Logikschicht) MUSS so gestaltet sein, dass sie ohne die GUI durch automatisierte Komponententests aufgerufen werden kann. | Muss | AT-NF-11: Mindestens ein lauffähiger Unit-Test pro Modul ohne GUI-Abhängigkeit. |
| NF-TEST-03 | Mindestens 60 % der Geschäftslogik-Methoden SOLLTEN durch automatisierte Tests abgedeckt sein (Line Coverage). | Soll | AT-NF-12: Coverage-Report > 60 %. |
### 5.5 Versionierung (NF-VER)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------|
| NF-VER-01 | Der gesamte Quellcode MUSS in Gitty unter den im Charter v1.1 (Kap. 6.2) genannten Repositories versioniert werden. | Muss | AT-NF-13: Sichtprüfung der Repositories. |
| NF-VER-02 | Jeder Merge in den Hauptbranch MUSS durch mindestens ein Code-Review eines anderen Teammitglieds freigegeben werden. | Muss | AT-NF-14: Review-Historie zeigt für jeden Merge mindestens einen Reviewer. |
### 5.6 Architektur und Datenhaltung (NF-ARCH)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------|
| NF-ARCH-01 | Das System MUSS alle Datensätze (Produkte, Kunden, Dokumente) persistent so speichern, dass sie nach einem Neustart der Anwendung vollständig wiederhergestellt werden. | Muss | AT-NF-15: Datensätze anlegen, Anwendung neu starten; Datensätze sind unverändert. |
| NF-ARCH-02 | Die Datenhaltung SOLLTE hinter einer abstrakten Schnittstelle (Repository bzw. DAO) gekapselt sein, sodass die konkrete Speichertechnologie austauschbar ist. | Soll | AT-NF-16: Code-Review zeigt Repository- bzw. DAO-Abstraktion. |
### 5.7 Sicherheit und Datenschutz (NF-SEC)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------|
| NF-SEC-01 | Das System SOLLTE personenbezogene Kundendaten so speichern, dass sie ohne Zugriff auf das Anwendungs-Verzeichnis nicht im Klartext einsehbar sind (z. B. lokale Datei in geschütztem Anwendungspfad). | Soll | AT-NF-17: Inspektion aus fremdem Nutzerkontext zeigt keinen lesbaren Klartext. |
| NF-SEC-02 | Das System SOLLTE dem Anwender ermöglichen, einen Kunden gemäß DSGVO Art. 17 zu löschen, sofern keine gesetzlichen Aufbewahrungspflichten (z. B. 10 Jahre für Rechnungen) entgegenstehen. | Soll | AT-NF-18: Löschanforderung ohne aktive Rechnungen entfernt den Kunden. |
---
## 6. Daten, Schnittstellen und Geschäftsregeln
### 6.1 Datenobjekte
Die folgenden Datenobjekte bilden den fachlichen Kern des Systems. Eine Darstellung als UML-Klassendiagramm wird im Pflichtenheft bzw. Architekturdokument ergänzt.
**6.1.1 Produkt**
- Identifikator: Produkt-ID (eindeutig, fortlaufend; systeminterner Primärschlüssel)
- Pflichtattribute: Bezeichnung (synonym: Produktname), Einzelpreis netto, Mehrwertsteuersatz
- Optionale Attribute: Artikelnummer (anwenderseitige Kennung; wird, sofern nicht eingegeben, aus der Produkt-ID nach Schema `P-<lfd.Nr.>` abgeleitet), Beschreibung, Kategorie
**6.1.2 Kunde**
- Identifikator: Kunden-ID (eindeutig, fortlaufend)
- Pflichtattribute: Firmenname bzw. Nachname, Straße, PLZ, Ort
- Optionale Attribute: Vorname, Telefon, E-Mail (Format wird validiert, falls angegeben), USt-IdNr., abweichende Lieferadresse, Ansprechpartner
**6.1.3 Angebot**
- Identifikator: Angebotsnummer (z. B. `A-<Jahr>-<lfd. Nr.>`)
- Pflichtattribute: Kundenreferenz, Datum, Positionen (Produkt, Menge, Einzelpreis), Gesamtsumme (netto bzw. brutto), Status (offen, angenommen, abgelehnt, überführt)
**6.1.4 Auftragsbestätigung**
- Identifikator: Auftragsbestätigungs-Nummer (z. B. `AB-<Jahr>-<lfd. Nr.>`)
- Pflichtattribute: Referenz auf Angebot, Kundenreferenz, Datum, Positionen, Gesamtsumme, Status (bestätigt, geliefert)
**6.1.5 Lieferschein**
- Identifikator: Lieferscheinnummer (z. B. `LS-<Jahr>-<lfd. Nr.>`)
- Pflichtattribute: Referenz auf Auftragsbestätigung, Kundenreferenz, Lieferdatum, Positionen (Produkt, Menge), Status (offen, geliefert, fakturiert)
**6.1.6 Rechnung**
- Identifikator: Rechnungsnummer (eindeutig, fortlaufend, lückenlos, z. B. `R-<Jahr>-<lfd. Nr.>`)
- Pflichtattribute: Referenz auf genau einen Lieferschein, Kundenreferenz, Rechnungsdatum, Positionen, Netto-, USt.- und Bruttosumme, Pflichtangaben nach § 14 UStG, Status (offen, bezahlt)
**6.1.7 Statusübergänge**
Die in Kap. 6.1.3 bis 6.1.6 genannten Statuswerte werden wie folgt geschaltet:
| Beleg | Aktion | Vor-Status | Folge-Status | Auslöser |
|---------------------|---------------------------------------------------|-----------------|----------------|---------------------------|
| Angebot | Erstellung | — | offen | BA-DP-01 |
| Angebot | Markierung „angenommen" | offen | angenommen | BA-DP-02 (Anwender) |
| Angebot | Markierung „abgelehnt" | offen | abgelehnt | BA-DP-02 (Anwender) |
| Angebot | Erzeugung Auftragsbestätigung | angenommen | überführt | BA-DP-03 (automatisch) |
| Auftragsbestätigung | Erzeugung aus Angebot | — | bestätigt | BA-DP-03 |
| Auftragsbestätigung | Erzeugung Lieferschein | bestätigt | geliefert | BA-DP-04 (automatisch) |
| Lieferschein | Erzeugung aus Auftragsbestätigung | — | offen | BA-DP-04 |
| Lieferschein | Bestätigung Auslieferung | offen | geliefert | Anwenderaktion |
| Lieferschein | Erzeugung Rechnung | geliefert | fakturiert | BA-DP-05 (automatisch) |
| Rechnung | Erzeugung aus Lieferschein | — | offen | BA-DP-05 |
| Rechnung | Markierung „bezahlt" | offen | bezahlt | Anwenderaktion |
### 6.2 Beziehungen zwischen Datenobjekten
| Beziehung | Multiplizität |
|---------------------------------------------------------------------------------|-----------------|
| Kunde &rarr; Angebot | 1 : n |
| Angebot &rarr; Auftragsbestätigung | 1 : 0..1 |
| Auftragsbestätigung &rarr; Lieferschein | 1 : 0..1 |
| Lieferschein &rarr; Rechnung | 1 : 0..1 |
| Produkt &rarr; Position (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) | 1 : n |
### 6.3 Geschäftsregeln
**GR-01 – Dokumentenkette**
Eine Rechnung verweist auf genau einen Lieferschein, ein Lieferschein auf genau eine Auftragsbestätigung, eine Auftragsbestätigung auf genau ein Angebot. Wenn ein Folgedokument erzeugt werden soll, dann muss das Vorgängerdokument im passenden Status (siehe Kap. 6.1.7) vorliegen.
Akzeptanztest AT-GR-01: Versuch, eine Rechnung ohne zugehörigen Lieferschein anzulegen, wird abgewiesen.
**GR-02 – Eindeutigkeit der Rechnungsnummer**
Wenn eine neue Rechnung erstellt wird, dann vergibt das System die nächste freie, fortlaufende Rechnungsnummer; Nummern dürfen nicht wiederverwendet werden.
Akzeptanztest AT-GR-02: Drei aufeinander folgende Rechnungen haben fortlaufende, eindeutige Nummern.
**GR-03 – Unveränderlichkeit festgeschriebener Rechnungen**
Wenn eine Rechnung erzeugt und gespeichert wurde, dann ist sie inhaltlich nicht mehr änderbar.
Akzeptanztest AT-GR-03: Bearbeitungsversuch auf gespeicherte Rechnung wird abgewiesen.
**GR-04 – Preisübernahme**
Wenn eine Produktposition in ein Angebot übernommen wird, dann wird der zu diesem Zeitpunkt gültige Einzelpreis in der Position festgehalten und durch spätere Produktpreisänderungen nicht verändert.
Akzeptanztest AT-GR-04: Preisänderung am Produkt verändert den Preis bestehender Angebote nicht.
**GR-05 – Stammdatenschutz**
Ein Produkt oder Kunde darf nicht gelöscht werden, solange er in einem Angebot, einer Auftragsbestätigung, einem Lieferschein oder einer Rechnung referenziert wird.
Akzeptanztest AT-GR-05: Löschversuch eines referenzierten Stammdatensatzes wird abgewiesen.
**GR-06 – Summenberechnung**
Wenn ein Dokument mit Positionen gespeichert wird, dann gilt: Nettosumme = SUM (Menge × Einzelpreis); USt.-Betrag pro Position = Netto × MwSt.-Satz; Bruttosumme = Netto + USt.
Akzeptanztest AT-GR-06: Manuelle Nachrechnung an drei Beispielen stimmt mit Systemausgabe überein.
### 6.4 Schnittstellen
| ID | Schnittstelle | Beschreibung |
|-------|-------------------------------------|--------------------------------------------------------------------|
| IF-01 | Benutzerschnittstelle (GUI) | Interaktive Oberfläche, siehe Kap. 4.4 |
| IF-02 | Datei-Schnittstelle Persistenz | Lokale Speicherung der Stammdaten und Dokumente (vgl. NF-ARCH-01) |
| IF-03 | PDF-Export-Schnittstelle | Erzeugung druckbarer Dokumente als PDF (vgl. BA-DP-07, BA-GUI-05) |
---
## 7. Akzeptanzkriterien und Abnahmebedingungen
### 7.1 Übernahme aus Project Charter v1.1
Aus Charter v1.1 (Kap. 13) werden die Abnahmekriterien übernommen und im Folgenden verfeinert.
### 7.2 Verfeinerte Akzeptanzkriterien
Das System gilt als **abgenommen**, wenn alle folgenden Kriterien erfüllt sind:
| ID | Akzeptanzkriterium | Bezug |
|-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------|
| AK-01 | Alle Muss-Anforderungen aus Kap. 4 und 5 sind implementiert und durch zugeordnete Akzeptanztests nachgewiesen. | BA-*, NF-* (Priorität Muss) |
| AK-02 | Die vier Pflichtmodule Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI sind in ihren Repositories (Gruppen G, H, F, E) lauffähig und in das Gesamtsystem integriert. | Charter v1.1, Kap. 6.2 |
| AK-03 | Der vollständige Dokumentenprozess Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung kann anhand eines Beispielkunden und -produkts durchgängig demonstriert werden, einschließlich PDF-Export. | Kap. 4.3 (BA-DP-01..07) |
| AK-04 | Die Traceability-Matrix (Anhang 8.4) ordnet jeder Muss-Anforderung mindestens einen Akzeptanztest zu. | NF-TEST-01 |
| AK-05 | Die Lasttests gemäß NF-PERF-01 und NF-PERF-02 sind mit dem geforderten Datenbestand erfolgreich durchgeführt. | Kap. 5.2 |
| AK-06 | Lastenheft v1.0 sowie Pflichtenheft bzw. Architekturdokument liegen in finaler freigegebener Version vor. | Charter v1.1, Kap. 7 und Kap. 8 |
| AK-07 | Die Abnahmepräsentation gegenüber dem Auftraggeber (Prof. Dr. Marmitt) ist erfolgreich durchgeführt. | Charter v1.1, M7 |
### 7.3 Definition of Done (modulbezogen)
Übernommen aus Charter v1.1 (Kap. 12). Ein einzelnes Feature bzw. Modul gilt als abgeschlossen, wenn es
- implementiert und funktionsfähig ist,
- getestet ist (mindestens ein Akzeptanztest pro Muss-Anforderung),
- ein Code-Review durchlaufen hat,
- dokumentiert ist,
- in das Gesamtsystem integriert ist.
---
## 8. Anhänge
### 8.1 Glossar
| Begriff | Bedeutung |
|---------------------|---------------------------------------------------------------------------------------------------------------------------------------|
| Angebot | Unverbindliches Preisangebot an einen Kunden |
| Auftragsbestätigung | Verbindliche Bestätigung der Auftragsannahme nach Angebot (synonym auch: Auftrag; Kurzform AB) |
| Lieferschein | Dokument, das die Auslieferung der Ware bescheinigt |
| Rechnung | Forderung nach § 14 UStG mit Steuerangaben |
| Stammdaten | Produkt- und Kundendaten (Grunddaten) |
| Bewegungsdaten | Dokumente (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) |
| Bezeichnung | Anzeigename eines Produkts (synonym: Produktname); siehe Kap. 6.1.1 |
| Artikelnummer | Anwenderseitige Produktkennung; wird, sofern nicht eingegeben, aus der Produkt-ID abgeleitet |
| Lastenheft (CRS) | Customer Requirements Specification, beschreibt aus Auftraggebersicht, was das System leisten soll |
| Pflichtenheft | Antwortdokument des Auftragnehmers, beschreibt, wie das System realisiert wird |
| V-Modell | Vorgehensmodell mit symmetrischer Zuordnung von Entwicklungs- und Testphasen |
| Traceability | Rückverfolgbarkeit von Anforderung zu Test |
| Akzeptanztest | Test, der die Erfüllung einer Anforderung aus Sicht des Auftraggebers prüft |
| Anwender | Einzige Benutzerrolle des Systems: bedient das Fakturierungssystem im Geschäftsalltag (keine Authentifizierungsrolle, siehe Kap. 1.3) |
### 8.2 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|-----------|------------------------------------------------------|
| AB | Auftragsbestätigung |
| AK | Akzeptanzkriterium |
| AT | Akzeptanztest |
| BA | Benutzeranforderung (Lastenheft-Schablone) |
| CRS | Customer Requirements Specification (Lastenheft) |
| DoD | Definition of Done |
| DSGVO | Datenschutz-Grundverordnung |
| F | Funktionale Anforderung (Pflichtenheft-Schablone) |
| GR | Geschäftsregel |
| GUI | Graphical User Interface |
| IF | Interface (Schnittstelle) |
| KV | Kundenverwaltung |
| LS | Lieferschein |
| MwSt. | Mehrwertsteuer |
| NF | Nicht-funktional |
| NF-ARCH | Nicht-funktional, Kategorie Architektur |
| NF-MAINT | Nicht-funktional, Kategorie Wartbarkeit |
| NF-PERF | Nicht-funktional, Kategorie Performance |
| NF-SEC | Nicht-funktional, Kategorie Security |
| NF-TEST | Nicht-funktional, Kategorie Testbarkeit |
| NF-USE | Nicht-funktional, Kategorie Usability |
| NF-VER | Nicht-funktional, Kategorie Versionierung |
| PV | Produktverwaltung |
| R | Rechnung |
| TH | Technische Hochschule |
| UStG | Umsatzsteuergesetz |
| USt-IdNr. | Umsatzsteuer-Identifikationsnummer |
### 8.3 Referenzen
- **[1]** `project-charter_v1_1.md` – Project Charter Fakturierungssystem, Version 1.1, 15.05.2026
- **[2]** `week6slides.pdf` – Vorlesung Software Engineering 1, Woche 6: Lastenheft und testbare Benutzeranforderungen
- **[3]** `week7slides.pdf` – Vorlesung Software Engineering 1, Woche 7: Pflichtenheft, Anforderungen und Traceability
- **[4]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen
- **[5]** DSGVO – Verordnung (EU) 2016/679
### 8.4 Traceability-Matrix (Übersicht)
Verkürzte Darstellung gemäß Vorlesung Woche 6. Die vollständige Matrix wird im Pflichtenheft bzw. Testkonzept geführt.
| Anforderung | Typ | Zugeordnete Akzeptanztests |
|-------------|----------------|----------------------------|
| BA-PV-01 | funktional | AT-PV-01, AT-PV-02 |
| BA-PV-02 | funktional | AT-PV-03, AT-PV-04 |
| BA-PV-03 | funktional | AT-PV-05, AT-PV-06 |
| BA-PV-04 | funktional | AT-PV-07, AT-PV-08 |
| BA-KV-01 | funktional | AT-KV-01, AT-KV-02 |
| BA-KV-02 | funktional | AT-KV-03, AT-KV-04 |
| BA-KV-03 | funktional | AT-KV-05, AT-KV-06 |
| BA-KV-04 | funktional | AT-KV-07, AT-KV-08 |
| BA-DP-01 | funktional | AT-DP-01 |
| BA-DP-02 | funktional | AT-DP-02 |
| BA-DP-03 | funktional | AT-DP-03 |
| BA-DP-04 | funktional | AT-DP-04 |
| BA-DP-05 | funktional | AT-DP-05 |
| BA-DP-06 | funktional | AT-DP-06 |
| BA-DP-07 | funktional | AT-DP-07 |
| BA-GUI-01 | funktional | AT-GUI-01, AT-GUI-02 |
| BA-GUI-02 | funktional | AT-GUI-03 |
| BA-GUI-03 | funktional | AT-GUI-04, AT-GUI-05 |
| BA-GUI-04 | funktional | AT-GUI-06, AT-GUI-07 |
| BA-GUI-05 | funktional | AT-GUI-08 |
| GR-01 | Geschäftsregel | AT-GR-01 |
| GR-02 | Geschäftsregel | AT-GR-02 |
| GR-03 | Geschäftsregel | AT-GR-03 |
| GR-04 | Geschäftsregel | AT-GR-04 |
| GR-05 | Geschäftsregel | AT-GR-05 |
| GR-06 | Geschäftsregel | AT-GR-06 |
| NF-USE-01 | Usability | AT-NF-01 |
| NF-USE-02 | Usability | AT-NF-02 |
| NF-USE-03 | Usability | AT-NF-03 |
| NF-PERF-01 | Performance | AT-NF-04 |
| NF-PERF-02 | Performance | AT-NF-05 |
| NF-PERF-03 | Performance | AT-NF-06 |
| NF-MAINT-01 | Wartbarkeit | AT-NF-07 |
| NF-MAINT-02 | Wartbarkeit | AT-NF-08 |
| NF-MAINT-03 | Wartbarkeit | AT-NF-09 |
| NF-TEST-01 | Testbarkeit | AT-NF-10 |
| NF-TEST-02 | Testbarkeit | AT-NF-11 |
| NF-TEST-03 | Testbarkeit | AT-NF-12 |
| NF-VER-01 | Versionierung | AT-NF-13 |
| NF-VER-02 | Versionierung | AT-NF-14 |
| NF-ARCH-01 | Architektur | AT-NF-15 |
| NF-ARCH-02 | Architektur | AT-NF-16 |
| NF-SEC-01 | Security | AT-NF-17 |
| NF-SEC-02 | Security | AT-NF-18 |
---

54
Unterlagen/Lastenheft/Lastenheft_v1_1.md
View File

@ -28,20 +28,20 @@ numbersections: false
## Freigabeübersicht ## Freigabeübersicht
| Rolle | Name | Datum | | Rolle | Name | Datum |
|--------------|----------------------------|-------| |--------------|----------------------------|------------|
| Ersteller | Christopher Lampert |24.06.2026| | Ersteller | Christopher Lampert | 24.06.2026 |
| Prüfer | Prof. Dr. Gerd Marmitt | | | Prüfer | Prof. Dr. Gerd Marmitt | |
| Freigebender | SE1 Team 2 (Gruppenleiter) | | | Freigebender | SE1 Team 2 (Gruppenleiter) | |
--- ---
## Dokumentenhistorie ## Dokumentenhistorie
| Version | Datum | Autor | Änderung | | Version | Datum | Autor | Änderung |
|---------|------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |---------|------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1.0 | 15.05.2026 | Christopher Lampert | Initiale Erstellung und Konsolidierung des Lastenhefts auf Basis Project Charter v1.1: Erfolgskriterien Z1–Z4 SMART; Nicht-Ziele um PDF-/E-Rechnung-Abgrenzung und Authentifizierung präzisiert; BA-PV-01 und BA-KV-01 an Datenobjekt-Pflichtattribute Kap. 6.1 angeglichen; Datenobjekte um Begriffsklärung Bezeichnung/Produktname/Artikelnummer ergänzt; neue Anforderungen BA-DP-07 (PDF-Export, fachlich) und BA-GUI-05 (PDF-Export-Schaltfläche); Modalverben in NF-Anforderungen an Prioritäten angeglichen; NF-TEST-03 Coverage-Schwelle auf 60 % angehoben; NF-MAINT-02 Akzeptanztest auf automatisierte Messung umgestellt; neuer Abschnitt 6.1.7 mit Statusübergangs-Tabelle; Begriff „Auftragsbestätigung" durchgängig verwendet; Traceability-Matrix in Kap. 8.4 entsprechend erweitert. | | 1.0 | 15.05.2026 | Christopher Lampert | Initiale Erstellung und Konsolidierung des Lastenhefts auf Basis Project Charter v1.1: Erfolgskriterien Z1–Z4 SMART; Nicht-Ziele um PDF-/E-Rechnung-Abgrenzung und Authentifizierung präzisiert; BA-PV-01 und BA-KV-01 an Datenobjekt-Pflichtattribute Kap. 6.1 angeglichen; Datenobjekte um Begriffsklärung Bezeichnung/Produktname/Artikelnummer ergänzt; neue Anforderungen BA-DP-07 (PDF-Export, fachlich) und BA-GUI-05 (PDF-Export-Schaltfläche); Modalverben in NF-Anforderungen an Prioritäten angeglichen; NF-TEST-03 Coverage-Schwelle auf 60 % angehoben; NF-MAINT-02 Akzeptanztest auf automatisierte Messung umgestellt; neuer Abschnitt 6.1.7 mit Statusübergangs-Tabelle; Begriff „Auftragsbestätigung" durchgängig verwendet; Traceability-Matrix in Kap. 8.4 entsprechend erweitert. |
| 1.1 | 25.06.2026 | Christopher Lampert | RÜberarbeitung nach Review: Freigabeübersicht um Datumsangaben ergänzt; Kap. 1.2 um eine fachliche Einleitung zur Herleitung der Projektziele erweitert; Kapitel „Begriffsklärung Lastenheft vs. Pflichtenheft“ entfernt und Kapitelstruktur angepasst; Geltungsbereich auf Zielgruppen und Leserschaft des Dokuments ausgerichtet; organisatorische Rahmenbedingungen aus dem Lastenheft entfernt (Zuordnung zum Project Charter gemäß Review-Hinweis); BA-GUI-01 lösungsneutral formuliert („Dropdown“ entfernt); BA-GUI-02 und BA-GUI-03 hinsichtlich der GUI-Darstellung abstrahiert; technische Rahmenbedingungen präzisiert; Dokumentenhistorie ergänzt sowie redaktionelle Konsistenz- und Strukturverbesserungen durchgeführt. | | 1.1 | 25.06.2026 | Christopher Lampert | RÜberarbeitung nach Review: Freigabeübersicht um Datumsangaben ergänzt; Kap. 1.2 um eine fachliche Einleitung zur Herleitung der Projektziele erweitert; Kapitel „Begriffsklärung Lastenheft vs. Pflichtenheft“ entfernt und Kapitelstruktur angepasst; Geltungsbereich auf Zielgruppen und Leserschaft des Dokuments ausgerichtet; organisatorische Rahmenbedingungen aus dem Lastenheft entfernt (Zuordnung zum Project Charter gemäß Review-Hinweis); BA-GUI-01 lösungsneutral formuliert („Dropdown“ entfernt); BA-GUI-02 und BA-GUI-03 hinsichtlich der GUI-Darstellung abstrahiert; technische Rahmenbedingungen präzisiert; Dokumentenhistorie ergänzt sowie redaktionelle Konsistenz- und Strukturverbesserungen durchgeführt. |
--- ---
@ -60,12 +60,12 @@ Ziel dieses Lastenhefts ist die Spezifikation der fachlichen Anforderungen an ei
Die fachlichen Projektziele leiten sich unmittelbar aus dem Geschäftsprozess der Fakturierung ab: Das System soll die durchgängige Bearbeitung von der Pflege der Produkt- und Kundenstammdaten über die Belegerstellung bis zur Rechnungsstellung ermöglichen. Die vier nachfolgenden Ziele (Z1–Z4) sind entlang der vier Pflichtmodule gegliedert und jeweils mit messbaren Erfolgskriterien sowie zugeordneten Akzeptanztests hinterlegt. Sie wurden aus Charter v1.1, Kapitel 4, übernommen und für das Lastenheft fachlich verfeinert: Die fachlichen Projektziele leiten sich unmittelbar aus dem Geschäftsprozess der Fakturierung ab: Das System soll die durchgängige Bearbeitung von der Pflege der Produkt- und Kundenstammdaten über die Belegerstellung bis zur Rechnungsstellung ermöglichen. Die vier nachfolgenden Ziele (Z1–Z4) sind entlang der vier Pflichtmodule gegliedert und jeweils mit messbaren Erfolgskriterien sowie zugeordneten Akzeptanztests hinterlegt. Sie wurden aus Charter v1.1, Kapitel 4, übernommen und für das Lastenheft fachlich verfeinert:
| Nr. | Ziel | Erfolgskriterium | | Nr. | Ziel | Erfolgskriterium |
|-----|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |-----|--------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Z1 | Produktverwaltung | Alle CRUD-Operationen bei bis zu 1.000 Produkten innerhalb der NF-PERF-01-Antwortzeit von 1 s; Akzeptanztests AT-PV-01 bis AT-PV-08 bestanden; Geschäftsregel GR-05 (Stammdatenschutz) eingehalten. | | Z1 | Produktverwaltung | Alle CRUD-Operationen bei bis zu 1.000 Produkten innerhalb der NF-PERF-01-Antwortzeit von 1 s; Akzeptanztests AT-PV-01 bis AT-PV-08 bestanden; Geschäftsregel GR-05 (Stammdatenschutz) eingehalten. |
| Z2 | Kundenverwaltung | CRUD bei bis zu 1.000 Kunden analog Z1; Akzeptanztests AT-KV-01 bis AT-KV-08 bestanden; DSGVO-konformes Löschen (NF-SEC-02) unter Beachtung der Aufbewahrungspflicht (GR-05) demonstrierbar. | | Z2 | Kundenverwaltung | CRUD bei bis zu 1.000 Kunden analog Z1; Akzeptanztests AT-KV-01 bis AT-KV-08 bestanden; DSGVO-konformes Löschen (NF-SEC-02) unter Beachtung der Aufbewahrungspflicht (GR-05) demonstrierbar. |
| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung an mindestens einem Beispielkunden und -produkt durchgängig demonstrierbar; Rechnung enthält alle Pflichtangaben nach § 14 UStG; Akzeptanztests AT-DP-01 bis AT-DP-07 sowie AT-GR-01 bis AT-GR-06 bestanden. | | Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung an mindestens einem Beispielkunden und -produkt durchgängig demonstrierbar; Rechnung enthält alle Pflichtangaben nach § 14 UStG; Akzeptanztests AT-DP-01 bis AT-DP-07 sowie AT-GR-01 bis AT-GR-06 bestanden. |
| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen; alle Belege über die GUI erstell- und als PDF exportierbar; NF-USE-01/02 nachgewiesen; Akzeptanztests AT-GUI-01 bis AT-GUI-08 bestanden. | | Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen; alle Belege über die GUI erstell- und als PDF exportierbar; NF-USE-01/02 nachgewiesen; Akzeptanztests AT-GUI-01 bis AT-GUI-08 bestanden. |
### 1.3 Nicht-Ziele ### 1.3 Nicht-Ziele
@ -135,9 +135,9 @@ Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieb
Im laufenden Betrieb des Systems wird folgende Benutzerrolle unterschieden: Im laufenden Betrieb des Systems wird folgende Benutzerrolle unterschieden:
| Rolle | Aufgaben | Typische Aktionen | | Rolle | Aufgaben | Typische Aktionen |
|---------------|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| |--------------|---------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten, löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; PDF exportieren | | **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten, löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; PDF exportieren |
Eine Authentifizierungs- oder Rechtekonzept-Rolle entfällt (siehe Kap. 1.3, Nicht-Ziele). Eine Authentifizierungs- oder Rechtekonzept-Rolle entfällt (siehe Kap. 1.3, Nicht-Ziele).
@ -305,19 +305,19 @@ Modalverben im Anforderungstext entsprechen der jeweiligen Priorität (Muss →
### 5.1 Usability (NF-USE) ### 5.1 Usability (NF-USE)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| |-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|-------------------------------------------------------------------------------------|
| NF-USE-01 | Das Anlegen eines neuen Kunden MUSS von einem Anwender ohne vorherige Schulung in weniger als 2 Minuten abgeschlossen werden können, wobei höchstens 1 Fehlbedienung pro 10 Testnutzenden zulässig ist. | Muss | AT-NF-01: Usability-Test mit 5 Probanden; Erfolgsquote > 90 %, Median-Zeit < 120 s.| | NF-USE-01 | Das Anlegen eines neuen Kunden MUSS von einem Anwender ohne vorherige Schulung in weniger als 2 Minuten abgeschlossen werden können, wobei höchstens 1 Fehlbedienung pro 10 Testnutzenden zulässig ist. | Muss | AT-NF-01: Usability-Test mit 5 Probanden; Erfolgsquote > 90 %, Median-Zeit < 120 s. |
| NF-USE-02 | Mindestens 80 % der Testnutzenden MÜSSEN die Aufgabe „Aus einem Angebot eine Rechnung erzeugen" im ersten Versuch ohne Hilfetext erfolgreich abschließen. | Muss | AT-NF-02: Usability-Test mit 5 Probanden; mindestens 4 von 5 erfolgreich. | | NF-USE-02 | Mindestens 80 % der Testnutzenden MÜSSEN die Aufgabe „Aus einem Angebot eine Rechnung erzeugen" im ersten Versuch ohne Hilfetext erfolgreich abschließen. | Muss | AT-NF-02: Usability-Test mit 5 Probanden; mindestens 4 von 5 erfolgreich. |
| NF-USE-03 | Das System MUSS bei jeder validierungspflichtigen Eingabe innerhalb von 1 Sekunde eine sichtbare Rückmeldung (Erfolg oder Fehler) anzeigen. | Muss | AT-NF-03: Manueller Test mit Stoppuhr; Rückmeldezeit < 1 s. | | NF-USE-03 | Das System MUSS bei jeder validierungspflichtigen Eingabe innerhalb von 1 Sekunde eine sichtbare Rückmeldung (Erfolg oder Fehler) anzeigen. | Muss | AT-NF-03: Manueller Test mit Stoppuhr; Rückmeldezeit < 1 s. |
### 5.2 Performance (NF-PERF) ### 5.2 Performance (NF-PERF)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | ID | Anforderung | Prio | Akzeptanzkriterium / Test |
|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| |------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|-------------------------------------------------------------------------|
| NF-PERF-01 | Das System MUSS jede Benutzeraktion innerhalb von 1 Sekunde mit einer sichtbaren Rückmeldung beantworten, bei einem Datenbestand von bis zu 1.000 Produkten und 1.000 Kunden. | Muss | AT-NF-04: Lasttest mit 1.000 Datensätzen je Entität; Antwortzeit < 1 s. | | NF-PERF-01 | Das System MUSS jede Benutzeraktion innerhalb von 1 Sekunde mit einer sichtbaren Rückmeldung beantworten, bei einem Datenbestand von bis zu 1.000 Produkten und 1.000 Kunden. | Muss | AT-NF-04: Lasttest mit 1.000 Datensätzen je Entität; Antwortzeit < 1 s. |
| NF-PERF-02 | Das System MUSS die Übersichtsliste von Produkten oder Kunden bei bis zu 1.000 Datensätzen innerhalb von 2 Sekunden vollständig anzeigen. | Muss | AT-NF-05: Lasttest mit 1.000 Einträgen; Anzeigedauer < 2 s. | | NF-PERF-02 | Das System MUSS die Übersichtsliste von Produkten oder Kunden bei bis zu 1.000 Datensätzen innerhalb von 2 Sekunden vollständig anzeigen. | Muss | AT-NF-05: Lasttest mit 1.000 Einträgen; Anzeigedauer < 2 s. |
| NF-PERF-03 | Das System SOLLTE den Anwendungsstart vom Aufruf bis zur bedienbaren Hauptansicht in höchstens 5 Sekunden abschließen (Referenzhardware: handelsüblicher Bürorechner). | Soll | AT-NF-06: Kaltstart auf Referenzhardware < 5 s. | | NF-PERF-03 | Das System SOLLTE den Anwendungsstart vom Aufruf bis zur bedienbaren Hauptansicht in höchstens 5 Sekunden abschließen (Referenzhardware: handelsüblicher Bürorechner). | Soll | AT-NF-06: Kaltstart auf Referenzhardware < 5 s. |
### 5.3 Wartbarkeit (NF-MAINT) ### 5.3 Wartbarkeit (NF-MAINT)

117
Unterlagen/Modultestbericht/Modultestbericht_Kundenverwaltung_v1_0.md 100644
View File

@ -0,0 +1,117 @@
---
title: "Modultestbericht – Kundenverwaltung"
subtitle: "SE1 Team 2 – Hochschule Mannheim · Modul Software Engineering 1"
author: "Christopher Lampert"
date: "26.06.2026"
lang: de-DE
geometry: "left=2.2cm,right=2.2cm,top=2cm,bottom=2cm"
fontsize: 10pt
mainfont: "Latin Modern Roman"
colorlinks: true
linkcolor: "blue"
urlcolor: "blue"
numbersections: false
header-includes:
- \setlength{\tabcolsep}{4pt}
- \renewcommand{\arraystretch}{1.12}
- \usepackage{etoolbox}
- \AtBeginEnvironment{longtable}{\small}
- \usepackage{newunicodechar}
- \newunicodechar{≥}{\ensuremath{\geq}}
- \newunicodechar{≤}{\ensuremath{\leq}}
---
# Modultestbericht – Modul Kundenverwaltung (Gruppe H)
**Modul:** Software Engineering 1
**Team / Gruppe:** SE1 Team 2 – Gruppe H (Kundenverwaltung), Package `de.hsmannheim.faktura.kunde`
**Version:** 1.0
**Stand:** 26.06.2026
**Autor / Tester:** Christopher Lampert
**Bezug:** Modultestplan (KV-Teil), Pflichtenheft v1.1, Lastenheft v1.1, Fahrplan Kundenverwaltung v1.1
Dieser Bericht dokumentiert die Durchführung und das Ergebnis der Modultests des Moduls **Kundenverwaltung**. Er weist nach, dass die im Modultestplan definierten Testfälle MT-KV-01 bis MT-KV-11 umgesetzt, ausgeführt und bestanden wurden, und belegt die geforderte Testabdeckung der Logikschicht (NF-TEST-03).
---
## Freigabeübersicht
| Funktion | Name | Rolle / Gruppe | Datum |
|--------------|----------------------------|------------------------------------|------------|
| Ersteller | Christopher Lampert | Autor / Tester, Gruppe H | 26.06.2026 |
| Prüfer | Oleg Akimenko | Gruppenleiter Gruppe H | _(offen)_ |
| Freigebender | SE1 Team 2 (Gruppenleiter) | Projektleitung / Freigabe | _(offen)_ |
---
## 1. Testgegenstand und Vorgehen
Geprüft wird die fachliche Logik der Kundenverwaltung – die Anforderungen **F-KV-01 … F-KV-04**, die Geschäftsregel **GR-05** (Stammdatenschutz / Löschsperre) und **NF-ARCH-01** (Persistenz) – über die öffentliche Schnittstelle des `KundeService`.
Die Tests sind als automatisierte JUnit-5-Tests **ohne GUI-Abhängigkeit** umgesetzt (NF-TEST-02) und in der Datei `KundeModultestTest.java` zusammengefasst. Jeder Testfall bildet **genau einen** Modultestplan-Fall ab (1:1) und trägt dessen Bezeichnung als `@DisplayName`, sodass das Testprotokoll unmittelbar aus dem Testlauf hervorgeht. Die Validierungs- und Persistenzschicht wird dabei real durchlaufen (echtes `KundeValidator`- und JSON-`KundeRepository`-Objekt je Test über `@TempDir`); lediglich die Beleg-Referenzprüfung der Löschsperre (GR-05) wird über das Interface `BelegReferenzPruefer` gesteuert. Die Ausführung erfolgt reproduzierbar über Maven (`mvn test`) bzw. den IntelliJ-Testrunner.
## 2. Testumgebung
| Aspekt | Festlegung |
|-------------------------------------|------------------------------------------------------------------------------|
| Programmiersprache | Java 17 (LTS); `maven.compiler.release=17` |
| Test-Framework | JUnit 5 (Jupiter) 5.10.2 |
| Build / Ausführung | Maven, `maven-surefire-plugin` 3.2.5 |
| Persistenz (im Test real genutzt) | Jackson Databind 2.17.1; lokale JSON-Datei je Test (`@TempDir`) |
| Abdeckungsmessung | IntelliJ IDEA Coverage Runner |
| Testdatei | `src/test/java/de/hsmannheim/faktura/kunde/service/KundeModultestTest.java` |
## 3. Testergebnisse
Alle elf Modultests wurden am **26.06.2026** ausgeführt und **bestanden**.
| Testfall | Testziel / Beschreibung | Anforderung | Ergebnis | Datum | Tester |
|----------|---------------------------------------------------|----------------------|-----------|------------|------------|
| MT-KV-01 | Kunde mit vollständigen Pflichtattributen anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-02 | Kunde ohne Firmenname bzw. Nachname anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-03 | Kunde ohne Straße anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-04 | Kunde mit ungültigem E-Mail-Format anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-05 | Vorhandenen Kunden bearbeiten | BA-KV-02 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-06 | Persistenz geänderter Kundendaten prüfen | BA-KV-02, NF-ARCH-01 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-07 | Kunde über Namen suchen | BA-KV-03 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-08 | Kunde über Kundennummer suchen | BA-KV-03 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-09 | Nicht vorhandenen Kunden suchen | BA-KV-03 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-10 | Nicht referenzierten Kunden löschen | BA-KV-04 | bestanden | 26.06.2026 | C. Lampert |
| MT-KV-11 | Referenzierten Kunden löschen | BA-KV-04, GR-05 | bestanden | 26.06.2026 | C. Lampert |
**Zusammenfassung:** 11 von 11 Testfällen bestanden (Pass-Quote 100 %); 0 fehlgeschlagen; 0 übersprungen.
## 4. Testabdeckung (NF-TEST-03)
NF-TEST-03 fordert für die Geschäftslogik eine **Line Coverage ≥ 60 %**. Gemessene Abdeckung der Logikschicht (`de.hsmannheim.faktura.kunde.service`) durch `KundeModultestTest`:
| Geltungsbereich | Klassen | Methoden | Zeilen (Line) | Branches |
|------------------------------------------|--------------|----------------|-----------------|-----------------|
| Logikschicht (`…kunde.service`) | 100 % (4/4) | 100 % (13/13) | 85 % (41/48) | 73 % (25/34) |
Mit **85 % Line Coverage** der Geschäftslogik bei **100 % abgedeckten Methoden** ist die geforderte Schwelle von 60 % deutlich übertroffen. **NF-TEST-03 ist erfüllt.**
## 5. Abdeckungsübersicht (Anforderung → Testfälle)
Übernommen aus dem Modultestplan (KV-Teil). Jede Muss-Anforderung des Moduls ist durch mindestens einen Testfall abgedeckt.
| Anforderung | Abgedeckte Testfälle |
|---------------------------|-----------------------|
| BA-KV-01 Kunde anlegen | MT-KV-01 bis MT-KV-04 |
| BA-KV-02 Kunde bearbeiten | MT-KV-05, MT-KV-06 |
| BA-KV-03 Kunde suchen | MT-KV-07 bis MT-KV-09 |
| BA-KV-04 Kunde löschen | MT-KV-10, MT-KV-11 |
| GR-05 Stammdatenschutz | MT-KV-11 |
| NF-ARCH-01 Persistenz | MT-KV-06 |
## 6. Fazit
Die fachlichen Anforderungen des Moduls Kundenverwaltung sind durch die Modultests MT-KV-01 bis MT-KV-11 vollständig abgedeckt und nachweislich erfüllt. Alle Tests bestehen (Pass-Quote 100 %), und die geforderte Testabdeckung der Logikschicht ist mit 85 % Line Coverage erreicht (NF-TEST-03). Die Traceability-Kette **BA-KV-0x → F-KV-0x → MT-KV-xx** ist über Modultestplan und diesen Bericht lückenlos belegbar.
---
## Änderungshistorie
| Version | Datum | Autor | Änderung |
|---------|------------|---------------------|---------------------------------------------------------------------------------------------------------------------------|
| 1.0 | 26.06.2026 | Christopher Lampert | Initiale Erstellung des Modultestberichts: Testergebnisse MT-KV-01…11, Coverage-Nachweis (NF-TEST-03), Abdeckungsübersicht. |

1130
Unterlagen/Pflichtenheft-GruppeH/Pflichtenheft_v1_1.md 100644
View File

File diff suppressed because it is too large Load Diff