chap 3: Planung und Vorbereitung; backlog/requirements tables; fix duplicate section headers

2026-08-25 19:56:46 +02:00
parent e547d3bb18
commit 980e21c252
19 changed files with 1360 additions and 56 deletions
@@ -1,15 +1,12 @@
 \section{Ausgangssituation}
 \label{sec:initial-situation}

-\section{Ausgangssituation}
-\label{sec:initial-situation}
-
 Die Idee, Kunden über Houston Zugang zu ihren Dokumenten zu ermöglichen, besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an — „Vertrag, Betriebshandbuch, Feinkonzepte an zentraler Stelle abgelegt" und „Rechnungen einsehbar". Diese Notiz blieb über zweieinhalb Jahre nahezu unverändert im Backlog und spiegelt die damaligen Bedürfnisse wider, ohne einen konkreten Lösungsansatz zu beschreiben.

-Zum Zeitpunkt des Projektbeginns im Sommer 2026 gab es keinen strukturierten Prozess, über den Kunden selbstständig auf ihre Dokumente zugreifen konnten. Verträge, Berichte und ähnliche Unterlagen wurden punktuell per E‑Mail oder über Dateiablagen bereitgestellt. Daraus ergaben sich mehrere Probleme:
+Zum Zeitpunkt des Projektbeginns im Sommer 2026 gab es keinen strukturierten Prozess, über den Kunden selbstständig auf ihre Dokumente zugreifen konnten. Verträge, Berichte und ähnliche Unterlagen wurden punktuell per E-Mail oder über Dateiablagen bereitgestellt. Daraus ergaben sich mehrere Probleme:

 \begin{itemize}
-    \item \textbf{Fehlende Zentralisierung:} Dokumente lagen verteilt in E‑Mails, Dateiablagen und lokalen Verzeichnissen ohne einheitlichen Zugangspunkt.
+    \item \textbf{Fehlende Zentralisierung:} Dokumente lagen verteilt in E-Mails, Dateiablagen und lokalen Verzeichnissen ohne einheitlichen Zugangspunkt.
    \item \textbf{Kein Self-Service für Kunden:} Kunden mussten Dokumente aktiv anfordern, anstatt sie eigenständig abrufen zu können.
    \item \textbf{Kein strukturierter Überblick:} Eine Übersicht nach Dokumententypen oder zeitlichem Verlauf war nicht vorhanden.
    \item \textbf{Kein sicherer, mandantengetrennter Zugriff:} Es existierte kein technischer Mechanismus, der sicherstellte, dass ein Kunde ausschließlich seine eigenen Dokumente einsehen konnte.
@@ -1,6 +1,3 @@
-\section{Beteiligte und Rollen}
-\label{sec:participants}
-
 \section{Projektbeteiligte}
 \label{sec:participants}

@@ -1,12 +1,9 @@
 \section{Projektbeschreibung}
 \label{sec:project-description}

-\section{Projektbeschreibung}
-\label{sec:project-description}
-
 Das Projekt \emph{Houston Dokumente} hat zum Ziel, Kunden im Kundenportal Houston einen zentralen Bereich bereitzustellen, in dem sie ihre Dokumente einsehen und herunterladen können. Die Dokumente werden in einem S3-Speichersystem abgelegt und gepflegt; den Kunden werden sie über eine neue Houston-Seite zugänglich gemacht.

-Bisher existierte kein einheitlicher, zentraler Zugangspunkt für kundenbezogene Dokumente wie Verträge, Berichte oder Protokolle. Diese wurden punktuell per E‑Mail oder Dateiablage bereitgestellt und waren für Kunden nicht selbstständig abrufbar. Die neue Dokumentenseite in Houston löst diese Situation ab: Mitarbeiter pflegen die Dokumente über ein internes Dateiverwaltungswerkzeug direkt im S3-Speicher, Kunden können sie anschließend strukturiert abrufen.
+Bisher existierte kein einheitlicher, zentraler Zugangspunkt für kundenbezogene Dokumente wie Verträge, Berichte oder Protokolle. Diese wurden punktuell per E-Mail oder Dateiablage bereitgestellt und waren für Kunden nicht selbstständig abrufbar. Die neue Dokumentenseite in Houston löst diese Situation ab: Mitarbeiter pflegen die Dokumente über ein internes Dateiverwaltungswerkzeug direkt im S3-Speicher, Kunden können sie anschließend strukturiert abrufen.

 Der Dokumentenbereich unterscheidet sieben fachlich definierte Dokumententypen — darunter Service-Protokolle, SLA-Reports, Monitoring Reports und Vertragsunterlagen — und gliedert die Anzeige anhand dieser Typen. Darüber hinaus umfasst das Projekt eine Suchfunktion, Filter nach Dokumententyp, Paginierung, einen PDF-Viewer, den Download einzelner Dateien sowie das Herunterladen mehrerer Dokumente als ZIP-Archiv. Zusätzlich werden sogenannte URL-Dateien unterstützt, mit denen beliebige Webadressen — etwa Links zu Teams-Kanälen oder SharePoint-Seiten — in der Dokumentenliste verknüpft werden können.

@@ -1,9 +1,6 @@
 \section{Projektabgrenzung}
 \label{sec:project-scope}

-\section{Projektabgrenzung}
-\label{sec:project-scope}
-
 Folgende Punkte sind explizit \emph{nicht} Bestandteil des Projekts:

 \begin{itemize}
@@ -1,9 +1,6 @@
 \section{Systemlandschaft}
 \label{sec:system-landscape}

-\section{Systemlandschaft}
-\label{sec:system-landscape}
-
 Der Dokumentenbereich ist in die bestehende Systemlandschaft von WorkSimple eingebettet. Abbildung~\ref{fig:system-context} zeigt den Systemkontext und das Zusammenspiel der beteiligten Systeme.

 \begin{figure}[H]
@@ -1,9 +1,6 @@
 \section{Zielsituation}
 \label{sec:target-situation}

-\section{Zielsituation}
-\label{sec:target-situation}
-
 Mit der Fertigstellung des Dokumentenbereichs erhalten Kunden im Kundenportal Houston erstmals einen strukturierten, selbstständig nutzbaren Zugang zu ihren Dokumenten. Die Zielsituation zeichnet sich durch eine zentrale Ablage im S3-Speicher und eine mandantengetrennte Darstellung in Houston aus.

 Der Dokumentenbereich bietet folgende zentrale Funktionen:
@@ -1,14 +1,27 @@
-\section{Backlog-Schnitt und Schätzung}
+\section{Backlog und Entwicklungsprozess}
 \label{sec:backlog}

-% TODO: 14 PBIs + 1 Bug unter Feature 484
-% Prozess: DoR, DoD, Approval-Team, Sprints 15–17.2026
-% Siehe Tabelle~\ref{tab:backlog} im Anhang
+\subsection{Entwicklungsprozess}

-% Gantt:
-% \begin{figure}[H]
-%   \centering
-%   \includegraphics[width=\textwidth]{figures/diagrams/gantt-plan.pdf}
-%   \caption{Zeitplanung über Sprints 15–17.2026}
-%   \label{fig:gantt}
-% \end{figure}
+Die Softwareentwicklung bei der Unicorn Development erfolgt nach einem agilen Prozess mit zweiwöchigen Sprints, verwaltet in Azure DevOps. Jedes Work Item durchläuft dabei einen definierten Zustandsautomaten, der in Abbildung~\ref{fig:ado-workflow} dargestellt ist.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.55\textwidth]{figures/diagrams/ado-workflow.pdf}
+    \caption{Zustände eines Work Items in Azure DevOps}
+    \label{fig:ado-workflow}
+\end{figure}
+
+Ein neu angelegtes Item befindet sich zunächst im Zustand \texttt{New}. Sobald Beschreibung und Akzeptanzkriterien vollständig sind, wird es zur Freigabe eingereicht (\texttt{To Approve}). Im Approval-Termin prüft das Team, ob das Item der \emph{Definition of Ready} genügt, stellt Rückfragen und schätzt den Aufwand in Story Points. Erst danach gilt es als \texttt{Approved} und kann in einen Sprint gezogen werden (\texttt{Committed}). Nach erfolgreichem Merge des zugehörigen Pull Requests wechselt das Item nach \texttt{Dev Completed}; die fachliche Abnahme überführt es schließlich nach \texttt{Test Completed}.
+
+Dieser Prozess erwies sich im Projektverlauf als wirksam: Die Rückfragen im Approval-Termin — insbesondere durch \emph{Timo Walter} — deckten mehrfach Lücken in den Akzeptanzkriterien auf, etwa zur Frage, wann und wie oft die Ordnerstruktur geprüft wird, oder ob Namensbeschränkungen für Kundenordner zu berücksichtigen sind.
+
+\subsection{Schnitt der Product Backlog Items}
+
+Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 — unmittelbar nach der Feature-Analyse — wurden die acht Items der Kernfunktionalität angelegt. Sie orientieren sich direkt an der Gliederung der Feature-Beschreibung: Der Document Explorer bildet die Basis, die im Abschnitt \emph{Feature-Creep} genannten Punkte (Suche, Einzeldownload, ZIP-Download, PDF-Modal, URL-Dateien) wurden jeweils zu eigenen Items. Am 7.~Juli 2026 kam das Item zur Typisierung über Icons hinzu, am 8.~Juli das Item zur automatischen Ordneranlage.
+
+Eine zweite Gruppe von Items entstand erst während der Umsetzung. Am 22.~Juli ergänzte die UI-Zuarbeit die Anforderungen um Paginierung und Typfilter. Am 28.~Juli wurde die Recherche zur Optimierung der S3-Abfrage angelegt, deren Ergebnis am 12.~August in das Item zum Kundenordner-Lookup mündete. Am 17.~August kam schließlich das Item zu den Race Conditions hinzu (siehe Abschnitt~\ref{sec:race-conditions}).
+
+Insgesamt hängen 14 Product Backlog Items und ein Bug am Feature. Die vollständige Übersicht mit Aufwandsschätzung, Sprint und Status findet sich in Tabelle~\ref{tab:backlog} im Anhang. Die geschätzten Aufwände summieren sich auf 46 Story Points, verteilt auf 35 Punkte in Sprint~15.2026 und 11 Punkte in Sprint~16.2026.
+
+Bemerkenswert ist die Aufteilung: Die im Voraus geschnittenen Items betreffen ausschließlich fachliche Funktionen. Sämtliche nachgeschobenen Items der zweiten Gruppe entstanden aus technischen Problemen, die erst bei der Implementierung sichtbar wurden — ein Muster, das in Abschnitt~\ref{sec:reflection} aufgegriffen wird.
@@ -1,7 +1,15 @@
 \section{Feature-Analyse}
 \label{sec:feature-analysis}

-% TODO: 18.06.2026 — 4 Rückfragen von Linus an Thomas, Antworten im selben Ticket (Feature 484 Rev 17–32)
-% - Autorisierung via Metadatum: ja
-% - Filestash als externe Website (kein Custom-UI): ja
-% - ...
+Das Feature~484 „Dokumente" existierte seit November 2023 als zweizeilige Bedarfsnotiz im Backlog. Am 10.~Juni 2026 arbeitete \emph{Thomas Drewermann} es in mehreren aufeinanderfolgenden Bearbeitungen zu einer vollständigen Feature-Beschreibung aus. Dabei entstanden die Entscheidung für einen S3-Speicher als Ablage, die Festlegung auf Filestash als internes Verwaltungswerkzeug, der Katalog der sieben Dokumententypen sowie die Abschnitte \emph{Feature-Creep} und \emph{Out of Scope}.
+
+Am 18.~Juni 2026 führte ich eine Feature-Analyse durch, um die verbliebenen Unklarheiten vor dem Backlog-Schnitt zu beseitigen. Vier Rückfragen wurden als Kommentare am Work Item gestellt und noch am selben Tag beantwortet. Drei davon entschieden Architekturfragen:
+
+\begin{enumerate}
+    \item \textbf{Autorisierung über Metadaten:} Auf die Frage, ob die Efecte-Organisations-ID als Metadatum am Kundenordner gespeichert und die Berechtigung darüber aufgelöst werden könne, lautete die Antwort \emph{ja}. Damit war das Autorisierungskonzept festgelegt (siehe Abschnitt~\ref{sec:authorization}).
+    \item \textbf{Filestash als externes Werkzeug:} Es wurde bestätigt, dass Filestash unverändert als Verwaltungsoberfläche genutzt wird und \emph{nicht} als Referenz für einen Nachbau in Houston dient. Damit beschränkte sich der Implementierungsaufwand auf die Kundensicht.
+    \item \textbf{Typisierung über Ordner statt Metadaten:} Auf die Frage, ob der Dokumententyp als Metafeld an der Datei vermerkt werden solle, lautete die Antwort \emph{nein, Ordner}. Der Typ wird also über den Unterordner bestimmt, in dem das Dokument liegt.
+    \item \textbf{Bedeutung der URL-Dateien:} Die vierte Frage klärte, dass mit der Verlinkung zu Teams oder SharePoint gemeint ist, \emph{externe} Ressourcen in den Dokumentenbereich einzubetten — und nicht umgekehrt Houston-Dokumente nach außen zu teilen. Daraus entstand das Product Backlog Item zur Unterstützung von \texttt{.url}-Dateien.
+\end{enumerate}
+
+Die dritte Entscheidung erwies sich im weiteren Verlauf als die folgenreichste. Die Abbildung des Typs über die Ordnerstruktur macht die Filterung nach Typ günstig, da sie sich auf ein Präfix-Listing reduziert. Sie erzwingt jedoch, dass die Ordnerstruktur für jeden Kunden vorhanden ist, und macht damit die automatische Anlage der Ordner zu einer eigenen Anforderung. Zugleich erschwert sie die typübergreifende Suche, da hierfür mehrere Präfixe durchlaufen werden müssen.
@@ -1,15 +1,34 @@
-\section{Infrastrukturbeschaffung}
+\section{Beschaffung der S3-Infrastruktur}
 \label{sec:infrastructure}

-% TODO: Service Requests an Maschinenraum (2026-07-22), Provisionierung durch Advanced Unibyte,
-% 3 Buckets (DEV/TEST/PROD), Credentials in Passbolt (2026-07-27)
-% Anfrage S3 Select (2026-07-30), Aktivierung durch AU (2026-08-07)
-% Search Integration: von AU nicht bereitgestellt (2026-08-17)
+Der für das Projekt benötigte S3-Speicher stand zu Projektbeginn nicht zur Verfügung und musste über den internen Service-Desk-Prozess beantragt werden. Da der Speicher nicht von WorkSimple selbst, sondern von Advanced Unibyte betrieben wird, war die Beschaffung mit einem mehrstufigen Abstimmungsweg verbunden. Abbildung~\ref{fig:timeline-infra} zeigt den zeitlichen Verlauf.

-% Timeline-Diagramm:
-% \begin{figure}[H]
-%   \centering
-%   \includegraphics[width=\textwidth]{figures/diagrams/timeline-infra.pdf}
-%   \caption{Chronologie der Infrastrukturbeschaffung}
-%   \label{fig:timeline-infra}
-% \end{figure}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{figures/diagrams/timeline-infra.pdf}
+    \caption{Chronologie der Infrastrukturbeschaffung}
+    \label{fig:timeline-infra}
+\end{figure}
+
+\subsection{Bereitstellung der Buckets}
+
+Am 22.~Juli 2026 stellte ich den Service Request „Houston DEV S3 Documents Speicher" an das interne Infrastruktur-Team. Der Request wurde am 23.~Juli \emph{Alexander Wagner} zugewiesen und am 27.~Juli abgeschlossen: Advanced Unibyte hatte die Buckets angelegt, die Zugangsdaten wurden im Passwortmanager Passbolt hinterlegt. Insgesamt wurden drei Buckets bereitgestellt — je einer für die Entwicklungs-, Test- und Produktivumgebung.
+
+Vom Antrag bis zur Verfügbarkeit vergingen fünf Arbeitstage. Da der Document Explorer als erstes Item ohnehin erst am 27.~Juli in die Umsetzung ging, entstand hieraus keine Verzögerung.
+
+\subsection{Freischaltung zusätzlicher Funktionen}
+
+Deutlich aufwendiger gestaltete sich die Klärung, welche S3-Funktionen die StorageGRID-Installation tatsächlich unterstützt. Im Rahmen der Recherche zur Optimierung des Kundenordner-Lookups (siehe Abschnitt~\ref{sec:lookup-research}) kamen zwei Funktionen als mögliche Lösungen in Betracht:
+
+\begin{itemize}
+    \item \textbf{S3 Select} (\texttt{SelectObjectContent}) erlaubt es, Inhalte einzelner Objekte serverseitig per SQL-ähnlicher Abfrage zu filtern \autocite{aws-s3-select, storagegrid-s3-select}.
+    \item Der \textbf{Search Integration Service} von StorageGRID spiegelt Objektmetadaten in einen Elasticsearch-Index und ermöglicht dadurch eine echte Suche über Metadaten \autocite{storagegrid-search-integration}.
+\end{itemize}
+
+Am 30.~Juli beantragte ich die Freischaltung beider Funktionen. Da hierfür der Betreiber einbezogen werden musste, kontaktierte \emph{Lennart Meinert} am 4.~August Advanced Unibyte. Am 6.~August benannte er die drei betroffenen Buckets, am 7.~August bestätigte Advanced Unibyte die Aktivierung von S3 Select für alle drei Umgebungen.
+
+Für den Search Integration Service fiel die Antwort anders aus: Am 17.~August teilte Advanced Unibyte mit, dass diese Funktion derzeit nicht angeboten werde; das Thema wurde intern an den dortigen Product Owner eskaliert. Am 21.~August schlug Advanced Unibyte ein Folgegespräch vor. Da zu diesem Zeitpunkt bereits eine Lösung ohne serverseitige Suche gefunden und umgesetzt war (siehe Abschnitt~\ref{sec:lookup-decision}), wurde der Service Request geschlossen und das Thema in den Ausblick verschoben.
+
+\subsection{Bewertung}
+
+Zwischen dem ersten Antrag und der abschließenden Klärung lagen vier Wochen. Diese Vorlaufzeit war zu Projektbeginn nicht eingeplant und beeinflusste die Architekturentscheidung unmittelbar: Ein Lösungsansatz, der auf einer erst noch zu beschaffenden Fremdleistung beruht, ist innerhalb eines Projektzeitraums von wenigen Wochen nicht belastbar. Die schließlich gewählte Lösung kommt daher ohne Erweiterung der Speicherfunktionen aus.
@@ -1,5 +1,18 @@
 \section{Einarbeitung}
 \label{sec:onboarding}

-% TODO: S3-API, AWS SDK für .NET, StorageGRID-Dokumentation
-% Quellen: note-1785344962361 (S3-Recherche mit Timo), note-1785413874041
+Vor Beginn der Implementierung war eine Einarbeitung in die für das Projekt relevanten Technologien erforderlich. Im Zentrum stand dabei der S3-Objektspeicher, mit dem im bisherigen Verlauf des Praktikums noch nicht gearbeitet worden war.
+
+\subsection{S3 als Objektspeicher}
+
+S3 (\emph{Simple Storage Service}) ist kein klassisches Dateisystem, sondern ein Objektspeicher. Objekte werden über einen flachen Schlüsselraum adressiert; eine Ordnerhierarchie existiert technisch nicht. Was in Werkzeugen wie Filestash als Ordner dargestellt wird, ist lediglich ein Präfix im Objektschlüssel, das in Verbindung mit einem Trennzeichen (\texttt{Delimiter}) beim Auflisten hierarchisch interpretiert wird \autocite{aws-listobjectsv2}. Diese Eigenschaft prägt das gesamte Ablagekonzept (siehe Abschnitt~\ref{sec:s3-layout}) und war für mehrere spätere Architekturentscheidungen ausschlaggebend.
+
+Eine zweite wesentliche Erkenntnis betrifft die Abfragemöglichkeiten: An Objekten können zwar benutzerdefinierte Metadaten hinterlegt werden, S3 bietet jedoch \emph{keine} Möglichkeit, Objekte anhand dieser Metadaten zu suchen. Ein Lookup nach einem Metadatenwert erfordert daher das Auflisten aller in Frage kommenden Objekte und eine anschließende clientseitige Filterung. Dieses Detail wurde erst im Verlauf der Implementierung zum zentralen technischen Problem des Projekts (siehe Abschnitt~\ref{sec:lookup-research}).
+
+\subsection{AWS SDK für .NET}
+
+Der Zugriff auf den S3-Speicher erfolgt aus Houston heraus über das AWS SDK für .NET. Zentrale Schnittstelle ist \texttt{IAmazonS3}, über die sämtliche Operationen (\texttt{ListObjectsV2}, \texttt{GetObject}, \texttt{PutObject}, \texttt{CopyObject}, \texttt{DeleteObjects}) ausgeführt werden. Da \texttt{IAmazonS3} eine Schnittstelle ist, lässt sie sich in Unit-Tests durch ein Mock ersetzen, was für die spätere Testabdeckung des Kundenordner-Lookups entscheidend war (siehe Abschnitt~\ref{sec:unit-tests}).
+
+\subsection{NetApp StorageGRID}
+
+Der eingesetzte Speicher wird nicht bei Amazon betrieben, sondern von Advanced Unibyte auf Basis von NetApp StorageGRID bereitgestellt. StorageGRID ist S3-kompatibel, implementiert die S3-API jedoch nicht vollständig. Welche Funktionen tatsächlich verfügbar sind, hängt von der Konfiguration der Installation ab und musste im Einzelfall geklärt werden. Diese Einschränkung betraf im Projektverlauf sowohl \texttt{SelectObjectContent} \autocite{storagegrid-s3-select} als auch den \emph{Search Integration Service} \autocite{storagegrid-search-integration} und führte zu den in Abschnitt~\ref{sec:infrastructure} beschriebenen Abstimmungen.
@@ -1,5 +1,33 @@
-\section{Anforderungserhebung}
+\section{Anforderungen}
 \label{sec:requirements}

-% TODO: Funktionale und nichtfunktionale Anforderungen aus den PBI-ACs
-% Tabelle: Anforderungsmatrix (funktional / nichtfunktional → PBI)
+Aus der Feature-Beschreibung und der Analyse ergaben sich die folgenden Anforderungen. Die funktionalen Anforderungen wurden anschließend in Product Backlog Items überführt; die vollständige Zuordnung findet sich in Tabelle~\ref{tab:requirements} im Anhang.
+
+\subsection{Funktionale Anforderungen}
+
+\begin{itemize}
+    \item \textbf{FA-1 — Dokumentenliste:} Auf der Seite \texttt{/documents} werden alle Dokumente der Organisation des angemeldeten Benutzers als Liste dargestellt. Ordner selbst werden nicht als Einträge angezeigt; leere Typordner erscheinen nicht.
+    \item \textbf{FA-2 — Mandantentrennung:} Ein Benutzer sieht ausschließlich Dokumente, die im Ordner seiner Organisation liegen. Die Zuordnung erfolgt über die \texttt{efecte-org-id} am Kundenordner.
+    \item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei vorhandener Rollenberechtigung sichtbar. Ein direkter Aufruf ohne Berechtigung führt zu einer 403-Antwort.
+    \item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument wird mit einem Icon dargestellt, das aus dem Unterordner abgeleitet wird. Unbekannte Typen erhalten ein Standard-Icon.
+    \item \textbf{FA-5 — Suche:} Dokumente können serverseitig nach ihrem Titel durchsucht werden, inklusive Teiltreffern. Ein leeres Suchfeld zeigt wieder die vollständige Liste.
+    \item \textbf{FA-6 — Typfilter:} Unterhalb der Suchleiste kann je Dokumententyp ein Element zum Ein- und Ausblenden ausgewählt werden.
+    \item \textbf{FA-7 — Paginierung:} Die Liste wird seitenweise dargestellt; die Seitengröße ist durch den Benutzer festlegbar, analog zu den übrigen Houston-Seiten.
+    \item \textbf{FA-8 — Einzeldownload:} Jeder Eintrag besitzt einen Download-Button. Der Download erfolgt über eine zeitlich begrenzte Pre-Signed URL \autocite{aws-presigned-urls} unter Beibehaltung des ursprünglichen Dateinamens.
+    \item \textbf{FA-9 — ZIP-Download:} Mehrere Dokumente können über Auswahlboxen markiert und gemeinsam als ZIP-Archiv heruntergeladen werden. Die Ordnerstruktur des Archivs entspricht der S3-Struktur; das Archiv wird erst beim Klick erzeugt.
+    \item \textbf{FA-10 — PDF-Vorschau:} PDF-Dokumente können in einem Modal angezeigt werden, ohne zuvor heruntergeladen zu werden. Für Nicht-PDF-Dateien wird keine Vorschau geöffnet.
+    \item \textbf{FA-11 — Share-Links:} Für jedes Dokument kann ein Freigabelink erzeugt werden, dessen Zielseite OpenGraph-Meta-Tags für eine Linkvorschau bereitstellt und anschließend auf den Document Explorer weiterleitet.
+    \item \textbf{FA-12 — URL-Dateien:} Im Speicher abgelegte \texttt{.url}-Dateien werden nach dem INI-Format ausgewertet und leiten beim Anklicken auf die hinterlegte Adresse weiter. Ist keine gültige URL erkennbar, wird die Datei wie eine normale Datei behandelt.
+    \item \textbf{FA-13 — Automatische Ordneranlage:} Beim Aufruf der Dokumentenseite wird die vollständige Typordnerstruktur für die Organisation angelegt, sofern sie noch nicht existiert.
+\end{itemize}
+
+\subsection{Nichtfunktionale Anforderungen}
+
+\begin{itemize}
+    \item \textbf{NFA-1 — Skalierbarkeit des Lookups:} Die Auflösung des Kundenordners darf nicht linear mit der Anzahl der Kunden wachsen. Im Normalfall soll ein einzelner Aufruf genügen.
+    \item \textbf{NFA-2 — Fehlerbehandlung:} Können Dokumente nicht geladen werden, wird eine verständliche Fehlermeldung angezeigt. Eine stillschweigend leere Seite ist nicht zulässig.
+    \item \textbf{NFA-3 — Leerer Zustand:} Existieren für einen berechtigten Benutzer keine Dokumente, wird ein entsprechender Hinweis angezeigt.
+    \item \textbf{NFA-4 — Konsistenz zur bestehenden Oberfläche:} Suche, Paginierung und Bedienelemente orientieren sich an den übrigen Houston-Seiten.
+    \item \textbf{NFA-5 — Testbarkeit:} Die Logik zur Auflösung des Kundenordners ist durch Unit-Tests mit einem gemockten \texttt{IAmazonS3} abgedeckt.
+    \item \textbf{NFA-6 — Pfadsicherheit:} Beim Download wird geprüft, dass der angeforderte Schlüssel innerhalb des Kundenordners liegt; Pfadanteile zum Verlassen des Ordners werden abgewiesen.
+\end{itemize}
@@ -1,4 +1,17 @@
 \section{Zeit- und Aufwandsplanung}
 \label{sec:schedule}

-% TODO: Sprints 15–17.2026, Aufwandsschätzungen (Story Points), 24 Manntage / 192 h gesamt
+Für das Praktikum sind 24 Manntage beziehungsweise 192 Arbeitsstunden vorgesehen. Der Projektzeitraum erstreckt sich von der Themenfindung Ende Mai 2026 bis zur Abgabe der Dokumentation. Die Umsetzung verteilt sich auf die Sprints 15.2026 bis 17.2026. Abbildung~\ref{fig:gantt} zeigt die geplante zeitliche Verteilung.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{figures/diagrams/gantt-plan.pdf}
+    \caption{Zeitplanung des Projekts}
+    \label{fig:gantt}
+\end{figure}
+
+Die Planung gliedert sich in vier Phasen. Die \textbf{Analyse- und Konzeptionsphase} (Ende Mai bis Anfang Juli) umfasste die Themenfindung mit \emph{Sarah Hinzmann} und \emph{Thomas Drewermann}, die Feature-Analyse sowie den Schnitt und die Freigabe der Product Backlog Items. Die \textbf{Implementierungsphase} begann am 27.~Juli mit dem ersten Pull Request und erstreckte sich über die Sprints 15 und 16. Parallel dazu lief die \textbf{Qualitätssicherung} in Form fortlaufender Code-Reviews; der Abnahmetest begann am 13.~August. Die \textbf{Abschlussphase} umfasst Release, Dokumentation und Präsentation.
+
+Eine Besonderheit der Planung ist die Abhängigkeit von der Infrastrukturbereitstellung: Der Document Explorer konnte erst umgesetzt werden, nachdem der S3-Speicher zur Verfügung stand. Diese Abhängigkeit wurde bereits im Approval-Termin am 8.~Juli durch \emph{Stephan Janßen} als Voraussetzung am Item vermerkt. Der tatsächliche Vorlauf für die Beschaffung wird im folgenden Abschnitt beschrieben.
+
+Der Soll-Ist-Vergleich der Zeitplanung findet sich in Abschnitt~\ref{sec:target-comparison}.