443 lines
25 KiB
Markdown
443 lines
25 KiB
Markdown
# Lastenheft – Fakturierungssystem
|
||
|
||
**Modul:** Software Engineering 1
|
||
**Team:** SE1 Team 2 – Hochschule Mannheim
|
||
**Version:** 1.0
|
||
**Stand:** 12.05.2026
|
||
**Autor:** Christopher Lampert
|
||
**Bezug:** Project Charter v1.1 (05.05.2026) – Fakturierungssystem
|
||
|
||
---
|
||
|
||
## Freigabeübersicht
|
||
|
||
| Ersteller | Prüfer | Freigebender |
|
||
|---|---|---|
|
||
| Christopher Lampert | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) |
|
||
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
||
| 12.05.2026 | 15.05.2026 | 15.05.2026 |
|
||
|
||
---
|
||
|
||
## Dokumentenhistorie
|
||
|
||
| Version | Datum | Autor | Änderung |
|
||
|---|---|---|---|
|
||
| 1.0 | 12.05.2026 | Christopher Lampert | Initiale Erstellung des Lastenhefts auf Basis Project Charter v1.1 |
|
||
|
||
---
|
||
|
||
## 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.
|
||
|
||
Das Lastenheft ist – soweit möglich – technologie- und lösungsneutral formuliert. Der konkrete Technologie-Stack ist im separaten Dokument `Technologiestack.md` dokumentiert und wird im Architekturdokument fortgeschrieben.
|
||
|
||
### 1.2 Projektziele
|
||
|
||
Übernommen und verfeinert aus Charter v1.1, Kapitel 4:
|
||
|
||
| Nr. | Ziel | Erfolgskriterium |
|
||
|---|---|---|
|
||
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden |
|
||
| Z2 | Kundenverwaltung | Kundendaten sind vollständig anlegbar, änderbar, löschbar und auffindbar |
|
||
| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung wird unterstützt |
|
||
| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen |
|
||
|
||
### 1.3 Nicht-Ziele
|
||
|
||
Folgende Funktionen sind **explizit nicht** Bestandteil dieses Projekts (Charter v1.1, 4.1):
|
||
|
||
- Mobile Anwendung
|
||
- Cloud-System / Multi-Tenant-Betrieb
|
||
- Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk)
|
||
- Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export)
|
||
- E-Rechnung (XRechnung, ZUGFeRD)
|
||
- Anbindung an externe Buchhaltungs- oder ERP-Systeme
|
||
- Mehrsprachigkeit (das System wird ausschließlich in deutscher Sprache realisiert)
|
||
|
||
### 1.4 Begriffsklärung: Lastenheft vs. Pflichtenheft
|
||
|
||
| Aspekt | Lastenheft (dieses Dokument) | Pflichtenheft (Folgedokument) |
|
||
|---|---|---|
|
||
| Sichtweise | Auftraggeber (Fachseite) | Auftragnehmer (Entwicklungsteam) |
|
||
| Frage | **Was** soll das System leisten? | **Wie** wird es umgesetzt? |
|
||
| Inhalt | Ziele, Einsatzkontext, fachliche Anforderungen | Architektur, Technologie, Detaildesign |
|
||
| Lösungsneutralität | Ja | Nein |
|
||
| Rolle im V-Modell | Eingabe für Anforderungen + Basis für Abnahmetests | Eingabe für Systemtests |
|
||
|
||
### 1.5 Geltungsbereich
|
||
|
||
Das Lastenheft umfasst alle Anforderungen an die vier Pflichtmodule **Produktverwaltung, Kundenverwaltung, Dokumentenprozess und Programmoberfläche (GUI)** sowie deren Zusammenspiel. Außerhalb des Geltungsbereichs liegen die unter 1.3 genannten Nicht-Ziele.
|
||
|
||
---
|
||
|
||
## 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.
|
||
|
||
### 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 |
|
||
| Druck-/Export-Schnittstelle | Erzeugung druckbarer Dokumente (z. B. PDF) | Ausgabeschnittstelle |
|
||
|
||
### 2.3 Organisatorische Rahmenbedingungen
|
||
|
||
- **Projektlaufzeit:** 15.04.2026 – 30.06.2026 (Charter v1.1, Kap. 10)
|
||
- **Teamgröße:** 11 Personen, organisiert in vier Untergruppen E, F, G, H
|
||
- **Zeit pro Person:** 2–3 Stunden pro Woche
|
||
- **Vorgehensmodell:** V-Modell
|
||
- **Budget:** kein finanzielles Budget
|
||
- **Kommunikation:** Discord/WhatsApp (täglich), Gitty (kontinuierlich), wöchentliche Meetings, E-Mail an Betreuer bei Bedarf
|
||
|
||
### 2.4 Rechtliche Rahmenbedingungen
|
||
|
||
- Rechnungen müssen die gesetzlichen Pflichtangaben nach **§ 14 Abs. 4 UStG** enthalten (vollständiger Name und Anschrift von Leistungserbringer und -empfänger, Steuernummer/USt-IdNr., Ausstellungsdatum, fortlaufende Rechnungsnummer, Menge und Art der Leistung, Liefer-/Leistungsdatum, Entgelt und Steuersatz).
|
||
- Personenbezogene Kundendaten unterliegen der **DSGVO** (Datenminimierung, Auskunfts- und Löschrecht).
|
||
|
||
*Hinweis: Eine abschließende rechtliche Prüfung ist mit dem Auftraggeber abzustimmen (siehe Handlungspunkte).*
|
||
|
||
### 2.5 Technische Rahmenbedingungen
|
||
|
||
- Das System wird **lokal** ausgeführt (keine zwingende Internetverbindung erforderlich).
|
||
- Die konkrete Technologieauswahl ist in `Technologiestack.md` dokumentiert.
|
||
- Daten werden persistent gespeichert, sodass sie nach einem Neustart der Anwendung verlustfrei verfügbar sind.
|
||
- Versionierung der Quellcode-Artefakte erfolgt über **Gitty** (Charter v1.1, Kap. 10).
|
||
|
||
---
|
||
|
||
## 3. Stakeholder und Benutzergruppen
|
||
|
||
### 3.1 Stakeholder
|
||
|
||
Übernommen aus Charter v1.1, Kap. 6.1:
|
||
|
||
| 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 werden folgende Benutzerrollen unterschieden:
|
||
|
||
| Rolle | Aufgaben | Typische Aktionen |
|
||
|---|---|---|
|
||
| **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten und löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; Dokumente exportieren und drucken |
|
||
|
||
### 3.3 Teamstruktur (Verantwortlichkeiten für die Umsetzung)
|
||
|
||
Verweis auf Charter v1.1, Kap. 6.2:
|
||
|
||
| Gruppe | Verantwortungsbereich | Bezug zu Kapitel |
|
||
|---|---|---|
|
||
| Gruppe E | Programmoberfläche (GUI) | 4.4 |
|
||
| Gruppe F | Dokumentenprozess | 4.3 |
|
||
| Gruppe G | Produktverwaltung | 4.1 |
|
||
| Gruppe H | Kundenverwaltung | 4.2 |
|
||
|
||
---
|
||
|
||
## 4. Fachliche Anforderungen (Funktionale Anforderungen)
|
||
|
||
Alle Anforderungen folgen einer der drei in den Vorlesungsfolien definierten Satzschablonen:
|
||
|
||
- **F-`<Nummer>`** Grundschablone funktional
|
||
- **BA-`<Nummer>`** Benutzeranforderung
|
||
- **GR-`<Nummer>`** Geschäftsregel (Kap. 6)
|
||
- **NF-`<Kategorie>`-`<Nummer>`** Nicht-funktional (Kap. 5)
|
||
|
||
Priorität: **Muss** = Pflicht für die Abnahme, **Soll** = wichtig, aber verzichtbar, **Kann** = optional / Erweiterung.
|
||
|
||
### 4.1 Modul Produktverwaltung (Gruppe G)
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
|
||
### 4.2 Modul Kundenverwaltung (Gruppe H)
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
|
||
### 4.3 Modul Dokumentenprozess (Gruppe F)
|
||
|
||
#### 4.3.1 Angebot
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---------------------------------------------------------------------------------------------------------------------------------------------|
|
||
|
||
#### 4.3.2 Auftragsbestätigung
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
|
||
#### 4.3.3 Lieferschein
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
|
||
#### 4.3.4 Rechnung
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
|
||
### 4.4 Modul GUI / Programmoberfläche (Gruppe E)
|
||
|
||
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
|
||
---
|
||
|
||
## 5. Qualitätsanforderungen (nicht-funktionale Anforderungen)
|
||
|
||
### 5.1 Usability (NF-USE)
|
||
|
||
| ID | Anforderung | Priorität | 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/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: Eingabe abschicken, Stoppuhr; Rückmeldezeit < 1 s. |
|
||
|
||
### 5.2 Performance (NF-PERF)
|
||
|
||
| ID | Anforderung | Priorität | 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; gemessene 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 MUSS den Anwendungsstart vom Aufruf bis zur bedienbaren Hauptansicht in höchstens 5 Sekunden abschließen (Referenzhardware: handelsüblicher Bürorechner, siehe Handlungspunkte). | Soll | AT-NF-06: Kaltstart auf Referenzhardware < 5 s. |
|
||
|
||
### 5.3 Wartbarkeit (NF-MAINT)
|
||
|
||
| ID | Anforderung | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
| NF-MAINT-01 | Der Quellcode MUSS modular nach den vier Modulen Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI getrennt sein (eigene Pakete/Verzeichnisse). | Muss | AT-NF-07: Statische Prüfung der Repository-Struktur. |
|
||
| NF-MAINT-02 | Mindestens 80 % der öffentlichen Klassen und Methoden MÜSSEN über kurze Dokumentationskommentare (Zweck, Parameter, Rückgabe) verfügen. | Soll | AT-NF-08: Statische Analyse / Stichprobe von 20 öffentlichen Methoden; > 16 dokumentiert. |
|
||
| 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 | Priorität | 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 30 % der Geschäftslogik-Methoden SOLLEN durch automatisierte Tests abgedeckt sein (Line Coverage). | Soll | AT-NF-12: Coverage-Report > 30 %. |
|
||
|
||
### 5.5 Versionierung (NF-VER)
|
||
|
||
| ID | Anforderung | Priorität | 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 in Gitty zeigt für jeden Merge mindestens einen Reviewer. |
|
||
|
||
### 5.6 Architektur und Datenhaltung (NF-ARCH)
|
||
|
||
| ID | Anforderung | Priorität | 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 beenden → neu starten → Datensätze sind unverändert vorhanden. |
|
||
| NF-ARCH-02 | Die Datenhaltung MUSS hinter einer abstrakten Schnittstelle (Repository oder DAO) gekapselt sein, sodass die konkrete Speichertechnologie austauschbar ist. | Soll | AT-NF-16: Code-Review zeigt Repository-/DAO-Abstraktion; Technologiewechsel würde nur diese Schicht betreffen. |
|
||
|
||
### 5.7 Sicherheit und Datenschutz (NF-SEC)
|
||
|
||
| ID | Anforderung | Priorität | Akzeptanzkriterium / Test |
|
||
|---|---|---|---|
|
||
| NF-SEC-01 | Das System MUSS 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 der Datendatei aus einem fremden Nutzerkontext zeigt keinen lesbaren Klartext (oder die Datei ist nicht zugreifbar). |
|
||
| NF-SEC-02 | Das System MUSS dem Anwender ERMÖGLICHEN, einen Kunden auf dessen Verlangen 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 an einen Kunden ohne aktive Rechnungen → Kunde wird entfernt; Anonymisierung bei vorhandenen Rechnungen ist möglich. |
|
||
|
||
---
|
||
|
||
## 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 / Architekturdokument ergänzt.
|
||
|
||
#### 6.1.1 Produkt
|
||
- **Identifikator:** Produkt-ID (eindeutig, fortlaufend)
|
||
- **Pflichtattribute:** Bezeichnung, Einzelpreis netto, Mehrwertsteuersatz
|
||
- **Optionale Attribute:** Beschreibung, Kategorie
|
||
|
||
#### 6.1.2 Kunde
|
||
- **Identifikator:** Kunden-ID (eindeutig, fortlaufend)
|
||
- **Pflichtattribute:** Firmenname/Nachname, Straße, PLZ, Ort
|
||
- **Optionale Attribute:** Vorname, Telefon, E-Mail, 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/brutto), Status (offen / überführt / verworfen)
|
||
|
||
#### 6.1.4 Auftragsbestätigung (Auftrag)
|
||
- **Identifikator:** Auftragsnummer (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 – falls genutzt)
|
||
|
||
### 6.2 Beziehungen zwischen Datenobjekten
|
||
|
||
| Beziehung | Multiplizität |
|
||
|---|---|
|
||
| Kunde → Angebot | 1 : n |
|
||
| Angebot → Auftragsbestätigung | 1 : 0..1 |
|
||
| Auftragsbestätigung → Lieferschein | 1 : 0..1 |
|
||
| Lieferschein → Rechnung | 1 : 0..1 |
|
||
| Produkt → Angebotsposition / Auftragsposition / Lieferscheinposition / Rechnungsposition | 1 : n |
|
||
|
||
### 6.3 Geschäftsregeln
|
||
|
||
| ID | Geschäftsregel | Akzeptanzkriterium / Test |
|
||
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|
|
||
| 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 jeweilige Vorgängerdokument im passenden Status vorliegen. | 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 aus der laufenden Sequenz; Nummern dürfen nicht wiederverwendet werden. | 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 nicht mehr inhaltlich änderbar. | 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 des Produkts in der Position festgehalten und nicht durch spätere Produktpreisänderungen verändert. | AT-GR-04: Preisänderung am Produkt verändert nicht den Preis bestehender Angebote/Aufträge. |
|
||
| GR-05 | **Stammdatenschutz:** Ein Produkt oder Kunde darf nicht gelöscht werden, solange er/es in einem Angebot, einer Auftragsbestätigung, einem Lieferschein oder einer Rechnung referenziert wird. | 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 = Nettosumme × MwSt.-Satz; Bruttosumme = Nettosumme + USt.-Betrag. | 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 (siehe NF-ARCH-01) |
|
||
| IF-03 | Druck-/Export-Schnittstelle | Erzeugung druckbarer Dokumente, vorzugsweise PDF (siehe F-DP-12) |
|
||
|
||
---
|
||
|
||
## 7. Akzeptanzkriterien und Abnahmebedingungen
|
||
|
||
### 7.1 Übernahme aus Project Charter v1.1
|
||
|
||
Aus Charter v1.1, Kap. 13, werden die folgenden Abnahmekriterien übernommen und im Folgenden verfeinert:
|
||
|
||
- alle Pflichtmodule implementiert
|
||
- vollständiger Dokumentenprozess vorhanden
|
||
- GUI funktionsfähig
|
||
- Tests erfolgreich
|
||
- Präsentation bestanden
|
||
|
||
### 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. | F-*, BA-*, NF-* (Priorität Muss) |
|
||
| AK-02 | Die vier Pflichtmodule Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI sind jeweils in ihrem Repository (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 → Auftragsbestätigung → Lieferschein → Rechnung kann anhand eines Beispielkunden und -produkts durchgängig demonstriert werden. | Kap. 4.3 |
|
||
| AK-04 | Die Traceability-Matrix (Anhang) 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 | Das Lastenheft und das Pflichtenheft / Architekturdokument liegen in der jeweils final freigegebenen Version vor. | Charter v1.1, Kap. 8 (M1, M2) |
|
||
| 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/Modul gilt als abgeschlossen, wenn:
|
||
|
||
- implementiert und funktionsfähig,
|
||
- getestet (mindestens ein Akzeptanztest pro Muss-Anforderung),
|
||
- Code-Review durchgeführt,
|
||
- dokumentiert,
|
||
- in das Gesamtsystem integriert.
|
||
|
||
---
|
||
|
||
## 8. Anhänge
|
||
|
||
### 8.1 Glossar
|
||
|
||
| Begriff | Bedeutung |
|
||
|---|---|
|
||
| **Angebot** | Unverbindliches Preisangebot an einen Kunden |
|
||
| **Auftragsbestätigung** | Verbindliche Bestätigung der Auftragsannahme nach Angebot |
|
||
| **Lieferschein** | Dokument, das die Auslieferung der Ware bescheinigt |
|
||
| **Rechnung** | Forderung nach § 14 UStG mit Steuerangaben |
|
||
| **Stammdaten** | Produkt- und Kundendaten (Grunddaten) |
|
||
| **Bewegungsdaten** | Dokumente (Angebot, Auftrag, Lieferschein, Rechnung) |
|
||
| **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 (Stammdaten pflegen, Dokumente erzeugen) |
|
||
|
||
### 8.2 Abkürzungsverzeichnis
|
||
|
||
| Abkürzung | Bedeutung |
|
||
|---|---|
|
||
| AB | Auftragsbestätigung |
|
||
| AK | Akzeptanzkriterium |
|
||
| AT | Akzeptanztest |
|
||
| BA | Benutzeranforderung |
|
||
| CRS | Customer Requirements Specification (Lastenheft) |
|
||
| DoD | Definition of Done |
|
||
| DSGVO | Datenschutz-Grundverordnung |
|
||
| F | Funktionale Anforderung |
|
||
| 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 (Maintainability) |
|
||
| 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]** `ProjectCharter_v1.1.md` – Project Charter Fakturierungssystem, Version 1.1, 05.05.2026
|
||
- **[2]** `projectcharter.pdf` – Project Charter Fakturierungssystem, Version 1.0 (Erstfassung)
|
||
- **[3]** `week6slides.pdf` – Vorlesung Software Engineering 1, Woche 6: Lastenheft und testbare Benutzeranforderungen, Prof. Dr. Gerd Marmitt
|
||
- **[4]** `week7slides.pdf` – Vorlesung Software Engineering 1, Woche 7: Pflichtenheft, Anforderungen und Traceability, Prof. Dr. Gerd Marmitt
|
||
- **[5]** `Technologiestack.md` – separates Dokument zum verwendeten Technologie-Stack (nur am Rand relevant, da Lastenheft lösungsneutral)
|
||
- **[6]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen
|
||
- **[7]** DSGVO – Verordnung (EU) 2016/679
|
||
|
||
### 8.4 Traceability-Matrix (Übersicht)
|
||
|
||
Verkürzte Darstellung gemäß Folie „Traceability-Matrix" (Woche 6, S. 34). Eine vollständige Matrix wird im Pflichtenheft / Testkonzept geführt.
|
||
|
||
| Anforderung | Typ | Zugeordneter Akzeptanztest |
|
||
|---|---|---|
|
||
|
||
|
||
---
|
||
|
||
*Ende des Dokuments – Lastenheft v1.0.*
|