SE1_Team_3/Lastenheft.md

249 lines
25 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

Software Engineering 1 | Lastenheft | Team 3 |
Frakturierungssystem
Datum: 15.05.2026 | Version: 1.0
Weiterleitung zum Git: <https://gitty.informatik.hs-mannheim.de/3028363/SE1_Team_3>
Inhalt
[1\. Einleitung und Zielbestimmung 2](#_Toc229738710)
[1.1 Zweck des Dokuments 2](#_Toc229738711)
[1.2 Projektziele 3](#_Toc229738712)
[1.3 Nicht-Ziele 3](#_Toc229738713)
[2\. Systemkontext und Rahmenbedingungen 4](#_Toc229738714)
[2.1 Einsatzkontext 4](#_Toc229738715)
[2.2 Rechtliche und Regulatorische Vorgaben 4](#_Toc229738716)
[3\. Stakeholder und Benutzergruppen 4](#_Toc229738717)
[3.1 Stakeholder 4](#_Toc229738718)
[3.2 Benutzerrollen 5](#_Toc229738719)
[4\. Fachliche Anforderungen (Funktionale Anforderungen) 5](#_Toc229738720)
[5\. Qualitätsanforderungen / Nicht-funktionale Anforderungen 6](#_Toc229738721)
[6\. Daten, Schnittstellen und Geschäftsregeln 7](#_Toc229738722)
[6.1 Datenobjekte (fachliche Sicht) 7](#_Toc229738723)
[6.2 Beziehungen zwischen Datenobjekten 8](#_Toc229738724)
[6.3 Schnittstellen 9](#_Toc229738725)
[6.4 Geschäftsregeln 9](#_Toc229738726)
[7\. Abnahmekriterien 10](#_Toc229738727)
[8\. Glossar 11](#_Toc229738728)
[8.1 Abkürzungsverzeichnis 11](#_Toc229738729)
[8.2 Begriffserklärung 11](#_Toc229738730)
Freigabeübersicht
| Autor | Freigebenden | Prüfer |
| ---------------------- | -------------- | ----------------------- |
| Khazanovych, Christian | Winkler, Louis | Prof. Dr. Marmitt, Gerd |
| Entwickler | Entwickler | Modulverantwortlicher |
| 12.05.2026 | 12.05.2026 | Datum, Unterschrift |
Dokumentenhistorie
| 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. |