Hätte, hätte, Fahrradkette… Diese Redewendung kennen wir alle, war aber des Öfteren traurige Realität vieler Softwareprojekte, denn eine Kette an Missverständnissen führt unweigerlich zu Unzufriedenheit, Terminverschiebungen, einem Refactoring und somit ungeplanten hohen Kosten, oder kann im schlimmsten Fall in der Auflösung einer Geschäftsbeziehung enden.
Fragt man die Beteiligten, hört man oft „Das hatte ich aber ganz anders verstanden.“ oder „Wie soll ich denn aus einem 80-seitigen Konzept in Prosa erkennen, was es tatsächlich zu tun gibt?“ Verständlich.
Das Beste aber kommt zum Schluss: wenn es nämlich zu einem Refactoring oder gar Erweiterung einer Implementierung kommt und nichts oder nur lückenhaft dokumentiert wurde, viel Spass beim Reverse Engineering und der Klärung der Frage, wer die Kosten dafür tragen soll.
Wie können Missverständnisse verhindert werden?
Ganz einfach: stellen Sie einen Requirements Engineer ein. Naja, ganz so einfach ist es natürlich nicht, aber dazu gleich mehr.
Ein Requirements Engineer stellt in diesem Prozess sicher, dass Anforderungen vollständig ermittelt, erhoben und spezifiziert werden. Er analysiert und modelliert sie mit bestimmten Methoden und Techniken. Zu guter Letzt prüft und dokumentiert er die Anforderungen.
Das Multitool kann noch mehr.
Ein Requirements trägt noch eine Vielzahl an Spezialeigenschaften in seinem Köcher mit, um zu seinem grossen Ziel zu gelangen. Analytisches Denk- und Abstraktionsvermögen sind Pflicht. Massgeschneidertes und gezieltes Vorgehen beim Ermitteln der Anforderungen mit den verschiedenen Stakeholdern? Kein Problem. Er weiss, wie und was er zu tun hat. Es kommt in Workshops zu Interessenkonflikten, Meinungsverschiedenheiten oder gar Streitigkeiten zwischen den Stakeholdern? Keine Sorge, das Multitool hat das nötige Werkzeug, um mit solchen Situationen umzugehen, zumindest bis zu einem gewissen Grad. Dabei helfen ihm vor allem sein Vermittlungsgeist und seine Überzeugungsfähigkeit.
Warum reicht es nicht aus einen Requirements Engineer anzustellen?
Nehmen Sie an, Sie sprechen nur Deutsch und gehen nach Japan und sprechen dort mit Einheimischen Deutsch oder fuchteln mit Ihren Händen rum, um zu kommunizieren. Wenn Sie Glück haben und lange genug suchen, werden Sie vielleicht auf den einen oder anderen Japaner stossen, der teilweise versteht, was Sie sagen möchten.
Und der Requirements Engineer wird mit sehr grosser Wahrscheinlichkeit UML-Diagramme erstellen, um Anforderungen zu spezifizieren. Wenn Sie also keinen Entwickler haben, der die gleiche Sprache spricht, bringt Ihnen der beste Requirements Engineer nicht viel.
Diese Tipps können helfen
- Vorausschauend planen: Stampfen Sie nicht ein Requirements Engineering Team aus dem Boden, ohne einen Plan darüber zu haben, wie Sie es in Ihren Prozess einbinden wollen.
- Kompetenzen verteilen: Trennen Sie Aufgabengebiete und Verantwortlichkeiten zwischen Projekt Manager, Entwickler und Requirements Engineer.
- Arbeitsmittel einsetzen: Stellen Sie Ihrem Requirements Engineer jene Mittel zur Verfügung, die er benötigt, damit er seiner Arbeit nachgehen kann.
Er wird es Ihnen danken, indem er dafür sorgt, dass Sie über Situationen, wie eingangs illustriert, rückblickend lächeln können.
Weiterführende Links
UML 2.5 Das umfassende Handbuch | Rheinwerk Verlag | ISBN 978-3-8362-6018-3
Professionelle Applikation für UML-Diagramme: SparxSystems
