diff --git a/Lastenheft/Lastenheft_v1_0.md b/Lastenheft/Lastenheft_v1_0.md index d4ee273..72d126e 100644 --- a/Lastenheft/Lastenheft_v1_0.md +++ b/Lastenheft/Lastenheft_v1_0.md @@ -2,7 +2,7 @@ title: "Lastenheft – Fakturierungssystem" subtitle: "SE1 Team 2 – Hochschule Mannheim" author: "Christopher Lampert" -date: "14.05.2026" +date: "15.05.2026" lang: de-DE geometry: "left=2.2cm,right=2.2cm,top=2cm,bottom=2cm" fontsize: 10pt @@ -20,9 +20,9 @@ numbersections: false **Modul:** Software Engineering 1 **Team:** SE1 Team 2 – Hochschule Mannheim **Version:** 1.0 -**Stand:** 14.05.2026 +**Stand:** 15.05.2026 **Autor:** Christopher Lampert -**Bezug:** Project Charter v1.1 (14.05.2026) – Fakturierungssystem +**Bezug:** Project Charter v1.1 (15.05.2026) – Fakturierungssystem --- @@ -36,9 +36,9 @@ numbersections: false ## Dokumentenhistorie -| Version | Datum | Autor | Änderung | -|---------|------------|---------------------|-----------------------------------------------------------------------------------------------------------| -| 1.0 | 12.05.2026 | Christopher Lampert | Initiale Erstellung des Lastenhefts auf Basis Project Charter v1.1 | +| Version | Datum | Autor | Änderung | +|---------|------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 1.0 | 15.05.2026 | Christopher Lampert | Initiale Erstellung und Konsolidierung des Lastenhefts auf Basis Project Charter v1.1: Erfolgskriterien Z1–Z4 SMART; Nicht-Ziele um PDF-/E-Rechnung-Abgrenzung und Authentifizierung präzisiert; BA-PV-01 und BA-KV-01 an Datenobjekt-Pflichtattribute Kap. 6.1 angeglichen; Datenobjekte um Begriffsklärung Bezeichnung/Produktname/Artikelnummer ergänzt; neue Anforderungen BA-DP-07 (PDF-Export, fachlich) und BA-GUI-05 (PDF-Export-Schaltfläche); Modalverben in NF-Anforderungen an Prioritäten angeglichen; NF-TEST-03 Coverage-Schwelle auf 60 % angehoben; NF-MAINT-02 Akzeptanztest auf automatisierte Messung umgestellt; neuer Abschnitt 6.1.7 mit Statusübergangs-Tabelle; Begriff „Auftragsbestätigung" durchgängig verwendet; Traceability-Matrix in Kap. 8.4 entsprechend erweitert. | --- @@ -52,18 +52,17 @@ Ziel dieses Lastenhefts ist die Spezifikation der fachlichen Anforderungen an ei - 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.2, Kapitel 4: +Ü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 | +| Nr. | Ziel | Erfolgskriterium | +|-----|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Z1 | Produktverwaltung | Alle CRUD-Operationen bei bis zu 1.000 Produkten innerhalb der NF-PERF-01-Antwortzeit von 1 s; Akzeptanztests AT-PV-01 bis AT-PV-08 bestanden; Geschäftsregel GR-05 (Stammdatenschutz) eingehalten. | +| Z2 | Kundenverwaltung | CRUD bei bis zu 1.000 Kunden analog Z1; Akzeptanztests AT-KV-01 bis AT-KV-08 bestanden; DSGVO-konformes Löschen (NF-SEC-02) unter Beachtung der Aufbewahrungspflicht (GR-05) demonstrierbar. | +| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung an mindestens einem Beispielkunden und -produkt durchgängig demonstrierbar; Rechnung enthält alle Pflichtangaben nach § 14 UStG; Akzeptanztests AT-DP-01 bis AT-DP-07 sowie AT-GR-01 bis AT-GR-06 bestanden. | +| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen; alle Belege über die GUI erstell- und als PDF exportierbar; NF-USE-01/02 nachgewiesen; Akzeptanztests AT-GUI-01 bis AT-GUI-08 bestanden. | ### 1.3 Nicht-Ziele @@ -73,9 +72,10 @@ Folgende Funktionen sind **explizit nicht** Bestandteil dieses Projekts: - Cloud-System bzw. Multi-Tenant-Betrieb - Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk) - Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export) -- E-Rechnung (XRechnung, ZUGFeRD) +- Strukturierte E-Rechnung (XRechnung, ZUGFeRD) — eine einfache PDF-Ausgabe der Belege ist hingegen **in-scope** (siehe BA-DP-07, BA-GUI-05) - Anbindung an externe Buchhaltungs- oder ERP-Systeme - Mehrsprachigkeit (das System wird ausschließlich in deutscher Sprache realisiert) +- Authentifizierung bzw. Benutzeranmeldung — Begründung: lokale Einbenutzer-Anwendung auf einem PC-Arbeitsplatz; Zugriffsschutz erfolgt durch das Betriebssystem-Login. NF-SEC-01 ergänzt einen Schutz der Datenhaltung auf Dateisystemebene. ### 1.4 Begriffsklärung: Lastenheft vs. Pflichtenheft @@ -106,6 +106,7 @@ Das Fakturierungssystem wird als **lokal installierte Einbenutzer-Anwendung** au 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. +6. Belege werden bei Bedarf als PDF exportiert (Archivierung, Versand). ### 2.2 Schnittstellen zur Umgebung @@ -115,7 +116,7 @@ Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieb |----------------------------------|----------------------------------------------------|----------------------| | Benutzerschnittstelle (GUI) | Interaktion mit dem Anwender | UI | | Lokales Dateisystem | Persistierung der Daten (Stammdaten, Dokumente) | Datei-Schnittstelle | -| Druck- bzw. Export-Schnittstelle | Erzeugung druckbarer Dokumente (z. B. PDF) | Ausgabeschnittstelle | +| PDF-Export-Schnittstelle | Erzeugung druckbarer Dokumente als PDF | Ausgabeschnittstelle | ### 2.3 Organisatorische Rahmenbedingungen @@ -124,7 +125,7 @@ Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieb - **Zeit pro Person:** 2–3 Stunden pro Woche - **Vorgehensmodell:** V-Modell - **Budget:** kein finanzielles Budget -- **Kommunikation:** Discord bzw. WhatsApp (täglich), Gitty (kontinuierlich), wöchentliche Meetings, E-Mail an Betreuer bei Bedarf +- **Kommunikation:** Discord bzw. WhatsApp (täglich), Gitty (kontinuierlich), wöchentliche Meetings, E-Mail an den Auftraggeber bei Bedarf ### 2.4 Rechtliche Rahmenbedingungen @@ -134,7 +135,6 @@ Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieb ### 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**. @@ -156,7 +156,9 @@ Im laufenden Betrieb des Systems wird folgende Benutzerrolle unterschieden: | Rolle | Aufgaben | Typische Aktionen | |---------------|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| -| **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten, löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; exportieren | +| **Anwender** | Bedient das System im Geschäftsalltag | Produkt- und Kundenstammdaten anlegen, bearbeiten, löschen; Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen erstellen; PDF exportieren | + +Eine Authentifizierungs- oder Rechtekonzept-Rolle entfällt (siehe Kap. 1.3, Nicht-Ziele). ### 3.3 Teamstruktur @@ -177,41 +179,41 @@ Alle Anforderungen folgen einer der in den Vorlesungsfolien definierten Satzscha - **GR-``** Geschäftsregel (siehe Kap. 6.3) - **NF-``-``** Nicht-funktionale Anforderung (siehe Kap. 5) -Priorität: **Muss** = Pflicht für die Abnahme, **Soll** = wichtig, aber verzichtbar, **Kann** = optional bzw. Erweiterung. +Priorität: **Muss** = Pflicht für die Abnahme, **Soll** = wichtig, aber verzichtbar, **Kann** = optional bzw. Erweiterung. Die Modalverben im Anforderungstext entsprechen jeweils der Priorität (MUSS / SOLLTE / KANN). ### 4.1 Modul Produktverwaltung (Gruppe G) **BA-PV-01 – Produkt anlegen (Muss)** -Als Anwender muss ich neue Produkte anlegen können, um Produktdaten zentral im System zu speichern. Die Anforderung gilt, wenn der Anwender die Eingabemaske geöffnet hat. Die Anforderung gilt als erfüllt, wenn Produktname, Artikelnummer und Einzelpreis netto gespeichert sind und das Produkt in der Produktübersicht erscheint. +Als Anwender muss ich neue Produkte anlegen können, um Produktdaten zentral im System zu speichern. Die Anforderung gilt, wenn der Anwender die Eingabemaske geöffnet hat. Die Anforderung gilt als erfüllt, wenn die in Kap. 6.1.1 genannten Pflichtattribute (Bezeichnung, Einzelpreis netto, Mehrwertsteuersatz) gespeichert sind und das Produkt in der Produktübersicht erscheint. -Akzeptanztests: AT-PV-01 (Speicherung), AT-PV-02 (Fehlermeldung bei fehlendem Pflichtfeld). +Akzeptanztests: AT-PV-01 (Speicherung mit vollständigen Pflichtattributen), AT-PV-02 (Fehlermeldung bei fehlendem Pflichtfeld, insbesondere fehlendem MwSt.-Satz). **BA-PV-02 – Produkt bearbeiten (Muss)** -Als Anwender muss ich bestehende Produktdaten bearbeiten können, um veraltete oder fehlerhafte Daten zu aktualisieren. Die Anforderung gilt, wenn ein vorhandenes Produkt zur Bearbeitung ausgewählt ist. Die Anforderung gilt als erfüllt, wenn geänderte Daten gespeichert, sofort in den Produktdetails sichtbar und nach erneutem Öffnen weiterhin vorhanden sind. +Als Anwender muss ich bestehende Produktdaten bearbeiten können, um veraltete oder fehlerhafte Daten zu aktualisieren. Die Anforderung gilt, wenn ein vorhandenes Produkt zur Bearbeitung ausgewählt ist. Die Anforderung gilt als erfüllt, wenn geänderte Daten gespeichert, sofort in den Produktdetails sichtbar und nach erneutem Öffnen weiterhin vorhanden sind. Bestehende Angebote werden gemäß GR-04 nicht verändert. -Akzeptanztests: AT-PV-03 (Preis ändern), AT-PV-04 (Persistenz nach Neuöffnen). +Akzeptanztests: AT-PV-03 (Preis ändern; bestehende Angebote bleiben unverändert), AT-PV-04 (Persistenz nach Neuöffnen). **BA-PV-03 – Produkt suchen (Muss)** -Als Anwender muss ich nach Produkten suchen können, um Produktdaten schnell zu finden. Die Anforderung gilt, wenn der Anwender einen Suchbegriff in das Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn Produkte über Name oder Artikelnummer gefunden werden und bei einer ungültigen Eingabe der Hinweis „Kein Produkt gefunden" erscheint. +Als Anwender muss ich nach Produkten suchen können, um Produktdaten schnell zu finden. Die Anforderung gilt, wenn der Anwender einen Suchbegriff in das Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn Produkte über Bezeichnung oder Artikelnummer gefunden werden und bei einer ungültigen Eingabe der Hinweis „Kein Produkt gefunden" erscheint. Akzeptanztests: AT-PV-05 (Treffer), AT-PV-06 (kein Treffer). **BA-PV-04 – Produkt löschen (Muss)** -Als Anwender muss ich Produkte löschen können, um nicht mehr angebotene oder fälschlicherweise angelegte Datensätze zu entfernen. Die Anforderung gilt, wenn der Anwender das Löschen eines Produkts auslöst. Die Anforderung gilt als erfüllt, wenn nach Bestätigung einer Sicherheitsabfrage das Produkt entfernt wird und nicht mehr in Übersicht und Suche erscheint. +Als Anwender muss ich Produkte löschen können, um nicht mehr angebotene oder fälschlicherweise angelegte Datensätze zu entfernen. Die Anforderung gilt, wenn der Anwender das Löschen eines Produkts auslöst und keine Sperre durch Geschäftsregel GR-05 (Stammdatenschutz) vorliegt. Die Anforderung gilt als erfüllt, wenn nach Bestätigung einer Sicherheitsabfrage das Produkt entfernt wird und nicht mehr in Übersicht und Suche erscheint. -Akzeptanztests: AT-PV-07 (Sicherheitsabfrage), AT-PV-08 (Produkt nicht mehr auffindbar). +Akzeptanztests: AT-PV-07 (Sicherheitsabfrage; Sperre bei Referenz), AT-PV-08 (Produkt nicht mehr auffindbar). ### 4.2 Modul Kundenverwaltung (Gruppe H) **BA-KV-01 – Kunde anlegen (Muss)** -Als Anwender muss ich neue Kunden anlegen können, um Kundendaten zentral im System zu speichern. Die Anforderung gilt, wenn der Anwender die Eingabemaske für einen neuen Kunden geöffnet hat. Die Anforderung gilt als erfüllt, wenn Vorname, Nachname und E-Mail-Adresse gespeichert sind und der Kunde anschließend in der Kundenliste erscheint. +Als Anwender muss ich neue Kunden anlegen können, um Kundendaten zentral im System zu speichern. Die Anforderung gilt, wenn der Anwender die Eingabemaske für einen neuen Kunden geöffnet hat. Die Anforderung gilt als erfüllt, wenn die in Kap. 6.1.2 genannten Pflichtattribute (Firmenname bzw. Nachname, Straße, PLZ, Ort) gespeichert sind und der Kunde anschließend in der Kundenliste erscheint. Wird eine E-Mail-Adresse angegeben, wird ihr Format validiert. -Akzeptanztests: AT-KV-01 (Speicherung), AT-KV-02 (Fehlermeldung bei fehlendem Pflichtfeld). +Akzeptanztests: AT-KV-01 (Speicherung mit vollständigen Pflichtattributen), AT-KV-02 (Fehlermeldung bei fehlendem Pflichtfeld bzw. ungültigem E-Mail-Format). **BA-KV-02 – Kunde bearbeiten (Muss)** @@ -229,7 +231,7 @@ Akzeptanztests: AT-KV-05 (Treffer), AT-KV-06 (kein Treffer). Als Anwender muss ich Kunden löschen können, um nicht mehr benötigte Datensätze zu entfernen. Die Anforderung gilt, wenn der Anwender das Löschen eines Kunden auslöst und keine Sperre durch Geschäftsregel GR-05 vorliegt. Die Anforderung gilt als erfüllt, wenn der Kunde nach Bestätigung entfernt wird und in Liste sowie Suche nicht mehr auffindbar ist. -Akzeptanztests: AT-KV-07 (Löschung), AT-KV-08 (nicht mehr auffindbar). +Akzeptanztests: AT-KV-07 (Löschung), AT-KV-08 (nicht mehr auffindbar; Sperre bei Referenz). ### 4.3 Modul Dokumentenprozess (Gruppe F) @@ -239,11 +241,11 @@ Akzeptanztests: AT-KV-07 (Löschung), AT-KV-08 (nicht mehr auffindbar). Als Anwender muss ich ein Angebot für einen Kunden erstellen können, um Kundenpreise verbindlich anzubieten. Die Anforderung gilt, wenn mindestens ein Kunde und ein Produkt im System vorhanden sind. Die Anforderung gilt als erfüllt, wenn ein Angebot mit Kundenreferenz, Datum, mindestens einer Position und korrekt berechneter Netto- und Bruttosumme gespeichert ist. -Akzeptanztest: AT-DP-01 (Angebot mit einer Position; korrekte Summen). +Akzeptanztest: AT-DP-01 (Angebot mit einer Position; korrekte Summen gemäß GR-06). **BA-DP-02 – Angebotsstatus setzen (Muss)** -Als Anwender muss ich ein Angebot als „angenommen" oder „abgelehnt" markieren können, um den Vertriebsstatus nachzuhalten. Die Anforderung gilt, wenn ein Angebot mit Status „offen" vorliegt. Die Anforderung gilt als erfüllt, wenn der gesetzte Status dauerhaft gespeichert wird und in der Übersicht sichtbar ist. +Als Anwender muss ich ein Angebot als „angenommen" oder „abgelehnt" markieren können, um den Vertriebsstatus nachzuhalten. Die Anforderung gilt, wenn ein Angebot mit Status „offen" vorliegt. Die Anforderung gilt als erfüllt, wenn der gesetzte Status dauerhaft gespeichert wird und in der Übersicht sichtbar ist. Statusübergänge folgen Kap. 6.1.7. Akzeptanztest: AT-DP-02 (Status persistent nach Neustart). @@ -251,9 +253,9 @@ Akzeptanztest: AT-DP-02 (Status persistent nach Neustart). **BA-DP-03 – Auftragsbestätigung aus Angebot erzeugen (Muss)** -Als Anwender muss ich ein angenommenes Angebot in eine Auftragsbestätigung umwandeln können, um den Auftrag verbindlich zu bestätigen. Die Anforderung gilt, wenn das Angebot den Status „angenommen" hat. Die Anforderung gilt als erfüllt, wenn alle Angebotsdaten in eine neue Auftragsbestätigung übernommen werden und das Vorgängerangebot referenziert ist. +Als Anwender muss ich ein angenommenes Angebot in eine Auftragsbestätigung umwandeln können, um den Auftrag verbindlich zu bestätigen. Die Anforderung gilt, wenn das Angebot den Status „angenommen" hat. Die Anforderung gilt als erfüllt, wenn alle Angebotsdaten in eine neue Auftragsbestätigung übernommen werden, das Vorgängerangebot referenziert ist und der Angebotsstatus automatisch auf „überführt" gesetzt wird (gemäß Kap. 6.1.7). -Akzeptanztest: AT-DP-03 (Datenübernahme komplett, Referenz vorhanden). +Akzeptanztest: AT-DP-03 (Datenübernahme komplett; Referenz vorhanden; Angebotsstatus „überführt"). #### 4.3.3 Lieferschein @@ -261,7 +263,7 @@ Akzeptanztest: AT-DP-03 (Datenübernahme komplett, Referenz vorhanden). Als Anwender muss ich aus einer Auftragsbestätigung einen Lieferschein erzeugen können, um die Auslieferung der Ware zu dokumentieren. Die Anforderung gilt, wenn eine Auftragsbestätigung mit Status „bestätigt" vorliegt. Die Anforderung gilt als erfüllt, wenn ein Lieferschein mit Referenz auf die Auftragsbestätigung, Lieferdatum und allen Positionen erzeugt und gespeichert wird. -Akzeptanztest: AT-DP-04 (Lieferschein referenziert AB; Positionen vollständig). +Akzeptanztest: AT-DP-04 (Lieferschein referenziert Auftragsbestätigung; Positionen vollständig). #### 4.3.4 Rechnung @@ -277,6 +279,14 @@ Als Anwender muss ich beim Erzeugen einer Rechnung das aktuelle Rechnungsdatum a Akzeptanztest: AT-DP-06 (Rechnungsdatum entspricht Systemdatum). +#### 4.3.5 Beleg-Export + +**BA-DP-07 – Beleg als PDF exportieren (Muss)** + +Als Anwender muss ich Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen als PDF-Datei exportieren können, um Belege archivieren und Kunden zustellen zu können. Die Anforderung gilt, wenn ein gespeicherter Beleg ausgewählt ist. Die Anforderung gilt als erfüllt, wenn die erzeugte PDF-Datei alle im Beleg gespeicherten Inhalte in druckbarer Form enthält (bei Rechnungen einschließlich aller § 14 UStG-Pflichtangaben) und unter einem vom Anwender gewählten Pfad gespeichert wird. + +Akzeptanztest: AT-DP-07 (PDF-Erzeugung je Belegtyp; Inhalt entspricht dem Beleg in der GUI; Rechnungs-PDF enthält alle § 14 UStG-Pflichtangaben). + ### 4.4 Modul GUI / Programmoberfläche (Gruppe E) **BA-GUI-01 – Angebotserfassung über grafische Maske (Muss)** @@ -285,9 +295,9 @@ Als Anwender muss ich über eine grafische Eingabemaske Angebote erstellen könn Akzeptanztests: AT-GUI-01 (Live-Summenaktualisierung), AT-GUI-02 (Erfolgsmeldung). -**BA-GUI-02 – Auftragsbearbeitung über GUI (Muss)** +**BA-GUI-02 – Auftragsbestätigung über GUI (Muss)** -Als Anwender muss ich Angebote über die GUI in Aufträge umwandeln können, ohne Daten manuell neu einzugeben. Die Anforderung gilt, wenn ein Angebot mit Status „angenommen" ausgewählt ist. Die Anforderung gilt als erfüllt, wenn alle Daten in die Auftragsmaske übernommen werden, die Maske mit dem Titel „Auftragsbestätigung" angezeigt wird und Pflichtfelder für den Liefertermin farblich markiert sind, solange sie leer sind. +Als Anwender muss ich Angebote über die GUI in Auftragsbestätigungen umwandeln können, ohne Daten manuell neu einzugeben. Die Anforderung gilt, wenn ein Angebot mit Status „angenommen" ausgewählt ist. Die Anforderung gilt als erfüllt, wenn alle Daten in die Auftragsbestätigungs-Maske übernommen werden, die Maske mit dem Titel „Auftragsbestätigung" angezeigt wird und Pflichtfelder für den Liefertermin farblich markiert sind, solange sie leer sind. Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung). @@ -303,47 +313,55 @@ Als Anwender muss ich Belege über eine Suchfunktion filtern können, um Dokumen Akzeptanztests: AT-GUI-06 (Echtzeit-Filter), AT-GUI-07 (Hinweis bei leerer Trefferliste). +**BA-GUI-05 – PDF-Export aus der Belegansicht (Muss)** + +Als Anwender muss ich auf jeder Belegansicht (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) den PDF-Export über eine Schaltfläche auslösen können, um die Funktion ohne Menünavigation zu erreichen. Die Anforderung gilt, wenn ein Beleg angezeigt wird. Die Anforderung gilt als erfüllt, wenn auf der Belegansicht eine Schaltfläche „Als PDF exportieren" sichtbar ist, beim Klick die in BA-DP-07 beschriebene Funktion ausgeführt und eine Erfolgsmeldung mit Speicherpfad angezeigt wird. + +Akzeptanztest: AT-GUI-08 (Schaltfläche sichtbar und funktionsfähig; Erfolgsmeldung). + --- ## 5. Qualitätsanforderungen (nicht-funktionale Anforderungen) +Modalverben im Anforderungstext entsprechen der jeweiligen Priorität (Muss → MUSS, Soll → SOLLTE, Kann → KANN). + ### 5.1 Usability (NF-USE) | ID | Anforderung | Prio | Akzeptanzkriterium / Test | |------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| | NF-USE-01 | Das Anlegen eines neuen Kunden MUSS von einem Anwender ohne vorherige Schulung in weniger als 2 Minuten abgeschlossen werden können, wobei höchstens 1 Fehlbedienung pro 10 Testnutzenden zulässig ist. | Muss | AT-NF-01: Usability-Test mit 5 Probanden; Erfolgsquote > 90 %, Median-Zeit < 120 s.| -| NF-USE-02 | Mindestens 80 % der Testnutzenden MÜSSEN die Aufgabe „Aus einem Angebot eine Rechnung erzeugen" im ersten Versuch ohne Hilfetext erfolgreich abschließen. | Muss | AT-NF-02: Usability-Test mit 5 Probanden; mindestens 4 von 5 erfolgreich. | -| NF-USE-03 | Das System MUSS bei jeder validierungspflichtigen Eingabe innerhalb von 1 Sekunde eine sichtbare Rückmeldung (Erfolg oder Fehler) anzeigen. | Muss | AT-NF-03: Manueller Test mit Stoppuhr; Rückmeldezeit < 1 s. | +| NF-USE-02 | Mindestens 80 % der Testnutzenden MÜSSEN die Aufgabe „Aus einem Angebot eine Rechnung erzeugen" im ersten Versuch ohne Hilfetext erfolgreich abschließen. | Muss | AT-NF-02: Usability-Test mit 5 Probanden; mindestens 4 von 5 erfolgreich. | +| NF-USE-03 | Das System MUSS bei jeder validierungspflichtigen Eingabe innerhalb von 1 Sekunde eine sichtbare Rückmeldung (Erfolg oder Fehler) anzeigen. | Muss | AT-NF-03: Manueller Test mit Stoppuhr; Rückmeldezeit < 1 s. | ### 5.2 Performance (NF-PERF) | ID | Anforderung | Prio | Akzeptanzkriterium / Test | |------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| -| NF-PERF-01 | Das System MUSS jede Benutzeraktion innerhalb von 1 Sekunde mit einer sichtbaren Rückmeldung beantworten, bei einem Datenbestand von bis zu 1.000 Produkten und 1.000 Kunden. | Muss | AT-NF-04: Lasttest mit 1.000 Datensätzen je Entität; Antwortzeit < 1 s. | -| NF-PERF-02 | Das System MUSS die Übersichtsliste von Produkten oder Kunden bei bis zu 1.000 Datensätzen innerhalb von 2 Sekunden vollständig anzeigen. | Muss | AT-NF-05: Lasttest mit 1.000 Einträgen; Anzeigedauer < 2 s. | -| NF-PERF-03 | Das System MUSS den Anwendungsstart vom Aufruf bis zur bedienbaren Hauptansicht in höchstens 5 Sekunden abschließen (Referenzhardware: handelsüblicher Bürorechner). | Soll | AT-NF-06: Kaltstart auf Referenzhardware < 5 s. | +| NF-PERF-01 | Das System MUSS jede Benutzeraktion innerhalb von 1 Sekunde mit einer sichtbaren Rückmeldung beantworten, bei einem Datenbestand von bis zu 1.000 Produkten und 1.000 Kunden. | Muss | AT-NF-04: Lasttest mit 1.000 Datensätzen je Entität; Antwortzeit < 1 s. | +| NF-PERF-02 | Das System MUSS die Übersichtsliste von Produkten oder Kunden bei bis zu 1.000 Datensätzen innerhalb von 2 Sekunden vollständig anzeigen. | Muss | AT-NF-05: Lasttest mit 1.000 Einträgen; Anzeigedauer < 2 s. | +| NF-PERF-03 | Das System SOLLTE den Anwendungsstart vom Aufruf bis zur bedienbaren Hauptansicht in höchstens 5 Sekunden abschließen (Referenzhardware: handelsüblicher Bürorechner). | Soll | AT-NF-06: Kaltstart auf Referenzhardware < 5 s. | ### 5.3 Wartbarkeit (NF-MAINT) -| ID | Anforderung | Prio | Akzeptanzkriterium / Test | -|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| -| NF-MAINT-01 | Der Quellcode MUSS modular nach den vier Modulen Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI getrennt sein (eigene Pakete bzw. Verzeichnisse). | Muss | AT-NF-07: Statische Prüfung der Repository-Struktur. | -| NF-MAINT-02 | Mindestens 80 % der öffentlichen Klassen und Methoden MÜSSEN über kurze Dokumentationskommentare (Zweck, Parameter, Rückgabe) verfügen. | Soll | AT-NF-08: Stichprobe von 20 Methoden; mindestens 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. | +| ID | Anforderung | Prio | Akzeptanzkriterium / Test | +|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|-------------------------------------------------------------------------------------------------------------| +| NF-MAINT-01 | Der Quellcode MUSS modular nach den vier Modulen Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI getrennt sein (eigene Pakete bzw. Verzeichnisse). | Muss | AT-NF-07: Statische Prüfung der Repository-Struktur. | +| NF-MAINT-02 | Mindestens 80 % der öffentlichen Klassen und Methoden SOLLTEN über kurze Dokumentationskommentare (Zweck, Parameter, Rückgabe) verfügen. | Soll | AT-NF-08: Automatisierte Auswertung (JavaDoc-/Doxygen-Report) zeigt > 80 %; Stichprobe als Sekundärprüfung. | +| NF-MAINT-03 | Das System MUSS einer dokumentierten, dreischichtigen Architektur (Präsentation, Logik, Datenhaltung) folgen. | Muss | AT-NF-09: Review des Architekturdokuments; nachweisbare Schichtentrennung. | ### 5.4 Testbarkeit (NF-TEST) -| ID | Anforderung | Prio | Akzeptanzkriterium / Test | -|------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| -| NF-TEST-01 | Jede Anforderung mit Priorität „Muss" MUSS mindestens einem Akzeptanztest in der Traceability-Matrix zugeordnet sein. | Muss | AT-NF-10: Vollständigkeitsprüfung der Traceability-Matrix vor Abnahme. | -| NF-TEST-02 | Die Geschäftslogik (Logikschicht) MUSS so gestaltet sein, dass sie ohne die GUI durch automatisierte Komponententests aufgerufen werden kann. | Muss | AT-NF-11: Mindestens ein lauffähiger Unit-Test pro Modul ohne GUI-Abhängigkeit. | -| NF-TEST-03 | Mindestens 30 % der Geschäftslogik-Methoden SOLLEN durch automatisierte Tests abgedeckt sein (Line Coverage). | Soll | AT-NF-12: Coverage-Report > 30 %. | +| ID | Anforderung | Prio | Akzeptanzkriterium / Test | +|------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|---------------------------------------------------------------------------------| +| NF-TEST-01 | Jede Anforderung mit Priorität „Muss" MUSS mindestens einem Akzeptanztest in der Traceability-Matrix zugeordnet sein. | Muss | AT-NF-10: Vollständigkeitsprüfung der Traceability-Matrix vor Abnahme. | +| NF-TEST-02 | Die Geschäftslogik (Logikschicht) MUSS so gestaltet sein, dass sie ohne die GUI durch automatisierte Komponententests aufgerufen werden kann. | Muss | AT-NF-11: Mindestens ein lauffähiger Unit-Test pro Modul ohne GUI-Abhängigkeit. | +| NF-TEST-03 | Mindestens 60 % der Geschäftslogik-Methoden SOLLTEN durch automatisierte Tests abgedeckt sein (Line Coverage). | Soll | AT-NF-12: Coverage-Report > 60 %. | ### 5.5 Versionierung (NF-VER) | ID | Anforderung | Prio | Akzeptanzkriterium / Test | |------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| -| NF-VER-01 | Der gesamte Quellcode MUSS in Gitty unter den im Charter v1.2 (Kap. 6.2) genannten Repositories versioniert werden. | Muss | AT-NF-13: Sichtprüfung der Repositories. | +| NF-VER-01 | Der gesamte Quellcode MUSS in Gitty unter den im Charter v1.1 (Kap. 6.2) genannten Repositories versioniert werden. | Muss | AT-NF-13: Sichtprüfung der Repositories. | | NF-VER-02 | Jeder Merge in den Hauptbranch MUSS durch mindestens ein Code-Review eines anderen Teammitglieds freigegeben werden. | Muss | AT-NF-14: Review-Historie zeigt für jeden Merge mindestens einen Reviewer. | ### 5.6 Architektur und Datenhaltung (NF-ARCH) @@ -351,14 +369,14 @@ Akzeptanztests: AT-GUI-06 (Echtzeit-Filter), AT-GUI-07 (Hinweis bei leerer Treff | ID | Anforderung | Prio | Akzeptanzkriterium / Test | |-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| | NF-ARCH-01 | Das System MUSS alle Datensätze (Produkte, Kunden, Dokumente) persistent so speichern, dass sie nach einem Neustart der Anwendung vollständig wiederhergestellt werden. | Muss | AT-NF-15: Datensätze anlegen, Anwendung neu starten; Datensätze sind unverändert. | -| NF-ARCH-02 | Die Datenhaltung MUSS hinter einer abstrakten Schnittstelle (Repository bzw. DAO) gekapselt sein, sodass die konkrete Speichertechnologie austauschbar ist. | Soll | AT-NF-16: Code-Review zeigt Repository- bzw. DAO-Abstraktion. | +| NF-ARCH-02 | Die Datenhaltung SOLLTE hinter einer abstrakten Schnittstelle (Repository bzw. DAO) gekapselt sein, sodass die konkrete Speichertechnologie austauschbar ist. | Soll | AT-NF-16: Code-Review zeigt Repository- bzw. DAO-Abstraktion. | ### 5.7 Sicherheit und Datenschutz (NF-SEC) -| ID | Anforderung | Prio | Akzeptanzkriterium / Test | -|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| -| NF-SEC-01 | Das System 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 aus fremdem Nutzerkontext zeigt keinen lesbaren Klartext. | -| NF-SEC-02 | Das System MUSS dem Anwender ERMÖGLICHEN, einen Kunden gemäß DSGVO Art. 17 zu löschen, sofern keine gesetzlichen Aufbewahrungspflichten (z. B. 10 Jahre für Rechnungen) entgegenstehen. | Soll | AT-NF-18: Löschanforderung ohne aktive Rechnungen entfernt den Kunden. | +| ID | Anforderung | Prio | Akzeptanzkriterium / Test | +|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|------------------------------------------------------------------------------------| +| NF-SEC-01 | Das System SOLLTE personenbezogene Kundendaten so speichern, dass sie ohne Zugriff auf das Anwendungs-Verzeichnis nicht im Klartext einsehbar sind (z. B. lokale Datei in geschütztem Anwendungspfad). | Soll | AT-NF-17: Inspektion aus fremdem Nutzerkontext zeigt keinen lesbaren Klartext. | +| NF-SEC-02 | Das System SOLLTE dem Anwender ermöglichen, einen Kunden gemäß DSGVO Art. 17 zu löschen, sofern keine gesetzlichen Aufbewahrungspflichten (z. B. 10 Jahre für Rechnungen) entgegenstehen. | Soll | AT-NF-18: Löschanforderung ohne aktive Rechnungen entfernt den Kunden. | --- @@ -370,24 +388,24 @@ Die folgenden Datenobjekte bilden den fachlichen Kern des Systems. Eine Darstell **6.1.1 Produkt** -- Identifikator: Produkt-ID (eindeutig, fortlaufend) -- Pflichtattribute: Bezeichnung, Einzelpreis netto, Mehrwertsteuersatz -- Optionale Attribute: Beschreibung, Kategorie +- Identifikator: Produkt-ID (eindeutig, fortlaufend; systeminterner Primärschlüssel) +- Pflichtattribute: Bezeichnung (synonym: Produktname), Einzelpreis netto, Mehrwertsteuersatz +- Optionale Attribute: Artikelnummer (anwenderseitige Kennung; wird, sofern nicht eingegeben, aus der Produkt-ID nach Schema `P-` abgeleitet), Beschreibung, Kategorie **6.1.2 Kunde** - Identifikator: Kunden-ID (eindeutig, fortlaufend) - Pflichtattribute: Firmenname bzw. Nachname, Straße, PLZ, Ort -- Optionale Attribute: Vorname, Telefon, E-Mail, USt-IdNr., abweichende Lieferadresse, Ansprechpartner +- Optionale Attribute: Vorname, Telefon, E-Mail (Format wird validiert, falls angegeben), USt-IdNr., abweichende Lieferadresse, Ansprechpartner **6.1.3 Angebot** - Identifikator: Angebotsnummer (z. B. `A--`) - Pflichtattribute: Kundenreferenz, Datum, Positionen (Produkt, Menge, Einzelpreis), Gesamtsumme (netto bzw. brutto), Status (offen, angenommen, abgelehnt, überführt) -**6.1.4 Auftragsbestätigung (Auftrag)** +**6.1.4 Auftragsbestätigung** -- Identifikator: Auftragsnummer (z. B. `AB--`) +- Identifikator: Auftragsbestätigungs-Nummer (z. B. `AB--`) - Pflichtattribute: Referenz auf Angebot, Kundenreferenz, Datum, Positionen, Gesamtsumme, Status (bestätigt, geliefert) **6.1.5 Lieferschein** @@ -400,21 +418,39 @@ Die folgenden Datenobjekte bilden den fachlichen Kern des Systems. Eine Darstell - Identifikator: Rechnungsnummer (eindeutig, fortlaufend, lückenlos, z. B. `R--`) - Pflichtattribute: Referenz auf genau einen Lieferschein, Kundenreferenz, Rechnungsdatum, Positionen, Netto-, USt.- und Bruttosumme, Pflichtangaben nach § 14 UStG, Status (offen, bezahlt) +**6.1.7 Statusübergänge** + +Die in Kap. 6.1.3 bis 6.1.6 genannten Statuswerte werden wie folgt geschaltet: + +| Beleg | Aktion | Vor-Status | Folge-Status | Auslöser | +|---------------------|---------------------------------------------------|-----------------|----------------|---------------------------| +| Angebot | Erstellung | — | offen | BA-DP-01 | +| Angebot | Markierung „angenommen" | offen | angenommen | BA-DP-02 (Anwender) | +| Angebot | Markierung „abgelehnt" | offen | abgelehnt | BA-DP-02 (Anwender) | +| Angebot | Erzeugung Auftragsbestätigung | angenommen | überführt | BA-DP-03 (automatisch) | +| Auftragsbestätigung | Erzeugung aus Angebot | — | bestätigt | BA-DP-03 | +| Auftragsbestätigung | Erzeugung Lieferschein | bestätigt | geliefert | BA-DP-04 (automatisch) | +| Lieferschein | Erzeugung aus Auftragsbestätigung | — | offen | BA-DP-04 | +| Lieferschein | Bestätigung Auslieferung | offen | geliefert | Anwenderaktion | +| Lieferschein | Erzeugung Rechnung | geliefert | fakturiert | BA-DP-05 (automatisch) | +| Rechnung | Erzeugung aus Lieferschein | — | offen | BA-DP-05 | +| Rechnung | Markierung „bezahlt" | offen | bezahlt | Anwenderaktion | + ### 6.2 Beziehungen zwischen Datenobjekten -| Beziehung | Multiplizität | -|--------------------------------------------------------------------|-----------------| -| Kunde → Angebot | 1 : n | -| Angebot → Auftragsbestätigung | 1 : 0..1 | -| Auftragsbestätigung → Lieferschein | 1 : 0..1 | -| Lieferschein → Rechnung | 1 : 0..1 | -| Produkt → Position (Angebot, Auftrag, Lieferschein, Rechnung) | 1 : n | +| Beziehung | Multiplizität | +|---------------------------------------------------------------------------------|-----------------| +| Kunde → Angebot | 1 : n | +| Angebot → Auftragsbestätigung | 1 : 0..1 | +| Auftragsbestätigung → Lieferschein | 1 : 0..1 | +| Lieferschein → Rechnung | 1 : 0..1 | +| Produkt → Position (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) | 1 : n | ### 6.3 Geschäftsregeln **GR-01 – Dokumentenkette** -Eine Rechnung verweist auf genau einen Lieferschein, ein Lieferschein auf genau eine Auftragsbestätigung, eine Auftragsbestätigung auf genau ein Angebot. Wenn ein Folgedokument erzeugt werden soll, dann muss das Vorgängerdokument im passenden Status vorliegen. +Eine Rechnung verweist auf genau einen Lieferschein, ein Lieferschein auf genau eine Auftragsbestätigung, eine Auftragsbestätigung auf genau ein Angebot. Wenn ein Folgedokument erzeugt werden soll, dann muss das Vorgängerdokument im passenden Status (siehe Kap. 6.1.7) vorliegen. Akzeptanztest AT-GR-01: Versuch, eine Rechnung ohne zugehörigen Lieferschein anzulegen, wird abgewiesen. @@ -454,39 +490,33 @@ Akzeptanztest AT-GR-06: Manuelle Nachrechnung an drei Beispielen stimmt mit Syst |-------|-------------------------------------|--------------------------------------------------------------------| | IF-01 | Benutzerschnittstelle (GUI) | Interaktive Oberfläche, siehe Kap. 4.4 | | IF-02 | Datei-Schnittstelle Persistenz | Lokale Speicherung der Stammdaten und Dokumente (vgl. NF-ARCH-01) | -| IF-03 | Druck- bzw. Export-Schnittstelle | Erzeugung druckbarer Dokumente, vorzugsweise PDF (vgl. BA-DP-04) | +| IF-03 | PDF-Export-Schnittstelle | Erzeugung druckbarer Dokumente als PDF (vgl. BA-DP-07, BA-GUI-05) | --- ## 7. Akzeptanzkriterien und Abnahmebedingungen -### 7.1 Übernahme aus Project Charter v1.2 +### 7.1 Übernahme aus Project Charter v1.1 -Aus Charter v1.2 (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 +Aus Charter v1.1 (Kap. 13) werden die Abnahmekriterien übernommen und im Folgenden verfeinert. ### 7.2 Verfeinerte Akzeptanzkriterien Das System gilt als **abgenommen**, wenn alle folgenden Kriterien erfüllt sind: -| ID | Akzeptanzkriterium | Bezug | -|-------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------| -| AK-01 | Alle Muss-Anforderungen aus Kap. 4 und 5 sind implementiert und durch zugeordnete Akzeptanztests nachgewiesen. | BA-*, NF-* (Priorität Muss) | -| AK-02 | Die vier Pflichtmodule Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI sind in ihren Repositories (Gruppen G, H, F, E) lauffähig und in das Gesamtsystem integriert. | Charter v1.2, 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 bzw. Architekturdokument liegen in der final freigegebenen Version vor. | Charter v1.2, Kap. 8 (M1, M2) | -| AK-07 | Die Abnahmepräsentation gegenüber dem Auftraggeber (Prof. Dr. Marmitt) ist erfolgreich durchgeführt. | Charter v1.2, M7 | +| ID | Akzeptanzkriterium | Bezug | +|-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------| +| AK-01 | Alle Muss-Anforderungen aus Kap. 4 und 5 sind implementiert und durch zugeordnete Akzeptanztests nachgewiesen. | BA-*, NF-* (Priorität Muss) | +| AK-02 | Die vier Pflichtmodule Produktverwaltung, Kundenverwaltung, Dokumentenprozess und GUI sind in ihren Repositories (Gruppen G, H, F, E) lauffähig und in das Gesamtsystem integriert. | Charter v1.1, Kap. 6.2 | +| AK-03 | Der vollständige Dokumentenprozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung kann anhand eines Beispielkunden und -produkts durchgängig demonstriert werden, einschließlich PDF-Export. | Kap. 4.3 (BA-DP-01..07) | +| AK-04 | Die Traceability-Matrix (Anhang 8.4) ordnet jeder Muss-Anforderung mindestens einen Akzeptanztest zu. | NF-TEST-01 | +| AK-05 | Die Lasttests gemäß NF-PERF-01 und NF-PERF-02 sind mit dem geforderten Datenbestand erfolgreich durchgeführt. | Kap. 5.2 | +| AK-06 | Lastenheft v1.0 sowie Pflichtenheft bzw. Architekturdokument liegen in finaler freigegebener Version vor. | Charter v1.1, Kap. 7 und Kap. 8 | +| AK-07 | Die Abnahmepräsentation gegenüber dem Auftraggeber (Prof. Dr. Marmitt) ist erfolgreich durchgeführt. | Charter v1.1, M7 | ### 7.3 Definition of Done (modulbezogen) -Übernommen aus Charter v1.2 (Kap. 12). Ein einzelnes Feature bzw. Modul gilt als abgeschlossen, wenn es +Übernommen aus Charter v1.1 (Kap. 12). Ein einzelnes Feature bzw. Modul gilt als abgeschlossen, wenn es - implementiert und funktionsfähig ist, - getestet ist (mindestens ein Akzeptanztest pro Muss-Anforderung), @@ -500,20 +530,22 @@ Das System gilt als **abgenommen**, wenn alle folgenden Kriterien erfüllt sind: ### 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 | +| Begriff | Bedeutung | +|---------------------|---------------------------------------------------------------------------------------------------------------------------------------| +| Angebot | Unverbindliches Preisangebot an einen Kunden | +| Auftragsbestätigung | Verbindliche Bestätigung der Auftragsannahme nach Angebot (synonym auch: Auftrag; Kurzform AB) | +| Lieferschein | Dokument, das die Auslieferung der Ware bescheinigt | +| Rechnung | Forderung nach § 14 UStG mit Steuerangaben | +| Stammdaten | Produkt- und Kundendaten (Grunddaten) | +| Bewegungsdaten | Dokumente (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) | +| Bezeichnung | Anzeigename eines Produkts (synonym: Produktname); siehe Kap. 6.1.1 | +| Artikelnummer | Anwenderseitige Produktkennung; wird, sofern nicht eingegeben, aus der Produkt-ID abgeleitet | +| Lastenheft (CRS) | Customer Requirements Specification, beschreibt aus Auftraggebersicht, was das System leisten soll | +| Pflichtenheft | Antwortdokument des Auftragnehmers, beschreibt, wie das System realisiert wird | +| V-Modell | Vorgehensmodell mit symmetrischer Zuordnung von Entwicklungs- und Testphasen | +| Traceability | Rückverfolgbarkeit von Anforderung zu Test | +| Akzeptanztest | Test, der die Erfüllung einer Anforderung aus Sicht des Auftraggebers prüft | +| Anwender | Einzige Benutzerrolle des Systems: bedient das Fakturierungssystem im Geschäftsalltag (keine Authentifizierungsrolle, siehe Kap. 1.3) | ### 8.2 Abkürzungsverzeichnis @@ -549,12 +581,11 @@ Das System gilt als **abgenommen**, wenn alle folgenden Kriterien erfüllt sind: ### 8.3 Referenzen -- **[1]** `project-charter_v1_2.md` – Project Charter Fakturierungssystem, Version 1.2, 14.05.2026 +- **[1]** `project-charter_v1_1.md` – Project Charter Fakturierungssystem, Version 1.1, 15.05.2026 - **[2]** `week6slides.pdf` – Vorlesung Software Engineering 1, Woche 6: Lastenheft und testbare Benutzeranforderungen - **[3]** `week7slides.pdf` – Vorlesung Software Engineering 1, Woche 7: Pflichtenheft, Anforderungen und Traceability -- **[4]** `Technologiestack.md` – separates Dokument zum verwendeten Technologie-Stack -- **[5]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen -- **[6]** DSGVO – Verordnung (EU) 2016/679 +- **[4]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen +- **[5]** DSGVO – Verordnung (EU) 2016/679 ### 8.4 Traceability-Matrix (Übersicht) @@ -576,10 +607,12 @@ Verkürzte Darstellung gemäß Vorlesung Woche 6. Die vollständige Matrix wird | BA-DP-04 | funktional | AT-DP-04 | | BA-DP-05 | funktional | AT-DP-05 | | BA-DP-06 | funktional | AT-DP-06 | +| BA-DP-07 | funktional | AT-DP-07 | | BA-GUI-01 | funktional | AT-GUI-01, AT-GUI-02 | | BA-GUI-02 | funktional | AT-GUI-03 | | BA-GUI-03 | funktional | AT-GUI-04, AT-GUI-05 | | BA-GUI-04 | funktional | AT-GUI-06, AT-GUI-07 | +| BA-GUI-05 | funktional | AT-GUI-08 | | GR-01 | Geschäftsregel | AT-GR-01 | | GR-02 | Geschäftsregel | AT-GR-02 | | GR-03 | Geschäftsregel | AT-GR-03 | @@ -605,4 +638,4 @@ Verkürzte Darstellung gemäß Vorlesung Woche 6. Die vollständige Matrix wird | NF-SEC-01 | Security | AT-NF-17 | | NF-SEC-02 | Security | AT-NF-18 | ---- \ No newline at end of file +--- diff --git a/Project-Charter/project-charter_v1_1.md b/Project-Charter/project-charter_v1_1.md index 7bf2ca5..48aac02 100644 --- a/Project-Charter/project-charter_v1_1.md +++ b/Project-Charter/project-charter_v1_1.md @@ -2,7 +2,7 @@ title: "Project Charter – Fakturierungssystem" subtitle: "SE1 Team 2 – Hochschule Mannheim" author: "Christopher Lampert" -date: "14.05.2026" +date: "15.05.2026" lang: de-DE geometry: "left=2.2cm,right=2.2cm,top=2cm,bottom=2cm" fontsize: 10pt @@ -20,22 +20,37 @@ numbersections: false **Modul:** Software Engineering 1 **Team:** SE1 Team 2 – Hochschule Mannheim **Version:** 1.1 -**Stand:** 14.05.2026 +**Stand:** 15.05.2026 --- ## 1. Freigabeübersicht -| Ersteller | Prüfer | Freigebender | -|------------------------|-------------------------|----------------------------| -| Oleg Akimenko | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) | +| Version | Ersteller | Prüfer | Freigebender | +|---------|---------------------|-------------------------|----------------------------| +| 1.0 | Oleg Akimenko | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) | +| 1.1 | Christopher Lampert | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) | -## 2. Dokumentenhistorie +## 2. Dokumentenhistorie und Änderungswesen -| Version | Datum | Autor | Änderung | -|----------|-----------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 1.0 | 15.04.26 | O. Akimenko | Initiale Erstellung | -| 1.1 | 05.05.26 | C. Lampert | Überarbeitung nach Review: Kapitelnummerierung angepasst, Anforderungen ins Lastenheft verschoben, Zeitplan konkretisiert, Technologie-Stack ausgelagert, Gruppenleiter dokumentiert, Nicht-Ziele präzisiert, Erfolgskriterien Z1 ergänzt, V-Modell-Kapitel ausformuliert | +### 2.1 Dokumentenhistorie + +| Version | Datum | Autor | Änderung | +|----------|-------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 1.0 | 15.04.2026 | O. Akimenko | Initiale Erstellung | +| 1.1 | 15.05.2026 | C. Lampert | Überarbeitung nach Review und Schwachstellenanalyse: Kapitelnummerierung angepasst; Anforderungen ins Lastenheft v1.0 verschoben; Technologie-Stack ausgelagert; Gruppenleiter dokumentiert; Nicht-Ziele präzisiert (PDF in-scope/E-Rechnung out-of-scope, Authentifizierung out-of-scope mit Begründung); Erfolgskriterien Z1–Z4 SMART und an NF-Anforderungen verknüpft; Pflichtenheft als Phase im V-Modell und Zeitplan ergänzt; Aufwandsschätzung je Phase; Pufferwoche vor M7; Risikoregister auf 9 Risiken mit messbaren Schwellwerten und Verantwortlichen erweitert; neues Kapitel „Annahmen und Abhängigkeiten" (Kap. 6.3); Begriff „Auftraggeber" durchgängig verwendet (auch Kap. 14); DoD um Akzeptanztest-Pflicht ergänzt; Abnahmekriterien erweitert; Änderungswesen-Prozess (Kap. 2.2) dokumentiert. | + +### 2.2 Änderungswesen + +Das Project Charter ist ein **lebendes Dokument**. Änderungen folgen folgendem Prozess: + +1. **Änderungsantrag:** Jedes Teammitglied kann einen begründeten Antrag an den eigenen Gruppenleiter stellen. +2. **Bewertung:** Die Gruppenleiter prüfen den Antrag im wöchentlichen Gruppenleiter-Meeting auf Auswirkungen auf Scope, Zeitplan, Risiken und Lastenheft. +3. **Freigabe:** Der Auftraggeber bestätigt die Änderung. +4. **Versionierung:** Versionsnummer wird angehoben (Minor: klärende Änderung; Major: Scope-Änderung). Datum, Autor und Änderungsumfang werden in Kap. 2.1 eingetragen. +5. **Synchronisation:** Alle bezugnehmenden Dokumente (Lastenheft, Pflichtenheft, Architekturdokument) werden im selben Schritt versions-synchronisiert. Eine Charter-Version referenziert immer die zum Zeitpunkt ihrer Freigabe gültige Lastenheft-Version und umgekehrt. + +--- ## 3. Projektübersicht @@ -57,22 +72,27 @@ Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell. ## 4. Projektziele -| 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 | Angebot → Auftragsbestätigung → Lieferschein → Rechnung wird durchgängig unterstützt | -| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen | +Die folgenden Ziele sind SMART formuliert und gegen die nicht-funktionalen Anforderungen sowie Akzeptanztests des Lastenhefts v1.0 (Kap. 5 bzw. Anhang 8.4) messbar. + +| Nr. | Ziel | Erfolgskriterium | +|------|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Z1 | Produktverwaltung | Alle CRUD-Operationen (Anlegen, Bearbeiten, Suchen, Löschen) bei einem Datenbestand von bis zu 1.000 Produkten innerhalb der NF-PERF-01-Antwortzeit von 1 s. Akzeptanztests AT-PV-01 bis AT-PV-08 bestanden. Geschäftsregel GR-05 (Stammdatenschutz bei referenzierten Produkten) eingehalten. | +| Z2 | Kundenverwaltung | CRUD bei bis zu 1.000 Kunden analog Z1. Akzeptanztests AT-KV-01 bis AT-KV-08 bestanden. DSGVO-konformes Löschen (NF-SEC-02) unter Beachtung der Aufbewahrungspflicht (GR-05) demonstrierbar. | +| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung an mindestens einem Beispielkunden und -produkt durchgängig demonstrierbar; Rechnung enthält alle Pflichtangaben nach § 14 UStG; Akzeptanztests AT-DP-01 bis AT-DP-07 sowie GR-01 bis GR-06 bestanden. | +| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen; alle Belege per GUI erstell- und als PDF exportierbar; Usability gemäß NF-USE-01/02 (Anlegen Kunde < 2 min, > 80 % Erfolgsquote „Angebot → Rechnung") nachgewiesen; Akzeptanztests AT-GUI-01 bis AT-GUI-08 bestanden. | ### 4.1 Nicht-Ziele +Folgendes ist **nicht** Bestandteil des Projekts: + - Mobile Anwendung - Cloud-System bzw. Multi-Tenant-Betrieb - Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk) - Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export) -- E-Rechnung (XRechnung, ZUGFeRD) +- Strukturierte E-Rechnung (XRechnung, ZUGFeRD) — eine einfache PDF-Ausgabe der Belege ist hingegen **in-scope** (siehe BA-DP-07 im Lastenheft) - Anbindung an externe Buchhaltungs- oder ERP-Systeme - Mehrsprachigkeit (System ausschließlich in deutscher Sprache) +- Authentifizierung bzw. Benutzeranmeldung — Begründung: lokale Einbenutzer-Anwendung; Zugriffsschutz erfolgt durch das Betriebssystem-Login des PC-Arbeitsplatzes (siehe Lastenheft Kap. 2.1 und NF-SEC-01) --- @@ -84,69 +104,101 @@ Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell. --- -## 6. Stakeholder und Teamstruktur +## 6. Stakeholder, Teamstruktur, Annahmen ### 6.1 Stakeholder -| Rolle | Beschreibung | -|-------------------|---------------------------------------------| -| Auftraggeber | Prof. Dr. Gerd Marmitt | -| Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) | -| Endnutzer | spätere Anwender (kleines Unternehmen) | +| Rolle | Beschreibung | +|--------------------------------------------|----------------------------------------| +| Auftraggeber (Lehrveranstaltungs-Betreuer) | Prof. Dr. Gerd Marmitt | +| Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) | +| Endnutzer | spätere Anwender (kleines Unternehmen) | ### 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 Project Charter unterzeichnet. +Pro Untergruppe ist ein **Gruppenleiter** benannt, der die Untergruppe gegenüber dem Gesamtteam und dem Auftraggeber vertritt und das Project Charter unterzeichnet. Pro Gruppe ist zusätzlich ein **Stellvertreter** benannt (Bus-Faktor > 2, siehe Kap. 9, R1/R9). -| Gruppe | Mitglieder | Gruppenleiter | Verantwortungsbereich | -|---------|-----------------------------------------------------------------------------------------|----------------------|-------------------------| -| E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | Nicolas Seelinger | Programmoberfläche | -| F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801] | Andreas Ivanovic | Dokumentenprozess | -| G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489] | Lulia Silk | Produktverwaltung | -| H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541] | Oleg Akimenko | Kundenverwaltung | +| Gruppe | Mitglieder | Gruppenleiter | Stellvertreter | Verantwortungsbereich | +|---------|-----------------------------------------------------------------------------------------|----------------------|---------------------|--------------------------| +| E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | Nicolas Seelinger | Hadil Jondi | Programmoberfläche (GUI) | +| F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801] | Andreas Ivanovic | Armin Omanovic | Dokumentenprozess | +| G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489] | Lulia Silk | Rahaf Alhosny | Produktverwaltung | +| H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541] | Oleg Akimenko | Christopher Lampert | Kundenverwaltung | + +### 6.3 Annahmen und Abhängigkeiten + +**Annahmen** (gelten als gegeben; sind sie nicht erfüllt, ist eine Re-Planung erforderlich): + +| ID | Annahme | +|----|---------------------------------------------------------------------------------------------------------------| +| A1 | Alle Teammitglieder bringen mindestens 2 h/Woche über die gesamte Projektlaufzeit ein. | +| A2 | Gitty, Discord und die lokale Entwicklungsumgebung sind während der gesamten Laufzeit verfügbar. | +| A3 | Der Auftraggeber steht für Rückfragen wöchentlich per E-Mail erreichbar (siehe Kap. 11). | +| A4 | Die Endgeräte der Anwender erfüllen die in NF-PERF-03 genannten Referenzhardware-Anforderungen. | + +**Abhängigkeiten zwischen den Gruppen** (Integrationsreihenfolge): + +| Modul (Gruppe) | Hängt ab von | Wann benötigt? | +|--------------------------|-----------------------------------------------------------|----------------| +| Produktverwaltung (G) | — | M4 Start | +| Kundenverwaltung (H) | — | M4 Start | +| Dokumentenprozess (F) | Produktverwaltung (G), Kundenverwaltung (H) – Datenmodell | M4 Mitte | +| GUI (E) | alle drei Backend-Module – Schnittstellen | M4 Mitte → M5 | + +Schnittstellen zwischen den Modulen werden bis Ende M2 (22.05.2026) als Schnittstellenkontrakte festgelegt. --- ## 7. Vorgehensmodell -Das Projekt orientiert sich am **V-Modell**. Auf der linken Seite des V werden die Anforderungs- und Entwurfsphasen durchlaufen (Anforderungsanalyse, Systemarchitektur, Detailentwurf, Implementierung), auf der rechten Seite die zugehörigen Testphasen (Komponenten-, Integrations-, Systemtest, Abnahmetest). Jede Entwicklungsphase wird so direkt mit der korrespondierenden Testphase verknüpft (Traceability gemäß Lastenheft, Kap. 8.4). +Das Projekt orientiert sich am **V-Modell**. Auf der linken Seite des V werden die Anforderungs- und Entwurfsphasen durchlaufen, auf der rechten Seite die zugehörigen Testphasen. Jede Entwicklungsphase wird direkt mit der korrespondierenden Testphase verknüpft (Traceability gemäß Lastenheft v1.0, Kap. 8.4). Die Phasen umfassen: -- Anforderungen (siehe Lastenheft v1.1) -- System- und Softwaredesign -- Implementierung -- Integration und Test -- Abnahme +- **Anforderungen** – Lastenheft v1.0 (Auftraggebersicht: was soll das System leisten) +- **Pflichtenheft / System-Spezifikation** – Antwortdokument des Auftragnehmers (wie wird es umgesetzt; siehe Lastenheft Kap. 1.4) +- **System- und Softwarearchitektur** +- **Detailentwurf (Moduldesign)** +- **Implementierung** +- **Komponenten- und Integrationstest** +- **Systemtest** (gegen Anforderungen, inkl. Lasttests NF-PERF) +- **Abnahme** (Akzeptanztests gegen Lastenheft) --- -## 8. Zeitplan und Meilensteine +## 8. Zeitplan, Meilensteine und Aufwand -Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet. Das Project Charter ist ein lebendes Dokument; bei Anpassungen wird eine neue Version erstellt. +Jeder Entwicklungsphase ist eine korrespondierende Testphase zugeordnet. Die letzte Woche (M7) ist als Puffer für Fehlerbeseitigung und Abnahmevorbereitung eingeplant. -| 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 | +| Nr. | Phase | Inhalt | Zeitraum | Aufwand (= Pers.-h) | +|-----|-----------------------------|--------------------------------------------------------------------------------|---------------------------|---------------------| +| M1 | Anforderungen | Lastenheft v1.0 (System- und Softwareanforderungen aus Auftraggebersicht) | 15.04.2026 – 15.05.2026 | 70 | +| M2 | Pflichtenheft & Architektur | Pflichtenheft, Systemarchitektur, Schnittstellenkontrakte zwischen den Gruppen | 16.05.2026 – 22.05.2026 | 35 | +| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, Dokumentenprozess, GUI) | 23.05.2026 – 29.05.2026 | 30 | +| M4 | Implementierung | Umsetzung aller Module im Code, parallel Komponententests | 30.05.2026 – 12.06.2026 | 90 | +| M5 | Integrationstest | Zusammenführung und Schnittstellentests | 13.06.2026 – 19.06.2026 | 30 | +| M6 | Systemtest | Prüfung gegen Anforderungen, Lasttests gemäß NF-PERF-01/02 | 20.06.2026 – 26.06.2026 | 30 | +| M7 | Puffer & Abnahme | Fehlerbehebung, Akzeptanztests, Präsentation, finale Abgabe | 27.06.2026 – 30.06.2026 | 25 | +| | | **Summe** | | **= 310** | + +Das Kapazitätsbudget bei 11 Personen × ca. 11 Wochen × 2,5 h beträgt ca. 300 h und entspricht damit knapp dem geschätzten Aufwand. Risiko Zeitverzug ist entsprechend als „Hoch / Mittel" eingestuft (siehe Kap. 9, R4). -> **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, Pair-Programming | -| Merge-Konflikte | Mittel / Mittel | Code Reviews, kurze Feature-Branches | -| Integrationsprobleme | Mittel / Mittel | Frühe Integrationstests, klare Schnittstellen | -| Zeitverzug | Hoch / Mittel | MVP-Fokus, wöchentliche Statusprüfung | +| ID | Risiko | Wahrsch. / Impact | Auslöser-Schwellwert / Indikator | Gegenmaßnahme | Verantwortlich | +|----|-----------------------------------------|-------------------|----------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|----------------------| +| R1 | Ausfall von Teammitgliedern | Mittel / Hoch | > 1 Person der Gruppe > 1 Woche ausgefallen | Pair-Programming, Wissensaustausch, Stellvertreter benannt (Kap. 6.2) | Gruppenleiter | +| R2 | Merge-Konflikte | Mittel / Mittel | Mehr als 2 ungelöste Konflikte/Woche pro Repo | Feature-Branches < 3 Tage, tägliche Pulls aus `main`, Code Reviews | Gruppenleiter | +| R3 | Integrationsprobleme | Mittel / Mittel | Schnittstellenkontrakt nicht bis Ende M2 vorhanden | Schnittstellenkontrakte vor Implementierung, frühe Mock-Integration ab M3 | Gruppe F + E | +| R4 | Zeitverzug | Hoch / Mittel | Meilenstein überschritten oder Backlog Soll/Ist > 20 % | MVP-Fokus, wöchentliche Statusprüfung, Pufferwoche M7 | Gesamtteam | +| R5 | Anforderungsänderung / Scope-Creep | Mittel / Hoch | > 2 nachträglich aufgenommene Muss-Anforderungen nach M2 | Anforderungs-Freeze für Muss-Anforderungen nach M2; Änderungswesen Kap. 2.2 | Auftraggeber + Team | +| R6 | Lernkurve Technologie-Stack | Hoch / Mittel | Spike in M2 nicht lauffähig | Spike-Sample je Gruppe in M2; gemeinsame Coding-Standards; gegenseitige Code Reviews | Gruppenleiter | +| R7 | DSGVO- / § 14 UStG-Compliance-Verstoß | Niedrig / Hoch | Akzeptanztest GR-01 oder AT-DP-05 fehlgeschlagen | Pflichtangaben in BA-DP-05 fest verdrahtet; NF-SEC-02-Funktion implementiert; Review-Checkliste GR-01 bis GR-06 | Gruppe F | +| R8 | Datenverlust auf lokalem System | Mittel / Hoch | Datenbestand seit > 48 h nicht gesichert | Tägliche Sicherung der lokalen Datendatei in Gitty-Branch `data-snapshots`; Testdatensätze ebenfalls in Gitty | Gruppe G + H | +| R9 | Ausfall Gruppenleiter | Niedrig / Hoch | Gruppenleiter > 1 Woche nicht erreichbar | Stellvertreter benannt (Kap. 6.2); wöchentliche Gruppenleiter-Synchronisation; Repository-Rechte für Stellvertreter | Gesamtteam | --- @@ -160,21 +212,22 @@ Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet. Das Project **Rahmenbedingungen:** -- Umsetzung aller Pflichtmodule -- saubere Repository-Struktur -- teamübergreifende Integration -- dokumentierter Entwicklungsprozess +- Umsetzung aller Pflichtmodule (Produktverwaltung, Kundenverwaltung, Dokumentenprozess, GUI) +- saubere Repository-Struktur (pro Gruppe ein Repo, einheitliche Namenskonvention) +- teamübergreifende Integration über vereinbarte Schnittstellenkontrakte +- dokumentierter Entwicklungsprozess (Lastenheft, Pflichtenheft, Architekturdokument) --- ## 11. Kommunikationswege -| Kanal | Zweck | Frequenz | -|--------------------|------------------|----------------| -| Discord / WhatsApp | Kommunikation | täglich | -| Gitty | Codeverwaltung | kontinuierlich | -| Meetings | Planung | wöchentlich | -| E-Mail | Betreuerkontakt | bei Bedarf | +| Kanal | Zweck | Frequenz | +|--------------------|-------------------------|----------------| +| Discord / WhatsApp | Tägliche Kommunikation | täglich | +| Gitty | Codeverwaltung, Reviews | kontinuierlich | +| Team-Meetings | Planung, Status | wöchentlich | +| Gruppenleiter-Sync | Koordination Gruppen | wöchentlich | +| E-Mail | Auftraggeber-Kontakt | bei Bedarf | --- @@ -183,20 +236,25 @@ Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet. Das Project Ein Feature gilt als abgeschlossen, wenn es - implementiert und funktionsfähig ist, -- getestet ist, -- ein Code-Review durchlaufen hat, -- dokumentiert ist, +- getestet ist und **für jede zugeordnete Muss-Anforderung mindestens ein Akzeptanztest erfolgreich durchlaufen wurde** (siehe Lastenheft Kap. 8.4), +- ein Code-Review durch ein anderes Teammitglied durchlaufen hat, +- dokumentiert ist (Code-Kommentare nach NF-MAINT-02; ggf. Eintrag im Pflichtenheft), - in das Gesamtsystem integriert ist. --- ## 13. Abnahmekriterien -- alle Pflichtmodule implementiert -- vollständiger Dokumentenprozess vorhanden -- GUI funktionsfähig -- Tests erfolgreich -- Präsentation bestanden +Das System gilt als abgenommen, wenn alle folgenden Kriterien erfüllt sind: + +1. Alle Pflichtmodule (Produkt-, Kundenverwaltung, Dokumentenprozess, GUI) sind implementiert und in das Gesamtsystem integriert. +2. Der vollständige Dokumentenprozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung ist durchgängig demonstrierbar. +3. Die GUI ist funktionsfähig und ermöglicht den vollständigen PDF-Export aller Belege. +4. Alle Muss-Anforderungen sind durch zugeordnete Akzeptanztests aus Lastenheft Kap. 8.4 nachgewiesen. +5. Die Lasttests gemäß NF-PERF-01 und NF-PERF-02 sind mit dem geforderten Datenbestand erfolgreich durchgeführt. +6. Lastenheft v1.0 sowie Pflichtenheft / Architekturdokument liegen in finaler freigegebener Version vor. +7. Die Traceability-Matrix (Lastenheft Kap. 8.4) ordnet jeder Muss-Anforderung mindestens einen Akzeptanztest zu. +8. Die Abnahmepräsentation gegenüber dem Auftraggeber ist erfolgreich durchgeführt. --- @@ -206,9 +264,8 @@ Je Untergruppe unterzeichnet ausschließlich der jeweilige **Gruppenleiter** (si | Rolle | Name | Unterschrift | Datum | |------------------------|------------------------|---------------------------------|-----------| -| Betreuer | Prof. Dr. Gerd Marmitt | ______________________________ | _________ | +| Auftraggeber | Prof. Dr. Gerd Marmitt | ______________________________ | _________ | | Gruppenleiter Gruppe E | Nicolas Seelinger | ______________________________ | _________ | | Gruppenleiter Gruppe F | Andreas Ivanovic | ______________________________ | _________ | | Gruppenleiter Gruppe G | Lulia Silk | ______________________________ | _________ | | Gruppenleiter Gruppe H | Oleg Akimenko | ______________________________ | _________ | -