Mit dem von uns gerne eingesetzten praktischen Vorgehensmodell frei nach

Volere erstellen wir Anforderungsspezifikation, Stakeholder-Analyse und Priorisierung. Da sich Prioritäten, Strukturen, Organisationen, Technik und Termine in der normalen Welt ständig ändern, muss auch jede einzelne Anforderung dieser Realität gerecht werden können. Sie schreiben Anforderungen in ein Dokument? Dann dürfen Sie sich freuen: Es gibt Optimierungspotenzial bei Kosten und Qualität.

Selten birgt die technische Unterstützung eines Prozesses so klare Vorteile wie bei der Business Analyse. Dieses Wort verwenden wir lieber bei unseren Requirements-Projekten, da zur Erstellung der Spezifikation das Verständnis des Geschäfts notwendig ist. Schon in der Urzeit der Anforderungsermittlung arbeiteten die Experten mit Karteikarten, unter Volere auch bekannt als Snowcards. Das ist kein Wunder. Hier kann man durch Umsortieren und Verteilen eine Strukturänderung abbilden. Schade, dass hier nur nach einem Kriterium sortiert werden kann. Anders bei einem Werkzeug, das Ihnen die unterschiedlichsten Sichten auf eine Business-Analyse erlaubt. Auch müssen bestimmte Abstimmungsstände eingefroren werden. Als Grundlage für Entscheidungen und Aufträge. In diesem Moment macht es Sinn, ein Dokument zu erzeugen. Sie können es dann auch Pflichtenheft nennen. Dies ist nicht die Spezifikation sondern ein Snapshot eines kontinuierlichen Prozesses der Klassifizierung, Strukturierung und Bewertung. Genau wie das Ergebnis eines Build-Laufs. Dies wird oft nicht sofort verstanden, vor allem, wenn Nichtinformatiker sich in das Requirementsengineering vertiefen. In dem Moment, wo eine Anforderungssammlung ausgedruckt und zu einem Meeting mitgenommen wird, ist sie schon veraltet. Wenn das verstanden wurde ist eine wichtige Voraussetzung für eine hohe Applikationsqualität erfüllt.

Ein Wort zu Stakeholdern

Das Hätscheln von Stakeholdern kann sich schnell einbürgern, wenn es darum geht ein System für ein Unternehmen zu entwickeln. Aber es gibt die verschiedensten Ausprägungen von Stakeholdern. Ich will die Spitznamen dafür nicht wiederholen.

Jede IT-Projektmanagement Erfahrung kennt Stakeholder. Diese können das Projekt unterstützen, sponsorn, begleiten und auch bremsen und behindern.

Wie kommt man im Projekt voran?

Die Grundregeln sind einfach. Wenn jemand einen Nutzen sieht, dann ist es sinnvoll zu investieren. Wir bewegen uns im unternehmerischen Rahmen. Hierzu zählen wir auch Verwaltungen und soziale Einrichtungen, solange man nicht die Lizenz zur Verschwendung hat. Wer kein Geld gibt, kein Interesse hat, keine Ressourcen bereitstellt, keinerlei Risiko eingehen will, ist kein Stakeholder. Jede Personensekunde dafür ist Verschwendung.

Beim Sammeln der Anforderungen ist der Übersetzungsprozess zwischen Nutzern und Entwicklern von Bedeutung. Anforderungen müssen explizit beschrieben werden, es darf keine impliziten Annahmen geben. Präzise Definitionen helfen Missverständnisse zu vermeiden. Damit sowohl die Nutzer als auch die Entwickler die gesamten Anforderungen lesen und verstehen kann. Jede Anforderung muss eindeutig identifizierbar sein sonst wird ein guter Test schwer möglich. Anforderungen müssen mit Abnahmekriterien verknüpft werden, damit geprüft werden kann, ob die Anforderungen erfüllt wurden. Tests werden aus den Abnahmekriterien abgeleitet.

Anforderungen müssen widerspruchsfrei sein. Falls es im Business Widersprüche gibt, wissen wir jetzt, warum es auch Business Analyse heisst. Hier können wesentliche Kostenverursacher aufgedeckt werden. Das Aufzeigen von Widersprüchen ist ein Erfolg! Oft werden Softwareprojekte als Kostenmonster verstanden. Dabei decken sie oft auf, was schon länger Reibungsverluste erzeugt. Es gibt Unternehmen, die haben nach der Business Analyse und erfolgreicher Strukturierung das System nicht sofort entwickelt. Die Vorteile der Umstrukturierung waren auch ohne Tool schon enorm. Wissenschaftliche Experimente zu diesem Thema haben das bestätigt.