Spezifikationsdokument
Anmerkung: Änderungen am Dokument sind noch möglich, bitte prüfen Sie vor abgaben den Änderungsverlauf:
- 2024-10-22 Dokument veröffentlicht.
- 2024-11-05 konkrete Punkte für Risiken.
- 2024-11-19 Übersicht wie das Dokument aussehen soll konkretisiert.
Übersicht
- Template ist frei zu wählen
- Für Seitenangaben unten: 1 Seite bedeutet 400-500 Wörter (auch wenn euer Template mehr/weniger Wörter pro Seite hat)
- Graphiken Zählen nicht in das Wortlimit (bis auf Text in den Graphiken).
- Für Seitenangaben unten: 1 Seite bedeutet 400-500 Wörter (auch wenn euer Template mehr/weniger Wörter pro Seite hat)
- Es gibt 4 Sektionen (je max 1 Seite bis auf die letzte)
- Gewünscht ist Fließtext mit strukturierenden Elementen (Subüberschriften, Paragraphen, usw.)
- Abgabe als PDF
- Die Sprache des Dokuments wählen die Auftraggeber:innen (AGs), bevorzugt wird Englisch.
Das Spezifikationsdokument stellt den „Vertrag“ zwischen dem Team und den AGs dar. Ziel ist die Klärung des Projektrahmens.
Während der ersten Iteration (nach dem ersten Treffen mit dem AG) schreibt das Team das Spezifikationsdokument basierend auf den Diskussionen mit den AGs.
Das Spezifikationsdokument soll innerhalb der ersten Iteration (vor dem zweiten Treffen mit den AGs) weitgehend fertiggestellt und den AGs sowie der Teamleitung für Feedback übergeben werden.
Die Deadline zur Abgabe des Dokuments zur Bewertung ist der 1. Dezember 2024. Zu diesem Zeitpunkt sollen die AGs das Dokument abgesegnet haben, ihr müsst also deutlich früher eine Version für Feedback produzieren.
Anmerkung: Im Vergleich zu den Vorjahren, sind Anforderungen/Userstories NICHT Teil des Spezifikationsdokuments.
Im Folgenden ist das Spezifikationsdokument in Form von „Bewertungskriterien“ definiert.
Allgemein soll auf eine hohe Qualität des Textes geachtet werden. Sagt was wichtig ist. Habt einen roten Faden. Fasst euch kurz.
Dokumentinhalte
Projektbeschreibung (maximal 1 Seite)
Hier soll ein Kontext für das Projekt gegeben, sowie die Zielsetzung des Projektes klargemacht werden.
Zu diesem Kapitel gehört ein Architekturdiagramm (nicht Teil des Seitenlimits) das den Text unterstützt.
Hier wird ein zusammenhängender Text erwartet, die Struktur nach den Punkten unten (Vision, Ist/Soll, Domänendetails) hat sich als allgemein gut erwiesen, ist aber nicht vorgegeben. Die Punkte müssen aber abgedeckt sein.
- Vision
- Ist die Vision des Projekts verständlich erklärt?
- Motiviert die Vision für das zu lösende Problem?
- Ergibt die Vision eine Übersicht über die zu entwickelnde Lösung?
- Wird der Kontext in den sich das Projekt integriert klar? Beispiel: was stellen sich die AGs in 3 Jahren mit dem Projekt vor?
- Ist die Vision des Projekts verständlich erklärt?
- Ist-/Sollzustand
- Wird klar, was vor dem Projekt gegeben ist?
- Wird klar, was allgemein am Ende des Projekts vorhanden sein soll?
- Welche Werte sind dem Auftraggeber besonders wichtig?
- Die konkreten Projektziele sind definiert.
- Wird klar, was vor dem Projekt gegeben ist?
- Domänenbeschreibung (wenn nötig)
- Wird die Domäne der zu entwickelnden Applikation erklärt?
- Werden die Benutzerrollen erklärt? Was soll Personen die das Projekt verwenden ermöglicht werden?
- Werden weitere Stakeholder erklärt? Wer ist von dem Projekt indirekt betroffen?
- Werden relevante Fachbegriffe erklärt?
- Werden Zusammenhänge zwischen verschiedenen Komponenten/Nutzern erläutert?
- Welche (speziellen) Einschränkungen müssen im Projekt berücksichtigt werden?
- Wird die Domäne der zu entwickelnden Applikation erklärt?
- Wird aus dem Architekturdiagramm ersichtlich …
- Was die vorhandenen und geplanten Teile des Systems sind?
- Wie die verschiedenen Benutzerrollen mit dem System interagieren?
- Was die vorhandenen und geplanten Teile des Systems sind?
Ergebnisse (Deliverables, maximal 1 Seite)
Vom Format her eignet sich hier eine Liste an kurzen Paragraphen. Adressierte Punkte sollen ausformuliert beschrieben sein, Stichpunkte sind nicht angemessen.
Ist geklärt …
- von welcher Art die Benutzerschnittstelle ist (z.B. Desktopanwendung, Webanwendung im Browser, Konsolenanwendung usw.)?
- in welchen Umgebungen die Entwicklung stattfindet und welche Tools/Libraries etc. für die Entwicklung verwendet werden?
- was für Hardware verwendet wird?
- wie das Projekt getestet wird?
- welche Testdaten benötigt werden und woher sie kommen?
- welche Testdaten benötigt werden und woher sie kommen?
- auf welchen Umgebungen/Konfigurationen das fertige Produkt laufen soll (mit welchen Tools/Libraries/Netzwerkbedingungen etc.)?
- was Artefakte sind die abgegeben werden sollen (z.B. Code, Dokumentation, Testergebnisse, Installation packages, Wiki)?
- Wird bei jedem Artefakt eindeutig beschrieben was und *wie viel* abgeliefert werden soll? (nicht gut z.B. “Alle Funktionen sollen ausreichend dokumentiert sein”)
- Wird bei jedem Artefakt eindeutig beschrieben was und *wie viel* abgeliefert werden soll? (nicht gut z.B. “Alle Funktionen sollen ausreichend dokumentiert sein”)
- in welcher *Form* die Artefakte abgegeben werden soll (z.B. auf einer CD, auf einen Stick, Link per Mail schicken, ausgedruckte Dokumentation, auf einer Codesharing Plattform)?
- wie mit Änderungswünschen verfahren werden soll?
- was ist das minimale Ergebniss (minimal viable product MVP), dass sich die AGs vorstellen?
Risiken (maximal 1 Seite)
Was sind die Risiken die verhindern könnten, dass die genannten Artefakte (Deliverables) erfolgreich erstellt werden? Wie soll damit umgegangen werden?
Siehe die Folien zu Konflikte und die Beispiele für Konfliktszenarien als Anregung für mögliche Probleme.
Projektrisiken sollten mit Wahrscheinlichkeiten, potenziellen Auswirkungen, und Mitigation aufgeschrieben werden.
Diskutieren sie zumindest kurz die Punkte:
- Was geschieht, wenn ein Teammitglied längere Zeit aufgrund von Krankheit ausfällt?
- Welche Ressourcen sind für das Teammitglied von Bedeutung, und wie steht es um deren Verfügbarkeit? Beispiele sind der Zugang zu Laborräumen, die Verfügbarkeit von Systemadministratoren für Software-Deployments oder möglicherweise Cloud-Dienste, die ausfallen könnten.
Bitte geben Sie an, wie wahrscheinlich das Eintreten eines Risikos ist (oder ob die Wahrscheinlichkeit unklar ist) und welche Schritte in einem solchen Fall unternommen werden, um das Projekt dennoch erfolgreich abzuschließen.
Rechtliches (kein Textlimit)
Ist klar geregelt, ob und wie Verwendungsrechte an den Auftraggeber abgetreten werden?
- Softwarelizenz?
- Veröffentlichung als open source?
- Studierende nutzen das Projekt später selber weiter?
- Gibt es Geheimhaltungsvereinbarungen?
- Wie läuft die Kommunikation?
- Was kann das Team vom AG erwarten?
- Was ist die Kontaktadresse des Teams? Wer ist verantwortlich auf Anfragen zu Antworten? Wie wird sichergestellt das Antworten zeitnah erfolgen?
- Was kann das Team vom AG erwarten?
Ist dass es sich um ein studentisches Projekt handelt (NICHT: entspricht Werksvertrag/Dienstvertrag…)?
Anmerkung: So weit der Orga bekannt haben Studis Rechte an ihren eigenen Arbeiten innerhalb von Lehrveranstaltungen. Es ist aber euer Verantwortung das vorher mit den AGs abzuklären.
Bewertungsnotizen: Formaler Gesamteindruck
- Hat das Dokument insgesamt eine ansprechende Form/Formatierung?
- Kann man Absätze angenehm lesen?
- Sind Seitenumbrüche sinnvoll gewählt?
- Wurde Whitespace sinnvoll eingesetzt?
- Kann man Absätze angenehm lesen?
- Ist der Schreibstil leserlich?
- Sind die meisten Sätze präzise und kurz?
- Sind die meisten Sätze grammatikalisch vollständig und richtig?
- Sind die meisten Sätze präzise und kurz?
- Gibt es keine bzw. nur wenige Rechtschreibfehler?
- Hat das Dokument eine logische Struktur, einen roten Faden, die man dem Dokument auch einfach entnehmen kann?