Requirements-Engineering mit Word und Excel – Teil II

Den ersten Teil zum Thema Requirements-Engineering könnt ihr hier lesen.

Im letzten Beitrag habe ich bereits die Aspekte erwähnt, die für eine handlungsorientierte Antwort auf die generelle Frage, welche Spezifikationen nötig sind, eine Rolle spielen.

Diese waren die Komplexität des Systems, ein Lastenheft vom Kunden oder dem Produktmanagement, Vorgaben durch Normen und wie intensiv das Thema im Unternehmen aufgegriffen wird. Daraus können wir die eine entscheidende Antwort zu den Spezifikationen generieren.

Auch wenn mich die Qualitätsmanagementbeauftragten aus meiner Branche jetzt gerne erschlagen würden: Der Alltag hat vielfach gezeigt, dass ein Lastenheft und eine System-Architektur-Spezifikation zunächst ausreichen.

Mir ist bewusst, dass auch die anderen Spezifikationen sehr relevant sind. Dennoch sind die beiden gerade genannten die Wichtigsten, und ich möchte in diesem Beitrag erläutern, warum.

Spezifikation I: Das Lastenheft in der Problemsicht

Das Lastenheft ist die Vereinbarung mit Dritten, also mit Außenstehenden, über die Lasten an das System. Wie ich es gerne formuliere: Es ist das „Wünsch dir was“, welches ihr – je nach Größe eures Unternehmens – gemeinsam mit dem Kunden oder dem Produktmanagement erstellt.

Zudem ist das Lastenheft ein Dokument, das in der Problemsicht angesiedelt ist: Ihr schafft somit eine Spezifikation, die die Problembeschreibung beinhaltet. Und mit dieser vereinbart ihr gemeinsam und hundertprozentig, was genau ihr machen wollt.

Mit hundertprozentig meine ich, dass es so vollständig vereinbart ist, wie es zum Zeitpunkt der Erstellung möglich ist – mir ist bewusst, dass ein Lastenheft nicht zu 100% fertig sein kann, bevor man mit der Entwicklung beginnt.

Alle Spezifikationen – egal auf welcher Ebene und in welcher Sicht –, die in solchen komplexen Entwicklungsprojekten genutzt werden, sind lebende Dokumente. Sie entstehen am Anfang eines Projektes, das ein Jahr oder anderthalb Jahre Entwicklungszeit hat.

Wir kennen unsere Zukunft noch nicht: Nachdem wir die Spezifikationen definiert haben, werden wir oft mit technologisch neuen Ideen und Konzepten konfrontiert. Wir sind also ständig auch auf völlig neuem Terrain unterwegs.

Folglich werden die Spezifikationen auch mit uns wachsen und ihre Reife mit der Zeit steigern. Geht also nicht davon aus, dass euer Lastenheft zu Beginn schon hundertprozentig fertig ist – es muss nur zu 100% vereinbart werden, dass es für alle Beteiligten beim aktuellen Stand ausreichend gut und vollständig ist, um die Entwicklung zu starten.

Das ist also die erste wesentliche Spezifikation, die ich gerade kleinen und mittelständischen Unternehmen unbedingt ans Herz legen möchte: Das Lastenheft ist das wichtigste Dokument aus der Problemsicht.

Wie ihr dieses erstellt, könnt ihr z.B. in der Episode „Drei Wege im Umgang mit Lastenheften“ des ZukunftsArchitekten-Podcasts nachhören.

Spezifikation II: Die System-Architektur in der Lösungssicht

Die zweite Spezifikation ist die der System-Architektur. Diese beschreibt die Lösung – und ist damit meines Erachtens ebenso wichtig wie das Lastenheft. Es ist ein Dokument auf der Systemebene und zeigt das gesamte System, im mechatronischen Umfeld auch die Elektronik, die Software und die Mechanik, alle Domänen.

Es ist quasi die Blaupause dessen, was ihr entwickeln wollt, inklusive Requirements. Wenn wir also alle Prozesse durchgehen, wie es zum Beispiel in der Automobil-Branche üblich ist, dann entsteht dieses Dokument sozusagen automatisch.

Die Prozessschritte zwischen dem Lastenheft und der System-Architektur-Spezifikation beinhalten mehrere Spezifikationen. Aber für alle, die in einem kleinen oder mittelständischen Unternehmen sind und ein sehr überschaubares System vorliegen haben, ist die System-Architektur-Spezifikation für die konkrete Umsetzung ein entscheidendes Dokument, weil ihr damit das große Bild beschreibt.

Das Schöne an dieser System-Architektur-Spezifikation ist außerdem: Es ist das erste Dokument, was du schaffst, wenn diese gesamte Ebene eigentlich noch fehlt. Du produzierst damit im Prinzip die Beschreibung dessen, was zu entwickeln ist.

Aus meinen Erfahrungen im Troubleshooting-Bereich weiß ich, dass es wirklich wichtig ist und beispielsweise neuen Kollegen im Team enorm dabei hilft, sehr schnell zu verstehen, was eigentlich entwickelt werden soll.

Die zwei entscheidenden Spezifikationen, die ihr also unabhängig von vielen individuellen Gegebenheiten unbedingt braucht, sind das Lastenheft aus der Problemsicht und die System-Architektur-Spezifikation aus der Lösungssicht.

Wie genau ihr euer Requirements-Engineering mit Word und Excel organisieren könnt, werde ich im nächsten Teil näher beschreiben.