2023-10-05 11:42:24 +02:00
= Pflichtenheft
:project_name: Projektname
== __{project_name}__
[options="header"]
[cols="1, 1, 1, 1, 4"]
|===
|Version | Status | Bearbeitungsdatum | Autoren(en) | Vermerk
|0.1 | In Arbeit | 10.10.2021 | Autor | Initiale Version
|===
== Inhaltsverzeichnis
Dieses Dokument benötigt ein Inhaltsverzeichnis. Es existieren mehrere Einbindungsmöglichkeiten.
== Zusammenfassung
2023-10-17 20:18:08 +02:00
Ziel des Projekts „Cateringservice“ ist es, eine web-basierte Java-Applikation für den Catering-Service „Mampf“ zu entwickeln, welche folgende Hauptfunktionen beinhalten soll:
- Kundenverwaltung
- Personalverwaltung
- Personalzuteilung
- Termin- und Eventplanung inkl. Zubehör, Lebensmittelbedarf
- Abrechnungs- und Rechnungserstellung
Zudem soll die Software diverse nicht-funktionale Kriterien, wie folgt, erfüllen:
- einfache Bedienbarkeit
- Absturzsicherheit
- einfache Erweiterbarkeit
- nachvollziehbare Strukturierung
- hohe Codequalität
Die Software gilt als fertig entwickelt und auslieferungsbereit, wenn die folgend in diesem Dokument aufgelisteten Akzeptanztest bestanden sind, auf welche sich mit dem Kunden geeinigt wurde.
2023-10-05 11:42:24 +02:00
== Aufgabenstellung und Zielsetzung
Text aus Aufgabenstellung kopieren und ggfs. präzisieren.
Insbesondere ergänzen, welche Ziele mit dem Abschluss des Projektes erreicht werden sollen.
== Produktnutzung
In welchem Kontext soll das System später genutzt werden? Welche Rahmenbedingungen gelten?
Zusätzlich kurze Einleitung für fachfremde Personen
== Interessensgruppen (Stakeholders)
2023-10-25 16:05:50 +02:00
Eine Liste aller realen und juristischen Personen(-gruppen),
die Einfluss auf die Anforderungen im Projekt haben.
Die Prioritäten bringen die Interessensgruppen in eine Rangfolge,
wobei eine niedrigere Zahl eine höhere Priorität darstellt.
[options="header", cols="2, ^1, 4, 4"]
|===
|Name
|Priorität
|Beschreibung
|Ziele
|{company_name}
|1
|Der Kunde des Projektes.
a|
- Vereinfachung des Betriebsablaufes
- Steigerung der Effizienz
- Möglichkeit der Expansion
|Mitarbeitende von {company_name}
|2
|Personen, die die Software verwenden
a|
- Einfache Bedienung
- Zuverlässige Funktion
|Kunden von {company_name}
|3
|Personen(-gruppen), deren Auftrage in der Software verwaltet werden
a|
- Guter Service
|===
2023-10-05 11:42:24 +02:00
== Systemgrenze und Top-Level-Architektur
=== Kontextdiagramm
2023-10-17 20:18:08 +02:00
image::models/analysis/systemContextDiagram.svg[]
2023-10-05 11:42:24 +02:00
=== Top-Level-Architektur
2023-10-17 20:18:08 +02:00
image::models/analysis/topLevelArchitecture.svg[]
2023-10-05 11:42:24 +02:00
== Anwendungsfälle
=== Akteure
2023-10-18 19:12:56 +02:00
[cols="1h,3"]
|===
|Nutzer
|Ist jede Person, die mit dem System interagiert - unabhängig, ob Sie eine Zugriffsberechtigung hat oder nicht.
2023-10-05 11:42:24 +02:00
2023-10-18 19:12:56 +02:00
|Registrieter Nutzer
|Ist jede Person, die eine Zugriffsberechtigung auf das System hat. Die Berechtigungen für diese Person sind begrenzt.
|Boss / Admin
|Ein registrieter Nutzer mit uneingeschränkten Berechtigungen.
|===
=== Anwendungsfalldiagramm / Use-Case Diagram
image::models/analysis/useCaseDiagram.svg[]
=== Anwendungsfallbeschreibung
===== Kundenverwaltung
[cols="1h,2"]
|===
|ID
|[UC0101]
|Name
|Kundendaten bearbeiten
|Beschreibung
|Der Nutzer verfügt über die Berechtigung die Daten eines Kunden (z.B. Rechnungsadresse) zu bearbeiten.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0102]
|Name
|Kundendaten einsehen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung die Daten eines Kunden einzusehen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0103]
|Name
|Kunden entfernen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen Kunden aus dem System zu entfernen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0104]
|Name
|Kunden hinzufügen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen neuen Kunden dem System hinzuzufügen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
2023-10-05 11:42:24 +02:00
|===
2023-10-18 19:12:56 +02:00
===== Personalverwaltung
[cols="1h,2"]
2023-10-05 11:42:24 +02:00
|===
2023-10-18 19:12:56 +02:00
|ID
|[UC0201]
|Name
|Personal hinzufügen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen Angestelten dem System hinzuzufügen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0202]
|Name
|Personaldaten bearbeiten
|Beschreibung
|Der Nutzer verfügt über die Berechtigung die personbezogenen Daten eines Angestelten zu ändern (z.B. die Adresse).
2023-10-05 11:42:24 +02:00
2023-10-18 19:12:56 +02:00
|Akteure
|Registrieter Nutzer
2023-10-05 11:42:24 +02:00
2023-10-18 19:12:56 +02:00
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0203]
|Name
|Personaldaten einsehen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung die personbezogenen Daten eines Angestelten einzusehen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0204]
|Name
|Personal entfernen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen Angestelten aus dem System zu entfernen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0205]
|Name
|Personal einem Auftrag zuordnen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen Angestelten für einen Auftrag einzuteilen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
===== Rechnungswesen
[cols="1h,2"]
|===
|ID
|[UC0301]
|Name
|Rechnung hinzufügen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung eine Rechnung dem System hinzuzufügen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0302]
|Name
|Rechnungen bearbeiten
|Beschreibung
|Der Nutzer verfügt über die Berechtigung eine bereits vorhandene Rechnung zu bearbeiten.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0303]
|Name
|Rechnung bezahlen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung eine Rechnung als bezahlt einzustufen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0304]
|Name
|Rechnung einsehen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung den Inhalt einer Rechnung einzusehen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
===== Auftragverwaltung
[cols="1h,2"]
|===
|ID
|[U0401]
|Name
|Auftragsdaten bearbeiten
|Beschreibung
|Der Nutzer verfügt über die Berechtigung den Inhalt eines vorhandenen Auftrags zubearbeiten.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0402]
|Name
|Auftragsdaten einsehen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung den Inhalt eines vorhandenen Auftrags einzusehen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0403]
|Name
|Auftrag entfernen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen vorhandenen Auftrag aus dem System zu entfernen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0404]
|Name
|Auftrag hinzufügen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung einen Auftrag dem System hinzuzufügen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
===== Inventarverwaltung
[cols="1h,2"]
|===
|ID
|[UC0501]
|Name
|Inventar einsehen
|Beschreibung
|Der Nutzer verfügt über die Berechtigung das Inventar einzusehen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0502]
|Name
|Inventar bearbeiten
|Beschreibung
|Der Nutzer verfügt über die Berechtigung den Inhalt des Inventars zu bearbeiten.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
===== Administration
[cols="1h,2"]
|===
|ID
|[UC0601]
|Name
|Registrieten Nutzer hinzufügen
|Beschreibung
|Der Admin verfügt über die Berechtigung einen registrieten Nutzer anzulegen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0602]
|Name
|Registrieten Nutzer entfernen
|Beschreibung
|Der Admin verfügt über die Berechtigung einen registrieten Nutzer aus dem System zu entfernen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
====== Oberfläche
[cols="1h,2"]
|===
|ID
|[UC0701]
|Name
|Login
|Beschreibung
|Der Nutzer verfügt über die Berechtigung die Login-Page aufzurufen.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
[cols="1h,2"]
|===
|ID
|[UC0702]
|Name
|Logout
|Beschreibung
|Der Nutzer verfügt über die Berechtigung sich abzumelden.
|Akteure
|Registrieter Nutzer
|Trigger
|
|Bedingungen
|
|Essizielle Schritte
|
|Erweiterungen
|
|Funkionale Vorraussetzungen
|
|===
2023-10-05 11:42:24 +02:00
== Funktionale Anforderungen
=== Muss-Kriterien
Was das zu erstellende Programm auf alle Fälle leisten muss.
=== Kann-Kriterien
Anforderungen die das Programm leisten können soll, aber für den korrekten Betrieb entbehrlich sind.
== Nicht-Funktionale Anforderungen
=== Qualitätsziele
2023-10-17 20:18:08 +02:00
[options="header"]
[cols="4,1"]
|===
| Qualitätsziel | Priorität (hoch - mittel - gering)
| einfache Bedienbarkeit (für Nicht-Informatiker) | hoch
| Absturzsicherheit | hoch
| einfache Erweiterbarkeit | mittel
| nachvollziehbare Strukturierung | mittel
| hohe Codequalität | mittel
|===
2023-10-05 11:42:24 +02:00
=== Konkrete Nicht-Funktionale Anforderungen
Beschreiben Sie Nicht-Funktionale Anforderungen, welche dazu dienen, die zuvor definierten Qualitätsziele zu erreichen.
Achten Sie darauf, dass deren Erfüllung (mindestens theoretisch) messbar sein muss.
2023-10-17 20:18:08 +02:00
==== Einfache Bedienbarkeit
- Interaktion vollständig über Knöpfe und Textfelder
- fehlerhafte Nutzereingaben werden dem Nutzer direkt mitgeteilt
- intuitives Design z. B. des Menüs
==== Absturzsicherheit
- fehlerhafte Eingaben der Nutzer dürfen nicht zu Abstürzen führen
==== Einfache Erweiterbarkeit
- Software muss so entworfen sein, dass einfach neue Produkte oder Dienstleistungen ergänzt werden können
==== Nachvollziehbare Strukturierung
- das Design der Software muss sich an bekannten und geeigneten Entwurfsmustern orientieren
==== Hohe Codequalität
- verständliche Dokumentation von Objekten und dessen Methoden
2023-10-05 11:42:24 +02:00
== GUI Prototyp
In diesem Kapitel soll ein Entwurf der Navigationsmöglichkeiten und Dialoge des Systems erstellt werden.
Idealerweise entsteht auch ein grafischer Prototyp, welcher dem Kunden zeigt, wie sein System visuell umgesetzt werden soll.
Konkrete Absprachen - beispielsweise ob der grafische Prototyp oder die Dialoglandkarte höhere Priorität hat - sind mit dem Kunden zu treffen.
=== Überblick: Dialoglandkarte
Erstellen Sie ein Übersichtsdiagramm, das das Zusammenspiel Ihrer Masken zur Laufzeit darstellt. Also mit welchen Aktionen zwischen den Masken navigiert wird.
//Die nachfolgende Abbildung zeigt eine an die Pinnwand gezeichnete Dialoglandkarte. Ihre Karte sollte zusätzlich die Buttons/Funktionen darstellen, mit deren Hilfe Sie zwischen den Masken navigieren.
=== Dialogbeschreibung
Für jeden Dialog:
1. Kurze textuelle Dialogbeschreibung eingefügt: Was soll der jeweilige Dialog? Was kann man damit tun? Überblick?
2. Maskenentwürfe (Screenshot, Mockup)
3. Maskenelemente (Ein/Ausgabefelder, Aktionen wie Buttons, Listen, …)
4. Evtl. Maskendetails, spezielle Widgets
== Datenmodell
=== Überblick: Klassendiagramm
2023-10-25 16:06:45 +02:00
image::models/analysis/domain.svg[]
2023-10-05 11:42:24 +02:00
=== Klassen und Enumerationen
Dieser Abschnitt stellt eine Vereinigung von Glossar und der Beschreibung von Klassen/Enumerationen dar. Jede Klasse und Enumeration wird in Form eines Glossars textuell beschrieben. Zusätzlich werden eventuellen Konsistenz- und Formatierungsregeln aufgeführt.
// See http://asciidoctor.org/docs/user-manual/#tables
[options="header"]
|===
|Klasse/Enumeration |Beschreibung |
|… |… |
|===
== Akzeptanztestfälle
Mithilfe von Akzeptanztests wird geprüft, ob die Software die funktionalen Erwartungen und Anforderungen im Gebrauch erfüllt. Diese sollen und können aus den Anwendungsfallbeschreibungen und den UML-Sequenzdiagrammen abgeleitet werden. D.h., pro (komplexen) Anwendungsfall gibt es typischerweise mindestens ein Sequenzdiagramm (welches ein Szenarium beschreibt). Für jedes Szenarium sollte es einen Akzeptanztestfall geben. Listen Sie alle Akzeptanztestfälle in tabellarischer Form auf.
Jeder Testfall soll mit einer ID versehen werde, um später zwischen den Dokumenten (z.B. im Test-Plan) referenzieren zu können.
== Glossar
Sämtliche Begriffe, die innerhalb des Projektes verwendet werden und deren gemeinsames Verständnis aller beteiligten Stakeholder essentiell ist, sollten hier aufgeführt werden.
Insbesondere Begriffe der zu implementierenden Domäne wurden bereits beschrieben, jedoch gibt es meist mehr Begriffe, die einer Beschreibung bedürfen. +
Beispiel: Was bedeutet "Kunde"? Ein Nutzer des Systems? Der Kunde des Projektes (Auftraggeber)?
== Offene Punkte
Offene Punkte werden entweder direkt in der Spezifikation notiert. Wenn das Pflichtenheft zum finalen Review vorgelegt wird, sollte es keine offenen Punkte mehr geben.
