12.05.2026 13:25 : v1.1 Project Charter und v1.0 Lasteheft
christopherlampert
parent
042dd86904
commit
594ab15861
|
|
@ -0,0 +1,490 @@
|
||||||
|
# Lastenheft – Fakturierungssystem
|
||||||
|
|
||||||
|
**Modul:** Software Engineering 1
|
||||||
|
**Team:** SE1 Team 2 – Hochschule Mannheim
|
||||||
|
**Version:** 1.0
|
||||||
|
**Stand:** 12.05.2026
|
||||||
|
**Autor:** Christopher Lampert
|
||||||
|
**Bezug:** Project Charter v1.1 (05.05.2026) – Fakturierungssystem
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Freigabeübersicht
|
||||||
|
|
||||||
|
| Ersteller | Prüfer | Freigebender |
|
||||||
|
|---|---|---|
|
||||||
|
| Christopher Lampert | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) |
|
||||||
|
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
||||||
|
| 12.05.2026 | 15.05.2026 | 15.05.2026 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dokumentenhistorie
|
||||||
|
|
||||||
|
| Version | Datum | Autor | Änderung |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 1.0 | 12.05.2026 | Christopher Lampert | Initiale Erstellung des Lastenhefts auf Basis Project Charter v1.1 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Einleitung und Zielbestimmung
|
||||||
|
|
||||||
|
### 1.1 Zweck dieses Dokuments
|
||||||
|
|
||||||
|
Ziel dieses Lastenhefts ist die Spezifikation der fachlichen Anforderungen an ein **Fakturierungssystem** für kleine Unternehmen. Das Dokument beschreibt aus Sicht des Auftraggebers, **was** das System leisten soll, und bildet die Grundlage für:
|
||||||
|
|
||||||
|
- die Systemarchitektur und das Pflichtenheft,
|
||||||
|
- die Projektplanung im V-Modell,
|
||||||
|
- die Akzeptanztests bei der Abnahme.
|
||||||
|
|
||||||
|
Das Lastenheft ist – soweit möglich – technologie- und lösungsneutral formuliert. Der konkrete Technologie-Stack ist im separaten Dokument `Technologiestack.md` dokumentiert und wird im Architekturdokument fortgeschrieben.
|
||||||
|
|
||||||
|
### 1.2 Projektziele
|
||||||
|
|
||||||
|
Übernommen und verfeinert aus Charter v1.1, Kapitel 4:
|
||||||
|
|
||||||
|
| Nr. | Ziel | Erfolgskriterium |
|
||||||
|
|---|---|---|
|
||||||
|
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden |
|
||||||
|
| Z2 | Kundenverwaltung | Kundendaten sind vollständig anlegbar, änderbar, löschbar und auffindbar |
|
||||||
|
| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung wird unterstützt |
|
||||||
|
| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen |
|
||||||
|
|
||||||
|
### 1.3 Nicht-Ziele
|
||||||
|
|
||||||
|
Folgende Funktionen sind **explizit nicht** Bestandteil dieses Projekts (Charter v1.1, 4.1):
|
||||||
|
|
||||||
|
- Mobile Anwendung
|
||||||
|
- Cloud-System / Multi-Tenant-Betrieb
|
||||||
|
- Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk)
|
||||||
|
- Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export)
|
||||||
|
- E-Rechnung (XRechnung, ZUGFeRD)
|
||||||
|
- Anbindung an externe Buchhaltungs- oder ERP-Systeme
|
||||||
|
- Mehrsprachigkeit (das System wird ausschließlich in deutscher Sprache realisiert)
|
||||||
|
|
||||||
|
### 1.4 Begriffsklärung: Lastenheft vs. Pflichtenheft
|
||||||
|
|
||||||
|
| Aspekt | Lastenheft (dieses Dokument) | Pflichtenheft (Folgedokument) |
|
||||||
|
|---|---|---|
|
||||||
|
| Sichtweise | Auftraggeber (Fachseite) | Auftragnehmer (Entwicklungsteam) |
|
||||||
|
| Frage | **Was** soll das System leisten? | **Wie** wird es umgesetzt? |
|
||||||
|
| Inhalt | Ziele, Einsatzkontext, fachliche Anforderungen | Architektur, Technologie, Detaildesign |
|
||||||
|
| Lösungsneutralität | Ja | Nein |
|
||||||
|
| Rolle im V-Modell | Eingabe für Anforderungen + Basis für Abnahmetests | Eingabe für Systemtests |
|
||||||
|
|
||||||
|
### 1.5 Geltungsbereich
|
||||||
|
|
||||||
|
Das Lastenheft umfasst alle Anforderungen an die vier Pflichtmodule **Produktverwaltung, Kundenverwaltung, Dokumentenprozess und Programmoberfläche (GUI)** sowie deren Zusammenspiel. Außerhalb des Geltungsbereichs liegen die unter 1.3 genannten Nicht-Ziele.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Systemkontext und Rahmenbedingungen
|
||||||
|
|
||||||
|
### 2.1 Einsatzkontext
|
||||||
|
|
||||||
|
Das Fakturierungssystem wird als **lokal installierte Einbenutzer-Anwendung** auf einem PC-Arbeitsplatz eines kleinen Unternehmens betrieben. Es unterstützt den vollständigen Geschäftsprozess von der Angebotserstellung bis zur Rechnungsstellung.
|
||||||
|
|
||||||
|
**Typischer Nutzungsablauf:**
|
||||||
|
|
||||||
|
1. Anwender pflegt Produkt- und Kundenstammdaten.
|
||||||
|
2. Anwender erstellt ein Angebot auf Basis dieser Stammdaten.
|
||||||
|
3. Bei Auftragsannahme wird das Angebot zur Auftragsbestätigung weiterverarbeitet.
|
||||||
|
4. Nach Lieferung wird aus der Auftragsbestätigung ein Lieferschein erzeugt.
|
||||||
|
5. Abschließend wird aus dem Lieferschein eine Rechnung erstellt.
|
||||||
|
|
||||||
|
### 2.2 Schnittstellen zur Umgebung
|
||||||
|
|
||||||
|
Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieben wird, beschränken sich die Schnittstellen auf:
|
||||||
|
|
||||||
|
| Schnittstelle | Zweck | Art |
|
||||||
|
|---|---|---|
|
||||||
|
| Benutzerschnittstelle (GUI) | Interaktion mit dem Anwender | UI |
|
||||||
|
| Lokales Dateisystem | Persistierung der Daten (Stammdaten, Dokumente) | Datei-Schnittstelle |
|
||||||
|
| Druck-/Export-Schnittstelle | Erzeugung druckbarer Dokumente (z. B. PDF) | Ausgabeschnittstelle |
|
||||||
|
|
||||||
|
### 2.3 Organisatorische Rahmenbedingungen
|
||||||
|
|
||||||
|
- **Projektlaufzeit:** 15.04.2026 – 30.06.2026 (Charter v1.1, Kap. 10)
|
||||||
|
- **Teamgröße:** 11 Personen, organisiert in vier Untergruppen E, F, G, H
|
||||||
|
- **Zeit pro Person:** 2–3 Stunden pro Woche
|
||||||
|
- **Vorgehensmodell:** V-Modell
|
||||||
|
- **Budget:** kein finanzielles Budget
|
||||||
|
- **Kommunikation:** Discord/WhatsApp (täglich), Gitty (kontinuierlich), wöchentliche Meetings, E-Mail an Betreuer bei Bedarf
|
||||||
|
|
||||||
|
### 2.4 Rechtliche Rahmenbedingungen
|
||||||
|
|
||||||
|
- Rechnungen müssen die gesetzlichen Pflichtangaben nach **§ 14 Abs. 4 UStG** enthalten (vollständiger Name und Anschrift von Leistungserbringer und -empfänger, Steuernummer/USt-IdNr., Ausstellungsdatum, fortlaufende Rechnungsnummer, Menge und Art der Leistung, Liefer-/Leistungsdatum, Entgelt und Steuersatz).
|
||||||
|
- Personenbezogene Kundendaten unterliegen der **DSGVO** (Datenminimierung, Auskunfts- und Löschrecht).
|
||||||
|
|
||||||
|
*Hinweis: Eine abschließende rechtliche Prüfung ist mit dem Auftraggeber abzustimmen (siehe Handlungspunkte).*
|
||||||
|
|
||||||
|
### 2.5 Technische Rahmenbedingungen
|
||||||
|
|
||||||
|
- Das System wird **lokal** ausgeführt (keine zwingende Internetverbindung erforderlich).
|
||||||
|
- Die konkrete Technologieauswahl ist in `Technologiestack.md` dokumentiert.
|
||||||
|
- Daten werden persistent gespeichert, sodass sie nach einem Neustart der Anwendung verlustfrei verfügbar sind.
|
||||||
|
- Versionierung der Quellcode-Artefakte erfolgt über **Gitty** (Charter v1.1, Kap. 10).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Stakeholder und Benutzergruppen
|
||||||
|
|
||||||
|
### 3.1 Stakeholder
|
||||||
|
|
||||||
|
Übernommen aus Charter v1.1, Kap. 6.1:
|
||||||
|
|
||||||
|
| ID | Stakeholder | Beschreibung | Interesse |
|
||||||
|
|---|---|---|---|
|
||||||
|
| S1 | Auftraggeber | Prof. Dr. Gerd Marmitt | Lehrziele erreicht, Abnahmekriterien erfüllt |
|
||||||
|
| S2 | Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) | Erfolgreiche Umsetzung, Lernzielerreichung |
|
||||||
|
| S3 | Endnutzer | spätere Anwender (kleines Unternehmen) | Funktionierender Fakturierungsablauf |
|
||||||
|
|
||||||
|
### 3.2 Benutzerrollen
|
||||||
|
|
||||||
|
Im laufenden Betrieb des Systems werden folgende Benutzerrollen unterschieden:
|
||||||
|
|
||||||
|
| Rolle | Aufgaben | Typische Aktionen |
|
||||||
|
|---|---|---|
|
||||||
|
| **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten und löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; Dokumente exportieren und drucken |
|
||||||
|
|
||||||
|
### 3.3 Teamstruktur (Verantwortlichkeiten für die Umsetzung)
|
||||||
|
|
||||||
|
Verweis auf Charter v1.1, Kap. 6.2:
|
||||||
|
|
||||||
|
| Gruppe | Verantwortungsbereich | Bezug zu Kapitel |
|
||||||
|
|---|---|---|
|
||||||
|
| Gruppe E | Programmoberfläche (GUI) | 4.4 |
|
||||||
|
| Gruppe F | Dokumentenprozess | 4.3 |
|
||||||
|
| Gruppe G | Produktverwaltung | 4.1 |
|
||||||
|
| Gruppe H | Kundenverwaltung | 4.2 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Fachliche Anforderungen (Funktionale Anforderungen)
|
||||||
|
|
||||||
|
Alle Anforderungen folgen einer der drei in den Vorlesungsfolien definierten Satzschablonen:
|
||||||
|
|
||||||
|
- **F-`<Nummer>`** Grundschablone funktional
|
||||||
|
- **BA-`<Nummer>`** Benutzeranforderung
|
||||||
|
- **GR-`<Nummer>`** Geschäftsregel (Kap. 6)
|
||||||
|
- **NF-`<Kategorie>`-`<Nummer>`** Nicht-funktional (Kap. 5)
|
||||||
|
|
||||||
|
Priorität: **Muss** = Pflicht für die Abnahme, **Soll** = wichtig, aber verzichtbar, **Kann** = optional / Erweiterung.
|
||||||
|
|
||||||
|
### 4.1 Modul Produktverwaltung (Gruppe G)
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---|
|
||||||
|
| F-PV-01 | Das System MUSS dem Anwender ERMÖGLICHEN, einen neuen Produktdatensatz mit den Pflichtfeldern Produkt-ID, Bezeichnung, Einzelpreis (netto) und Mehrwertsteuersatz anzulegen. | Muss | AT-PV-01: Nach Eingabe der Pflichtfelder und Bestätigung wird ein Datensatz mit eindeutiger Produkt-ID gespeichert und in der Produktliste angezeigt. |
|
||||||
|
| F-PV-02 | Das System MUSS dem Anwender ERMÖGLICHEN, einen bestehenden Produktdatensatz auszuwählen und seine Attribute (außer der Produkt-ID) zu bearbeiten und zu speichern. | Muss | AT-PV-02: Nach Speichern enthält der ausgewählte Datensatz die geänderten Werte; eine erneute Anzeige bestätigt die Persistierung. |
|
||||||
|
| F-PV-03 | Das System MUSS dem Anwender ERMÖGLICHEN, einen Produktdatensatz zu löschen, sofern dieser nicht in einem aktiven Angebot, Auftrag, Lieferschein oder einer Rechnung referenziert wird. | Muss | AT-PV-03: Löschen eines unreferenzierten Produkts entfernt es aus der Produktliste. Löschen eines referenzierten Produkts wird verhindert und mit Hinweis abgewiesen. |
|
||||||
|
| F-PV-04 | Das System MUSS eine Übersichtsliste aller Produkte mit den Spalten Produkt-ID, Bezeichnung und Einzelpreis anzeigen. | Muss | AT-PV-04: Beim Aufruf der Produktverwaltung werden alle gespeicherten Produkte tabellarisch angezeigt. |
|
||||||
|
| BA-PV-05 | Als Anwender muss ich Produkte über die Bezeichnung suchen können, um sie bei der Angebotserstellung schnell zu finden. Die Anforderung gilt, wenn mindestens ein Produkt im System gespeichert ist. Die Anforderung gilt als erfüllt, wenn nach Eingabe eines Suchbegriffs alle Produkte angezeigt werden, deren Bezeichnung den Suchbegriff (Groß-/Kleinschreibung ignorierend) enthält. | Muss | AT-PV-05: Suchbegriff „Schraube" liefert alle Produkte mit „Schraube" in der Bezeichnung; bei keinem Treffer wird ein Hinweis angezeigt. |
|
||||||
|
| F-PV-06 | Das System MUSS bei der Eingabe des Einzelpreises Werte kleiner als 0 ablehnen und eine sichtbare Fehlermeldung anzeigen. | Muss | AT-PV-06: Eingabe „-1" wird abgelehnt; Eingabe „0,00" und „99,99" werden akzeptiert. |
|
||||||
|
| F-PV-07 | Das System SOLL dem Anwender ERMÖGLICHEN, ein Produkt um eine Beschreibung (Freitext, max. 500 Zeichen) zu ergänzen. | Soll | AT-PV-07: Eine Beschreibung mit bis zu 500 Zeichen wird gespeichert; bei Überschreitung wird die Eingabe abgewiesen. |
|
||||||
|
| F-PV-08 | Das System SOLL dem Anwender ERMÖGLICHEN, Produkte einer Kategorie zuzuordnen. | Soll | AT-PV-08: Ein Produkt kann genau einer Kategorie zugeordnet werden; die Kategorie ist in der Produktliste sichtbar. |
|
||||||
|
|
||||||
|
### 4.2 Modul Kundenverwaltung (Gruppe H)
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---|
|
||||||
|
| F-KV-01 | Das System MUSS dem Anwender ERMÖGLICHEN, einen neuen Kundendatensatz mit den Pflichtfeldern Kunden-ID, Firmenname / Nachname, Straße, PLZ und Ort anzulegen. | Muss | AT-KV-01: Nach Eingabe aller Pflichtfelder und Bestätigung wird der Kunde mit eindeutiger Kunden-ID gespeichert und in der Kundenliste angezeigt. |
|
||||||
|
| F-KV-02 | Das System MUSS dem Anwender ERMÖGLICHEN, einen bestehenden Kundendatensatz auszuwählen und seine Attribute (außer der Kunden-ID) zu bearbeiten und zu speichern. | Muss | AT-KV-02: Nach Speichern enthält der Datensatz die geänderten Werte; eine erneute Anzeige bestätigt die Persistierung. |
|
||||||
|
| F-KV-03 | Das System MUSS dem Anwender ERMÖGLICHEN, einen Kundendatensatz zu löschen, sofern dieser nicht in einem aktiven Dokument (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) referenziert wird. | Muss | AT-KV-03: Löschen eines unreferenzierten Kunden entfernt ihn aus der Kundenliste; Löschen eines referenzierten Kunden wird mit Hinweis abgewiesen. |
|
||||||
|
| F-KV-04 | Das System MUSS eine Übersichtsliste aller Kunden mit den Spalten Kunden-ID, Firmenname/Name, PLZ und Ort anzeigen. | Muss | AT-KV-04: Beim Aufruf der Kundenverwaltung werden alle gespeicherten Kunden tabellarisch angezeigt. |
|
||||||
|
| BA-KV-05 | Als Anwender muss ich Kunden anhand von Name oder Kunden-ID suchen können, um sie bei der Dokumenterstellung schnell auszuwählen. Die Anforderung gilt, wenn mindestens ein Kunde im System gespeichert ist. Die Anforderung gilt als erfüllt, wenn nach Eingabe eines Suchbegriffs alle Kunden angezeigt werden, deren Name oder ID den Suchbegriff (Groß-/Kleinschreibung ignorierend) enthält. | Muss | AT-KV-05: Suchbegriff „Müller" liefert alle Kunden mit „Müller" im Namen. |
|
||||||
|
| F-KV-06 | Das System MUSS das Format einer eingegebenen E-Mail-Adresse anhand des Musters `<lokal>@<domain>.<tld>` prüfen und ungültige Eingaben mit einer Fehlermeldung ablehnen. | Muss | AT-KV-06: „a@b.de" wird akzeptiert, „abc" oder „a@b" werden abgelehnt. |
|
||||||
|
| F-KV-07 | Das System SOLL dem Anwender ERMÖGLICHEN, optionale Felder Telefonnummer, E-Mail, USt-IdNr. und eine abweichende Lieferadresse pro Kunde zu pflegen. | Soll | AT-KV-07: Optionale Felder werden gespeichert; Felder dürfen leer bleiben, ohne dass eine Fehlermeldung erscheint. |
|
||||||
|
| F-KV-08 | Das System SOLL dem Anwender ERMÖGLICHEN, mehrere Ansprechpartner pro Kunde zu hinterlegen. | Soll | AT-KV-08: Zu einem Kunden können mehrere Ansprechpartner (Name, Telefon, E-Mail) gespeichert und angezeigt werden. |
|
||||||
|
|
||||||
|
### 4.3 Modul Dokumentenprozess (Gruppe F)
|
||||||
|
|
||||||
|
Der Dokumentenprozess realisiert den Kernworkflow **Angebot → Auftragsbestätigung → Lieferschein → Rechnung**. Jedes Folgedokument referenziert eindeutig sein Vorgängerdokument (siehe Geschäftsregeln Kap. 6.3).
|
||||||
|
|
||||||
|
#### 4.3.1 Angebot
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---------------------------------------------------------------------------------------------------------------------------------------------|
|
||||||
|
| BA-DP-01 | Als Anwender muss ich ein Angebot für einen ausgewählten Kunden anlegen können, um einem Interessenten ein verbindliches Preisangebot zu übermitteln. Die Anforderung gilt, wenn mindestens ein Kunde und ein Produkt im System gespeichert sind. Die Anforderung gilt als erfüllt, wenn nach Auswahl von Kunde, mindestens einer Produktposition (Produkt, Menge) und Bestätigung ein Angebot mit eindeutiger Angebotsnummer, Datum und berechneter Gesamtsumme gespeichert ist. | Muss | AT-DP-01: Angebot mit 2 Positionen wird angelegt, Angebotsnummer und Gesamtsumme (Sum Menge × Einzelpreis + USt.) werden korrekt angezeigt. |
|
||||||
|
| F-DP-02 | Das System MUSS jede Angebotsnummer fortlaufend und eindeutig vergeben. | Muss | AT-DP-02: Zwei direkt nacheinander angelegte Angebote haben aufeinanderfolgende Nummern; doppelte Nummern sind nicht möglich. |
|
||||||
|
| F-DP-03 | Das System MUSS dem Anwender ERMÖGLICHEN, ein Angebot solange zu bearbeiten, wie es noch nicht in eine Auftragsbestätigung überführt wurde. | Muss | AT-DP-03: Bearbeitung eines neuen Angebots ist möglich; nach Überführung in eine Auftragsbestätigung ist nur noch Anzeige möglich. |
|
||||||
|
|
||||||
|
#### 4.3.2 Auftragsbestätigung
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---|
|
||||||
|
| BA-DP-04 | Als Anwender muss ich aus einem bestehenden Angebot eine Auftragsbestätigung erzeugen können, um dem Kunden die Auftragsannahme verbindlich zu bestätigen. Die Anforderung gilt, wenn ein Angebot im Status „offen" vorliegt. Die Anforderung gilt als erfüllt, wenn eine Auftragsbestätigung mit eigener Auftragsnummer und Verweis auf die Angebotsnummer gespeichert ist und alle Positionen aus dem Angebot übernommen wurden. | Muss | AT-DP-04: Aus Angebot A-2026-0001 entsteht Auftragsbestätigung AB-2026-0001 mit identischen Positionen und Verweis „aus Angebot A-2026-0001". |
|
||||||
|
| F-DP-05 | Das System MUSS aus jedem Angebot maximal eine Auftragsbestätigung erzeugen lassen. | Muss | AT-DP-05: Ein zweiter Versuch, aus demselben Angebot eine Auftragsbestätigung zu erzeugen, wird mit Hinweis abgewiesen. |
|
||||||
|
|
||||||
|
#### 4.3.3 Lieferschein
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---|
|
||||||
|
| BA-DP-06 | Als Anwender muss ich aus einer bestehenden Auftragsbestätigung einen Lieferschein erzeugen können, um die Auslieferung der Ware zu dokumentieren. Die Anforderung gilt, wenn eine Auftragsbestätigung im Status „bestätigt" vorliegt. Die Anforderung gilt als erfüllt, wenn ein Lieferschein mit eigener Lieferscheinnummer, Verweis auf die Auftragsbestätigung und Lieferdatum gespeichert ist. | Muss | AT-DP-06: Aus AB-2026-0001 entsteht LS-2026-0001 mit Lieferdatum und Positionsübernahme. |
|
||||||
|
| F-DP-07 | Das System MUSS auf dem Lieferschein die Mengen und Bezeichnungen der zu liefernden Produkte, nicht aber Preise und Steuersätze anzeigen. | Muss | AT-DP-07: Generierter Lieferschein enthält Mengen + Bezeichnungen, aber keine Preisspalten. |
|
||||||
|
|
||||||
|
#### 4.3.4 Rechnung
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---|
|
||||||
|
| BA-DP-08 | Als Anwender muss ich aus einem bestehenden Lieferschein eine Rechnung erzeugen können, um die erbrachte Leistung in Rechnung zu stellen. Die Anforderung gilt, wenn ein Lieferschein im Status „geliefert" vorliegt. Die Anforderung gilt als erfüllt, wenn eine Rechnung mit eindeutiger Rechnungsnummer, Rechnungsdatum, Verweis auf den Lieferschein und vollständigen Pflichtangaben nach § 14 UStG gespeichert ist. | Muss | AT-DP-08: Aus LS-2026-0001 entsteht R-2026-0001 mit allen Pflichtangaben und korrekt berechneter Netto-, USt.- und Bruttosumme. |
|
||||||
|
| F-DP-09 | Das System MUSS jede Rechnung mit den Pflichtangaben nach § 14 Abs. 4 UStG versehen (siehe Kap. 2.4). | Muss | AT-DP-09: Automatisierte Prüfung der Rechnung gegen die § 14-UStG-Pflichtfelder-Checkliste; alle Felder sind vorhanden. |
|
||||||
|
| F-DP-10 | Das System MUSS jede Rechnungsnummer fortlaufend und lückenlos vergeben. | Muss | AT-DP-10: Drei aufeinander folgende Rechnungen haben fortlaufende, lückenlose Nummern. |
|
||||||
|
| F-DP-11 | Das System MUSS eine erzeugte Rechnung gegen Änderungen schützen (keine Bearbeitung nach Festschreibung). | Muss | AT-DP-11: Nach Erzeugung ist die Rechnung nur noch lesbar; ein Bearbeitungsversuch wird abgewiesen. |
|
||||||
|
| F-DP-12 | Das System SOLL dem Anwender ERMÖGLICHEN, jedes Dokument (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) als druckbares PDF zu exportieren. | Soll | AT-DP-12: Export erzeugt eine PDF-Datei, die in einem Standard-PDF-Viewer korrekt geöffnet werden kann. |
|
||||||
|
| F-DP-13 | Das System SOLL dem Anwender ERMÖGLICHEN, zu jedem Kunden alle zugehörigen Dokumente in einer Übersicht anzuzeigen. | Soll | AT-DP-13: Aufruf der Kundenübersicht zeigt alle Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen dieses Kunden. |
|
||||||
|
|
||||||
|
### 4.4 Modul GUI / Programmoberfläche (Gruppe E)
|
||||||
|
|
||||||
|
| ID | Anforderung (Satzschablone) | Priorität | Akzeptanzkriterium / Test |
|
||||||
|
|---|---|---|---|
|
||||||
|
| F-GUI-01 | Das System MUSS eine Hauptnavigation bereitstellen, über die der Anwender zu jedem Modul (Produktverwaltung, Kundenverwaltung, Dokumentenprozess) in maximal einem Klick gelangen kann. | Muss | AT-GUI-01: Von jedem Modul aus ist jedes andere Modul in 1 Klick erreichbar. |
|
||||||
|
| F-GUI-02 | Das System MUSS jede ungültige Eingabe in Eingabefeldern (Pflichtfeld leer, falsches Format, ungültiger Wertebereich) ablehnen und eine textliche Fehlermeldung am betroffenen Feld anzeigen. | Muss | AT-GUI-02: Pflichtfeld leer → Fehlermeldung sichtbar, Speichern wird blockiert. |
|
||||||
|
| F-GUI-03 | Das System MUSS in jedem Modul ein einheitliches Layout (gleiche Position der Hauptnavigation, gleiche Buttonbeschriftungen für „Speichern", „Abbrechen", „Löschen", „Neu") verwenden. | Muss | AT-GUI-03: Heuristische Prüfung über alle Screens: Positionen und Beschriftungen sind konsistent. |
|
||||||
|
| BA-GUI-04 | Als Anwender muss ich eine sichtbare Bestätigung erhalten, wenn ich einen Datensatz speichere oder lösche, um zu erkennen, dass die Aktion erfolgreich war. Die Anforderung gilt, wenn der Anwender eine Speichern- oder Löschen-Aktion auslöst. Die Anforderung gilt als erfüllt, wenn das System innerhalb von 1 Sekunde eine sichtbare Rückmeldung (z. B. Statusmeldung) anzeigt. | Muss | AT-GUI-04: Nach jeder Speichern-/Löschen-Aktion erscheint binnen 1 s eine Bestätigung; Lasttest mit 10 aufeinanderfolgenden Aktionen. |
|
||||||
|
| F-GUI-05 | Das System MUSS vor jeder Löschaktion eine Bestätigungsabfrage anzeigen. | Muss | AT-GUI-05: Klick auf „Löschen" öffnet einen Dialog „Wirklich löschen? (Ja/Nein)"; nur bei „Ja" wird gelöscht. |
|
||||||
|
| F-GUI-06 | Das System SOLL dem Anwender ERMÖGLICHEN, in jeder Tabellenansicht (Produkt-, Kunden-, Dokumentenliste) nach jeder Spalte aufsteigend und absteigend zu sortieren. | Soll | AT-GUI-06: Klick auf eine Spaltenüberschrift sortiert die Liste; erneuter Klick kehrt die Reihenfolge um. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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 |
|
||||||
|
|---|---|---|
|
||||||
|
| F-PV-01 … F-PV-08 | funktional | AT-PV-01 … AT-PV-08 |
|
||||||
|
| F-KV-01 … F-KV-08 | funktional | AT-KV-01 … AT-KV-08 |
|
||||||
|
| BA-DP-01 … F-DP-13 | funktional | AT-DP-01 … AT-DP-13 |
|
||||||
|
| F-GUI-01 … F-GUI-06 | funktional | AT-GUI-01 … AT-GUI-06 |
|
||||||
|
| NF-USE-01 … NF-USE-03 | nicht-funktional (Usability) | AT-NF-01 … AT-NF-03 |
|
||||||
|
| NF-PERF-01 … NF-PERF-03 | nicht-funktional (Performance) | AT-NF-04 … AT-NF-06 |
|
||||||
|
| NF-MAINT-01 … NF-MAINT-03 | nicht-funktional (Wartbarkeit) | AT-NF-07 … AT-NF-09 |
|
||||||
|
| NF-TEST-01 … NF-TEST-03 | nicht-funktional (Testbarkeit) | AT-NF-10 … AT-NF-12 |
|
||||||
|
| NF-VER-01, NF-VER-02 | nicht-funktional (Versionierung) | AT-NF-13, AT-NF-14 |
|
||||||
|
| NF-ARCH-01, NF-ARCH-02 | nicht-funktional (Architektur) | AT-NF-15, AT-NF-16 |
|
||||||
|
| NF-SEC-01, NF-SEC-02 | nicht-funktional (Sicherheit) | AT-NF-17, AT-NF-18 |
|
||||||
|
| GR-01 … GR-06 | Geschäftsregel | AT-GR-01 … AT-GR-06 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Ende des Dokuments – Lastenheft v1.0.*
|
||||||
|
|
@ -1,238 +1,238 @@
|
||||||
---
|
---
|
||||||
title: Project Charter – Fakturierungssystem
|
title: Project Charter – Fakturierungssystem
|
||||||
author: Oleg Akimenko
|
author: Oleg Akimenko
|
||||||
version: 1.0
|
version: 1.0
|
||||||
lang: de-DE
|
lang: de-DE
|
||||||
toc: true
|
toc: true
|
||||||
---
|
---
|
||||||
|
|
||||||
# Freigabeübersicht
|
# Freigabeübersicht
|
||||||
|
|
||||||
| Ersteller | Prüfer | Freigebender |
|
| Ersteller | Prüfer | Freigebender |
|
||||||
|---|---|---|
|
|---|---|---|
|
||||||
| Oleg Akimenko | Prof. Dr. Gerd Marmitt | [Wird im Team abgestimmt] |
|
| Oleg Akimenko | Prof. Dr. Gerd Marmitt | [Wird im Team abgestimmt] |
|
||||||
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
||||||
| 15.04.2026 | 15.04.2026 | 30.06.2026 |
|
| 15.04.2026 | 15.04.2026 | 30.06.2026 |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Dokumentenhistorie
|
# Dokumentenhistorie
|
||||||
|
|
||||||
| Version | Datum | Autor | Änderung |
|
| Version | Datum | Autor | Änderung |
|
||||||
|---|---|---|---|
|
|---|---|---|---|
|
||||||
| 1.0 | 15.04.2026 | Oleg Akimenko | Initiale Erstellung |
|
| 1.0 | 15.04.2026 | Oleg Akimenko | Initiale Erstellung |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Projektübersicht
|
# Projektübersicht
|
||||||
|
|
||||||
## Projektzweck
|
## Projektzweck
|
||||||
|
|
||||||
Das Ziel des Projekts ist die konzeptionelle und praktische Entwicklung eines modularen Fakturierungssystems im Rahmen des Moduls Software Engineering 1.
|
Das Ziel des Projekts ist die konzeptionelle und praktische Entwicklung eines modularen Fakturierungssystems im Rahmen des Moduls Software Engineering 1.
|
||||||
|
|
||||||
Das System bildet einen vollständigen Geschäftsprozess von der Angebotserstellung über die Auftragsbestätigung und den Lieferschein bis hin zur Rechnungserstellung ab.
|
Das System bildet einen vollständigen Geschäftsprozess von der Angebotserstellung über die Auftragsbestätigung und den Lieferschein bis hin zur Rechnungserstellung ab.
|
||||||
|
|
||||||
Dabei steht nicht nur die Implementierung im Vordergrund, sondern insbesondere die Anwendung strukturierter Softwareentwicklungsprozesse und die Umsetzung eines klassischen Vorgehensmodells.
|
Dabei steht nicht nur die Implementierung im Vordergrund, sondern insbesondere die Anwendung strukturierter Softwareentwicklungsprozesse und die Umsetzung eines klassischen Vorgehensmodells.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Projekthintergrund
|
## Projekthintergrund
|
||||||
|
|
||||||
Die Entwicklung moderner Softwaresysteme erfordert strukturierte Vorgehensmodelle, klare Anforderungen und eine saubere Trennung von Entwicklungs- und Testphasen.
|
Die Entwicklung moderner Softwaresysteme erfordert strukturierte Vorgehensmodelle, klare Anforderungen und eine saubere Trennung von Entwicklungs- und Testphasen.
|
||||||
|
|
||||||
Im Rahmen des Moduls Software Engineering 1 wird ein praxisnahes Projekt durchgeführt, das die Anwendung klassischer Entwicklungsprozesse im Team ermöglicht.
|
Im Rahmen des Moduls Software Engineering 1 wird ein praxisnahes Projekt durchgeführt, das die Anwendung klassischer Entwicklungsprozesse im Team ermöglicht.
|
||||||
|
|
||||||
Das Fakturierungssystem dient als realistisches Szenario, um zentrale Konzepte der Softwareentwicklung wie Anforderungsanalyse, Architekturdesign, Implementierung, Integration und Test praktisch umzusetzen.
|
Das Fakturierungssystem dient als realistisches Szenario, um zentrale Konzepte der Softwareentwicklung wie Anforderungsanalyse, Architekturdesign, Implementierung, Integration und Test praktisch umzusetzen.
|
||||||
|
|
||||||
Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell.
|
Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Projektziele
|
# Projektziele
|
||||||
|
|
||||||
| Nr. | Ziel | Erfolgskriterium |
|
| Nr. | Ziel | Erfolgskriterium |
|
||||||
|---|---|---|
|
|---|---|---|
|
||||||
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet und gelöscht werden |
|
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet und gelöscht werden |
|
||||||
| Z2 | Kundenverwaltung | Kundendaten sind vollständig verwaltbar |
|
| Z2 | Kundenverwaltung | Kundendaten sind vollständig verwaltbar |
|
||||||
| Z3 | Dokumentenworkflow | Angebot → Auftragsbestätigung → Lieferschein → Rechnung |
|
| Z3 | Dokumentenworkflow | Angebot → Auftragsbestätigung → Lieferschein → Rechnung |
|
||||||
| Z4 | GUI | Benutzerfreundliche und funktionale Oberfläche |
|
| Z4 | GUI | Benutzerfreundliche und funktionale Oberfläche |
|
||||||
|
|
||||||
## Nicht-Ziele
|
## Nicht-Ziele
|
||||||
|
|
||||||
- Mobile Anwendung
|
- Mobile Anwendung
|
||||||
- Cloud-System
|
- Cloud-System
|
||||||
- Mehrbenutzer-Online-System
|
- Mehrbenutzer-Online-System
|
||||||
- Buchhaltungssystem
|
- Buchhaltungssystem
|
||||||
- E-Rechnung
|
- E-Rechnung
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Business Case
|
# Business Case
|
||||||
|
|
||||||
- Zielgruppe: kleine Unternehmen und Lernprojekt
|
- Zielgruppe: kleine Unternehmen und Lernprojekt
|
||||||
- Nutzen: Automatisierung von Fakturierungsprozessen
|
- Nutzen: Automatisierung von Fakturierungsprozessen
|
||||||
- Problem: manuelle Rechnungsprozesse sind fehleranfällig und ineffizient
|
- Problem: manuelle Rechnungsprozesse sind fehleranfällig und ineffizient
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Stakeholder
|
# Stakeholder
|
||||||
|
|
||||||
| Rolle | Beschreibung |
|
| Rolle | Beschreibung |
|
||||||
|---|---|
|
|---|---|
|
||||||
| Auftraggeber | Prof. Dr. Gerd Marmitt |
|
| Auftraggeber | Prof. Dr. Gerd Marmitt |
|
||||||
| Entwicklungsteam | SE1 Team 2 |
|
| Entwicklungsteam | SE1 Team 2 |
|
||||||
| Endnutzer | spätere Anwender des Systems |
|
| Endnutzer | spätere Anwender des Systems |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Teamstruktur und Repositories
|
# Teamstruktur und Repositories
|
||||||
|
|
||||||
| Gruppe | Repository | Mitglieder | Verantwortungsbereich |
|
| Gruppe | Repository | Mitglieder | Verantwortungsbereich |
|
||||||
|---|---|---|---|
|
|---|---|---|---|
|
||||||
| Gruppe E | SE1_Gruppe_E | Hadil Jondi [3030438], Nicolas Seelinger [3027710]| Programmoberfläche |
|
| Gruppe E | SE1_Gruppe_E | Hadil Jondi [3030438], Nicolas Seelinger [3027710]| Programmoberfläche |
|
||||||
| Gruppe F | SE1_Gruppe_F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801]| Dokumentenprozess |
|
| Gruppe F | SE1_Gruppe_F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801]| Dokumentenprozess |
|
||||||
| Gruppe G | SE1_Gruppe_G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489]| Produktverwaltung |
|
| Gruppe G | SE1_Gruppe_G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489]| Produktverwaltung |
|
||||||
| Gruppe H | SE1_Gruppe_H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541]| Kundenverwaltung |
|
| Gruppe H | SE1_Gruppe_H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541]| Kundenverwaltung |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Funktionale Anforderungen
|
# Funktionale Anforderungen
|
||||||
|
|
||||||
- Verwaltung von Produkten
|
- Verwaltung von Produkten
|
||||||
- Verwaltung von Kunden
|
- Verwaltung von Kunden
|
||||||
- Benutzeroberfläche
|
- Benutzeroberfläche
|
||||||
- Angebotserstellung
|
- Angebotserstellung
|
||||||
- Auftragsbestätigung
|
- Auftragsbestätigung
|
||||||
- Lieferschein
|
- Lieferschein
|
||||||
- Rechnungserstellung
|
- Rechnungserstellung
|
||||||
|
|
||||||
## Nicht-funktionale Anforderungen
|
## Nicht-funktionale Anforderungen
|
||||||
|
|
||||||
- Gute Usability
|
- Gute Usability
|
||||||
- Wartbarer Code
|
- Wartbarer Code
|
||||||
- Versionierung über Git
|
- Versionierung über Git
|
||||||
- Saubere Architektur
|
- Saubere Architektur
|
||||||
- Testbarkeit der Module
|
- Testbarkeit der Module
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Vorgehensmodell
|
# Vorgehensmodell
|
||||||
|
|
||||||
Das Projekt orientiert sich am V-Modell.
|
Das Projekt orientiert sich am V-Modell.
|
||||||
|
|
||||||
- Anforderungen
|
- Anforderungen
|
||||||
- System- und Softwaredesign
|
- System- und Softwaredesign
|
||||||
- Implementierung
|
- Implementierung
|
||||||
- Integration und Test
|
- Integration und Test
|
||||||
- Abnahme
|
- Abnahme
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Zeitplan / Meilensteine (V-Modell-orientiert)
|
# Zeitplan / Meilensteine (V-Modell-orientiert)
|
||||||
|
|
||||||
Das Projekt orientiert sich am V-Modell mit Fokus auf Verifikation und Validierung.
|
Das Projekt orientiert sich am V-Modell mit Fokus auf Verifikation und Validierung.
|
||||||
Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet.
|
Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet.
|
||||||
|
|
||||||
| Nr. | Phase | Inhalt | Datum |
|
| Nr. | Phase | Inhalt | Datum |
|
||||||
|---|---|---|---|
|
|---|---|---|---|
|
||||||
| M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen | 15.04.2026 |
|
| M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen | 15.04.2026 |
|
||||||
| M2 | Architektur | Systemarchitektur und Schnittstellendesign | [Datum] |
|
| M2 | Architektur | Systemarchitektur und Schnittstellendesign | [Datum] |
|
||||||
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | [Datum] |
|
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | [Datum] |
|
||||||
| M4 | Implementierung | Umsetzung aller Module im Code | [Datum] |
|
| M4 | Implementierung | Umsetzung aller Module im Code | [Datum] |
|
||||||
| M5 | Integrationstest | Zusammenführung und Schnittstellentests | [Datum] |
|
| M5 | Integrationstest | Zusammenführung und Schnittstellentests | [Datum] |
|
||||||
| M6 | Systemtest | Prüfung gegen Anforderungen | [Datum] |
|
| M6 | Systemtest | Prüfung gegen Anforderungen | [Datum] |
|
||||||
| M7 | Abnahme | Präsentation und finale Abgabe | 30.06.2026 |
|
| M7 | Abnahme | Präsentation und finale Abgabe | 30.06.2026 |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Technologie-Stack
|
# Technologie-Stack
|
||||||
|
|
||||||
| Bereich | Technologie |
|
| Bereich | Technologie |
|
||||||
|---|---|
|
|---|---|
|
||||||
| Frontend | JavaFX |
|
| Frontend | JavaFX |
|
||||||
| Backend | Java |
|
| Backend | Java |
|
||||||
| Datenbank | SQLite |
|
| Datenbank | SQLite |
|
||||||
| Version Control | Gitty |
|
| Version Control | Gitty |
|
||||||
| Tools | IntelliJ, VS Code, Discord |
|
| Tools | IntelliJ, VS Code, Discord |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Risikomanagement
|
# Risikomanagement
|
||||||
|
|
||||||
| Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme |
|
| Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme |
|
||||||
|---|---|---|
|
|---|---|---|
|
||||||
| Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch |
|
| Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch |
|
||||||
| Merge-Konflikte | Mittel / Mittel | Code Reviews |
|
| Merge-Konflikte | Mittel / Mittel | Code Reviews |
|
||||||
| Integrationsprobleme | Mittel / Mittel | frühe Tests |
|
| Integrationsprobleme | Mittel / Mittel | frühe Tests |
|
||||||
| Zeitverzug | Hoch / Mittel | MVP-Fokus |
|
| Zeitverzug | Hoch / Mittel | MVP-Fokus |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Ressourcen und Rahmenbedingungen
|
# Ressourcen und Rahmenbedingungen
|
||||||
|
|
||||||
- Teamgröße: 11 Personen
|
- Teamgröße: 11 Personen
|
||||||
- Zeit pro Person: 2–3 Stunden pro Woche
|
- Zeit pro Person: 2–3 Stunden pro Woche
|
||||||
- Projektlaufzeit: 15.04.2026 – 30.06.2026
|
- Projektlaufzeit: 15.04.2026 – 30.06.2026
|
||||||
- Budget: kein Budget
|
- Budget: kein Budget
|
||||||
- Infrastruktur: Gitty, Discord, lokale Entwicklung
|
- Infrastruktur: Gitty, Discord, lokale Entwicklung
|
||||||
|
|
||||||
Rahmenbedingungen:
|
Rahmenbedingungen:
|
||||||
- Umsetzung aller Pflichtmodule
|
- Umsetzung aller Pflichtmodule
|
||||||
- saubere Repository-Struktur
|
- saubere Repository-Struktur
|
||||||
- Teamübergreifende Integration
|
- Teamübergreifende Integration
|
||||||
- dokumentierter Entwicklungsprozess
|
- dokumentierter Entwicklungsprozess
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Kommunikationswege
|
# Kommunikationswege
|
||||||
|
|
||||||
| Kanal | Zweck | Frequenz |
|
| Kanal | Zweck | Frequenz |
|
||||||
|---|---|---|
|
|---|---|---|
|
||||||
| Discord/Whatsapp
|
| Discord/Whatsapp
|
||||||
|
|
||||||
|
|
||||||
| Kommunikation | täglich |
|
| Kommunikation | täglich |
|
||||||
| Gitty | Codeverwaltung | kontinuierlich |
|
| Gitty | Codeverwaltung | kontinuierlich |
|
||||||
| Meetings | Planung | wöchentlich |
|
| Meetings | Planung | wöchentlich |
|
||||||
| E-Mail | Betreuerkontakt | bei Bedarf |
|
| E-Mail | Betreuerkontakt | bei Bedarf |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Definition of Done
|
# Definition of Done
|
||||||
|
|
||||||
Ein Feature gilt als abgeschlossen, wenn:
|
Ein Feature gilt als abgeschlossen, wenn:
|
||||||
|
|
||||||
- Implementiert und funktionsfähig
|
- Implementiert und funktionsfähig
|
||||||
- getestet
|
- getestet
|
||||||
- Code Review durchgeführt
|
- Code Review durchgeführt
|
||||||
- dokumentiert
|
- dokumentiert
|
||||||
- integriert
|
- integriert
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Abnahmekriterien
|
# Abnahmekriterien
|
||||||
|
|
||||||
- alle Pflichtmodule implementiert
|
- alle Pflichtmodule implementiert
|
||||||
- vollständiger Dokumentenprozess vorhanden
|
- vollständiger Dokumentenprozess vorhanden
|
||||||
- GUI funktionsfähig
|
- GUI funktionsfähig
|
||||||
- Tests erfolgreich
|
- Tests erfolgreich
|
||||||
- Präsentation bestanden
|
- Präsentation bestanden
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Genehmigung
|
# Genehmigung
|
||||||
|
|
||||||
| Rolle | Unterschrift | Datum |
|
| Rolle | Unterschrift | Datum |
|
||||||
|---|---|---|
|
|---|---|---|
|
||||||
| Betreuer | ______________________________ | __________ |
|
| Betreuer | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
| Teammitglied: | ______________________________ | __________ |
|
| Teammitglied: | ______________________________ | __________ |
|
||||||
Binary file not shown.
|
|
@ -0,0 +1,198 @@
|
||||||
|
# Project Charter – Fakturierungssystem
|
||||||
|
|
||||||
|
**Modul:** Software Engineering 1
|
||||||
|
**Team:** SE1 Team 2 – Hochschule Mannheim
|
||||||
|
**Version:** 1.1
|
||||||
|
**Stand:** 05.05.2026
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Freigabeübersicht
|
||||||
|
|
||||||
|
| Ersteller | Prüfer | Freigebender |
|
||||||
|
|---|---|---|
|
||||||
|
| Oleg Akimenko | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) |
|
||||||
|
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
||||||
|
| 15.04.2026 | 15.04.2026 | 30.06.2026 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Dokumentenhistorie
|
||||||
|
|
||||||
|
| Version | Datum | Autor | Änderung |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 1.0 | 15.04.2026 | Oleg Akimenko | Initiale Erstellung |
|
||||||
|
| 1.1 | 05.05.2026 | Christopher Lampert | Überarbeitung nach Review (Kapitelnummerierung, Anforderungen ins Lastenheft verschoben, Zeitplan konkretisiert, Technologie-Stack in separates Dokument ausgelagert, Gruppenleiter dokumentiert) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Projektübersicht
|
||||||
|
|
||||||
|
### 3.1 Projektzweck
|
||||||
|
|
||||||
|
Das Ziel des Projekts ist die konzeptionelle und praktische Entwicklung eines modularen Fakturierungssystems im Rahmen des Moduls Software Engineering 1.
|
||||||
|
|
||||||
|
Das System bildet einen vollständigen Geschäftsprozess von der Angebotserstellung über die Auftragsbestätigung und den Lieferschein bis hin zur Rechnungserstellung ab. Dabei steht nicht nur die Implementierung im Vordergrund, sondern insbesondere die Anwendung strukturierter Softwareentwicklungsprozesse und die Umsetzung eines klassischen Vorgehensmodells.
|
||||||
|
|
||||||
|
### 3.2 Projekthintergrund
|
||||||
|
|
||||||
|
Die Entwicklung moderner Softwaresysteme erfordert strukturierte Vorgehensmodelle, klare Anforderungen und eine saubere Trennung von Entwicklungs- und Testphasen.
|
||||||
|
|
||||||
|
Im Rahmen des Moduls Software Engineering 1 wird ein praxisnahes Projekt durchgeführt, das die Anwendung klassischer Entwicklungsprozesse im Team ermöglicht. Das Fakturierungssystem dient als realistisches Szenario, um zentrale Konzepte der Softwareentwicklung wie Anforderungsanalyse, Architekturdesign, Implementierung, Integration und Test praktisch umzusetzen.
|
||||||
|
|
||||||
|
Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Projektziele
|
||||||
|
|
||||||
|
| Nr. | Ziel | Erfolgskriterium |
|
||||||
|
|---|---|---|
|
||||||
|
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet und gelöscht werden |
|
||||||
|
| Z2 | Kundenverwaltung | Kundendaten sind vollständig verwaltbar |
|
||||||
|
| Z3 | Dokumentenworkflow | Angebot → Auftragsbestätigung → Lieferschein → Rechnung |
|
||||||
|
| Z4 | GUI | Benutzerfreundliche und funktionale Oberfläche |
|
||||||
|
|
||||||
|
### 4.1 Nicht-Ziele
|
||||||
|
|
||||||
|
- Mobile Anwendung
|
||||||
|
- Cloud-System
|
||||||
|
- Mehrbenutzer-Online-System
|
||||||
|
- Buchhaltungssystem
|
||||||
|
- E-Rechnung
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Business Case
|
||||||
|
|
||||||
|
- **Zielgruppe:** kleine Unternehmen und Lernprojekt
|
||||||
|
- **Nutzen:** Automatisierung von Fakturierungsprozessen
|
||||||
|
- **Problem:** manuelle Rechnungsprozesse sind fehleranfällig und ineffizient
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Stakeholder und Teamstruktur
|
||||||
|
|
||||||
|
### 6.1 Stakeholder
|
||||||
|
|
||||||
|
| Rolle | Beschreibung |
|
||||||
|
|---|---|
|
||||||
|
| Auftraggeber | Prof. Dr. Gerd Marmitt |
|
||||||
|
| Entwicklungsteam | SE1 Team 2 |
|
||||||
|
| Endnutzer | spätere Anwender des Systems |
|
||||||
|
|
||||||
|
### 6.2 Teamstruktur, Repositories und Gruppenleiter
|
||||||
|
|
||||||
|
Pro Untergruppe ist ein **Gruppenleiter** benannt, der die Untergruppe gegenüber dem Gesamtteam und dem Auftraggeber vertritt und das Projekt-Charter unterzeichnet.
|
||||||
|
|
||||||
|
| Gruppe | Repository | Mitglieder | Gruppenleiter | Verantwortungsbereich |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| Gruppe E | SE1_Gruppe_E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | *[zu bestimmen]* | Programmoberfläche |
|
||||||
|
| Gruppe F | SE1_Gruppe_F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801] | *[zu bestimmen]* | Dokumentenprozess |
|
||||||
|
| Gruppe G | SE1_Gruppe_G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489] | *[zu bestimmen]* | Produktverwaltung |
|
||||||
|
| Gruppe H | SE1_Gruppe_H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541] | *[zu bestimmen]* | Kundenverwaltung |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Vorgehensmodell
|
||||||
|
|
||||||
|
Das Projekt orientiert sich am **V-Modell**.
|
||||||
|
|
||||||
|
- Anforderungen
|
||||||
|
- System- und Softwaredesign
|
||||||
|
- Implementierung
|
||||||
|
- Integration und Test
|
||||||
|
- Abnahme
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Zeitplan / Meilensteine (V-Modell-orientiert)
|
||||||
|
|
||||||
|
Das Projekt orientiert sich am V-Modell mit Fokus auf Verifikation und Validierung. Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet. Das Project Charter ist ein lebendes Dokument – bei Anpassungen wird eine neue Version erstellt.
|
||||||
|
|
||||||
|
| Nr. | Phase | Inhalt | Datum |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen (Lastenheft) | 15.04.2026 – 15.05.2026 |
|
||||||
|
| M2 | Architektur | Systemarchitektur und Schnittstellendesign | 22.05.2026 |
|
||||||
|
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | 29.05.2026 |
|
||||||
|
| M4 | Implementierung | Umsetzung aller Module im Code | 12.06.2026 |
|
||||||
|
| M5 | Integrationstest | Zusammenführung und Schnittstellentests | 19.06.2026 |
|
||||||
|
| M6 | Systemtest | Prüfung gegen Anforderungen | 26.06.2026 |
|
||||||
|
| M7 | Abnahme | Präsentation und finale Abgabe | 30.06.2026 |
|
||||||
|
|
||||||
|
> **Hinweis:** Der Technologie-Stack ist in einem separaten Dokument (`Technologiestack.md`) dokumentiert und wird perspektivisch im Architekturdokument (vgl. SE2) fortgeschrieben.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Risikomanagement
|
||||||
|
|
||||||
|
| Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme |
|
||||||
|
|---|---|---|
|
||||||
|
| Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch |
|
||||||
|
| Merge-Konflikte | Mittel / Mittel | Code Reviews |
|
||||||
|
| Integrationsprobleme | Mittel / Mittel | frühe Tests |
|
||||||
|
| Zeitverzug | Hoch / Mittel | MVP-Fokus |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Ressourcen und Rahmenbedingungen
|
||||||
|
|
||||||
|
- **Teamgröße:** 11 Personen
|
||||||
|
- **Zeit pro Person:** 2–3 Stunden pro Woche
|
||||||
|
- **Projektlaufzeit:** 15.04.2026 – 30.06.2026
|
||||||
|
- **Budget:** kein Budget
|
||||||
|
- **Infrastruktur:** Gitty, Discord, lokale Entwicklung
|
||||||
|
|
||||||
|
**Rahmenbedingungen:**
|
||||||
|
|
||||||
|
- Umsetzung aller Pflichtmodule
|
||||||
|
- saubere Repository-Struktur
|
||||||
|
- teamübergreifende Integration
|
||||||
|
- dokumentierter Entwicklungsprozess
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. Kommunikationswege
|
||||||
|
|
||||||
|
| Kanal | Zweck | Frequenz |
|
||||||
|
|---|---|---|
|
||||||
|
| Discord / WhatsApp | Kommunikation | täglich |
|
||||||
|
| Gitty | Codeverwaltung | kontinuierlich |
|
||||||
|
| Meetings | Planung | wöchentlich |
|
||||||
|
| E-Mail | Betreuerkontakt | bei Bedarf |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 12. Definition of Done
|
||||||
|
|
||||||
|
Ein Feature gilt als abgeschlossen, wenn:
|
||||||
|
|
||||||
|
- implementiert und funktionsfähig
|
||||||
|
- getestet
|
||||||
|
- Code Review durchgeführt
|
||||||
|
- dokumentiert
|
||||||
|
- integriert
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 13. Abnahmekriterien
|
||||||
|
|
||||||
|
- alle Pflichtmodule implementiert
|
||||||
|
- vollständiger Dokumentenprozess vorhanden
|
||||||
|
- GUI funktionsfähig
|
||||||
|
- Tests erfolgreich
|
||||||
|
- Präsentation bestanden
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 14. Genehmigung
|
||||||
|
|
||||||
|
Je Untergruppe unterzeichnet ausschließlich der jeweilige **Gruppenleiter** (siehe Kapitel 6.2).
|
||||||
|
|
||||||
|
| Rolle | Name | Unterschrift | Datum |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Betreuer | Prof. Dr. Gerd Marmitt | ______________________________ | __________ |
|
||||||
|
| Gruppenleiter Gruppe E | *[zu bestimmen]* | ______________________________ | __________ |
|
||||||
|
| Gruppenleiter Gruppe F | *[zu bestimmen]* | ______________________________ | __________ |
|
||||||
|
| Gruppenleiter Gruppe G | *[zu bestimmen]* | ______________________________ | __________ |
|
||||||
|
| Gruppenleiter Gruppe H | *[zu bestimmen]* | ______________________________ | __________ |
|
||||||
Loading…
Reference in New Issue