Best practice: Anforderungsspezifikation (Lastenheft) erstellen

Bild: NicoElNino / shutterstock.com

In einer idealen Welt kommt die Anforderungsspezifikation (auch als Lastenheft bekannt) immer vom Kunden und enthält wenige Unklarheiten. Da die ideelle Welt nicht existiert, wirst du als Auftragnehmer meist nur rudimentär mitgeteilt bekommen, was die Anforderungen tatsächlich sind und dir den Rest selbst erarbeiten müssen.

Aufseiten des Auftragnehmers spricht man vom Pflichtenheft. In der Literatur werden beide unterschiedlich behandelt. Steht die Anforderungsspezifikation, ist das Pflichtenheft allerdings nicht mehr weit weg. Deshalb wäre es aus meiner Sicht schwachsinnig daraus getrennte Beiträge zu machen. Dafür fehlt mir und euch die Zeit.

Um deine Existenz als Selbständiger zu bewahren, solltest dir du so wenige Fehler wie möglich erlauben. Vor allem in der Anfangszeit. Egal, ob du einen Auftrag annimmst, selbst jemanden beauftragst oder deine eigene Idee umsetzt: Eine gute Planung ist die halbe Miete. Und eines der wichtigsten Instrumente für eine gute Planung ist die Anforderungsspezifikation.

Anforderungsspezifikation Aufbau

Der Aufbau eines Lastenheftes ist in der Regel immer ähnlich. Der Inhalt unterscheidet sich jedoch essenziell, je nachdem ob es sich um ein reales Produkt, eine Dienstleistung oder eine Software handelt. Es kann sein, dass ich in meinem Beitrag ein bisschen zu sehr softwarelastige Beispiele bringe. Aber das ist halt mein Steckenpferd.

Lastenheft – Einleitung

Bei der Einleitung der Anforderungsspezifikation sollte in zwei- bis drei Sätzen beschrieben werden, was das Problem ist und wie es gelöst werden soll. Zudem sollten die beteiligten Unternehmen und die verantwortlichen Personen aufgeführt werden. Bestenfalls mit Kontaktmöglichkeiten, dass bei Nachfragen schnell Kontakt aufgenommen werden kann.

Es empfiehlt sich den aktuellen Stand des Dokuments mittels Datumsangabe am Ende der Einleitung aufzuführen. Bestenfalls mit einer Versionierung. Da solche Dokumente meistens per E-Mail öfters Hin und Her gesendet werden, kann eine ordentliche Versionierung Verwirrungen vorbeugen.

Ist-Zustand beschreiben

Wen man etwas Neues beauftragt, fehlt einem offensichtlich etwas im Unternehmen oder man ist mit den vorhandenen Mitteln unzufrieden. Es hilft beide Seiten, wenn im Lastenheft aufgeführt ist, wie es derzeit gehandhabt wird und warum man unzufrieden ist.

Soll-Zustand erörtern

Nachdem der Ist-Zustand in der Anforderungsspezifikation beschrieben wurde, geht es jetzt darum zu beschreiben, wie man sich die Lösung vorstellt. Wichtig ist klar zu machen, wie konkret das Produkt/die Dienstleistung den vorhandenen Unmut lösen soll. Ist das von allen Seiten nicht klar definiert, kommt es am Ende des Projekts relativ sicher zu Frust.

Sowohl für die Beschreibung des Soll-Zustands als auch des Ist-Zustands sind Prozessbeschreibungen und Skizzen von Vorteil um die Wünsche und Probleme zu visualisieren.

Schnittstellen beschreiben

Vor allem bei der Software-Modellierung ein nicht zu unterschätzender Punkt. Deshalb sollte Schnittstellenbeschreibung im Lastenheft alle Verknüpfungen zwischen verschiedenen Systemen beschreiben. Zum Beispiel wie die Eingabe von Daten geschieht. Wann Rechner-zu-Rechner Kommunikation, wann Mensch-zu-Rechner oder Rechner-zu-Mensch Kommunikation stattfindet.

Der Klassiker ist oft, dass am Ende ein Ergebnis herauskommen soll, es aber nie definiert wurde, wie. Der Entwickler macht eine Textausgabe, der Auftragnehmer will das aber in Excel haben. Das wird dann umgesetzt, bis sich herausstellt, dass das nächste Skript gar nicht mit Excel-Dateien weiterarbeiten kann. Oder es wird eine Eingabemaske für Android-Geräte entwickelt, weil im Kernunternehmen jeder so ein Smartphone besitzt. Dann stellt sich heraus, dass eine Außenstelle nur Apple-Produkte verwendet. Im großen Umfang könnte das zum Scheitern von Projekten führen oder zu erheblichen Mehrkosten.

Schlimmer wird es, wenn Fremdentwicklungen integriert werden sollen. Dann muss wirklich von vornherein klar sein, ob das überhaupt möglich ist.

Funktionale Anforderungen definieren

Jetzt kommen wir langsam zu den Punkten, an die man denkt, wenn das Wort Anforderungsspezifikation zum ersten Mal fällt. Die funktionalen Anforderungen sollten möglichst genau und detailliert beschreiben, was für ein Ergebnis wo und wie erwartet wird. Die einzelnen Anforderungen werden deshalb meist tabellarisch aufgezählt.

Beispiel Spezifikation

Bei einer sozialen Plattform soll die Anforderung “Foto hochladen” definiert werden. Dann könnte die Anforderungsbeschreibung im Lastenheft wie folgt aussehen:

• Anforderung: Foto hochladen
• Beschreibung: Jeder User soll die Möglichkeit besitzen, Fotos hochzuladen.
• Problembeschreibung: Der User soll die Möglichkeit besitzen, verschiedene Fotoformate hochzuladen. Dazu muss gewährleistet werden, dass er die Fotos einzelnen Alben zuordnen kann. Außerdem muss er es als Profilbild verwenden können.
• Abnahmekriterium: Folgende Formate müssen hochgeladen werden können: PNG, JPG, JPEG. Bei einer maximalen Auflösung von 4000 * 4000 px und einer maximalen Größe von 4 MB. Danach muss das Bild einem Album zugeordnet können und/oder als Profilbild verwendet werden. Darüber hinaus muss die Funktion selber aufgerufen werden können oder aus dem Profilbild/dem jeweiligen Album selbst. Dann muss es vorausgewählt sein, dass es im Profilbild/im Album zugeordnet ist.

Wie du siehst ähneln sich die Punkte ziemlich. Wichtig ist vor allem, dass klar wird, was das Problem ist und wie die Lösung aussehen soll. Je detaillierter, desto besser. Man hätte in dem Beispiel auch übertreiben können und drei Anforderungen daraus erstellen können: Foto frei hochladen, Foto aus Album hochladen, Foto aus Profilbild hochladen.

Der wichtigste Punkt ist wohl das Abnahmekriterium und die Kurzbeschreibung. Man könnte die einzelnen Anforderungsbeschreibungen auch noch mit weiteren Punkten ausstatten. Kundenzufriedenheit (wie sehr beeinflusst die Anforderung die Zufriedenheit der Kunden positiv) oder negativ, sollte der Punkt nicht eingeführt werden. Die Priorität der Anforderung könnte noch sinnvoll sein. Betroffene Systeme, Schnittstellen und Personen. Welche Konflikte zu erwarten sind. Welche Anforderungen zuvor erfüllt sein müssen, damit diese Anforderung überhaupt Sinn macht.

Nichtfunktionale Anforderungen definieren

Nichtfunktionale Anforderungen definiert man in der Anforderungsspezifikation eigentlich genauso wie die oben beschriebenen Funktionalen. Jedoch ist es hier subjektiver, was das Abnahmekriterium ist und wie genau das umzusetzen ist. Deshalb sollte hier vermehrt mit Skizzen oder sogenannten Mockups gearbeitet werden.

Nichtfunktionale Anforderungen könnten folgende sein:

• Benutzbarkeit: Kann man die Software/das Produkt ohne Erklärung benutzen. Wie viel einfacher im Gegensatz zur Konkurrenz ist das Produkt? Wie schnell soll die Eingabe verarbeitet werden? -> Skizze der grafischen Oberfläche.
• Zuverlässigkeit: Wie viele Anwendungen hält das Produkt aus? Welche Verfügbarkeit hat die Software? Welche Sicherheitsmaßnahmen gibt es für einen Ausfall?
• Effizienz: Ist das Produkt / die Software / die Dienstleistung im Preis-Leistungs-Verhältnis besser als die Konkurrenz oder die vorherige Lösung? Wie gut sind die variablen Kosten? Wie hoch ist der Gewinn bei der Einführung?
• Änderbarkeit: Mit welchem Aufwand ist eine Änderung in der Spezifikation verbunden? Auch im Nachhinein.
• Übertragbarkeit: Wie einfach kann die Software auf eine andere Hardware/einem anderen Betriebssystem übertragen werden?
• Wartbarkeit: Wie gut lässt sich beispielsweise der Programmcode warten (gute Dokumentation)? Was passiert, wenn es ein Software-Update bei verwendeten Schnittstellen gibt?

Risiken & Folgeabschätzungen

Es lohnt sich immer, die Risiken eines Projekts einzuschätzen, wie hoch die Eintrittswahrscheinlichkeit ist und wie, beziehungsweise ob man dem Risiko begegnen kann. Beispielsweise was passiert, wenn der Chefentwickler länger ausfällt, Bauteile nicht geliefert werden oder die Hardware an ihre Grenzen stößt.

Darüber hinaus sollten mögliche Risiken benannt werden, die nach dem Release auftreten können. Beispielsweise eine zu stark ansteigende Datenmenge oder zu viele Zugriffe, falsche Verwendung des Produkts und ähnliche Risiken.

Aufwands- und Kostenabschätzung

Nicht zwingend erforderlich, aber äußerst hilfreich ist eine Aufwands- und Kosteneinschätzung. Dafür würde ich die einzelnen Spezifikationen in eine Tabelle setzen und die benötigten Stunden schätzen. Dazu noch die nicht definierten Aufwände, wie beispielsweise Projektmanagement, Dokumentation und mögliche Lizenzkosten und schon besitzt man einen guten Überblick über den Aufwand und die Kosten.

Lastenheft: Nützliche Werkzeuge

Da es bei der Gestaltung der Anforderungsspezifikation keine Grenzen gibt, kann und sollte man sich unterschiedlicher Werkzeuge bedienen um die Anforderungen so gut wie Möglich zu beschreiben. Hier möchte ich aus meiner Sicht die Wichtigsten aufzählen und beschreiben. Jedoch ohne Anspruch auf Vollständigkeit. Denn viele Modellierungssprachen entscheiden sich dann nur noch in Nuancen zu denen, die ich hier aufgezählt habe.

Ereignisgesteuerte Prozesskette (EPK)

Ich weiß nicht, wie viele EPKs ich in meinem Studium machen musste, aber anscheinend sind sie für Projektmanager ziemlich wichtig. Nun, wo ich praktische Erfahrung habe, muss ich sagen, dass ich mir oft EPKs irgendwo hinkritzel. Sei es um einen Algorithmus zu visualisieren oder um Abläufe in meinem eigenen kleinen Unternehmen zu definieren.

EPKs bilden Prozesse ab. Beispielsweise, was passiert, wenn ein Supportfall eingeht. Es gibt immer ein Ereignis, dann ein Entscheidungskriterium und je nachdem, wie entschieden wird, geht der Pfad weiter. Man kann es auch erweitern mit zusätzlichen Infos und Tasks. Ich habe eine Ereignisgesteuerte Prozesskette für die Idee eines kostenpflichtigen Supports umgesetzt. Den haben wir zwar so nicht eingeführt, aber es verdeutlicht ganz gut, wie man EPKs einsetzen kann. (Das Beispiel ist nicht akademisch korrekt, also nutzt es bitte nicht zur Prüfungsvorbereitung an der Uni)

Unified Modeling Language (UML)

Die UML ist wohl das mächtigste Werkzeug für Projektmanager. In ihr werden einige der wichtigsten Modellierungsmöglichkeiten in einer Sprache zusammengefasst. Als Selbständiger sollte man sich die UML unbedingt zu Eigen machen, denn egal für welche Art von Business, man kann damit eigentlich jeden Prozess, jede Struktur und jede Aufgabe, egal in welcher Branche beschreiben.

Die UML kennt 14 Diagrammarten. Ich möchte exemplarisch zwei aus unserem Studienprojekt, die Entwicklung einer “Flickr”-Alternative, aufzeigen.

Use-Case-Diagramm

Ein Use-Case-Diagramm oder auch Anwendungsfalldiagramm genannt, zeigt die Beziehungen zwischen verschiedenen Akteuren und deren Abhängigkeiten zum jeweiligen Anwendungsfall auf. Das ist nicht nur in der Software-Entwicklung ein nützliches Instrument, sondern auch in Organisationsstrukturen. So könnte Beispielsweise auch Fertigungsprozesse und die beteiligten Akteure damit abgebildet werden. Oder aber in einer Bank, wer alles bei einer Kreditentscheidung abhängig beteiligt ist. Der Fantasie sind hier keine Grenzen gesetzt.

In unserem Fall wollten wir aufzeigen, welche Funktionen unsere Fotoplattform bieten soll und welche Akteure daran beteiligt sind. Die einzelnen Punkte waren übrigens die oben erwähnten funktionalen und nichtfunktionalen Anforderungen in unserer Spezifikation.

Klassendiagramm

Das Klassendiagramm ist vor allem in der Software-Entwicklung ein super hilfreiches Instrument. Aus ihr kann man später die Software-Architektur ableiten. Sowohl für den Programmcode als auch für die Datenbank.

In einem Klassendiagramm werden die einzelnen Klassen mit ihren Eigenschaften und dessen Beziehung zu anderen Klassen abgebildet.  Hier nutze ich jetzt einmal das Beispiel aus Wikipedia, da das aus unserem Projekt nicht ganz ideal war.

Von Stkl – Redrawn in SVG, original PNG Klassendiagramm-1.png by Gubaer, CC BY-SA 3.0,

Mock-ups

In der Fachliteratur werden Mock-ups eigentlich nicht als Modellierungsmöglichkeit vorgeschlagen. Trotzdem halte ich Mock-ups vor allem für nichtfunktionale Anforderungen sehr gut, um im Lastenheft zu verdeutlichen, wie am Ende das Produkt / die Software aussehen soll.

Ein Mock-up ist ein Vorführmodell ohne Funktion. Bei einem Produkt könnte man das Mock-up zum Beispiel mittels 3D-Drucker erstellen. In der Software-Modellierung benutzt man meistens Tools, die ein grafisches Interface abbilden können. Oder “What You See Is What You Get” (WYSIWYG) Editoren, beziehungsweise einfache Designtools wie Bootstrap Editoren.

Modellierungstools

Es gibt ziemlich sicher mittlerweile tausende Modellierungstools zur Erstellung von Anforderungsspezifikationen. Ich habe bisher “nur” mit dreien gearbeitet. Von diesen Erfahrungen erzähle ich euch, alles andere wäre unseriös. Wie man eine Suchmaschine bedient, um weitere zu finden, wisst ihr sicherlich.

Windows Visio

Bisher immer noch mein Lieblings-Modellierungsprogramm. Auch wenn es manchmal die Verknüpfungen einzelner Objekte vermasselt, ist es doch sehr anwendungsfreundlich. Darüber hinaus besitzt es zahlreiche nützliche Grafiken, die für die Modellierung notwendig sind.

Ein Wermutstropfen ist der Preis, vor allem, da es nicht im Standard-Office-Paket enthalten ist. Einen Lizenz-Key erhält man (noch) für rund 30€. Mal sehen, wie lange es noch dauert, bis man es nur noch im Office 365 Abo erhält. Dort kostet es ab 12,70 € / Monat.

OpenOffice Draw

OpenOffice Draw ist die Open-Source-Alternative zu Windows Visio. Sie erfüllt seinen Zweck bie einfachen Modellierungsdiagrammen. Trotzdem wurde ich mit diesem Tool nicht immer ganz warm, wenn es einmal komplexer wird. Für kleine Diagramme sicherlich einen Blick wert.

Draw.io

Draw.io ist ein browserbasiertes Tool zur Erstellung von allerhand Modellierungsmodellen und Diagrammen. Also sicherlich auch hilfreich für andere Präsentationen. Von der Oberfläche ähnelt es dem Google-Sheet. Die Auswahlmöglichkeiten sind gut und die Bedienung ist einwandfrei. Vielleicht sogar eine bessere Alternative als Windows Visio. Leider habe ich damit noch kein großes Diagramm erstellt. Aber was ich bisher gesehen habe, war sehr gut.

Modellierungs- und Diagrammtypen von Draw.io

Da es ein Open-Source-Projekt ist, ist die Benutzung kostenlos. Bisher habe ich auch keine versteckten Premiumkosten entdecken können. Man darf die erstellten Grafiken lizenzfrei verwenden, selbst für kommerzielle Zwecke. Es ist lediglich möglich, sich exklusive Cloud-Dienstleistungen zu sichern, über die sich der Dienst finanziert.

Anforderungsspezifikation: Volere Vorlage

Nun weißt du, wie eine Anforderungsspezifikation aussehen sollte und welche Modellierungsmöglichkeiten im Lastenheft vorkommen können.

In Studienprojekten habe ich die Vorlage von Volere kennen und lieben gelernt. Diese ist eigentlich kein Hexenwerk, sondern nur noch einmal die einzelnen Punkte eines Lastenhefts strukturiert und mit Beispielen versehen als Dokument aufgelistet.

Wer sich also die eigene Strukturierung der Anforderungsspezifikation sparen möchte, kann sich auf der Volere Homepage für 55 $ die Vorlage für ein Projekt erwerben.

Das Lastenheft in der Praxis

Wie ich eingangs geschrieben habe, wäre der Idealfall, dass das Lastenheft vom Auftraggeber geliefert wird. Meistens ist das nicht der Fall, außer man arbeitet mit größeren Firmen mit entsprechendem Know-how zusammen. In der Regel werden die Anforderungen in Meetings und grobem Mailaustausch zusammengetragen. Hier empfiehlt es sich, dass du eine Anforderungsspezifikation daraus erstellst und diese bevor du loslegst, absegnen lässt.

Die Anforderungsspezifikation ist darüber hinaus sehr hilfreich, wenn mehrere Leute (z.B. deine Mitarbeiter) an einem Projekt arbeiten. Je technisch detaillierter hierbei die Ausformulierung ist, desto wahrscheinlicher ist ein gelingen des Projekts.

Natürlich verschlingt auch die Erstellung einer Anforderungsspezifikation einiges an Zeit. Oftmals ist der Kunde auch nicht bereit dies auszugeben. Trotzdem solltest du beachten, dass du mit vernünftiger Planung meist schneller in der Umsetzung bist und dies über diesen Weg einpreisen kannst. Am Ende profitieren beide Seiten vom Projekterfolg. Es gibt nichts Schlimmeres, als dass ein Projekt scheitert oder Erwartungen enttäuscht werden. Und das ist ohne vernünftige Planung äußerst wahrscheinlich.

Klar ist aber auch, dass es nicht möglich ist alle Eventualitäten schon im Voraus zu kennen. Deshalb sollte das eigene Projektmanagement flexibel genug sein, auch während eines Projekts die Anforderungen zu evaluieren und gegebenenfalls anzupassen.

Lastenheft vs. Pflichtenheft

Da die Anforderungsspezifikation eigentlich vom Auftraggeber kommen sollte, kommt das Pflichtenheft eigentlich vom Auftragnehmer. Dabei wird noch einmal detaillierter auf die Umsetzbarkeit der einzelnen Anforderungen eingegangen. Im schlimmsten Fall werden unrealistische Anforderungen begründet gestrichen.

In der Realität entwickelst du als Selbständiger wie gesagt meistens das Lastenheft selbst. Es wandelt sich, nach der finalen Besprechung mit dem Auftraggeber quasi in ein Pflichtenheft um.

Ich freue mich von dir zu hören!

Du kommst bei deinem Projekt nicht weiter oder brauchst einen Boost? Dann lass dir von mir helfen zum Beispiel bei: ► Beratung für Selbständige, Gründer & Ideenschmiede Egal, ob du erste Tipps brauchst. Einmal über deine Idee reden möchtest oder mit mir das Konzept für das nächste Facebook ausarbeiten willst. ► Entwicklung von Software, APPs & Webseiten Beispielsweise: WordPress Shops & Plugins, (Gaming-)Apps, Datenbank-Applikationen oder andere smoothe Anwendungen! Mehr Infos, Preise und Kontaktmöglichkeiten findest du hier!