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:
- 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.
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.