\chapter{Anforderungserfassung}
\label{chap:anforderungserfassung}
Obwohl bereits ein grober Anriss des Zielsystems bekannt ist, ist es unabdinglich eine Anforderungsanalyse durchzuführen,
dies um Details auszuarbeiten \cite{bib:christoph-ebert-vorwort-systematisches-re}.
Hierbei ist es wichtig, kein exzessives Pflichtenheft aufzubauen, denn letztendlich zählt nur, was dem Kunden geliefert wird.
Nicht, wie viele gar nicht benötigte Anforderungen umgesetzt wurden.
\enquote{\textit{Zu viele oder falsche Anforderungen ruinieren Budgets, Termine und die Qualität.}}
\cite{bib:christoph-ebert-vorwort-systematisches-re}.
Die Anforderungen eines Produktes sind in drei Kategorien einzuteilen: \acp{FA}, \acp{NFA}
und Constraints \cite{bib:heinemann-vorlesung-re}.
Wie oben erwähnt, sind bereits die Constraints und einige funktionale und nichtfunktionale Anforderungen bekannt. Diese sind:
\begin{table}[htbp]
    \centering
    \begin{tabular}{|l|l|}
        \hline
        \textbf{Art der Anforderung} & \textbf{Anforderungsbeschreibung}\\
        \hline
        \hline
        \ac{NFA} & \makecell[l]{Angaben zum Weingut des Weines\\sollen aus dem Accountdatensatz anstatt\\aus dem Webform kommen.}\\
        \hdashline
        \ac{NFA} & \makecell[l]{Aus dem Papierformular soll ein\\Webformular werden.}\\
        \hdashline
        \ac{FA} & \makecell[l]{Beim Erstellen einer Weinteilnahme\\soll ein QR-Code als PDF generiert werden,\\der den Wein identifiziert.}\\
        \hdashline
        \ac{FA} & \makecell[l]{Durch scannen des QR-Codes auf dem\\mit einer Weinteilnahme erstellten PDFs soll\\dem Wein der Status \enquote{Eingegangen}\\ zugewiesen werden.}\\
        \hdashline
        Constraint & Einbau in brown-field TYPO3\\
        \hdashline
        Constraint & Mitarbeiter-UI in TYPO3-Backend\\
        \hdashline
        Constraint & Nutzer-UI im Frontend\\
        \hdashline
        \ac{NFA} & \makecell[l]{Registrierte Weinteilnahmen\\bestehen aus einem Wein und einem Zustand\\(ausstehend,eingegangen,abgelehnt).}\\
        \hdashline
        \hline
    \end{tabular}
    \caption{Initial bekannte Anforderungen}
    \label{tbl:initial-bekante-anforderungen}
\end{table}

Um nähere Anforderungen zu ermitteln, werden die Befragungstechniken \enquote{Interview} und \enquote{Fragebogen} verwendet
\cite{bib:heinemann-vorlesung-re}.

\section{Interview mit Product Owner}
Zunächst wird ein Interview mit dem \ac{PO} geführt. Ziel dieses Interviews ist
es, konkrete Fragen zu Anforderungen zu klären und somit konkrete Anforderungen zu formulieren.
Aufgrund der individuellen Gesprächsführung wurde sich für ein \enquote{teil-standardisiertes Interview}
entschieden. Bei einem teil-standardisiertem Interview gibt es vordefinierte Fragen,
aber auch Freiraum für Improvisation und Persönlichkeit.
Für ein gutes Interview ist Vorbereitung wichtig. Daher wurden bereits sämtliche wichtigen Fragen
in einem Fragebogen festgehalten. Dieser Interview-Fragebogen liegt in \fullref{chap:anhang-interview-fragebogen} anbei.
Ebenso ist Vorbereitung auf Seiten des Interview-Teilnehmers wichtig, weshalb das Interview einen Tag zuvor angesprochen wurde.
Um möglichst objektive und unvorbeeinflusste Antworten zu gewährleisten wird darauf geachtet,
keine Suggestivfragen zu stellen
\cite{bib:kleine-re-fibel}.

\section{Online-Fragebögen für Stakeholder}
Um Fragebögen für Stakeholder formulieren zu können, muss zunächst bekannt sein, wer die Stakeholder sind.
\quotecite{Ein Stakeholder eines Systems ist eine Person oder Organisation, welche (direkt oder indirekt)
\break{}Einfluss auf die Anforderungen des betrachteten Systems hat.}
\break\cite{bib:basiswissen-re}.
Daraus ergeben sich die Stakeholdergruppen: \enquote{Mitarbeiter \ac{WM}} und \enquote{teilnehmende Weingüter}.
Jede dieser Stakeholdergruppen sieht das System aus einer anderen Perspektive
\break\cite{bib:kleine-re-fibel}.
Daher ist es wichtig, Einblicke und Bedürfnisse aller Stakeholdergruppen einzuholen
und die individuellen Perspektiven und Bedürfnisse dieser beim Entwurf der Fragebögen zu berücksichtigen.
Ebenso ist es wichtig, die relevantesten Fragen am Anfang zu stellen, da Formulare nicht immer vollständig ausgefüllt werden
\cite{bib:kleine-re-fibel}. Somit sind auch bei einem nur teilweise ausgefüllten Fragebogen die wichtigsten
Fragen beantwortet.
Sämtliche Fragen an die Stakeholdergruppe \enquote{Mitarbeiter \ac{WM}} wurden bereits im Interview mit dem \ac{PO}
beantwortet und als Anforderungen festgehalten. Der \ac{PO} repräsentiert in diesem Falle
die Stakeholdergruppe \enquote{Mitarbeiter \ac{WM}} und steht seit geraumer Zeit mit \ac{WM} in
persönlichem, engen Austausch. Daher gibt es keine offenen Fragen, die diese Stakeholdergruppe
beantworten könnte. Somit fällt ein Onlinefragebogen für die Stakeholdergruppe \enquote{Mitarbeiter \ac{WM}} weg.
Der Fragebogen der Stakeholdergruppe \enquote{teilnehmende Weingüter} liegt im Anhang unter
\fullref{chap:anhang-fragebogen-extern} bei.
Um den Aufwand und somit die Hemmschwelle des Ausfüllens
eines solchen Online-Fragebogens zu minimieren, gibt es lediglich sechs quantitative Fragen
zuzüglich einem optionalen Freitextfeld, um sonstige Wünsche zum Ausdruck zu bringen.
Eine Anmeldung über Google für Google-Forms ist nicht erforderlich.
Der Link zu diesem Online-Fragebogen wurde \ac{WM} mit der Bitte um Weitergabe an
die Probenteilnehmer übergeben.

\section{Erkenntnisse}
Aus dem Interview mit dem \ac{PO} ergibt sich ein Pflichtenheft.
Das Pflichtenheft und das Protokoll zum Interview sind im Anhang unter je
\fullref{chap:anhang-pflichtenheft} und \fullref{chap:anhang-interview-protokoll} zu finden.
Ergebnisse dieses Interviews sind zahlreiche Anforderungen und Ideen. Eine der wichtigsten Ideen stellt das
projektbezogene, wöchentliche Statusmeeting dar: Jeden Donnerstag soll um 9:30 Uhr der aktuelle Stand
des Projektes vorgestellt, diskutiert und Rücksprache gehalten werden.
Weitere wichtigste Erkenntnisse des Interviews sind:
\begin{description}
  \item[Endgerät für Scanning und Scanneranwendung]\hfill\\
    Gescannt wird von Mobiltelefonen mit einer QR-Code-App wie QRBot.
    QRBot ermöglicht es Nutzern für jeden aufgerufenen QR-Code eine Vorlagen-URL aufzurufen,
    um den gescannten Wert als Teil der Url, z.B. als Get-Parameter, zu übergeben \cite{bib:qrbot}.
    Das ist prädestiniert für API-ähnliche Webseitenaufrufe, um Weine einzuchecken.
  \item[Trennung von Weinen nach Jahresauswahlproben im Frontend]\hfill\\
    Da es $n$ Jahresauswahlproben gibt und Weine immer genau einer Jahresauswahlprobe zugeordnet sein müssen, macht es wenig
    Sinn alle Weine eines Nutzers auf einmal anzuzeigen. So ist es eine Anforderung, dass die
    Weinansicht in zwei Ebenen unterteilt ist: Die erste Ebene soll eine Auflistung aller Jahresauswahlproben sein
    und in der Einzelansicht der Jahresauswahlproben sollen alle Weine aufgelistet sein, die dieser Jahresauswahlprobe angehören.
    Diese Weine sind ebenso anklickbar und führen zu einer Einzelansicht der Weine.
  \item[Nutzerführung für \ac{WM}-Angestellte]\hfill\\
    Gescanne QR-Codes von Weinen sollen den Wein als eingegangen markieren und anschließend dem
    Mitarbeiter zeigen, welcher Wein eingechecked wurde. Somit dient das Scannen eines Codes ebenso zur
    Einsicht der Details der gelagerten Flaschen.
    Es soll ein Backendmodul \cite{bib:typo3-docs-modules} geben, das für den Export von CSV-Daten zuständig ist.
    Sonstige Aktionen sind im TYPO3-Backend mit nativen Werkzeugen erreichbar.
  \item[Verschiedene Web-Ansichten]\hfill
    \begin{itemize}
      \item Jahresauswahlproben-Listenansicht
      \item Jahresauswahlproben-Detailansicht
      \item Wein-Registrierungsformular
      \item PDF-Url für Versandbriefe
      \item Registrierungsseite mit mehreren Schritten
      \item Mitarbeiterseite für gescannte QR-Codes
      \item Listenansicht der Jahresauswahlproben im CSV-Exporter im Backend
      \item Detailansicht der Jahresauswahlprobe im CSV-Exporter im Backend
  \end{itemize}

\end{description}

Der Online-Fragebogen für teilnehmende Weingüter wurde über einen Monat hinweg nicht beantwortet, insofern
gibt es keine Bedürfnisse dieser Herkunft zu präsentieren.
\\
\\
Aus der Anforderugserfassung ergibt sich als Pendant zu \enpointy{\textit{\ref{fig:geschaeftsprozess-vorher} Geschäftsprozess Jahresauswahlprobe: vor der Digitalisierung}} % Der Name hat linebreaks drin, also geht fullref nicht gut...
der gewünschte Geschäftsprozess der Jahresauswahlprobe nach Fertigstellung dieses Projektes.
Hierbei ist es wichtig, die Schnittstelle zwischen den gleichbleibenden Arbeitsschritten und den zu digitalisierenden
Arbeitsschritten zu beachten. Diese Schnittstelle sollte unverändert bleiben,
um eine nahtlose Integration in den restlichen, bestehenden Workflow von \ac{WM} zu gewährleisten.
Diese Schnittstelle stellt eine Excel-Tabelle dar. Zuvor wurde diese Excel-Tabelle von Hand aus den
Anmeldeformularen erstellt. Nach Fertigstellung dieses Projektes soll diese Tabelle in Form
von CSV-Daten aus dem Redaktionssystem exportiert werden können. Diese können Mitarbeiter von \ac{WM} in Excel
importieren und in kommenden Planungsschritten der Jahresauswahlprobe ohne Umstellung weiter verwenden.
Das ist wichtig, da solche Umstellungen, ohne nennenswerte Verbesserungen des restlichen, von dieser
Ausarbeitung unberührten Workflows, Zeit kostet, ohne Vorteile zu erbringen.
Dieser Zeitverlust würde den durch die Digitalisierung erzielten Gewinn schädigen.

\begin{nicepic}
    \includegraphics[width=1\textwidth]{images/geschäftsprozess-nachher.png}
    \captionof{figure}{Geschäftsprozess Jahresauswahlprobe: nach der Digitalisierung}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:geschaeftsprozess-nachher}
\end{nicepic}