diff --git a/Lastenheft.md b/Lastenheft.md index ae406a4..8738934 100644 --- a/Lastenheft.md +++ b/Lastenheft.md @@ -211,8 +211,8 @@ Die Anforderung gilt als erfüllt, wenn ich Kunde, mindestens eine Produktpositi **BA-14 – Rechnung stornieren** Als Anwender:in muss ich eine gespeicherte Rechnung stornieren können, um fehlerhafte oder nicht mehr gültige Rechnungen aus dem System zu entnehmen zu können. -Die Anforderung gilt, wenn eine Rechnung im Status „offen" im System gespeichert ist. -Die Anforderung gilt als erfüllt, wenn die Rechnung den Status „storniert" erhält, nicht mehr als offen gelistet wird und der Vorgang mit Datum und Benutzer protokolliert ist. +Die Anforderung gilt, wenn eine Rechnung im Status „offen“ im System gespeichert ist. +Die Anforderung gilt als erfüllt, wenn die Rechnung den Status „storniert“ erhält, nicht mehr als offen gelistet wird und der Vorgang mit Datum und Benutzer protokolliert ist. --- @@ -231,13 +231,13 @@ Das System soll die Erstellung eines beliebigen Dokumenttyps (Angebot, Auftragsb Das System soll nach dem Programmstart in **maximal 5 Sekunden** vollständig bedienbereit sein, bei einem Datenbestand gemäß Q-01. **Q-05 – Benutzbarkeit: Ersterstellung Rechnung** -Eine erstmalige Anwender:in soll eine vollständige Rechnung an einen neu angelegten Kunden in **unter 10 Minuten** im ersten Versuch ohne externe Hilfe erstellen können. Überprüfung durch Usability-Test mit mindestens **5 Testpersonen**. +Eine Person, die die Anwendung erstmals nutzt, soll eine vollständige Rechnung an einen neu angelegten Kunden in **unter 10 Minuten** im ersten Versuch ohne externe Hilfe erstellen können. Überprüfung durch Usability-Test mit mindestens **5 Testpersonen**. **Q-06 – Datensicherheit: Lokale Speicherung** Das System soll **100 %** der personenbezogenen und geschäftlichen Daten ausschließlich lokal auf dem Anwender-PC ablegen, ohne jede Datenübertragung an externe Dienste. Überprüfung durch Netzwerk-Monitoring während eines repräsentativen Nutzungslaufs. **Q-07 – Datenintegrität: Unveränderlichkeit versendeter Rechnungen** -Das System soll nach dem Versandstatus „versendet" einer Rechnung **jede inhaltliche Änderung ablehnen** und ausschließlich Korrekturen über Storno- oder Korrekturrechnungen ermöglichen, gemäß GoBD. +Das System soll nach dem Versandstatus „versendet“ einer Rechnung **jede inhaltliche Änderung ablehnen** und ausschließlich Korrekturen über Storno- oder Korrekturrechnungen ermöglichen, gemäß GoBD. **Q-08 – Wiederherstellbarkeit: Datenexport** Das System soll dem Anwender einen vollständigen Export aller Stamm- und Bewegungsdaten in einem offenen, dokumentierten Format ermöglichen, mit einer Exportdauer von **maximal 30 Sekunden** bei einem Datenbestand gemäß Q-01. @@ -278,7 +278,7 @@ Eine Anbindung an externe Online-Dienste, Cloud-Speicher oder Buchhaltungssystem Wenn eine neue Rechnung erzeugt wird, dann vergibt das System eine fortlaufende, lückenlose Rechnungsnummer auf Basis der höchsten bisher vergebenen Nummer (GoBD). **GR-02 – Unveränderlichkeit versendeter Dokumente** -Wenn ein Dokument den Status „versendet" hat, dann sind sämtliche inhaltlichen Änderungen ausgeschlossen; Korrekturen erfolgen ausschließlich über neue Dokumente (Storno, Korrekturrechnung). +Wenn ein Dokument den Status „versendet“ hat, dann sind sämtliche inhaltlichen Änderungen ausgeschlossen; Korrekturen erfolgen ausschließlich über neue Dokumente (Storno, Korrekturrechnung). **GR-03 – Steuerberechnung** Wenn eine Dokumentposition gespeichert wird, dann berechnet das System Netto-, Steuer- und Bruttobetrag automatisch auf Basis des dem Produkt zum Zeitpunkt der Dokumenterstellung zugeordneten Steuersatzes (Snapshot-Prinzip). @@ -300,56 +300,56 @@ Wenn eine neue Rechnung erstellt wird und kein abweichendes Zahlungsziel angegeb **AC-01 (zu BA-01, BA-04)** – *Kunde anlegen und auffinden* Vorbedingung: Anwendung gestartet, Modul Kundenverwaltung geöffnet. -Aktion: Anwender:in erfasst einen neuen Kunden mit Pflichtfeldern und speichert. +Aktion: Die Anwenderin bzw. der Anwender erfasst einen neuen Kunden mit Pflichtfeldern und speichert. Erwartet: Das System vergibt eine eindeutige Kundennummer, der Kunde erscheint in der Suchergebnisliste innerhalb von ≤ 1 Sekunde (gemäß Q-02). **AC-02 (zu BA-02, BA-03, GR-04)** – *Kunde ändern und Löschsperre* Vorbedingung: Ein Kunde mit mindestens einer verknüpften Rechnung existiert. -Aktion: Anwender:in ändert einen Adressbestandteil und speichert; anschließend versucht sie, den Kunden zu löschen. +Aktion: Die Anwenderin bzw. der Anwender ändert einen Adressbestandteil und speichert; anschließend wird versucht, den Kunden zu löschen. Erwartet: Das System speichert die Änderung erfolgreich, lehnt das Löschen ab und zeigt einen Hinweis mit der Anzahl verknüpfter Dokumente. **AC-03 (zu BA-05, BA-06, GR-02)** – *Produkt anlegen, ändern, Snapshot-Verhalten* Vorbedingung: Ein Produkt ist bereits in einer früheren Rechnung erfasst. -Aktion: Anwender:in ändert den Einzelpreis des Produkts und erstellt anschließend eine neue Rechnung mit diesem Produkt. +Aktion: Die Anwenderin bzw. der Anwender ändert den Einzelpreis des Produkts und erstellt anschließend eine neue Rechnung mit diesem Produkt. Erwartet: Die alte Rechnung behält den ursprünglichen Preis, die neue Rechnung übernimmt den geänderten Preis. **AC-04 (zu BA-07, BA-08)** – *Produkt löschen und suchen* Vorbedingung: Mindestens 100 Produkte sind im System. -Aktion: Anwender:in sucht ein Produkt anhand der Bezeichnung und löscht es (sofern unverknüpft). +Aktion: Die Anwenderin bzw. der Anwender sucht ein Produkt anhand der Bezeichnung und löscht es (sofern unverknüpft). Erwartet: Die Suchergebnisse erscheinen in ≤ 1 Sekunde (gemäß Q-02); das gelöschte Produkt erscheint anschließend nicht mehr in der Liste. **AC-05 (zu BA-09, Q-03)** – *Angebot erstellen und exportieren* Vorbedingung: Mindestens ein Kunde und 5 Produkte sind erfasst. -Aktion: Anwender:in erstellt ein Angebot mit 5 Positionen und exportiert es als PDF. +Aktion: Die Anwenderin bzw. der Anwender erstellt ein Angebot mit 5 Positionen und exportiert es als PDF. Erwartet: Das Angebot ist mit Angebotsnummer und korrekten Summen gespeichert; der PDF-Export ist in ≤ 2 Sekunden abgeschlossen (gemäß Q-03). **AC-06 (zu BA-10)** – *Auftragsbestätigung erstellen* Vorbedingung: Ein Angebot liegt vor. -Aktion: Anwender:in erstellt eine Auftragsbestätigung mit Übernahme aller Positionen. +Aktion: Die Anwenderin bzw. der Anwender erstellt eine Auftragsbestätigung mit Übernahme aller Positionen. Erwartet: Die Auftragsbestätigung ist mit eindeutiger Nummer gespeichert und als PDF exportierbar. **AC-07 (zu BA-11)** – *Lieferschein erstellen* Vorbedingung: Eine Auftragsbestätigung liegt vor. -Aktion: Anwender:in erstellt einen Lieferschein mit Lieferdatum. +Aktion: Die Anwenderin bzw. der Anwender erstellt einen Lieferschein mit Lieferdatum. Erwartet: Der Lieferschein ist mit eindeutiger Nummer und allen Positionsdaten gespeichert und als PDF exportierbar. **AC-08 (zu BA-12, GR-01, GR-06)** – *Rechnung erstellen mit Pflichtangaben* Vorbedingung: Kunde und mindestens eine Position liegen vor; letzte Rechnungsnummer = R-000123. -Aktion: Anwender:in erstellt eine Rechnung ohne abweichendes Zahlungsziel. +Aktion: Die Anwenderin bzw. der Anwender erstellt eine Rechnung ohne abweichendes Zahlungsziel. Erwartet: Die neue Rechnung trägt die Nummer R-000124, ein Zahlungsziel von 14 Tagen und alle Pflichtangaben gemäß § 14 UStG. **AC-09 (zu BA-13)** – *Geführte Rechnungserstellung* Vorbedingung: Mindestens ein Kunde und ein Produkt sind im System vorhanden. -Aktion: Anwender:in startet die Rechnungserstellung, wählt einen Kunden aus, erfasst eine Produktposition mit Menge, prüft Rechnungsdatum und Zahlungsziel und speichert nach Anzeige der Zusammenfassung. +Aktion: Die Anwenderin bzw. der Anwender startet die Rechnungserstellung, wählt einen Kunden aus, erfasst eine Produktposition mit Menge, prüft Rechnungsdatum und Zahlungsziel und speichert nach Anzeige der Zusammenfassung. Erwartet: Die Rechnung wird gespeichert; die Zusammenfassung enthält Kunde, Produktposition, Menge, Summen, Rechnungsdatum und Zahlungsziel. **AC-10 (zu BA-14)** – *Rechnung stornieren* -Vorbedingung: Eine Rechnung im Status „offen" existiert im System. -Aktion: Anwender:in wählt die Rechnung aus und führt die Stornierung durch. -Erwartet: Die Rechnung erhält den Status „storniert", erscheint nicht mehr in der Liste offener Rechnungen, und der Vorgang ist mit Datum protokolliert. +Vorbedingung: Eine Rechnung im Status „offen“ existiert im System. +Aktion: Die Anwenderin bzw. der Anwender wählt die Rechnung aus und führt die Stornierung durch. +Erwartet: Die Rechnung erhält den Status „storniert“, erscheint nicht mehr in der Liste offener Rechnungen, und der Vorgang ist mit Datum protokolliert. **AC-11 (zu Q-09)** – *Pflichtfeldhinweis korrigieren* -Vorbedingung: Die Formulare „Kunde anlegen", „Produkt anlegen" und „Rechnung erstellen" sind erreichbar. +Vorbedingung: Die Formulare „Kunde anlegen“, „Produkt anlegen“ und „Rechnung erstellen“ sind erreichbar. Aktion: Testpersonen versuchen in jedem Formular ohne jeweils ein Pflichtfeld zu speichern; anschließend ergänzen sie die fehlende Angabe und speichern erneut. Erwartet: Das System verhindert jeweils zuerst das Speichern und zeigt einen Hinweis mit dem Namen des fehlenden Pflichtfelds; in mindestens 80 % der Testdurchläufe gelingt die Korrektur ohne externe Hilfe im ersten Korrekturversuch. @@ -358,7 +358,7 @@ Das Projekt gilt als abgenommen, wenn: - alle Akzeptanzkriterien **AC-01 bis AC-11** erfolgreich durchlaufen wurden, - die Qualitätsanforderungen **Q-01 bis Q-09** durch entsprechende Tests bestätigt sind, -- der Abschlusspräsentation gemäß Project Charter (Meilenstein **M-07**) durch den Auftraggeber zugestimmt wurde, +- die Abschlusspräsentation gemäß Project Charter (Meilenstein **M-07**) durch den Auftraggeber abgenommen wurde, - die Traceability-Matrix (Anforderung ↔ Testfall) vollständig vorliegt. --- diff --git a/ProjectCharter.md b/ProjectCharter.md index 60abd6d..74797d6 100644 --- a/ProjectCharter.md +++ b/ProjectCharter.md @@ -107,8 +107,8 @@ Ein Feature gilt als **fertiggestellt**, wenn: - Der Code ist implementiert und funktioniert lokal - Unit Tests sind geschrieben und bestehen -- Der Code wurde von mindestens einem anderen Teammitglied reviewed (Pull Request) -- Die Änderungen sind in den `main`-Branch gemergt +- Der Code wurde von mindestens einem anderen Teammitglied geprüft (Pull Request) +- Die Änderungen sind in den `main`-Branch zusammengeführt - Die relevante Dokumentation wurde aktualisiert - Das Feature wurde manuell getestet @@ -137,8 +137,8 @@ Ein Feature gilt als **fertiggestellt**, wenn: |:--- |:--- |:--- | | **1** | Anforderungsanalyse | Project Charter, Stakeholder-Analyse, Lastenheft | | **2** | Systementwurf | Systemarchitektur, Technologiewahl | -| **3** | Komponentenentwurf | UI/UX Mockups, Datenbankdesign, Pflichtenheft | -| **4** | Implementierung | Produkt-, Kundenverwaltung, Dokumentenzyklus, UI | +| **3** | Komponentenentwurf | UI/UX-Mockups, Datenbankdesign, Pflichtenheft | +| **4** | Implementierung | Produkt- und Kundenverwaltung, Dokumentenzyklus, UI | | **5** | Integrationstest | Schnittstellentests, Modulübergreifende Tests | | **6** | Systemtest | Integrationstests, Systemvalidierung | | **7** | Abnahmetest | Abnahme durch Betreuer, Abschlusspräsentation | @@ -180,7 +180,7 @@ Jede Entwicklungsphase korrespondiert mit ihrer jeweiligen Testphase im Rahmen d ## Technologie-Stack -> **Hinweis:** Die endgültige Technologieentscheidung erfolgt im Rahmen des Systementwurfs (Meilenstein M-03). Der technologie-Stack wird dort vollständig ausgeführt und gehört inhaltlich zum Architekturdokument. +> **Hinweis:** Die endgültige Technologieentscheidung erfolgt im Rahmen des Systementwurfs (Meilenstein M-03). Der Technologie-Stack wird dort vollständig ausgeführt und gehört inhaltlich zum Architekturdokument. # Kommunikations- und Entscheidungswege @@ -188,13 +188,13 @@ Jede Entwicklungsphase korrespondiert mit ihrer jeweiligen Testphase im Rahmen d |--------------------------|--------------------------|---------------| | *Discord* | Team-Kommunikation | täglich | | *Wöchentliches Meeting* | Fortschrittsbesprechung | wöchentlich | -| *E-Mail* | Kommunikation mit Professor| bei Bedarf | +| *E-Mail* | Kommunikation mit Professor | bei Bedarf | --- # Genehmigung / Unterschriften -Mit ihrer Unterschrift bestätigen die Gruppenleiter im Namen ihrer jeweiligen Untergruppe, dass sie den Inhalt dieser Project Charta gelesen haben und damit einverstanden sind. +Mit ihrer Unterschrift bestätigen die Gruppenleiter im Namen ihrer jeweiligen Untergruppe, dass sie den Inhalt dieser Project Charter gelesen haben und damit einverstanden sind. **Betreuer/in:** ________________________________________ Datum: ____________