Der Einsatz von modellbasierten Werkzeugen für das Anforderungsmanagement soll uns das Leben erleichtern und die Arbeit effizienter gestalten. Doch oft werden die Werkzeuge nur als Word-Ersatz benutzt. Die Anforderungen werden in das Tool eingetragen und dann wird ein Dokument ausgeleitet. Die Möglichkeiten von Wiederverwendung (Reuse) werden kaum genutzt. In meiner beruflichen Praxis sehe ich, dass es für viele Unternehmen schwierig ist Anforderungen über Projekte oder Produkte hinweg wiederzuverwenden. In diesem Artikel möchte ich Denkansätze dazu geben, das Anforderungsmanagement neu zu durchdenken und damit einen deutlichen Effizienzgewinn mit besserer Qualität zu erreichen.
Warum schreiben wir Anforderungen immer neu?
Ein neues Projekt steht an. Es geht los mit einem Lasten- oder Pflichtenheft. Vielleicht druckt man sich ein altes Dokument als Vorlage aus und dann geht es los. Wir legen ein Projekt in unserem Werkzeug an und tippen los: „Das System soll …“. Das Tool generiert artig eine eindeutige ID für diese Anforderung (REQ-0001).
So schreibt man dann alle Anforderungen für das Produkt herunter. Ich vereinfache an dieser Stelle bewusst und ignoriere die Methodiken zur Ermittlung der Anforderungen. An diese Stelle geht es nur um deren Dokumentation und Verwaltung. Viele Unternehmen haben bereits eine Reihe von Produkten und somit auch Anforderungen. Warum erstellt man die Anforderungen jetzt wieder neu, anstelle sie wie Lego Bausteine wiederzuverwenden? Eine Liste mit möglichen Gründen:
- Die alten Produkte sind nicht gut dokumentiert und es soll jetzt richtig gemacht werden.
- Das neue Produkt ist doch ganz anders, als das alte.
- Die anderen Dokumente kenne ich nicht, dafür war ich nicht zuständig. Eventuell habe ich überhaupt keine Zugriffsrechte.
- Ich habe keine Ahnung wie ich mit meinem Werkzeug Anforderungen wiederverwenden kann.
- Ich weiß nicht wo ich schauen soll, da es einige Produkte mit guten und viele mit schlechten Beispielen gibt.
- Eigentlich habe ich gar keine Zeit mich mit so etwas zu befassen. Ich muss fertig werden – selbst ist der Mann.
Die Anzahl der Gründe ist also nicht zu unterschätzen. Trotzdem lohnt sich die Mühe.
Warum immer wieder neu Schreiben schlecht ist?
Sich Anforderungen immer wieder neu auszudenken, ist wie das Rad jedes Mal neu zu erfinden. Dieser Prozess ist nicht besonders stabil. Vielleicht hatte man vor kurzem eine Schulung zum Thema Requirements Engineering und ist bedacht Anforderungen geeignet zu formulieren. Es kann aber auch sein, dass man etwas aus der Übung ist und die Qualität der Anforderungen deutlich leidet. Doch wer ist schon in der Lage, sich an die verschiedensten Anforderungen zu erinnern, die für ein Produkt notwendig sind. Was brauchte die Produktion und der Service noch einmal und was hatte es mit den nicht funktionalen Anforderungen auf sich? Angeleitet von den Überschriften schustert man etwas zusammen. Ich denke es wird jedem klar, dass die Qualität dieser Spezifikation bei weitem nicht so gut sein kann, wie eine, die bereits über verschiedene Produkte gereift ist. Doch nicht nur die Anforderungen, auch die Testfälle sind zu beachten. Die Erstellung der Testfälle nimmt mehr Zeit in Anspruch als die Dokumentation der Anforderung. Würde man Anforderungen übernehmen, so könnte man auch die Testfälle eins zu eins wiederverwenden. Eine enorme Arbeitserleichterung und Zeitersparnis.
Wie soll das Anforderungsmanagement realisiert werden?
Meine Empfehlung ist es, eine Datenbank oder ein gemeinsames Projekt mit allen Anforderungen und Testfällen anzulegen. Aus dieser Quelle bedienen sich dann die Projekte und ziehen sich daraus die Anforderungen heraus.
Dabei gibt es die „Common Requirements“, die inhaltlich nicht verändert werden müssen. Dazu zählen Anforderungen, deren Inhalte keiner Änderung bedürfen, z.B. Beschriftungen von Anwendungsteilen und Typenschildern, Normen, zu verwendende Anschlüsse (Netzbuchse, USB, …), Anforderungen an Wartbarkeit…
Die „Customize Requirements“ sind Anforderungen, die einen oder mehrere Parameter haben und angepasst werden müssen. Als Beispiel können wir uns das Maximalgewicht eines Systems mit < 15 kg definieren. Dieser Wert kann von Produkt zu Produkt variieren, aber auch bei Gerätevarianten unterschiedlich sein. Dieser Wert stellt somit nur einen Parameter der Anforderungen in Abhängigkeit von Produkt, Variante und Version dar. Weitere „Customize Requirements“ können auch Performance Anforderungen sein. Als Beispiel könnte eine Anforderung definiert sein, welche Amplitudeneinstellungen für einen EKG-Monitor anzeigbar sind.
|
|
| Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer E-Mail: madzar@medtech-ingenieur.de Tel.: +49 9131 691 240 |
|
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf. |
|
Das Vorgehen ist nun so, dass man für das Produkt die zutreffenden Common Requirements auswählt und diese importiert. Das Gleiche tut man auch für die „Customize Requirements“, wobei man hier die Parameter entsprechend wählt. Damit sollte schon ein großer Teil der Arbeit getan sein. Je größer die entsprechende Datenbank, desto mehr Lego Steine gibt es, die wiederverwendet und nicht neu geschrieben werden müssen. Alle anderen, die tatsächlich noch nicht in der Datenbank vorliegen, werden tatsächlich im Projekt angelegt. Falls diese Anforderungen Kandidaten für die Wiederverwendung sind, dann kann man diese wieder in die Datenbank übernehmen.
Tipps
Falls Sie nicht bereits eine Lösung für das oben beschriebene Problem haben und vorhaben, ihr Anforderungsmanagement auf die nächste Ebene zu heben, dann habe ich die folgenden Tipps für Sie:
- Achten Sie darauf, dass die Qualität der Anforderungen und Testfälle in der Datenbank gut ist, da Sie diese in die Produkte kippen werden.
- Definieren Sie einen Datenbankverantwortlichen, der sich um die Anforderungen kümmert.
- Achten Sie über alle Projekte darauf, dass die IDs eindeutig sind. Nur so kann man sicherstellen, dass Anforderungen wiederverwendet werden können.
- Starten Sie beim nächsten Projekt nicht nur Projektanforderungen zu sammeln, sondern gleichzeitig ihre Datenbank aufzubauen.
Ich habe in diesem Artikel bewusst die Werkzeuge rausgehalten. Alle Werkzeuge, mit denen ich bisher gearbeitet habe, unterstützen dieses Vorgehen. Falls Sie Fragen haben und Hilfe benötigen, können Sie mich gerne kontaktieren.
Viele Grüße
Goran Madzar
