25 KiB

Raw Blame History

Version	Datum	Autor	Grund der Änderung
1.0	12.05.2026	Christian Khazanovych	Initiale Erstellung des Lastenhefts und Kapitel 1-3 sowie die Ergänzung dieser
1.1	14.05.2026	Kutlu Patir, Taha Erdogan, Sarav Guli	Initiale Erstellung von Kapitel 4-5. Sowie alle anderen Gruppen Ergänzung der jeweils 2 Anforderungen
1.2	14.05.2026	Robin Senger	Initiale Erstellung von Kapitel 6 sowie Ergänzung der Daten und Schnittstellen
1.3	14.05.2026	Louis Winkler	Ergänzung der Geschäftsregeln (Kapitel 6)
1.4	14.05.2026	Meltem Bardakci	Initiale Erstellung sowie Ergänzung von Kapitel 7-8

Einleitung und Zielbestimmung

Zweck des Dokuments

Dieses Lastenheft spezifiziert die fachlichen Anforderungen an eine lokale Fakturierungsanwendung für Kleinstunternehmen und Freiberufler. Es beschreibt aus Sicht des Auftraggebers, welche Funktionalitäten das System bereitstellen muss und dient als verbindliche Basis für:

Die technische Konzeption (Pflichtenheft) und die Systemarchitektur
Die Planung und Durchführung von Akzeptanztests im Rahmen der Qualitätssicherung
Die rechtssichere Umsetzung regulatorischer Anforderungen

Projektziele

Ziele	Begründung
Bestandsmanagement	Das System muss eine persistente Speicherung und Pflege von Artikelstammdaten, Preisen und Lagerbeständen ermöglichen
Kundenstammdaten	Bereitstellung einer zentralen Datenbank zur Verwaltung von Kundeninformationen inklusive einer lückenlosen Transaktionshistorie
User Interface (UI)	Realisierung einer intuitiven und ergonomischen Benutzeroberfläche zur Minimierung der Einarbeitungszeit für Endanwender
Belegworkflow	Abbildung des vollständigen kaufmännischen Prozesses durch die systemgestützten Überführung von Angeboten in rechtskonforme Rechnungen

Nicht-Ziele

Um den Fokus auf die Kernfunktionalitäten zu wahren, werden folgende Aspekte ausdrücklich, als nicht Bestandteil des Projekts definiert:

Cloud & Konnektivität: Es erfolgt keine Implementierung von Cloud Schnittstellen oder externen Datenbank Backends. Das System operiert ausschließlich im Offline Modus.
Single-User-Limitierung: Eine Unterstützung für gleichzeitige Zugriffe im Netzwerk oder eine differenzierte Benutzerverwaltung (Rollen/Rechte) ist nicht vorgesehen.
Support: Es besteht kein Anspruch auf kommerzielle Wartung, Fehlerbehebung nach Projektabschluss oder vertraglich zugesicherte Garantien.
Buchhalterische Tiefe: Das System dien der Belegerstellung, nicht der Buchführung. Steuerrechtliche Berechnungen, Bilanzen oder eine Anbindung an das Finanzamt sich nicht Teil des Funktionsumfangs.
Mobile & Web: Die Anwendung wird rein als Desktop Lösung entwickelt. Mobile Endgeräte oder Web-Browser werden nicht unterstützt.

Systemkontext und Rahmenbedingungen

Einsatzkontext

Die Anwendung ist als unabhängiges Desktop System konzipiert, das ohne permanente Internetverbindung operiert. Der Fokus liegt auf der lokalen Verarbeitung am Einzelarbeitsplatz eines Freiberufler- oder Kleinstunternehmen.

Schnittstellen und Datenfluss:

Eingabe: Manuelle Erfassung von Stammdaten (Produkte, Preise, Kunden) sowie Transaktionsdaten durch den Anwender.
Speicherung: Die Datenhaltung erfolgt persistent auf dem lokalen Dateisystem des Nutzers, um Datenschutzvorgaben (DSGVO) durch physische Datenhoheit zu gewährleisten.
Ausgabe: Generierung kaufmännischer Dokumente (Angebote, Rechnungen), die für den Export oder Druck bereitgestellt werden.

Rechtliche und Regulatorische Vorgaben

Die Software ist darauf ausgelegt, die administrativen Hürden der Rechnungslegung zu minimieren und gleichzeitig Rechtssicherheit zu bieten.

Steuerrecht: Jede erzeugte Rechnung integriert zwingend alle Pflichtangaben gemäß § 14 UStG, darunter fortlaufende Nummern, Steuernummern und korrekte Leistungszeiträume.
Revisionssicherheit (GoBD): Das System implementiert einen Schreibschutz für finale Belege, um nachträgliche Manipulationen auszuschließen und die Integrität der Buchführung zu wahren.
Datenschutz: Durch das Prinzip der Datensparsamkeit und die rein lokale Infrastruktur wird eine unbefugte Übermittlung von Kundendaten an Dritte systemisch verhindert.

Stakeholder und Benutzergruppen

Stakeholder

ID	Stakeholder	Beschreibung
SH-01	Auftraggeber	Verzeichnis der Forderungen, Bedingungen, Ziele, Bewertung des Projekts
SH-02	Projektteam	Erfolgreiche Umsetzung des Projekts und der Ziele
SH-03	Endnutzer	Funktionierender, lokal nutzbarer Fakturierungsablauf

Benutzerrollen

Da das System explizit für den Einzelplatzbetrieb konzipiert ist, wird im operativen Kontext auf eine komplexe Hierarchie verzichtet. Stattdessen fokussiert sich die Anwendung auf eine zentrale Rolle, die den gesamten kaufmännischen Workflow abbildet

Rolle: Einzelanwender:in

Diese Rolle repräsentiert die natürliche Person (z.B. Freiberufler:in oder Inhaber:in eines Kleinstunternehmens), die das System vollumfänglich nutzt. Die Konzentration auf eine einzige Rolle stellt sicher, dass alle kaufmännischen Prozesse ohne Medienbruch in einer Hand bleiben.

Fachliche Anforderungen (Funktionale Anforderungen)

Die funktionalen Anforderungen beschreiben, welche fachlichen Funktionen der Einzelanwender mit dem System ausführen können muss. Jede Anforderung ist testbar formuliert und enthält ein konkretes Erfüllungskriterium.

ID	Priorität	Anforderung	Anforderung gilt als erfüllt
FA-01	Muss	Das System muss dem Einzelanwender ermöglichen, neue Kundendatensätze mit Name, Anschrift und Kontaktinformationen anzulegen, um Kunden für spätere Angebote und Rechnungen verwenden zu können.	Nach Eingabe und Speicherung der Kundendaten wird der Kunde dauerhaft in der Kundenübersicht angezeigt und kann für ein Dokument ausgewählt werden.
FA-02	Muss	Das System muss dem Einzelanwender ermöglichen, Produktdaten mit Bezeichnung, Preis und Bestand zu speichern, um Produkte in kaufmännischen Dokumenten verwenden zu können.	Nach dem Speichern eines Produkts erscheint dieses in der Produktübersicht und kann bei der Erstellung eines Angebots oder einer Rechnung ausgewählt werden.
FA-03	Muss	Das System muss dem Einzelanwender ermöglichen, ein Angebot für einen vorhandenen Kunden mit mindestens einer Produktposition zu erstellen, um einen Geschäftsvorgang vor der Rechnungsstellung zu dokumentieren.	Nach Auswahl eines Kunden und mindestens eines Produkts erstellt das System ein Angebot mit Positionsübersicht, Nettobetrag, Steuerbetrag und Gesamtbetrag.
FA-04	Muss	Das System muss dem Einzelanwender ermöglichen, aus einem vorhandenen Angebot eine Rechnung zu erzeugen, um den Dokumentenprozess von Angebot bis Rechnung abzubilden.	Nach Auswahl eines vorhandenen Angebots erzeugt das System eine Rechnung, übernimmt Kundendaten und Positionen und vergibt eine eindeutige Rechnungsnummer.

Qualitätsanforderungen / Nicht-funktionale Anforderungen

Die Qualitätsanforderungen beschreiben, unter welchen messbaren Bedingungen das System die fachlichen Funktionen erfüllen soll. Zusammen mit Kapitel 4 ergeben sich genau acht Anforderungen.

ID	Priorität	Anforderung	Anforderung gilt als erfüllt
Q-01	Muss	Das System soll so gestaltet sein, dass ein neuer Einzelanwender ohne technische Vorkenntnisse einen Kunden anlegen, ein Produkt erfassen und eine Rechnung erstellen kann.	Die Aufgabe kann in einem manuellen Test ohne Hilfestellung innerhalb von 10 Minuten durchgeführt werden.
Q-02	Muss	Das System soll gespeicherte Kunden-, Produkt-, Angebots- und Rechnungsdaten dauerhaft lokal erhalten.	Nach dem Schließen und erneuten Starten der Anwendung sind zuvor gespeicherte Daten weiterhin vollständig vorhanden.
Q-03	Muss	Das System soll alle Kunden- und Rechnungsdaten ausschließlich lokal speichern und keine automatische Übertragung an externe Server oder Cloud-Dienste durchführen.	Die Anwendung ist ohne Internetverbindung vollständig nutzbar und speichert Daten nur lokal.
Q-04	Muss	Das System soll final erzeugte Rechnungen gegen nachträgliche Änderungen schützen, um die Nachvollziehbarkeit kaufmännischer Dokumente zu unterstützen.	Nach dem finalen Erzeugen einer Rechnung können Rechnungsnummer, Kundendaten, Positionen und Beträge nicht mehr direkt verändert werden.

Daten, Schnittstellen und Geschäftsregeln

Datenobjekte (fachliche Sicht)

Die folgenden Datenobjekte bilden den fachlichen Kern des Systems. Eine detaillierte UML-Darstellung (Klassendiagramm, ER-Diagramm) erfolgt im Pflichtenheft.

Objekt	Kernattribute
Kunde	Kunden-ID (eindeutig, fortlaufend), Name/Firmenname, vollständige Anschrift, Steuernummer/USt-IdNr., E-Mail, Telefon
Produkt	Produkt-ID (eindeutig, fortlaufend), Bezeichnung, Netto-Einzelpreis, Mehrwertsteuersatz, optionale Beschreibung
Dokumentposition	Produktreferenz, Menge, Einzelpreis (Snapshot zum Erstellungszeitpunkt), Steuersatz (Snapshot), Positionssumme
Angebot	Angebotsnummer, Erstellungsdatum, Gültigkeitsdatum, Kundenreferenz, Positionen, Netto-/Steuer-/Bruttosumme, Status (offen / überführt / verworfen)
Auftragsbestätigung	AB-Nummer, Datum, Kundenreferenz, Referenz auf Angebot, Positionen, Netto-/Steuer-/Bruttosumme, Status
Lieferschein	Lieferscheinnummer, Lieferdatum, Kundenreferenz, Referenz auf Auftragsbestätigung, Positionen (Bezeichnung, Menge - keine Preise)
Rechnung	Rechnungsnummer (fortlaufend, lückenlos), Rechnungsdatum, Leistungsdatum, Kundenreferenz, Referenz auf Lieferschein, Positionen, Netto-/Steuer-/Bruttosumme, Zahlungsziel, Status (offen / bezahlt), alle Pflichtangaben gem. § 14 UStG

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 → Dokumentposition	1 : n

Schnittstellen

ID	Schnittstelle	Zweck
IF-01	Benutzerschnittstelle (GUI)	Interaktive Oberfläche zur Bedienung aller Module durch den Einzelanwender
IF-02	Lokales Dateisystem	Persistente Speicherung aller Stamm- und Bewegungsdaten sowie exportierter Dokumente
IF-03	Druck-/Export-Schnittstelle	Erzeugung druckbarer PDF-Dokumente (Angebot, Lieferschein, Rechnung)

Eine Anbindung an externe Dienste, Cloud-Speicher oder Buchhaltungssysteme ist ausdrücklich nicht Bestandteil des Systems (vgl. Abschnitt 1.3 Nicht-Ziele).

Geschäftsregeln

ID	Geschäftsregel
GR-01	Fortlaufende Rechnungsnummern: Jede neue Rechnung erhält automatisch die nächste freie, lückenlose Rechnungsnummer. Bereits vergebene Nummern dürfen nicht wiederverwendet werden (GoBD-konform).
GR-02	Unveränderlichkeit finaler Belege: Sobald ein Dokument den Status „versendet" bzw. „festgeschrieben" erreicht, sind inhaltliche Änderungen systemseitig gesperrt. Korrekturen erfolgen ausschließlich über neue Storno- oder Korrekturdokumente.
GR-03	Snapshot-Prinzip (Preisübernahme): Beim Hinzufügen einer Produktposition zu einem Dokument werden Einzelpreis und Steuersatz zum Zeitpunkt der Erstellung unveränderlich im Dokument gespeichert. Spätere Preisänderungen am Produkt wirken sich nicht auf bestehende Dokumente aus.
GR-04	Referenzielle Integrität: Kunden- und Produktdatensätze dürfen nicht gelöscht werden, solange sie in einem aktiven oder archivierten Dokument referenziert sind. Das System verweigert den Löschvorgang und gibt einen entsprechenden Hinweis aus.
GR-05	Dokumentenketten-Konsistenz: Ein Folgedokument (z. B. Auftragsbestätigung aus Angebot) übernimmt automatisch Kunde, Positionen und Mengen aus dem Vorgängerdokument und speichert eine eindeutige Rückreferenz. Das Vorgängerdokument wechselt dabei in den Status „überführt".
GR-06	Summenberechnung: Nettosumme = Summe (Menge × Einzelpreis); USt.-Betrag = Nettosumme × MwSt.-Satz; Bruttosumme = Nettosumme + USt.-Betrag. Die Berechnung erfolgt automatisch beim Speichern eines Dokuments.

Abnahmekriterien

ID	Bezug (Anforderung)	Abnahmekriterium	Testmethode
AK-01	Kundenverwaltung	Ein neuer Kunde kann nur gespeichert werden, wenn alle Pflichtfelder gemäß § 14 UStG ausgefüllt sind.	Manueller Test (Eingabeprüfung)
AK-02	Datenintegrität	Das Löschen eines Kunden, der bereits in einer Rechnung referenziert wird, wird systemseitig mit einer Fehlermeldung verhindert.	Negativtest (Löschversuch)
AK-03	GoBD-Konformität	Finalisierte Belege (Rechnungen) erhalten einen Schreibschutz und können nicht mehr editiert werden.	Funktionsprüfung
AK-04	Offline-Betrieb	Die Anwendung startet und funktioniert ohne vorhandene Internetverbindung; Daten werden lokal gespeichert.	Systemtest (ohne Netzwerk)
AK-05	Belegworkflow	Das System generiert aus einem bestehenden Angebot eine rechtskonforme Rechnung unter Beibehaltung der Daten.	Workflow-Test

Glossar

Abkürzungsverzeichnis

Abkürzung	Bedeutung
SH	Stakeholder
FA	Fachliche Anforderungen
Q	Qualitätsanforderungen
IF	Interface
AK	Abnahmekriterien
AB-Nummer	Auftragsbestätigung
n/m	Kardinalitäten/Multiplizitäten in den Datenbeziehungen (z.B. 1 : n)
GoBD	Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form.
UI	User Interface; die grafische Benutzeroberfläche, über die der Anwender mit dem System interagiert.
GUI	Graphical User Interface (Grafische Benutzeroberfläche)
UStG	Umsatzsteuergesetz; insbesondere § 14 regelt die Pflichtangaben auf einer Rechnung.
DSGVO	Datenschutz-Grundverordnung der Europäischen Union; regelt die Verarbeitung personenbezogener Daten.

Begriffserklärung

Begriff	Erklärung
Fakturierung	Der Prozess der Rechnungsstellung für erbrachte Leistungen oder gelieferte Waren.
Medienbruch	Ein Informationsverlust oder Mehraufwand, der entsteht, wenn Daten zwischen verschiedenen Systemen manuell übertragen werden müssen.
Revisionssicherheit	Die Eigenschaft eines Systems, Daten so zu archivieren, dass sie nachträglich nicht mehr unbemerkt verändert oder gelöscht werden können.
Stammdaten	Grundlegende Informationen über Kunden oder Produkte, die über einen längeren Zeitraum unverändert bleiben.
Stakeholder	Personen oder Gruppen, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Projekts haben.
Persistente Speicherung	Die dauerhafte Speicherung von Daten auf einem Datenträger (hier das lokale Dateisystem), sodass diese auch nach dem Beenden der Anwendung erhalten bleibt.
Snapshot-Prinzip	Ein Verfahren, bei dem Daten (wie Preise oder Steuersätze) zum Zeitpunkt einer Transaktion fest im Dokument eingefroren werden, damit spätere Änderungen an den Stammdaten das historische Dokument nicht verfälschen.
Pflichtenheft	Die technische Antwort des Entwicklers auf das Lastenheft; es beschreibt die detaillierte Umsetzung (wie z. B. die UML-Darstellung).
Bewegungsdaten	Daten, die im Gegensatz zu Stammdaten durch Geschäftsvorgänge entstehen und sich ständig ändern (z. B. Angebote, Rechnungen).
GoBD-Konformität	Die Einhaltung der Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern in elektronischer Form, insbesondere zum Schutz gegen Manipulation.

25 KiB Raw Blame History Unescape Escape