3028868
/
SE1_Team_2
5
5
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Commit

main
3027248 2026-05-15 10:03:23 +02:00
parent 88b90265a9
commit a76b149f1b
2 changed files with 173 additions and 101 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

114
Lastenheft/Lastenheft_v1_0.md
View File

@ -22,23 +22,23 @@ numbersections: false
**Version:** 1.0 **Version:** 1.0
**Stand:** 14.05.2026 **Stand:** 14.05.2026
**Autor:** Christopher Lampert **Autor:** Christopher Lampert
**Bezug:** Project Charter v1.2 (14.05.2026) – Fakturierungssystem **Bezug:** Project Charter v1.1 (14.05.2026) – Fakturierungssystem
--- ---
## Freigabeübersicht ## Freigabeübersicht
| Ersteller | Prüfer | Freigebender | | Ersteller | Prüfer | Freigebender |
|------------------------|---------------------------|--------------------------------| |---------------------|------------------------|---------------------------|
| Christopher Lampert | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) | | Christopher Lampert | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter)|
--- ---
## Dokumentenhistorie ## Dokumentenhistorie
| Version | Datum | Autor | Änderung | | Version | Datum | Autor | Änderung |
|---------|------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |---------|------------|---------------------|-----------------------------------------------------------------------------------------------------------|
| 1.0 | 12.05.2026 | Christopher Lampert | Initiale Erstellung des Lastenhefts auf Basis Project Charter v1.1 Ausarbeitung Kap. 4 (funktionale Anforderungen) gemäß Anforderungsliste; Traceability-Matrix gefüllt | | 1.0 | 12.05.2026 | Christopher Lampert | Initiale Erstellung des Lastenhefts auf Basis Project Charter v1.1 |
--- ---
@ -59,7 +59,7 @@ Das Lastenheft ist – soweit möglich – technologie- und lösungsneutral form
Übernommen und verfeinert aus Charter v1.2, Kapitel 4: Übernommen und verfeinert aus Charter v1.2, Kapitel 4:
| Nr. | Ziel | Erfolgskriterium | | Nr. | Ziel | Erfolgskriterium |
|-----|----------------------|---------------------------------------------------------------------------------------------------| |-----|----------------------|---------------------------------------------------------------------------------------------------------------|
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden | | Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden |
| Z2 | Kundenverwaltung | Kundendaten sind vollständig anlegbar, änderbar, löschbar und auffindbar | | 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 | | Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung wird unterstützt |
@ -112,7 +112,7 @@ Das Fakturierungssystem wird als **lokal installierte Einbenutzer-Anwendung** au
Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieben wird, beschränken sich die Schnittstellen auf: Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieben wird, beschränken sich die Schnittstellen auf:
| Schnittstelle | Zweck | Art | | Schnittstelle | Zweck | Art |
|-----------------------------|---------------------------------------------------------|----------------------| |----------------------------------|----------------------------------------------------|----------------------|
| Benutzerschnittstelle (GUI) | Interaktion mit dem Anwender | UI | | Benutzerschnittstelle (GUI) | Interaktion mit dem Anwender | UI |
| Lokales Dateisystem | Persistierung der Daten (Stammdaten, Dokumente) | Datei-Schnittstelle | | Lokales Dateisystem | Persistierung der Daten (Stammdaten, Dokumente) | Datei-Schnittstelle |
| Druck- bzw. Export-Schnittstelle | Erzeugung druckbarer Dokumente (z. B. PDF) | Ausgabeschnittstelle | | Druck- bzw. Export-Schnittstelle | Erzeugung druckbarer Dokumente (z. B. PDF) | Ausgabeschnittstelle |
@ -145,7 +145,7 @@ Da das System gemäß Charter (Nicht-Ziele) ohne externe Systemanbindung betrieb
### 3.1 Stakeholder ### 3.1 Stakeholder
| ID | Stakeholder | Beschreibung | Interesse | | ID | Stakeholder | Beschreibung | Interesse |
|----|-------------------|------------------------------------|-------------------------------------------------| |----|-------------------|----------------------------------------|-----------------------------------------------|
| S1 | Auftraggeber | Prof. Dr. Gerd Marmitt | Lehrziele erreicht, Abnahmekriterien erfüllt | | S1 | Auftraggeber | Prof. Dr. Gerd Marmitt | Lehrziele erreicht, Abnahmekriterien erfüllt |
| S2 | Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) | Erfolgreiche Umsetzung, Lernzielerreichung | | S2 | Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) | Erfolgreiche Umsetzung, Lernzielerreichung |
| S3 | Endnutzer | spätere Anwender (kleines Unternehmen) | Funktionierender Fakturierungsablauf | | S3 | Endnutzer | spätere Anwender (kleines Unternehmen) | Funktionierender Fakturierungsablauf |
@ -193,6 +193,18 @@ Als Anwender muss ich bestehende Produktdaten bearbeiten können, um veraltete o
Akzeptanztests: AT-PV-03 (Preis ändern), AT-PV-04 (Persistenz nach Neuöffnen). Akzeptanztests: AT-PV-03 (Preis ändern), 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.
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.
Akzeptanztests: AT-PV-07 (Sicherheitsabfrage), AT-PV-08 (Produkt nicht mehr auffindbar).
### 4.2 Modul Kundenverwaltung (Gruppe H) ### 4.2 Modul Kundenverwaltung (Gruppe H)
**BA-KV-01 – Kunde anlegen (Muss)** **BA-KV-01 – Kunde anlegen (Muss)**
@ -207,6 +219,18 @@ Als Anwender muss ich bestehende Kundendaten bearbeiten können, um veraltete od
Akzeptanztests: AT-KV-03 (Telefonnummer ändern), AT-KV-04 (Persistenz). Akzeptanztests: AT-KV-03 (Telefonnummer ändern), AT-KV-04 (Persistenz).
**BA-KV-03 – Kunde suchen (Muss)**
Als Anwender muss ich nach Kunden suchen können, um Kundendaten schnell zu finden. Die Anforderung gilt, wenn der Anwender einen Suchbegriff in das Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn Kunden über Namen oder Kundennummer gefunden werden und bei einer ungültigen Eingabe der Hinweis „Kein Kunde gefunden" erscheint.
Akzeptanztests: AT-KV-05 (Treffer), AT-KV-06 (kein Treffer).
**BA-KV-04 – Kunde löschen (Muss)**
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).
### 4.3 Modul Dokumentenprozess (Gruppe F) ### 4.3 Modul Dokumentenprozess (Gruppe F)
#### 4.3.1 Angebot #### 4.3.1 Angebot
@ -217,13 +241,41 @@ Als Anwender muss ich ein Angebot für einen Kunden erstellen können, um Kunden
Akzeptanztest: AT-DP-01 (Angebot mit einer Position; korrekte Summen). Akzeptanztest: AT-DP-01 (Angebot mit einer Position; korrekte Summen).
**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.
Akzeptanztest: AT-DP-02 (Status persistent nach Neustart).
#### 4.3.2 Auftragsbestätigung #### 4.3.2 Auftragsbestätigung
**BA-DP-02 – Auftragsbestätigung aus Angebot erzeugen (Muss)** **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 und das Vorgängerangebot referenziert ist.
Akzeptanztest: AT-DP-02 (Datenübernahme komplett, Referenz vorhanden). Akzeptanztest: AT-DP-03 (Datenübernahme komplett, Referenz vorhanden).
#### 4.3.3 Lieferschein
**BA-DP-04 – Lieferschein aus Auftragsbestätigung erzeugen (Muss)**
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).
#### 4.3.4 Rechnung
**BA-DP-05 – Rechnung aus Lieferschein erzeugen (Muss)**
Als Anwender muss ich aus einem Lieferschein eine Rechnung erzeugen können, um die Forderung gegenüber dem Kunden zu stellen. Die Anforderung gilt, wenn ein Lieferschein mit Status „geliefert" vorliegt. Die Anforderung gilt als erfüllt, wenn eine Rechnung mit allen Pflichtangaben nach § 14 UStG, eindeutiger Rechnungsnummer und Referenz auf den Lieferschein erzeugt ist.
Akzeptanztest: AT-DP-05 (Pflichtangaben vollständig; Rechnungsnummer eindeutig gemäß GR-02).
**BA-DP-06 – Automatisches Rechnungsdatum (Muss)**
Als Anwender muss ich beim Erzeugen einer Rechnung das aktuelle Rechnungsdatum automatisch gesetzt bekommen, um konsistente Buchungsdaten zu gewährleisten. Die Anforderung gilt, wenn der Anwender eine neue Rechnung anlegt. Die Anforderung gilt als erfüllt, wenn das Rechnungsdatum beim Anlegen automatisch auf das aktuelle Systemdatum gesetzt und dauerhaft gespeichert wird.
Akzeptanztest: AT-DP-06 (Rechnungsdatum entspricht Systemdatum).
### 4.4 Modul GUI / Programmoberfläche (Gruppe E) ### 4.4 Modul GUI / Programmoberfläche (Gruppe E)
@ -239,6 +291,18 @@ Als Anwender muss ich Angebote über die GUI in Aufträge umwandeln können, ohn
Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung). Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
**BA-GUI-03 – Rechnungslegung und Statusanzeige (Muss)**
Als Anwender muss ich über die GUI aus einem Lieferschein eine Rechnung erzeugen und deren Status einsehen können, um den Abrechnungsfortschritt zu verfolgen. Die Anforderung gilt, wenn ein abrechnungsreifer Lieferschein vorliegt. Die Anforderung gilt als erfüllt, wenn die GUI vor dem finalen Speichern eine Druckvorschau anzeigt und der Auftragsstatus in der Übersicht durch ein grünes Icon als „Abgeschlossen" markiert wird.
Akzeptanztests: AT-GUI-04 (Druckvorschau), AT-GUI-05 (Status-Icon).
**BA-GUI-04 – Belegsuche mit Echtzeit-Filterung (Muss)**
Als Anwender muss ich Belege über eine Suchfunktion filtern können, um Dokumente schnell aufzurufen. Die Anforderung gilt, wenn der Anwender Suchbegriffe in das GUI-Suchfeld eingibt. Die Anforderung gilt als erfüllt, wenn die Trefferliste tabellarisch dargestellt wird, sich bei Eingabe von Name oder Nummer sofort aktualisiert und bei einer ungültigen Suche der Text „Keine Treffer gefunden" erscheint.
Akzeptanztests: AT-GUI-06 (Echtzeit-Filter), AT-GUI-07 (Hinweis bei leerer Trefferliste).
--- ---
## 5. Qualitätsanforderungen (nicht-funktionale Anforderungen) ## 5. Qualitätsanforderungen (nicht-funktionale Anforderungen)
@ -246,7 +310,7 @@ Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
### 5.1 Usability (NF-USE) ### 5.1 Usability (NF-USE)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | 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-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-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-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. |
@ -254,7 +318,7 @@ Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
### 5.2 Performance (NF-PERF) ### 5.2 Performance (NF-PERF)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | 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-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-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-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. |
@ -262,7 +326,7 @@ Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
### 5.3 Wartbarkeit (NF-MAINT) ### 5.3 Wartbarkeit (NF-MAINT)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | 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-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-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. | | NF-MAINT-03 | Das System MUSS einer dokumentierten, dreischichtigen Architektur (Präsentation, Logik, Datenhaltung) folgen. | Muss | AT-NF-09: Review des Architekturdokuments; nachweisbare Schichtentrennung. |
@ -270,7 +334,7 @@ Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
### 5.4 Testbarkeit (NF-TEST) ### 5.4 Testbarkeit (NF-TEST)
| ID | Anforderung | Prio | Akzeptanzkriterium / 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-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-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 %. | | NF-TEST-03 | Mindestens 30 % der Geschäftslogik-Methoden SOLLEN durch automatisierte Tests abgedeckt sein (Line Coverage). | Soll | AT-NF-12: Coverage-Report > 30 %. |
@ -278,21 +342,21 @@ Akzeptanztest: AT-GUI-03 (Datenübernahme und Markierung).
### 5.5 Versionierung (NF-VER) ### 5.5 Versionierung (NF-VER)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | 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.2 (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. | | 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) ### 5.6 Architektur und Datenhaltung (NF-ARCH)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | 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-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 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. |
### 5.7 Sicherheit und Datenschutz (NF-SEC) ### 5.7 Sicherheit und Datenschutz (NF-SEC)
| ID | Anforderung | Prio | Akzeptanzkriterium / Test | | 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-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. | | 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. |
@ -339,7 +403,7 @@ Die folgenden Datenobjekte bilden den fachlichen Kern des Systems. Eine Darstell
### 6.2 Beziehungen zwischen Datenobjekten ### 6.2 Beziehungen zwischen Datenobjekten
| Beziehung | Multiplizität | | Beziehung | Multiplizität |
|-----------------------------------------------------------------|---------------| |--------------------------------------------------------------------|-----------------|
| Kunde &rarr; Angebot | 1 : n | | Kunde &rarr; Angebot | 1 : n |
| Angebot &rarr; Auftragsbestätigung | 1 : 0..1 | | Angebot &rarr; Auftragsbestätigung | 1 : 0..1 |
| Auftragsbestätigung &rarr; Lieferschein | 1 : 0..1 | | Auftragsbestätigung &rarr; Lieferschein | 1 : 0..1 |
@ -411,7 +475,7 @@ Aus Charter v1.2 (Kap. 13) werden die folgenden Abnahmekriterien übernommen und
Das System gilt als **abgenommen**, wenn alle folgenden Kriterien erfüllt sind: Das System gilt als **abgenommen**, wenn alle folgenden Kriterien erfüllt sind:
| ID | Akzeptanzkriterium | Bezug | | 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-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-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 &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung kann anhand eines Beispielkunden und -produkts durchgängig demonstriert werden. | Kap. 4.3 | | AK-03 | Der vollständige Dokumentenprozess Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung kann anhand eines Beispielkunden und -produkts durchgängig demonstriert werden. | Kap. 4.3 |
@ -500,12 +564,22 @@ Verkürzte Darstellung gemäß Vorlesung Woche 6. Die vollständige Matrix wird
|-------------|----------------|----------------------------| |-------------|----------------|----------------------------|
| BA-PV-01 | funktional | AT-PV-01, AT-PV-02 | | BA-PV-01 | funktional | AT-PV-01, AT-PV-02 |
| BA-PV-02 | funktional | AT-PV-03, AT-PV-04 | | BA-PV-02 | funktional | AT-PV-03, AT-PV-04 |
| BA-PV-03 | funktional | AT-PV-05, AT-PV-06 |
| BA-PV-04 | funktional | AT-PV-07, AT-PV-08 |
| BA-KV-01 | funktional | AT-KV-01, AT-KV-02 | | BA-KV-01 | funktional | AT-KV-01, AT-KV-02 |
| BA-KV-02 | funktional | AT-KV-03, AT-KV-04 | | BA-KV-02 | funktional | AT-KV-03, AT-KV-04 |
| BA-KV-03 | funktional | AT-KV-05, AT-KV-06 |
| BA-KV-04 | funktional | AT-KV-07, AT-KV-08 |
| BA-DP-01 | funktional | AT-DP-01 | | BA-DP-01 | funktional | AT-DP-01 |
| BA-DP-02 | funktional | AT-DP-02 | | BA-DP-02 | funktional | AT-DP-02 |
| BA-DP-03 | funktional | AT-DP-03 |
| BA-DP-04 | funktional | AT-DP-04 |
| BA-DP-05 | funktional | AT-DP-05 |
| BA-DP-06 | funktional | AT-DP-06 |
| BA-GUI-01 | funktional | AT-GUI-01, AT-GUI-02 | | BA-GUI-01 | funktional | AT-GUI-01, AT-GUI-02 |
| BA-GUI-02 | funktional | AT-GUI-03 | | 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 |
| GR-01 | Geschäftsregel | AT-GR-01 | | GR-01 | Geschäftsregel | AT-GR-01 |
| GR-02 | Geschäftsregel | AT-GR-02 | | GR-02 | Geschäftsregel | AT-GR-02 |
| GR-03 | Geschäftsregel | AT-GR-03 | | GR-03 | Geschäftsregel | AT-GR-03 |
@ -532,5 +606,3 @@ Verkürzte Darstellung gemäß Vorlesung Woche 6. Die vollständige Matrix wird
| NF-SEC-02 | Security | AT-NF-18 | | NF-SEC-02 | Security | AT-NF-18 |
--- ---
*Ende des Dokuments – Lastenheft v1.1.*

10
Project-Charter/project-charter_v1_1.md
View File

@ -58,7 +58,7 @@ Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell.
## 4. Projektziele ## 4. Projektziele
| Nr. | Ziel | Erfolgskriterium | | Nr. | Ziel | Erfolgskriterium |
|----|---------------------|---------------------------------------------------------------------------------------------------| |------|---------------------|-----------------------------------------------------------------------------------------------------|
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden | | Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden |
| Z2 | Kundenverwaltung | Kundendaten sind vollständig anlegbar, änderbar, löschbar und auffindbar | | Z2 | Kundenverwaltung | Kundendaten sind vollständig anlegbar, änderbar, löschbar und auffindbar |
| Z3 | Dokumentenworkflow | Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung wird durchgängig unterstützt | | Z3 | Dokumentenworkflow | Angebot &rarr; Auftragsbestätigung &rarr; Lieferschein &rarr; Rechnung wird durchgängig unterstützt |
@ -99,7 +99,7 @@ Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell.
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.
| Gruppe | Mitglieder | Gruppenleiter | Verantwortungsbereich | | Gruppe | Mitglieder | Gruppenleiter | Verantwortungsbereich |
|---|-----------------------------------------------------------------------------------------|----------------------|------------------------| |---------|-----------------------------------------------------------------------------------------|----------------------|-------------------------|
| E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | Nicolas Seelinger | Programmoberfläche | | E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | Nicolas Seelinger | Programmoberfläche |
| F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801] | Andreas Ivanovic | Dokumentenprozess | | 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 | | G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489] | Lulia Silk | Produktverwaltung |
@ -126,7 +126,7 @@ Die Phasen umfassen:
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 entsprechende Testphase zugeordnet. Das Project Charter ist ein lebendes Dokument; bei Anpassungen wird eine neue Version erstellt.
| Nr. | Phase | Inhalt | Datum | | Nr. | Phase | Inhalt | Datum |
|-----|--------------------|-----------------------------------------------------------------------------------------|-----------------------------| |-----|--------------------|------------------------------------------------------------------------------------|-----------------------------|
| M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen (Lastenheft) | 15.04.2026 – 15.05.2026 | | M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen (Lastenheft) | 15.04.2026 – 15.05.2026 |
| M2 | Architektur | Systemarchitektur und Schnittstellendesign | 22.05.2026 | | M2 | Architektur | Systemarchitektur und Schnittstellendesign | 22.05.2026 |
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | 29.05.2026 | | M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | 29.05.2026 |
@ -142,10 +142,10 @@ Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet. Das Project
## 9. Risikomanagement ## 9. Risikomanagement
| Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme | | Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme |
|-------------------------------|-----------------------------|----------------------------------------------| |-------------------------------|-----------------------------|-----------------------------------------------|
| Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch, Pair-Programming | | Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch, Pair-Programming |
| Merge-Konflikte | Mittel / Mittel | Code Reviews, kurze Feature-Branches | | Merge-Konflikte | Mittel / Mittel | Code Reviews, kurze Feature-Branches |
| Integrationsprobleme | Mittel / Mittel | Frühe Integrationstests, klare Schnittstellen| | Integrationsprobleme | Mittel / Mittel | Frühe Integrationstests, klare Schnittstellen |
| Zeitverzug | Hoch / Mittel | MVP-Fokus, wöchentliche Statusprüfung | | Zeitverzug | Hoch / Mittel | MVP-Fokus, wöchentliche Statusprüfung |
--- ---