Requirements-Engineering mit Word und Excel
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.
Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.
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 KnowHow 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?
Mit diesen Fragen bekomme ich die Aspekte genannt, 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 Kapitel 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.
Erstellen der Spezifikationen
Kommen wir in diesem Kapitel nun auf die Organisation der Spezifikationen zu sprechen. Bei diesem Thema kommen fast automatisch die entsprechenden Tools ins Spiel. Meine erste Empfehlung vorweg:
Besser Word anstelle von Excel verwenden!
Wenn ihr keine Requirements-Engineering-Werkzeuge habt, nutzt lieber Word als Excel. Mit jahrelanger Erfahrung möchte ich mich wirklich nachdrücklich dafür aussprechen.
Der Hintergrund ist relativ einfach. Man kann in Excel zwar recht schnell viele (Unter-)Tabellen produzieren und gleichzeitig über diverse Makros auch noch eine „Pseudo-Traceability“ einbauen. Doch meiner Meinung nach geht Excel an dieser Stelle auch ganz schnell nach hinten los.
Es gibt zunächst einen ganz pragmatischen Grund, warum Excel nicht gut funktioniert: Wir können keine Bilder in die Excel-Tabellen kopieren. Wenn ich aber ein gutes beschreibendes Bild für mein System habe, ist es natürlich mehr als blöd, wenn ich es in der Spezifikation nicht darstellen kann.
Hinzu kommt, dass der Ausdruck bzw. der PDF-Export einer Excel-Tabelle beispielsweise für Kunden oder einen Dritten bedeutend aufwändiger ist als bei Word. Daher also meine Empfehlung aus der Praxis: Nutzt lieber Word, dort könnt ihr schließlich auch mit Spalten arbeiten.
Modularisierung der Spezifikationen
Meine zweite große Empfehlung: Eine Modularisierung. Versucht, eure Spezifikationen zu modularisieren. Nehmt ein Word-Dokument und sammelt dort das Inhaltsverzeichnis und alle dokumentenspezifischen Informationen für die Spezifikation.
Legt zudem eigene Doc-Files für die ganzen relevanten einzelnen Kapitel an. Nehmt euch dafür ein wenig Zeit und schaut mit Sinn und Verstand, was zusammen in ein Word-Dokument gehört. Nicht jedes Unterkapitel gehört hier in ein Doc-File, doch clever aufbereitet ist dieser modulare Aufbau sehr wertvoll.
Das Ganze hat zwei große Vorteile: Zum einen können mehrere Kollegen gleichzeitig an unterschiedlichen Kapiteln arbeiten, ohne dass sie sich gegenseitig behindern, alles doppeln und hinterher alle Änderungen aufwändig in einem Dokument zusammenführen müssen.
Zweitens ist Word so deutlich schneller. Gerade wenn ihr diese Dateien auf einem Firmen-Netzlaufwerk liegen habt, kann es sehr mühselig sein, ein 20 oder 30 Megabyte großes Word-Dokument überhaupt zu öffnen. Mit den Kapitel-Dokumenten habt ihr wesentlich angenehmere Größen und könnt flexibler arbeiten.
Versionierung
Modularisierung macht also extrem viel Sinn. Ein weiterer Aspekt, der damit zusammenhängt, ist die „Versionierung“, also die Nachverfolgung der Text-Revisionen: Achtet darauf, dass ihr bei euren Files immer die Möglichkeit habt, alte Stände wieder zurückzuholen!
Das hat den großen Vorteil, dass ihr zu jedem Zeitpunkt schauen könnt, wann ihr ein Requirement entfernt oder warum ihr ein neues hinzugefügt habt. Gleichzeitig habt ihr natürlich auch Sicherungskopien, wenn diese Form des Versionen-Managements auf euren Servern bzw. in eurer Firmen-Infrastruktur liegt und Backups produziert werden.
Wie ihr dieses Management handhabt, kann variieren. Das Einfachste ist, alles über einen Subversion-Server und entsprechende Free Tools abzubilden. Das integriert sich sehr schön in die klassische Explorer-Sicht von Windows oder in den Finder auf Macs.
Damit habt ihr die Möglichkeit, alles effizient zu versionieren und müsst zudem jedes Mal ein- und auschecken, sodass ihr auch Kommentare hinterlassen und erläutern könnt, warum es diese neue Version gibt, welche Änderungen vorliegen etc.
Vergleichbarkeit der Strukturen
Ein weiterer Vorteil dieser Organisation von Spezifikationen ist die Vergleichbarkeit der Strukturen – wenn diese gut abgesprochen sind. Ich kann nur empfehlen, eine einheitliche Dokumentenstruktur zu vereinbaren. So bleiben alle Files ähnlich und werden auch gleich verständlich sein.
Ihr könnt hierfür gerne die Templates für die System-Requirements und System-Architecture-Spezifikationen nehmen, die ich in den Podcast-Episode 29 und Episode 30 online gestellt habe. Passt diese einfach für eure Bedürfnisse an.
Wenn Vergleichbarkeit vorliegt, könnt ihr eure Erfahrungen auch mit anderen Teams austauschen. Wenn ihr beispielsweise immer das gleiche Kapitel zu einer Basistechnologie habt, die ihr über alle verschiedenen Produkte in eurem Unternehmen einsetzt, dann könnt ihr dieses als feste Grundlage verwenden: „Das ist unser Kapitel für die Anforderungen an die Basistechnologie XY. Alle verweisen immer auf dieses Kapitel und verändern es nur gemeinsam.“
Schließlich hat diese Vergleichbarkeit auch den Vorteil, dass Kollegen, die das reviewen, es viel schneller verstehen, weil sie die Struktur und den Sinn dahinter kennen.
Tabellen in Word
Wenn ihr mit Word arbeitet, legt eine simple, pragmatische Tabelle an. Ich empfehle hierbei sehr, mit vier Spalten zu arbeiten (und nicht im Excel-View !!! ):
- Die erste Spalte ist der Requirements-Text, das heißt das Statement.
- Die zweite Spalte ist der Requirements-Typ, handelt es sich also um eine Bemerkung zu einer Dokumentenanforderung, eine Überschrift, die Dokumentenanforderung per se etc.
- Die dritte Spalte ist der aktuelle Status, beispielsweise: „Noch nicht angefasst“, „In Arbeit“, „In Review“ oder „Freigegeben“.
- Die vierte Spalte beinhaltet den Test-Level. Ich empfehle diese Spalte ausdrücklich, auch wenn ich sie selten sehe. Aber es gehört sich für einen System-Ingenieur, dass er für Kollegen auf der Testseite auch Vorschläge macht, auf welcher Ebene sie eine Anforderung testen können.
Diese vierte Spalte hat aber noch einen anderen Hintergrund, den ich in anderen Episoden bereits erklärt habe. Ganz kurz zusammengefasst: Wenn ich Schwierigkeiten habe, dem Systemtester hier zu sagen, auf welcher Ebene er das bitte testen soll, dann weiß ich, dass ich meine Anforderung schlecht geschrieben und z.B. zwei Anforderungen in einen Satz gepackt habe. Für System-Ingenieure ist diese Spalte also extrem vorteilhaft.
Legt einfach diese vier Spalten in einem Kapitel an und arbeitet damit – aber ohne Prosa zu verwenden! Wenn ihr mit Word arbeitet, verleitet dies oftmals und ganz schnell zu Prosa. Ihr solltet aber unbedingt die Requirements-Engineering-Grammatik benutzen, um die Sätze entsprechend zu strukturieren.
Die Requirements-Engineering-Grammatik
In dieser Grammatik findet ihr drei bzw. vier Level: Am Anfang steht meist die sogenannte „Condition“, also eine Kondition, die in einem When-Statement formuliert wird, z.B. „wenn die Temperatur über 80 Grad steigt, muss das System das Ventil öffnen“. Das kommt bei einem Anforderungssatz nicht immer vor, wichtig ist aber, dass ihr das reinschreiben könnt, wenn es vorliegt. Das zweite Level ist das „Objekt“, also das, was ich in diesem Satz bezeichne, an wen ich diese Anforderung richte. In dem Beispielsatz war es „das System“. Dann könnt ihr einen sogenannten „Schweregrad“ der Anforderung definieren. Typischerweise haben wir drei verschiedene Ebenen: Ein „muss“ bedeutet eine absolut klare und hundertprozentige Vorgabe. Trotz aller unterschiedlichen Definitionen anderer Level gibt es immer dieses „muss“, das heißt, die Anforderung ist zu 100 Prozent zu erfüllen. „Sollte“ und „kann“ sind weitere Möglichkeiten, die Firmen nutzen – manche haben auch vier Level. „Sollte“ bedeutet, etwas zu einem hohen Grad zu erfüllen, wobei diese Anforderung aber auch eine ähnlich gelagerte Lösung sein kann. Und „Kann“ ist eine Empfehlung, die erfolgen kann, aber nicht muss. In der Requirements-Grammatik folgt dann noch die Aktion, z.B. „das Ventil öffnen“. Insgesamt haben wir also die Kondition, das Objekt, die Einstufung und die Aktion.
Chris Rupp hat ein sehr gutes Buch dazu geschrieben, das kann ich euch nur wärmstens empfehlen. Alternativ könnt ihr auch im Netz nach „Requirements-Struktur“ suchen.
Es hat mehrere Gründe, warum mir das hier wichtig ist. Zum einen sind Anforderungen interpretierbar – gerade, wenn wir sie verschriftlichen. Durch den Satzbau der Requirements-Engineering-Grammatik haben wir die Möglichkeit, Anforderungen viel, viel klarer zu formulieren und auch immer nur eine Anforderung anzubringen. Ich weiß, dass sich das Dokument später durchaus blöd liest, weil jeder Satz genau die gleiche Form hat – aber wir schreiben ja keinen unterhaltenden Roman, sondern versuchen, ein technisches Problem zu spezifizieren. Und dafür macht diese Grammatik sehr viel Sinn. Zum anderen hat sie den großen Vorteil, dass wir unsere Testbarkeit erhöhen können, wenn wir sie einsetzen. So kann auch ein System- oder Softwaretester relativ klar einen Testfall definieren: Er erhöht z.B. die Temperatur auf 79 Grad, wobei das Ventil noch zu sein soll. Er erhöht die Temperatur auf 80 Grad – und das Ventil soll sich öffnen. Er höht die Temperatur auf 81 Grad, das Ventil soll auch hierbei geöffnet sein. Er kann also richtig simpel Grenztests machen etc. Ihr seht, diese Art der Grammatik macht sehr viel Sinn, also versucht, sie zu nutzen.
Keine Requirements-IDs in Word!
Und eines noch: Vergebt keine Requirements-IDs. Das ist zwar sehr verlockend, aber ihr werdet dadurch früher oder später in Teufels Küche kommen. Der Grund ist relativ einfach: Ihr setzt den ersten Schwung an Requirements auf, nummeriert sie durch und gebt das Dokument eurem Kollegen zum Review, der ein paar Änderungen und Ergänzungen macht. Damit ist relativ klar, dass ihr jetzt noch ein paar Requirements irgendwo dazwischen setzen werdet – und diese dann aber die höchste Nummer haben, die aktuell letzte ID, die ihr vergebt. Das geht dann noch ein paarmal so weiter und nach ein paar Monaten ist es unglaublich schwierig, herauszufinden, welche denn die letzte ID war, die vergeben worden ist. Die korrekte Nummerierung ist kaum noch herzustellen.
Tools setzen IDs automatisch, Word nun mal nicht. Dementsprechend kommt ihr da eigentlich nur total durcheinander. Das heißt, lasst es lieber weg.
Mit Word ohne Traceability & Reports arbeiten
Mir ist durchaus bewusst, dass Traceability wichtig ist. Mit den Requirements-Engineering-Werkzeugen wenden wir sie auch an. Wenn ihr aber mit Word arbeitet, ist Traceability kaum einbaubar. Das ist einfach Fakt.
Dabei ist diese Möglichkeit der Nachverfolgung durchaus wertvoll. Wenn z.B. oben im Lastenheft eine Anforderung vom Kunden steht, beispielsweise „Das System muss bei 80 Grad abschalten“, so habt ihr sofort eine vernünftige Anforderungsbeschreibung: „Wenn die Temperatur über 80 Grad steigt oder wenn die Temperatur bei 80 Grad ist, muss das System das Ventil öffnen.“ Daraus entwickeln sich zudem verschiedene Anforderungen für die verschiedenen Domains. Also für die Software, für die Elektronik, die Mechanik, Satzanforderungen zu Öffnungsgeschwindigkeiten, Winkeln, Messungen und so weiter.
Aus diesem einen banalen Satz, den ich auf der Systemebene habe, können unten eine ganze Menge Requirements herausfallen. Genau das ist Traceability: Wir können nachvollziehen, wo das alles herkommt. Was ist aus dieser Lastenheftanforderung eigentlich ganz unten auf der Domain-Ebene in den jeweiligen mechatronischen Bereichen geworden?
Oder auch andersrum: Der Kollege aus der Konstruktion kann sagen: „Woher kommt die Anforderung über eine Öffnungsgeschwindigkeit in meinem konstruktiven Ventil? Und wieso ist das so, wie es da drinsteht?“ Diese Möglichkeit der Nachvollziehbarkeit ist mit Requirements-Engineering-Werkzeugen gegeben.
Sie mit Word herzustellen, ist wirklich furchtbar schwierig, ganz zu schweigen von Excel. Ich rate ja ohnehin von Excel ab, denn auch hier verleitet Excel einen geradezu dazu, Traceability zu versuchen – was im totalen Chaos enden wird. Tut euch den Gefallen und lasst es.
Ein weiterer Teil, der fehlt, wenn ihr nur Word nutzt, sind die Reports. Ihr könnt zwar auch in Word ein paar Skripte laufen lassen. Wenn wir aber Requirements-Management-Werkzeuge einsetzen, können wir zudem sehr ausführliche Reports machen. Mit solchen Funktionen lassen sich Fehler sehr gut herausfischen, z.B. Requirements, die nicht verlinkt oder noch nicht zugeordnet sind und vieles mehr. Hier gibt es diverse Möglichkeiten, Reports zu machen.
In Word solltet ihr das aber bitte nicht machen: Keine IDs, keine Traceability und versucht auch gar nicht erst, Reports aufzubauen.
Word – nicht selbstgebaute Word-Tools!
Als letzten „Bitte tut es nicht“-Punkt möchte ich noch Folgendes anbringen: Baut bitte keine eigenen Tools. Ich habe jetzt mittlerweile einige Firmen gesehen, die mit Word und Excel gearbeitet haben und dann anfingen, in Office ein paar Makros zu nutzen, um z.B. mit Visual Basic zu programmieren.
Einer fängt dann, das Ganze umzumodellieren und auf die Bedürfnisse des Requirements-Managements anzupassen – und somit, Tools zu bauen. Ganz ehrlich: Der Kauf von Lizenzen ist viel, viel günstiger, als wenn ein Kollege über drei Jahre hinweg versucht, etwas zusammenzubauen.
Und noch schlimmer: Es folgt immer die Erkenntnis, dass die eigenen Möglichkeiten am Ende sind und man jetzt eigentlich Dinge implementieren müsste, die das Ganze zu einer richtigen Tool-Suite machen. Also, das macht alles keinen Sinn.
Sagt lieber von Anfang an ganz klar: „Wir nutzen Word. Und wir nutzen es mit viel Sinn und Verstand und folgen den Empfehlungen – aber es wird niemals ein Requirements-Engineering-Tool werden.“ Es ist einfach Word und damit hat es sich.
[thrive_leads id=’5883′]
Von Reviews, Verantwortlichkeiten & Freigaben
Ein weiterer Punkt, der die Organisation der Spezifikationen angeht, betrifft die Verantwortlichkeiten: Wer ist eigentlich für die Spezifikationen verantwortlich? Das ist gerade in diesem Kontext ein wichtiger Punkt und hat folgenden Hintergrund:
Wenn wir Requirements-Management-Werkzeuge einsetzen, gibt es Logins und damit eindeutige Benutzer. So etwas habt ihr bei Word aber nicht, jeder mit Zugriffsrechten auf das Laufwerk kann die Dateien öffnen, bearbeiten, umspeichern. Dementsprechend macht es sehr viel Sinn, klare Rollen zu vergeben: Wer ist verantwortlich für das Dokument? Wer ist verantwortlich für die Freigabe etc.? Legt diese Rollen fest und haltet euch daran. So gibt es stets eine Person, die genau diese oder mehrere Rollen auf dem Hut hat und damit verantwortlich ist für das, was da geschieht.
Hier fällt auch das Thema Review hinein: Eine eurer stärksten Waffen, gerade wenn ihr Word nutzt und eben nicht Requirements-Engineering-Tools, sind Reviews. Sie sind elementar wichtig, wie ich bereits in der Podcast-Episode 013, „Geheimwaffe Reviews“, betont habe.
Ich kann auch hier wieder nur empfehlen, Reviews zu nutzen. Denn mit den Verantwortlichkeiten kommen hier auch die Freigaben hinzu: Nichts ist schlimmer, als Dokumente zu haben, die in irgendeinem Vorab-Stand hängen – gebt diese Dokumente frei!
Klare Organisation
Wie ich im letzten Kapitel schon angedeutet habe, gibt es durchaus einige Vorteile bei der Nutzung eines professionellen Requirements-Engineering-Tools. Traceability haben wir bereits besprochen. Der zweite Vorteil sind die Reports: Ihr könnt relativ einfach Statistiken erzeugen, die in Review-Kontexten sehr hilfreich sind:
- Wie viel Anforderungen haben wir?
- Wie viel Prozent der Anforderungen sind überhaupt verlinkt?
- Habe ich Anforderungen drin, die schwierig oder zu lang sind?
Bei den Tools habt ihr eine vollautomatische Versions- und auch Freigabenkontrolle.
Praxis-Tipp
Im Hilti-Projekt, das ich ein Jahr lang als Mentor begleitet habe, wurde außerdem ein sogenanntes „Document of Truth“, also das „Dokument der Wahrheit“ geschaffen. Dort wurden die relevanten Inhalte gesammelt und nur diese haben dann auch gegolten. So haben wir das Lastenheft für das Produktmanagement erstellt und die Spezifikationen im Entwicklungsprojekt aufgebaut.
Sie brauchen schnell ein Lastenheft?
In einem Gespräch können wir mögliche Lösungen besprechen. 100% Vertraulich, 100% unverbindlich.
Einfache Wiederverwendung
Diese klare Organisation ist ebenso sinnvoll wie die viel einfachere Wiederverwendung: Modularisierung, Standardisierung und Vergleichbarkeit hin oder her, aber in der aktuellen Automobil-Industrie sind wir an einem Punkt, wo wir sozusagen aus dem Regal arbeiten: Wenn wir ein neues System entwerfen, nehmen wir Requirements-Module aus einem „Regal“ und packen das alles in ein Dokument. Und das Thema „Change-Management“ ist mit Requirements-Engineering-Tools viel einfacher. Wenn der Kunde mit einer Anforderungsänderung kommt, „Oh nein, das System muss bei 75 Grad schon abschalten“, könnt ihr das Werkzeug nutzen und die Konsequenzen im Change-Management viel, viel einfacher organisieren.
Das geht auch mit Word, aber es ist doch deutlich aufwändiger. Ihr gewinnt also durchaus eine Menge, wenn ihr ein Requirements-Engineering-Tool einsetzt. Aber ich möchte hier auch die großen Herausforderungen der Tools nicht verschweigen.
Aufwand und Kosten bei Tools
Zunächst muss klar sein, dass kein Tool eine Plug-and-Play-Lösung darstellt. Wenn ein Vertriebler euch das erzählt, werdet skeptisch. Requirements-Engineering-Tools sind sehr komplexe Werkzeuge, die bestimmte Anforderungen einhalten, funktional sein und Features bereitstellen müssen. Wenn ihr diese Werkzeuge einsetzt, müsst ihr eine Infrastruktur dafür haben, eine Konfiguration dieser Werkzeuge etc. – es gibt kein Plug and Play, egal welches Werkzeug ihr nutzt! Fragt mal Konstrukteure, ob es ein Plug and Play für ihr CAD-Tool gibt? Die werden euch wahrscheinlich auslachen.
Ihr müsst immer davon ausgehen, dass ihr das Tool individuell auf eure Bedürfnisse anpassen und zudem alle Anforderungen und Bedürfnisse des Tools berücksichtigen müsst.
Ein weiterer wichtiger Punkt ist der Kostenpunkt Lizenzen. Es gibt unglaublich viele Lizenzmodelle bis hin zu teuren Premium-Modellen, je nachdem, wie groß eure Firma ist und ob dieser Tool-Hersteller überhaupt mit euch redet – manche tun dies erst ab einer Unternehmensgröße von zwei- bis fünftausend Mann. Es gibt andere, die da wesentlich flexibler sind und mir persönlich auch viel mehr liegen.
Fazit – Mit einem Tool nicht zum Fool werden!
Generell solltet ihr euch an folgendes Sprichwort halten:
„A Fool with a Tool is just a Fool, but the Tool makes the Disaster faster.“
Mit anderen Worten, ihr müsst euch bei drei elementaren Dingen Gedanken machen: Werkzeug, Methode, Inhalt.
Am Ende des Tages kommt es auf den Inhalt an. Die Methode ist wichtig, um diesen Inhalt zu schaffen. Und das Tool ist wichtig, um den Inhalt zu verwalten – aber ohne gescheiten Inhalt ist der Rest egal. Und man kann auch ein furchtbar teures Requirements-Engineering-Tool mit den pfiffigsten Features mit Blödsinn befüllen – und somit nichts gewinnen: Ich habe zwar ein teures Tool verwendet, aber trotzdem nur Müll drin.
Also, geht wirklich in euch und überlegt, ob ein Requirements-Engineering-Tool euch in eurem konkreten Fall wirklich hilft. Und wenn ihr euch dafür entscheidet, lasst euch Zeit bei der Wahl und dann bei der Umsetzung in eurem Projekt.
Meine Empfehlung als erfahrener Mentor diverser Firmen ist: Nehmt ein echtes Projekt, kein AddOn-Projekt, an dem ihr das ausprobiert. Nehmt lieber ein echtes Projekt, das gerade in der Entwicklung ist, das wirklich den Bedarf hat – und gebt euch mindestens zwölf Monate Zeit, damit klar zu kommen. Alles andere ist Quatsch.
Zwölf Monate ist ein ganz typischer Zeitraum, um sich diesem Thema anständig zu nähern. Wir reden hier schließlich von Requirements-Engineering, egal auf welchem Level, in welcher Komplexität, in welchem Branchen-Kontext – das ist ein so großes Thema, das lässt sich nicht im Hau-Ruck-Verfahren handhaben.
Vergleicht es doch mit einem Marathon. Da würdet ihr auch nicht auf die Idee kommen, erst zwei Monate vorher mit dem Lauftraining zu beginnen. Das scheint jedem klar zu sein – im Requirements-Engineering glauben aber komischerweise viele, dass das in zwei Monaten funktionieren kann, einfach weil sie Profis sind.
Also, übernehmt euch nicht, geht vorsichtig, bewusst und mit genug Raum und Zeit vor. Denn ob mit Word oder mit einem Requirements-Engineering-Tool – ihr habt Großes vor und das will geplant sein.
Vor- und Nachteile
meine Einschätzung zu Word und Excel als RE-Tools
- Pro
- günstig
- Modularisierung mit Doc-Files
- Word ist schneller
- keine Impact-Analyse möglich
- Änderungskontrolle auf Benutzerebene nicht möglich
- kontrolliert und gesteuerte Reviews möglich
- kein Änderungs-Management
- Kontra
- keine Requirement-IDs
- nur Pseudo-Traceability möglich
- keine Reports
- keine Impact-Analyse möglich
- Änderungskontrolle auf Benutzerebene nicht möglich
- kontrolliert und gesteuerte Reviews möglich
- kein Änderungs-Management