Spezifikation¶

Die Spezifikation ist im Rahmen der Projektarbeit sowohl ein zentrales Dokument als auch Instrument zur strukturierten, nachvollziehbaren und zielgerichteten Umsetzung Ihres Vorhabens. Denn sie beschreibt die Anforderungen, die an eine Produkt, System oder auch Bauprojekt gestellt werden und übersetzt damit Erwartungen in überprüfbare Vorgaben. Metaphorisch gesprochen ist die Spezifikation also das gemeinsame Drehbuch, an das sich alle Beteiligten halten müssen, da es festlegt, was gebaut, entwickelt oder programmiert werden soll und auch die spezifische Funktionalität, Beschaffenheit sowie technische Umsetzung präzisiert. Im Idealfall räumt die Spezifikation sogar Missverständnisse aus, noch ehe der erste Stein gesetzt oder die erste Code-Zeile geschrieben wurde – und damit alle Teammitglieder jederzeit Zugang zu ihrem Drehbuch haben, ist die Spezifikation in der Praxis als Teil der Projektanforderungsdokumentation beispielsweise in der Projektakte abzulegen. Richten wir also im Folgenden einmal den Blick auf das Dokument, welches im Wesentlichen die Grundlage für Planung, technische Realisierung, Qualitätssicherung und spätere Abnahme bildet.

Zielsetzungen und häufige Fehler¶

Wie bereits einleitend angedeutet, besteht das primäre Ziel einer Spezifikation darin, ein gemeinsames Verständnis aller Projektbeteiligten über Ziele, Inhalte und Erwartungen herzustellen. Sie dient so auch der Vermeidung von Missverständnissen, indem sie Interpretationsspielräume minimiert und damit ein stabiles Fundament für die technische Umsetzung schafft. Um dieser Zielsetzung gerecht zu werden, ist es entscheidend, die fachlichen Anforderung klar und deutlich zu formulieren, so dass sowohl bei der Entwicklung und Testung als auch bei der späteren Abnahme darauf aufgebaut werden kann.

In der Praxis ist jedoch immer wieder festzustellen, dass Spezifikationen häufig Schwächen in ihrer Formulierung aufweisen. Unklare Begriffe oder ungenaue Formulierungen führen nicht selten zu Mehrarbeit durch gehäufte Rückfragen oder gar Fehlentwicklungen. Es gilt daher, Aussagen wie „Das System soll benutzerfreundlich sein“ zu vermeiden – denn diese sind in Bezug auf die konkreten Anforderungen zu vage. Setzen Sie daher unbedingt auf klare Formulierungen und konkret messbare Vorgaben, die für Klarheit sorgen – wie beispielsweise „Die Ladezeit darf zwei Stunden nicht überschreiten“. Formulierungen ohne Aussagekraft sind jedoch nicht die einzigen Fehler, die bei der Erstellung von Spezifikationen immer wieder auftreten. So kann auch eine fehlende Priorisierung der Anforderungen ebenso wie die unzureichende Einbindung aller relevanten Stakeholder im weiteren Projektverlauf Probleme mit sich bringen. Wie Sie diese Fehler vermeiden, erfahren Sie im Folgenden.

Arten der Spezifikation¶

Innerhalb einer Spezifikation lassen sich verschiedene Typen unterscheiden, die sich durch ihren Gegenstandsbereich sowie ihren funktionalen Zweck voneinander abgrenzen lassen: Die funktionale Spezifikation bezieht sich auf die Leistungsanforderungen eines Systems, etwa welche Funktionen Nutzer ausführen können sollen. Ergänzt wird diese durch nicht-funktionale Spezifikationen, die Qualitätsanforderungen – etwa in Hinblick auf Sicherheit, Performance oder Benutzerfreundlichkeit – beschreiben. Die technische Spezifikation hingegen bezieht sich auf die konkrete technische Umsetzung, einschließlich der Beschreibung verwendeter Schnittstellen, Technologien und Datenstrukturen. Schließlich kann eine Anwendungsspezifikation auch den konkreten Nutzungskontext präzisieren, indem sie Anforderungen an die Bedienung durch bestimmte Nutzergruppen oder in spezifischen Umgebungen festlegt.

Ein Beispiel, in dem die Spezifikation für einen neu zu entwickelnden Lidschatten festgeschrieben wird, soll Ihnen die verschiedenen Arten einmal verdeutlichen:

Die funktionalen Spezifikationen umfassen etwa die Erwartung, dass das Produkt eine gleichmäßige, farbintensive Deckkraft bietet, sowohl trocken als auch feucht applizierbar ist und dabei zuverlässig auf dem Augenlid haftet. Die nicht-funktionalen Spezifikationen betreffen hingegen qualitative Merkmale, wie eine mindestens zwölfstündige Haltbarkeit, Hautverträglichkeit gemäß dermatologischen Standards sowie die Einhaltung kosmetikrechtlicher Vorgaben bezüglich Inhaltsstoffen. Die technische Spezifikation konkretisiert diese Anforderungen durch Angaben zur Formulierung (z. B. talkumfrei), zur Verpackung (z. B. wiederverwendbares Magnetpfännchen im Kunststoff-Duo-Case) und zur Kompatibilität mit Applikationstools. Schließlich beschreibt die Anwendungsspezifikation den Gebrauchskontext: Der Lidschatten soll sich sowohl für den Alltagsgebrauch als auch für Bühnen-Make-up eignen, auf unterschiedlichen Hauttypen funktionieren und unter typischen Bedingungen (Licht, Temperatur, Bewegung) ästhetisch bestehen.

Lastenheft und Pflichtenheft¶

Im Kontext einer Spezifikation ist zwischen Lastenheft und Pflichtenheft zu unterscheiden – zwei komplementäre Dokumente, die durch unterschiedliche Perspektiven bestimmt sind:

Das Lastenheft, das in der Regel vom Auftraggeber erstellt wird, nimmt eine problem- und zielorientierte Sichtweise ein und beschreibt, was ein Produkt oder System leisten soll. Es legt also die Ziele, das Projektumfeld und die gewünschten Funktionen fest, ohne jedoch eine bestimmte technische Lösung vorwegzunehmen. Es bleibt damit lösungsneutral und bildet die Grundlage für die Ausarbeitung des Pflichtenhefts.

Das Pflichtenheft wiederum wird vom Auftragnehmer auf Basis des Lastenhefts erstellt und beschreibt, wie die Anforderungen des Auftraggebers umgesetzt werden sollen. Es dokumentiert also konkret die technischen Maßnahmen, Architekturen und Technologien mittels derer das Projekt verwirklicht werden soll und ist somit realisierungsorientiert und lösungsspezifisch.

Eine sorgfältige Abstimmung beider Dokumente ist unabdingbar. Denn Änderungen im Pflichtenheft können Auswirkungen auf das Lastenheft haben, etwa wenn sich bestimmte Anforderungen als technisch nicht umsetzbar erweisen – eine iterative Rückkopplung und Freigabe durch den Auftraggeber sind daher essenziell.

Erstellung einer Spezifikation¶

Die Erstellung einer Spezifikation folgt in der Regel einem mehrstufigen Prozess, der mit der systematischen Anforderungserhebung beginnt. Ziel ist es, die Erwartungen und Bedarfe aller relevanten Stakeholder möglichst vollständig zu erfassen. Dabei können unterschiedliche Erhebungsmethoden zum Einsatz kommen – darunter Interviews, Workshops, Fragebögen, Beobachtungen oder aber auch die Analyse vorhandener Dokumente.

Im nächsten Schritt werden die Anforderungen strukturiert und kategorisiert – etwa in funktionale und nicht-funktionale Anforderungen oder nach dem MoSCoW-Modell in Muss-, Soll- und Kann-Anforderungen. Auch eine Zuordnung zu bestimmten Systemmodulen oder -bereichen ist in dieser Phase üblich.

Das MoSCoW-Modell¶

Das MoSCoW-Modell ist eine häufig eingesetzte Methode zur Priorisierung von Anforderungen, die ihren Ursprung in der agilen Projektplanung hat und insbesondere im Rahmen von Dynamic Systems Development Method (DSDM) etabliert wurde. Der Begriff selbst ist ein Akronym, das sich aus den Anfangsbuchstaben der vier Priorisierungskategorien zusammensetzt:

M – Must: Anforderungen, die zwingend erfüllt werden müssen, damit das Projekt als erfolgreich gelten kann.
S – Should: Anforderungen, die wichtig sind, aber notfalls temporär zurückgestellt werden können.
C – Could: Anforderungen, die wünschenswert, aber nicht notwendig sind – sie stellen eine Verbesserung dar.
W – Won’t (this time): Anforderungen, die bewusst nicht umgesetzt werden, aber ggf. in späteren Überarbeitungen oder Nachfolgeprojekten berücksichtigt werden könnten.

Das MoSCoW-Modell unterstützt das Projektteam dabei, Anforderungen mit begrenzten Ressourcen gezielt zu priorisieren, und sorgt für Transparenz in Bezug auf Erwartungen und Kompromisse. Es sollte bereits während der Anforderungserhebung eingesetzt und fortlaufend überprüft werden.

Die im Anschluss erfolgende Formulierung der eigentlichen Spezifikation erfordert große Sorgfalt. Denn Anforderungen sollen eindeutig, überprüfbar, konsistent und vollständig fixiert werden. Verzichten Sie daher - wie oben bereits erläutert – auf vage Aussagen, sondern setzen Sie stets auf präzise Formulierungen und legen Sie konkret messbare Zielsetzungen fest.

Nach der Formulierung ist eine regelmäßige Abstimmung mit Auftraggebern, Entwicklern und Fachexperten unerlässlich. Im Rahmen solcher Reviewprozesse kann die Spezifikation auf ihre Verständlichkeit, Umsetzbarkeit und Vollständigkeit hin geprüft werden. Die Verwendung von Prototypen kann dabei helfen, abstrakte Anforderungen anschaulicher zu machen und ein gemeinsames Verständnis zu fördern.

Mit Abschluss der Abstimmungen erfolgt die formale Freigabe sowie die Dokumentation der Spezifikation. Dabei ist insbesondere auf eine sorgfältige Versionierung zu achten. Jede Änderung muss eindeutig nachvollziehbar sein, mit entsprechender Begründung und klarer Autorenschaft. Während veraltete Versionen der Spezifikation inklusive Änderungsprotokoll zentral archiviert werden, muss die aktuelle Version für alle Beteiligten jedoch stets zugänglich sein und als verbindliche Grundlage anerkannt werden.

Die Spezifikation als lebendiges Dokument¶

Eine besondere Herausforderung liegt darin begründet, dass eine Spezifikation kein statisches Dokument ist. Denn in dynamischen Projektumgebungen ändern sich Anforderungen häufig durch technologische Entwicklungen, neue gesetzliche Rahmenbedingungen oder veränderte Erwartungen seitens der Stakeholder. Eine Fortschreibung der Spezifikation ist daher essenziell.

Um diese zu gewährleisten, ist ein professionelles Änderungsmanagement erforderlich. Change-Request-Prozesse, Versionierungssysteme wie Confluence sowie regelmäßige Reviewzyklen – beispielsweise monatlich – sichern die Nachvollziehbarkeit und Qualität des Dokuments über den gesamten Projektverlauf hinweg ab. In der Praxis haben sich zwei Modelle zur Fortschreibung etabliert: Zum einen die Spezifikation als „lebendes Wiki“, das fortlaufend ergänzt wird. Zum anderen formale Spezifikationsdokumente mit explizitem Änderungsprotokoll, wie sie im klassischen Projektmanagement üblich sind.

Jedoch birgt die kontinuierliche Weiterentwicklung auch Risiken: So kann das sogenannte „Feature Creep“ – also das unkontrollierte Wachstum von Anforderungen – sowohl Budget- als auch Zeitpläne gefährden. Zudem kann es zu Zielkonflikten kommen, wenn Änderungen nicht sorgfältig mit den ursprünglichen Projektzielen abgeglichen werden – klare Rollen, Verantwortlichkeiten sowie ein verbindlicher Änderungsprozess sind daher entscheidend.

Mit der Spezifikation haben wir nun genau festgelegt, was wie erreicht werden soll und welche Anforderungen das Ergebnis erfüllen muss. Um diese Anforderungen strukturiert und kontrollierbar umzusetzen, wird ein klarer Prozess sowie eine sinnvolle Abfolge von Arbeitsschritten benötigt. Im nächsten Schritt betrachten Sie daher das Phasenmodell und lernen, wie sich Projekte systematisch in planbare Etappen gliedern lassen.