Geschrieben am

Welches Requirements-Management-Tool? — Die Qual der Wahl

Toolbox with tools on white isolated background. 3d

Welches Tool — die Qual der Wahl

Im Anschluss an Requirement-Management-Trainings kommt immer wieder die Frage auf, welches Requirement Management-Tool denn das beste sei.

Meine Antwort darauf ist: Es gibt nicht das beste Tool. Verschiedene Tools können unterschiedliche Dinge gut und je nach Preis können sie vielleicht sogar viele Dinge gut. Vielleicht sogar welche, die man gar nicht braucht und eigentlich nicht bezahlen möchte.

Wer sich für die Einführung eines Requirements-Management-Tools interessiert, hat leider zunächst einmal die zeitintensive Aufgabe, sich genau zu überlegen, was er damit machen möchte — und was nicht. Dies ist von Organisation zu Organisation verschieden, stark vom Reifegrad des Spezifikationsprozesses abhängig, weiterhin natürlich stark abhängig von der Art des Produkts — sowie von vielem mehr.

Ich will im folgenden verschiedene Kriterien nennen, die Organisationen durchgehen sollten, die vor der Entscheidung stehen, ein Requirements-Management-Tool zu verwenden:

Was soll spezifiziert werden?

Die Antwort erscheint erst einmal einfach: na Produkte natürlich! Auf den zweiten Blick ist die Frage jedoch leider recht komplex:

  • Was für Produkte sollen spezifiziert werden? Geht es um Softwareprodukte? Hardwareprodukte? Geht es um rein mechanisch arbeitende Produkte ohne jeglichen Elektronik-Bestandteil? Oder haben die Produkte einen hohen Anteil an Prozessen, die sauber dargestellt werden müssen?
  • Welche Sprache wird für die Spezifikation eingesetzt? Natürliche Sprache in Deutsch oder Englisch? Oder werden auch dedizierte Spezifikationssprachen verwendet wie UML, Schaltpläne, Konstruktionsskizzen, 3D-Modelle oder dgl.? Oder soll sogar die Möglichkeit bestehen, die Spezifikationssprache selbst zu definieren, um zu einer Domain Specific Language zu kommen?
  • Und schlussendlich: Auf welchen Spezifikationsebenen soll eine Toolunterstützung eingeführt werden? Auf der Lastenheft-Ebene (bzw. Product Backlog-Ebene)? Oder auch auf einer darunter liegenden technischen Ebene (Pflichtenheft, Konstruktionsplan, Schaltplan)?

Welche Integration des Tools ist notwendig bzw. gewünscht?

Um eine hohe Produktivität zu erzielen, können Requirements-Management-Werkzeuge in die verschiedensten Prozesse eingebunden werden. Verschiedene Produkte sind darauf unterschiedlich vorbereitet. Folgende Möglichkeiten sind gängig:

  • Integration mit einem Ticketing-Tool: Das hat den Vorteil, dass Spezifikationsaufgaben in einem Ticketing-System (Issue-Tracking-System) hinterlegt werden können und nachverfolgt werden kann, aus welchem Ticket sich welche Spezifikationsänderung ergeben hat.
  • Vertikale Integration: Soll das Requirements Management-Tool für mehrere Spezifikationsebenen (Lastenheft bzw. Product Backlog, Pflichtenheft, Systemarchitektur) eingesetzt werden? Das hat den immensen Vorteil, ein Tracing von Kundenanforderung bis hinunter zur technischen Realisierung zu haben. Der Vorteil: man hat jederzeit die Möglichkeit nachzuschauen, wo jede noch so kleine Nuance in der technischen Umsetzung herrührt — und: welche Auswirkungen es rückwärts betrachtet auf die Kundenwünsche hat, wenn man sie weglässt.
  • Qualitätsmanagement: ist eine Integration mit einem QM-Tool angedacht? Das ermöglicht einfaches Reporting der Test- und Implementierungs-Coverage und ist für Projektleiter und QM-Mitarbeiter meist sehr interessant.
  • Historisierung: Soll es möglich sein, den Spezifikationsstand mit früheren Ständen (etwa einer Baseline) zu vergleichen? Der Vorteil liegt darin, einfach herausfinden zu können, wie es über den Lauf der Zeit zu einem bestimmten Requirement kam und auch, grobe Schätzungen automatisiert alleine auf Basis der Menge der geplanten Änderungen durchführen zu können. Eine Historisierung eines Spezifikationsmodells kann hierbei durch das Tool selbst angeboten werden oder durch eine Verzahnung mit einem weiteren, darauf spezialisierten Tool (wie SVN, Git, PTC, …).
  • Branching: Nicht nur in der Softwareentwicklung, auch bei Spezifikationstätigkeiten ist ein Branching möglich und auch sinnvoll. Beispielsweise dann, wenn von der Produkt-Mainline indivualisierte Derivat-Produkte entstehen sollen, die auf Kunden individuell angepasst sind. Oder, wenn an einem großen Produkt verschiedene Projekt-Teams weiterarbeiten und Features hinzu-spezifizieren, die erst in einem Rutsch in den Head gemergt (und dann entwickelt) werden sollen.
  • Generierung von Sourcecode: Je spezieller und domain-spezifischer spezifiziert wird und je weniger Freiheitsgrade verwendet werden, umso näher liegt es, sich einmal genau anzuschauen, ob Software(teile) generiert werden können. Dazu muss das Spezifikationswerkzeug entweder selbst über Generator-Funktionalität verfügen — oder es muss eine API zur Verfügung stellen, die es ermöglicht, die Spezifikation durch einen Externen Generator maschinell auslesen zu lassen.

Das sind nur einige der Möglichkeiten, die sich bieten, wenn man über die Anschaffung eines Requirements-Management-Tools nachdenkt.

Aber auch wenn die Möglichkeiten eines Tools gewaltig sind, gilt nach wie vor der alte Leitsatz:

„A fool with a tool is still a fool.“

Denn auch eine noch so gute maschinelle Integration der Toolchain funktioniert nur unter einer Bedingung:

Die Prozesse müssen stimmen

Integrationen verschiedener Tools in der Produktentwicklung machen nur dann Sinn, wenn sie eine bestimmte, vorher verabschiedete Vorgehensweise in der Kollaboration abbilden. Oder anders herum gesagt: Ohne einen abgesprochenen Prozess in der Produktentwicklung (Product Life Cycle Management) bringen selbst die teuersten Tools nicht viel, weil sie ihre immensen Vorteile nicht ausspielen können.

Einführungsprojekt

Wie man sieht: die Einführung eines Requirements-Management-Tools ist nicht ganz so einfach wie die Installation von Word. Ein Requirements-Management-Tool ist notwendigerweise hoch integriert, wenn es seine Möglichkeiten entfalten soll.

Das zieht dann sinnvollerweise ein Einführungsprojekt (und vielleicht sogar vorgeschaltet ein Auswahlprojekt) nach sich, bei dem auch die Frage der Datenmigration geklärt werden kann: Was kostet es, die bisher vorhandenen Spezifikationsdokumente in das Tool zu überführen?

Eine gut verlesene Liste potentieller Kandidaten für die Auswahl haben Dr. Birk und Gerald Heller in ihrem Blog „Software Engineering Applied“ hinterlegt, auf die ich hier gerne verweise.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.