52 KiB
| title | subtitle | author | date | lang | geometry | fontsize | mainfont | colorlinks | linkcolor | urlcolor | toc | toc-depth | numbersections |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Lastenheft – Fakturierungssystem | SE1 Team 2 – Hochschule Mannheim | Christopher Lampert | 15.05.2026 | de-DE | left=2.2cm,right=2.2cm,top=2cm,bottom=2cm | 10pt | Latin Modern Roman | true | blue | blue | true | 3 | false |
Lastenheft – Fakturierungssystem
Modul: Software Engineering 1 Team: SE1 Team 2 – Hochschule Mannheim Version: 1.0 Stand: 15.05.2026 Autor: Christopher Lampert Bezug: Project Charter v1.1 (15.05.2026) – Fakturierungssystem
Freigabeübersicht
| Ersteller | Prüfer | Freigebender |
|---|---|---|
| Christopher Lampert | Prof. Dr. Gerd Marmitt | 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. 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
Übernommen und verfeinert aus Charter v1.1, Kapitel 4:
| 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 → Auftragsbestätigung → Lieferschein → 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.
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:
- Anwender pflegt Produkt- und Kundenstammdaten.
- Anwender erstellt ein Angebot auf Basis dieser Stammdaten.
- Bei Auftragsannahme wird das Angebot zur Auftragsbestätigung weiterverarbeitet.
- Nach Lieferung wird aus der Auftragsbestätigung ein Lieferschein erzeugt.
- Abschließend wird aus dem Lieferschein eine Rechnung erstellt.
- 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 Organisatorische Rahmenbedingungen
- Projektlaufzeit: 15.04.2026 – 30.06.2026
- 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 bzw. WhatsApp (täglich), Gitty (kontinuierlich), wöchentliche Meetings, E-Mail an den Auftraggeber 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 bzw. USt-IdNr., Ausstellungsdatum, fortlaufende Rechnungsnummer, Menge und Art der Leistung, Liefer- bzw. Leistungsdatum, Entgelt und Steuersatz).
- Personenbezogene Kundendaten unterliegen der DSGVO (Datenminimierung, Auskunfts- und Löschrecht).
2.5 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).
3.3 Teamstruktur
| 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 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 per Dropdown 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 farblich markiert sind, 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 durch ein grünes Icon als „Abgeschlossen" markiert 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 → Angebot | 1 : n |
| Angebot → Auftragsbestätigung | 1 : 0..1 |
| Auftragsbestätigung → Lieferschein | 1 : 0..1 |
| Lieferschein → Rechnung | 1 : 0..1 |
| Produkt → 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 → Auftragsbestätigung → Lieferschein → 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 |