Beiträge

Requirement Engineering für komplexe Systeme – Teil II

Im letzten Beitrag habe ich bereits zwei Probleme des Requirement Engineering in komplexen Systemen angesprochen: Fehlende Lastenhefte und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Hier möchte ich zwei weitere, nicht weniger relevante Probleme diskutieren. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil I

In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirement Engineering für komplexe Systeme so wichtig ist. Hierfür erläutere ich zunächst die ersten großen Schwierigkeiten in solchen Situationen: Das fehlende Lastenheft und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Weiterlesen

Requirements-Engineering mit Word und Excel – Teil VI

Nachdem ich im letzten Teil schon einige Unterschiede zwischen Word und Requirements-Engineering-Tools angesprochen habe, möchte ich das jetzt weiter vertiefen. Was können wir eigentlich gewinnen, wenn wir auf ein Requirements-Tool umstellen?

Klare Organisation 

Wie ich beim letzten Mal schon angedeutet habe, gibt es durchaus einige Vorteile. 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.

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.

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.

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 Ad-on-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.

Requirements-Engineering mit Word und Excel – Teil V

Nachdem ich im letzten Teil die Tabellenstruktur in Word und die Requirements-Engineering-Grammatik detailliert beschrieben habe, kommen wir in diesem Teil zu Traceability, Verantwortlichkeiten & Co.

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.

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-Management-Werkzeuge, sind Reviews. Sie sind elementar wichtig, wie ich bereits in der Podcast-Episode 006, „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!

Dafür könnt ihr wunderbar die Reviews nutzen: Sobald ihr ein Review gemacht und die Feedbacks eingebaut habt, ist es freigegeben, automatisch. Das ist eine relativ einfache Vereinbarung, die ihr mit allen Beteiligten treffen könnt.

Im nächsten Teil werde ich auf diese Vorteile und auch auf die Herausforderungen der Requirements-Engineering-Tools weiter eingehen.

Requirements-Engineering mit Word und Excel – Teil IV

Nachdem wir in den letzten Beiträgen die Spezifikationen und ihre Organisation besprochen haben, komme ich nun zum Thema Word und die Arbeit mit Spalten.

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“ googeln.

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.

Weitere wertvolle Tipps und Tricks u.a. zur Traceability beschreibe ich im nächsten Teil der Reihe.

Episoden

SF007: Fünf Tipps zum Requirements Management mit Word und Excel

28.07.2015 38 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Mittelständische Firmen nutzen Word oder Excel, weil Requirements Management Tools sind zu teuer oder zu kompliziert sind. Das kann schnell schief gehen.

Ich gehe in dieser Episode auf viele Hörerfragen zum Requirements Engineering und Management mit Word und Excel ein. In der Episode wirst du erfahren, wie Spezifikationen mit Word gehand habt werden können und warum Excel der Tod für dein Requiremens Management ist.

Inhalt der Episode:

  • Die aktuelle Situation in mittelständischen Unternehmen
  • Meine fünf Tipps zum Requirements Management mit Word und Excel
    • Welche Spezifikationen brauche ich?
    • Wie organisiere ich die Spezifikationen?
    • Wer ist für die Spezifikationen verantwortlich?
    • Was könnt Ihr gewinnen, wenn Ihr auf ein Requirements Management Tool geht?
    • Was sind die Herausforderungen mit einem Requirements Management Tool?