Requirements-Engineering mit Word und Excel – Teil I

Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.

Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Word und Excel zu arbeiten, was nicht immer einfach ist – und weswegen ich die nächsten Beiträge diesem Thema widmen möchte.

Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.

Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe „traditionell“ – die Word- oder auch Excel-Werkzeuge.

Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.

Das Ziel dieser Episoden ist es, euch das nötige How-to und viele Tipps zu vermitteln, um eure Spezifikationen mit Word zu handhaben. Zunächst habe ich ein paar Begriffsklärungen und ein wenig Hintergrundwissen für Leser, die die vorangegangenen Beiträge noch nicht kennen.

Ebenen und Sichtweisen von Spezifikationen

Ein wichtiger Punkt bei Spezifikationen ist die Unterscheidung verschiedener Ebenen: Die oberste Ebene, das sogenannte Customer-Level, beinhaltet alle Lasten aus Sicht des Kunden oder der involvierten Kundengruppen.

Die zweite Ebene ist die System-Ebene. Das ist im Prinzip die Ebene, die das gesamte System betrachtet. Sie bietet einen sehr generellen Überblick über das System und die entsprechenden Requirements.

Dann gibt es noch die dritte Ebene, die sogenannte Technologie-Ebene, die beispielsweise Software, Elektronik oder Konstruktion meint.

Im Überblick: Die oberste Ebene gilt dem Kunden und meint die Spezifikationen, die die Anforderungen beinhalten. Die zweite Ebene meint das System, also die Spezifikationen, die die Architektur beinhalten. Und die dritte umfasst eben die Technologie-Spezifikationen.

Neben diesen drei Ebenen gibt es bei Spezifikationen auch noch zwei grundsätzliche und grundsätzlich verschiedene Sichtweisen. Die eine Sicht ist die sogenannte „Problemsicht“. Das ist im Prinzip eine Beschreibung der Anforderungen in Bezug auf das Problem, in der nur Funktionen und nicht funktionale Anforderungen festgehalten werden.

Die zweite Sicht ist die „Lösungssicht“. Hier beschreiben wir die Anforderungen bezogen auf die Lösung. Das ist also ein Dokument, in dem die Lösung, die Komponenten und welche Anforderungen diese Komponenten übernehmen, im Fokus stehen.

Wer noch mehr dazu wissen möchte: Ich habe zahlreiche Podcast-Episoden zu diesen Themen online gestellt, beispielsweise Episode sieben, „Lastenheft versus Pflichtenheft“. In den Episoden 29 und 30 gehe ich explizit auf die beiden Dokumente – auf die System-Requirements-Spezifikation und System-Architecture-Spezifikation – auf der System-Ebene ein.

Es gibt noch weitere Episoden, in denen ich auf Doors eingehe, also wie man Lastenhefte bewerten kann etc. Schaut einfach mal rein, wenn ihr sie noch nicht gehört habt.

Welche Spezifikationen sind notwendig?

Steigen wir nun also richtig ein: Ein besonders wichtiger Punkt sollte gut durchdacht werden: Welche Spezifikationen brauche ich? Wir haben schließlich die beiden Sichten Problem und Lösung und die Ebenen, das heißt also mindestens sechs verschiedene Spezifikationen, die eine Rolle spielen können.

Bei kleinen und mittelständischen Unternehmen ist die Frage, welche Spezifikationen benötigt werden, entscheidend. Wenn ich das gefragt werde, stelle ich den Firmen folgende Gegenfragen, um die Lösung zu fixieren.

Das Erste ist: Wie komplex ist das System? Reden wir über ein relativ klar abgegrenztes, überschaubares System oder ist es ein sehr komplexes, z.B. mit hohen Interaktionen zu anderen Systemen? Die Antwort auf diese Frage ist ein sehr guter erster Indikator für die nötigen Spezifikationen.

Das Zweite, was ich danach erfrage, ist: Gibt es überhaupt ein Lastenheft? Dies kann entweder von einem externen Kunden mitgebracht werden, der dann sagt, „genau das will ich haben“, oder aber es gibt ein Lastenheft vom Produktmanagement, Marketing, Vertrieb oder einer ähnlichen Abteilung. Die Entwicklung sagt hier also, „wir brauchen das, das und das für die zukünftige Generation unserer Produkte.“

Meine dritte Frage lautet: Welche Vorgaben liegen durch Normen vor? Je nach Kontext können diverse Normen einzuhalten sein, im Bereich Automotive oder Medizintechnik beispielsweise Safety- bzw. Sicherheitsnormen. In solchen Branchen werden also schon allein durch die Normen gewisse Spezifikationen definiert.

Und die letzte Frage ist: Wie oft betrifft Dich dieses Thema? Hast Du damit vielleicht alle sechs Monate zu tun, weil es ein sehr überschaubares System oder Produkt ist und Du vielleicht nur fünf Kollegen hast? Oder wird das Ganze kontinuierlich immer wieder sehr intensiv in die Entwicklung hineinspielen?

Im nächsten Teil beschreibe ich, wie ich mit diesen Fragen zu einer sehr pragmatischen Antwort auf die generelle Frage komme, welche Spezifikationen benötigt werden.