swt23w23/src/main/asciidoc/pflichtenheft.adoc

= 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

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.

== 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)

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
|===


== Systemgrenze und Top-Level-Architektur

=== Kontextdiagramm

image::models/analysis/systemContextDiagram.svg[]

=== Top-Level-Architektur

image::models/analysis/topLevelArchitecture.svg[]

== Anwendungsfälle

=== Akteure

Akteure sind die Benutzer des Software-Systems oder Nachbarsysteme, welche darauf zugreifen. Dokumentieren Sie die Akteure in einer Tabelle. Diese Tabelle gibt einen Überblick über die Akteure und beschreibt sie kurz. Die Tabelle hat also mindestens zwei Spalten (Akteur Name und Kommentar).
Weitere relevante Spalten können bei Bedarf ergänzt werden.

// See http://asciidoctor.org/docs/user-manual/#tables
[options="header"]
[cols="1,4"]
|===
|Name |Beschreibung
|...  |...
|===

=== Überblick Anwendungsfalldiagramm
Anwendungsfall-Diagramm, das alle Anwendungsfälle und alle Akteure darstellt

=== Anwendungsfallbeschreibungen
Dieser Unterabschnitt beschreibt die Anwendungsfälle. In dieser Beschreibung müssen noch nicht alle Sonderfälle und Varianten berücksichtigt werden. Schwerpunkt ist es, die wichtigsten Anwendungsfälle des Systems zu finden. Wichtig sind solche Anwendungsfälle, die für den Auftraggeber, den Nutzer den größten Nutzen bringen.
Für komplexere Anwendungsfälle ein UML-Sequenzdiagramm ergänzen.
Einfache Anwendungsfälle mit einem Absatz beschreiben.
Die typischen Anwendungsfälle (Anlegen, Ändern, Löschen) können zu einem einzigen zusammengefasst werden.

== 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


[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
|===

=== 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.

==== 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

== 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
UML-Analyseklassendiagramm

=== 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.