Korrigiere kleinere Formulierungen

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, 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 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: Eine Testperson 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: Eine Testperson ändert einen Adressbestandteil und speichert; anschließend versucht sie, 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: Eine Testperson ä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: Eine Testperson 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: Eine Testperson 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: Eine Testperson 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: Eine Testperson 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: Eine Testperson 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: Eine Testperson 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.
+Vorbedingung: Eine Rechnung im Status „offen“ existiert im System.
-Aktion: Anwender:in wählt die Rechnung aus und führt die Stornierung durch.
+Aktion: Eine Testperson 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.
+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.
 
 ---

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)
+- Der Code wurde von mindestens einem anderen Teammitglied geprüft (Pull Request)
-- Die Änderungen sind in den `main`-Branch gemergt
+- 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 |
+| **3** | Komponentenentwurf | UI/UX-Mockups, Datenbankdesign, Pflichtenheft |
-| **4** | Implementierung | Produkt-, Kundenverwaltung, Dokumentenzyklus, UI |
+| **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: ____________