Anforderungen richtig austauschen

Stellen Sie sich vor, Sie bestellen eine Systemkomponente von einem Zulieferer. Sicherlich schreiben Sie ein Lastenheft und schmeißen es Ihrem Zulieferer “über den Zaun”. In einer perfekten Welt würde der Zulieferer genau verstehen was Sie benötigen, und drei Monate später bekämen Sie die optimale Systemkomponente entsprechend Ihrer Spezifikation geliefert. Wenn es nur so einfach wäre.

In der Praxis gibt es zwei entscheidende Unterschiede: Zum einen sollten Sie vom Zulieferer eine Rückmeldung verlangen, bevor dieser sich an die Umsetzung macht. Zum anderen wird es sicherlich ein paar Mal hin und her gehen, mit Änderungswünschen auf beiden Seiten, Auftraggeber und Zulieferer. Wenn man diese Aspekte nicht berücksichtigt, dann kann die Entwicklung ein böses Ende nehmen, denn auf beiden Seiten bestehen erhebliche Risiken: Der Auftraggeber kann ein Ergebnis erhalten, was nicht den Wünschen – oder dem aktuellen Stand der Anforderungen – entspricht, das aber trotzdem vertragskonform ist. Der Zulieferer hingegen riskiert saftige Vertragsstrafen, falls wichtige Anforderungsänderungen verloren gehen – oder wichtige Anforderungen einfach vergessen werden.

Wie geht man mit dieser Problematik um? In diesem Artikel werden zwei Aspekte beleuchtet: Zum einen die Prozessebene: Wie gehen wir mit Änderungen um? Zum anderen die technische Ebene: Wie kann man technisch effizient einen Anforderungsaustausch umsetzen?

Technische Aspekte

Beginnen wir mit den technischen Aspekten. Zum Glück ist es heutzutage nicht mehr notwendig, Anforderungen in Word, Excel oder gar PDF zu übertragen. Denn mit dem Requirements Interchange Format (ReqIF)¹ gibt es ein offenes, standardisiertes Format, mit dem sich Anforderungen verlustfrei übertragen lassen. Den meisten Lesern wird klar sein, warum MS Office, PDF oder ähnliche Formate nicht gut für einen Anforderungsaustausch geeignet sind. Da dies aber für das Folgende wichtig ist, hier eine kurze Zusammenfassung:

Zunächst, Anforderungen sollten klar abgegrenzt sein. Das ist bei Excel vielleicht noch gegeben: Eine Zeile in Excel entspricht einer Anforderungen. Aber schon mit Word wird es schwieriger diese Abgrenzung explizit zu machen, und bei PDFs ist dies nur mit ungenauen Heuristiken möglich.

Weiterhin sollten Anforderungen identifizierbar sein, also eine ID haben. In Excel ist das noch machbar, indem die ID in einer eigenen Spalte gespeichert wird. Bei den anderen Formaten gibt es leider keine saubere Lösung.

Anforderungen sollten auch Attribute haben, wie Priorität, Kommentar, Status, usw. In Excel kann dies mit weiteren Spalten realisiert werden, aber in Word und PDFs gibt es keine zufriedenstellende Lösung.

Und zuletzt: Anforderungen sollten miteinander verknüpft werden können. Zum Beispiel sollten ein Lastenheft und ein Pflichtenheft eine Verlinkung haben, über die erkannt wird, welche Systemanforderung welche Kundenanforderung umsetzt. Auch hierfür gibt es mit den genannten Formaten keine brauchbare Lösung.

Bei dieser Liste kommt Excel noch am Besten weg. Allerdings hat Excel die Einschränkung, dass sich Abbildungen nicht sauber einbetten lassen. Und das wird häufig gefordert.

An dieser Stelle soll hier noch einmal klargestellt werden, dass es hier nur um den Austausch von Anforderungen geht. Firmenintern wird (hoffentlich) eine professionelle Lösung für das Anforderungsmanagement benutzt. Wenn jedoch der Partner nicht das gleiche Werkzeug benutzt, dann muss ein Export für den Partner durchgeführt werden, und in der Vergangenheit war das nun leider häufig eines der oben genannten Formate.

ReqIF für den verlustfreien Austausch von Anforderungen

Zum Glück gibt es inzwischen das ReqIF-Format, das den verlustfreien Austausch von Anforderungen ermöglicht. ReqIF steht für “Requirements Interchange Format”. Es wurde explizit für den Austausch von Anforderungen entwickelt und hat keine der eben genannten Schwächen. Was aber in der Praxis viel wichtiger ist: Jedes Werkzeug für Anforderungsmanagement, das ernst genommen werden möchte, unterstützt heutzutage ReqIF.

ReqIF ist ein internationaler Standard. Die Object Management Group (OMG) – manchem durch die Standardisierung der UML bekannt – ist auch für ReqIF verantwortlich. Aber auch ein sauber definierter Standard wie ReqIF muss richtig umgesetzt werden. Daher gibt es schon seit vielen Jahren eine Arbeitsgruppe, die viele Nutzer von ReqIF und Hersteller von ReqIF-Werkzeugen um sich versammelt hat.² Unterstützt wird das Ganze von einer quelloffenen Referenzimplementierung von ReqIF, an der sich Werkzeughersteller orientieren können.³

Das Ergebnis ist eine robuste, technische Grundlage für den Austausch von Anforderungen, mit der Austauschprozesse umgesetzt werden können. Die Entwicklung von ReqIF hat auch den Werkzeugmarkt ganz schön aufgemischt: Denn durch ein offenes, verlustfreies Format für Anforderungen sind auch die Kosten der Migration von einem Werkzeug zu einem anderen deutlich gesunken. In den letzten Jahren sind viele neue Werkzeughersteller auf dem Markt erschienen.

Das Zusammenspiel sollte so leicht wie möglich funktionieren

Prozess-Aspekte

Leider ist die Übertragung der Daten nur die halbe Miete. Das Problem sind, wie so oft, die Änderungen und die Rückmeldungen. Das bedeutet, dass die Rückmeldungen vom Partner wieder in die eigene Anforderungsdatenbank eingepflegt werden müssen. Dabei ist unter anderem darauf zu achten, dass Weiterentwicklung und Versionierung berücksichtigt werden. Dazu ein konkretes Beispiel:

Stellen Sie sich vor, der Auftraggeber schickt eine Anforderung zum Zulieferer, der diese mit dem Status “Akzeptiert” zurückschickt. Inzwischen hat der Auftraggeber die Anforderung jedoch erweitert. Nun ist wichtig, dass die erweiterte Anforderung nicht als “Akzeptiert” markiert wird. Ähnliche Vorsicht ist bei der Verknüpfung zwischen Lastenheft und Pflichtenheft notwendig: Wenn sich eine Anforderung im Lastenheft ändert, dann müssen die entsprechenden Anforderungen im Pflichtenheft neu geprüft werden.

Vorarbeit im HIS-Prozess

Das Rad muss nicht jedes Mal neu erfunden werden. Prozesse können weiterverwendet werden. Und zum Glück gibt es eine nützliche Vorlage zu Austauschprozessen: Die Herstellerinitiative Software (HIS) ist eine Arbeitsgruppe der Automobilindustrie, die entsprechende Vorarbeit geleistet hat. Das Ergebnis ist der sogenannte HIS-Prozess.⁴

Der HIS-Prozess deckt alle wichtigen Aspekte für einen erfolgreichen Anforderungsaustausch ab. Dabei geht es oft um das “was”, nicht das “wie”. Er fordert zum Beispiel, dass sich die Parteien auf ein Austauschformat einigen, gibt aber keines vor. Hier ist aber interessant, dass ReqIF explizit entwickelt wurde, um den HIS-Prozess zu ermöglichen. Insofern ist ReqIF eine gute Wahl für die Umsetzung.

Der Prozess ist in sechs Anwendungsfälle unterteilt. In der Praxis sollten diese als Ausgangspunkt gesehen und den Anforderungen der Organisation entsprechend angepasst und erweitert werden. Die sechs Anwendungsfälle sind:

• Initialisierung – das ist die Abstimmung der Partner bezüglich der technischen und logistischen Details.
• Export und Verpackung – Für jeden Austausch müssen die “richtigen” Anforderungen exportiert und für die Übermittlung aufbereitet werden.
• Übertragung – hier unterscheiden sich Firmen erheblich: Für den einen sind E-Mail-Anhänge völlig in Ordnung, für jemand anderen müssen die Daten verschlüsselt und digital signiert sein.
• Import – neben dem reinen Import sollte unter anderem auch eine Plausibilitätsprüfung durchgeführt werden.
• Evaluierung der Anforderungen – Sinn und Zweck ist ja das Evaluieren von Anforderungen, in welcher Form auch immer.
• Prüfung der Evaluierung – Die Ergebnisse der Evaluierung werden mit Hilfe der bereits genannten Anwendungsfälle wieder zurück übermittelt. Dort müssen diese dann überprüft werden.

Bewerten von Anforderungen

In manchen Firmen gibt es Dutzende von leicht unterschiedlichen Status-Attributen. Daher sollten die Status-Attribute des HIS-Prozesse benutzt werden, falls Firmen-interne Gründe nicht dagegen sprechen.

Links sehen Sie Status und Transitionen für Zulieferer, rechts Status und Transitionen für Hersteller

Neben dem Status gibt es auch ein Kommentar-Attribut, um die Entscheidung für einen bestimmten Status weiter zu erläutern.

Attributierung oder Offene Punkte?

Zuletzt stellt sich die Frage, was übertragen werden soll. Der empfohlene Ansatz ist es, die Anforderungen mit Status- und Kommentar-Attribut zu versehen, die dann vom Partner befüllt werden. Es gibt aber noch einen anderen Ansatz. Es kann auch eine Liste mit offenen Punkten übermittelt werden. Das macht insbesondere dann Sinn, wenn die Anzahl der Anforderungen hoch ist und die Anzahl der problematischen Anforderungen klein. Es ist nicht verwunderlich, dass so ein Ansatz aus dem Automobil-Umfeld kommt, denn Lastenhefte mit zehntausenden von Anforderungen sind dort keine Seltenheit. Idealerweise ist diese Liste mit den Anforderungen über eine Traceabililty verknüpft. Das muss die Transfertechnologie aber auch unterstützen.

Anforderungsaustausch leben

Ein Austauschprozess kann sehr einfach sein, aber auch beliebig kompliziert. Da hilft der bekannte Ansatz: “So einfach wie möglich, so kompliziert wie nötig”. Insbesondere muss ein Prozess gelebt werden, um einen Mehrwert zu bieten. Und je einfacher er ist, desto höher sind die Chancen dafür.

Wenn er jedoch richtig gelebt wird, dann können alle Partner sicher sein, dass die Anforderungen gelesen und verstanden wurden; Wenn auch noch eine pragmatische Traceability existiert, dann werden Entwickler mit der Nase auf geänderte Anforderungen gestoßen, weil das verwendete Werkzeug abgeleitete Artefakte als “suspekt” markiert hat.

Ein strukturierter Austausch von Anforderungen ist nicht einfach zu leben. Aber mit ReqIF ist er ein gutes Stück leichter geworden, und wenn er richtig gelebt wird, ist der Nutzen enorm.

Literatur

[1] Requirements Interchange Format: http://re-magazine.ireb.org/issues/2014-3-gaining-height/open-up
[2] ProSTEP ReqIF Implementor Forum: http://www.prostep.org/de/projekte/reqif-implementor-forum-req-if.html
[3] ReqIF-Studio, ein RE-Werkzeug basierend auf dem quelloffenen Eclipse Requirements Modeling Framework: http://formalmind.com/de/tools/studio/
[4] der HIS-Prozess für den Austausch von Anforderungen: http://formalmind.com/blog/reqif-here-what-now/