Leitfaden zur Anforderungsanalyse/-Management speziell nach Requirements Engineering

1 Einleitung

Was macht den Auftraggeber/Kunde glücklich?

Dies klingt vermeintlich nach der zentralen Frage in der Unternehmensberatung. Diese Fragestellung ist für uns bei der novamusHR01 jedoch zu simpel gedacht. Viel wichtiger in einer ganzheitlichen Beratung für den Kunden ist die Frage: „Was braucht der Kunde um langfristig glücklich - und vor allem - langfristig unternehmerisch erfolgreich zu sein?“ Dafür ist ein Verständnis für das „Big Picture“ unabdingbar.

Bei der systembezogenen IT-Beratung geht es, sehr vereinfacht gesagt, darum die Anforderungen des Auftraggebers/Kunden zu kennen und diese durch ein neues und/oder verbessertes IT-System bestmöglich zu erfüllen. (Bei der Prozess- und Managementberatung kommen die Perspektive der Geschäftsprozesse sowie der Unternehmensstruktur hinzu.) Genau hier setzt der Themenbereich des Anforderungsmanagements an. Wie in sehr vielen anderen Feldern auch haben sich hier im Laufe der Zeit unterschiedliche Begriffe, Ansätze, Vorgehensweisen, Methoden und Standards entwickelt und etabliert.

Genauer beschrieben seien im Folgendem zwei bekannte bzw. wichtige Vertreter:

Im deutschsprachigen Raum begegnet uns bei unseren novamusHR01 Kunden gelegentlich im IT-Projektumfeld das Vorgehen basierend auf dem Lastenheft und Pflichtenheft. Dieses Vorgehen spielt vor allem eine wichtige Rolle in (öffentlichen) IT-Ausschreibungsverfahren.

International gesehen sind die Begrifflichkeiten „Lasten- und Pflichtenheft“ geradezu unbekannt und es existiert auch keine direkte bzw. trennscharfe Übersetzung der beiden Wörter, was in unseren internationalen Projekten wiederum häufig Erklärungsbedarf nach sich zieht, um Verwirrung zu vermeiden. Hier hat sich der Begriff des „Requirements Engineering“ als internationaler und industrieübergreifender Standard durchgesetzt.

Worin sich das Vorgehen nach Lasten- und Pflichtenheft im Vergleich zum Requirement Engineering unterscheidet und wie wir in unseren Projekten bei novmausHR01 damit umgehen, haben wir im Folgenden beschrieben.

1.1 Lastenheft und Pflichtenheft

Zunächst sind Lastenheft und Pflichtenheft voneinander zu unterscheiden! Grob gesagt beschreibt ein Lastenheft WAS der Auftraggeber bzw. Kunde sich wünscht, also seine Anforderungen. Dies wird daher in der Regel vom Auftraggeber selbst erstellt und an einen Auftragnehmer übergeben bzw. im Rahmen eines Ausschreibungsverfahrens veröffentlicht. Dies setzt entsprechend voraus, dass der Kunde sich bereits im Klaren darüber ist, was genau er benötigt.

Auf Basis des Lastenheftes erstellt der Auftragnehmer das Pflichtenheft und beschreibt WIE und WOMIT er die Kundenanforderungen erfüllen möchte bzw. wird. Das Lastenheft ist also immer Basis für das Pflichtenheft. Mindestens wird das Lastenheft (bzw. die Kundenanforderungen) aber ein Bestandteil des Pflichtenheft (also der Systemspezifikation) sein, um einen Abgleich zwischen Kundenanforderungen und Erfüllungsgrad durch den Auftragnehmer zu gewährleisten. Im einfachsten Falle überführt man ein Lastenheft in ein Pflichtenheft, wobei der Umfang für das Pflichtenheft immer höher ist als im Lastenheft.

Das Pflichtenheft und das Lastenheft sind in der Regel ein wichtiger Bestandteil des Vertrages zwischen dem Auftraggeber/Kunde und dem Auftragnehmer. Das Pflichtenheft erstellen wir daher in enger Abstimmung mit dem Auftraggeber und lassen dies am Ende von beiden Seiten unterschreiben.

Im deutschsprachigen Raum sind die Richtlinien VDI 2519 und 3694 weit verbreitet. Diese beschreiben den möglichen Aufbau von Dokumenten und die Themen bzw. Anforderungen oder Anforderungslösungen, die unbedingt in einem Lasten- oder Pflichtenheft dokumentiert werden müssen. Laut DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“. Die Anforderungen des zuvor ausgearbeiteten Lastenhefts sind dann also mit technischen Festlegungen der Betriebs- und Wartungsumgebung zu verknüpfen.

Hinweis: In „modernen“ und vor allem agilen Projektmethoden wie etwa mittels Scrum, Lean Development, Kanban, etc. empfinden wir und unsere Kunden ein Lasten- und Pflichtenheft als eher hinderlich, da diese im Konflikt mit der agilen Idee bzw. dem „Agile Thinking“ stehen.

1.2 Requirements Engineering

Da Lasten- und Pflichtenheft im internationalen Umfeld keine Rolle spielen und auch im deutschsprachigen Raum nicht gerade die neuesten Ansätze sind, wird dieses Vorgehen zunehmend vom „Requirements Engineering“ (kurz: RE) verdrängt.

Im Gegensatz zum zuvor beschriebenen Ansatz, wird im RE nicht erwartet, dass der Kunde ein vollumfängliches Dokument als Arbeitsgrundlage zur Verfügung stellt. Allgemein wird der Kunde mehr als wichtigste von mehreren Informationsquellen für die Erstellung von Unterlagen durch uns, die novamusHR01, gesehen.

Vielmehr wird hier der Grundgedanke verfolgt, dass der Kunde bzw. Auftraggeber gar nicht wissen kann/muss, wie eine für ihn zufriedenstellende (IT-)Lösung aussieht. Gerade im sich ständig verändernden Umfeld der Technologie, speziell in der Informationstechnologie, übersteigt es auch oft die Kompetenz des Kunden zu wissen was aktuell (teils auch zukünftig) möglich und auch realisierbar ist. Den begrenzten „Technologiehorizont“ der Kundenseite lässt sich beispielsweise - mit Bezug auf HR - wie im folgendem Schalen-Modell darstellen:

Daher verfolgen wir im RE den Ansatz, dass unsere Berater in erster Linie die grundlegenden Wünsche und Ziele verstehen und auf Basis dessen Anforderungen stellvertretend für den Kunden formulieren, die technisch realisierbar sind und unternehmensstrategisch einen Mehrwert bieten. Dieses Verständnis in Form von Anforderungen wird dann rollierend weiterentwickelt und mit dem Kunden abgestimmt, um eine möglichst hohe Kundenzufriedenheit sicher zustellen.

Dieses bereits iterative Vorgehen ermöglicht es das RE an ein agiles Projektumfeld zu adaptieren. Wir verwenden meist vordefinierte agile RE-Vorgehensmodelle, wie das „RE@Agile“, welches speziell für den Einsatz in agilen Ansätzen (wie Scrum, Lean Development, Kanban, etc.) entwickelt wurde.

Ziel des RE ist es eine Anforderungsdokumentation zu schaffen, die die Wünsche und Ziele des Kunden bestmöglich widerspiegelt und gleichzeitig so gestaltet ist, dass eine dritte Partei (wie etwa eine interne IT, ein Softwareentwicklungsunternehmen oder andere (Service-) Dienstleister) in die Lage versetzt wird, diese Kundenanforderungen möglichst effizient umzusetzen. Dieses Dokument wird dann häufig als Vertragsbestandteil zwischen Kunde/Auftraggeber und Auftragnehmer also der Partei, die die Anforderungen des Kunden umsetzt, genutzt.

Unsere Berater nehmen also eine vermittelnde Rolle ein und dienen als Brücke/Übersetzer zwischen Kunde und Realisierer/Implementierer. NovamusHR01 bringt damit in Einklang, was der Kunde braucht, um langfristig unternehmerisch erfolgreich zu sein und was unter vorhandenen Ressourcen wie Zeit und Budget auch technisch umsetzbar ist. Diese vermittelnde Schnittstellenrolle wird in der Praxis häufig allgemein als „Business Analyst“ oder speziell als „Requirements Engineer“ bezeichnet.
Schematisch lässt sich dieser Sachverhalt in einem Venn-Diagramm darstellen:

Die drei wichtigsten Instanzen bei der Bereitstellung von Vorgehensmodellen, Methoden und Techniken sowie Zertifizierungen im Bereich Requirements Engineering sind diese großen internationalen Fachverbände:

• IIBA (International Institute of Business Analysis)
• PMI (Project Management Institute)
• IREB (International Requirements Engineering Board) (Hauptsitz in Karlsruhe)

1.3 Abgrenzung

Wie in den vorigen Absätzen gezeigt, ergeben sich grundlegende Unterschiede und somit Vor- und Nachteile, in den beiden beschriebenen und möglichen Ansätzen (Lasten- und Pflichtenheft und RE) zum Anforderungsmanagement. Auf Grund

• der weiteren Verbreitung,
• des geringeren Kundenaufwands
• der höheren Aktualität,
• der besseren Kombinierbarkeit mit agilen Methoden
  wird im Folgendem nur das Requirements Engineering weiter beschrieben und auch von uns empfohlen.

2 Vorgehensmodel zum Requirements Engineering

Im Folgenden wird sich, bei Unterschieden im möglichen Vorgehen, auf einen Konsens der drei wichtigsten Vorgehensmodelle, definiert durch die vorgenannten internationalen Fachverbände, gestützt, der sich auch in der Praxis bewährt hat.

2.1 Überblick zum Vorgehen

Bevor wir bei novmausHR01 mit dem eigentlichen Requirements Engineering (kurz: RE) beginnen, quasi in Schritt 0, müssen wir das „große Ganze“ verstehen. Neben der Frage in welcher Projektphase das RE stattfindet ist es essentiell zu wissen wer der Kunde ist, was seine Ziele und Wünsche sind, was er braucht um langfristig glücklich - und vorallem - langfristig unternehmerisch erfolgreich zu sein. Aus diesem Verständnis leiten wir Grundsätze so wie eine „Stoßrichtung“ des RE ab. Diese Grundsätze dokumentieren wir dann allgemeinverständlich, zentral und allgemeinzugreifbar. Sehr Hilfreich hat sich hier in der Praxis die Definition von „Guiding Principles“ bzw. Leitsätzen oder auch „Terms of Reference“ (kurz: ToR) erwiesen.

2.1.1 Ermittlung

Nachdem diese Grundsätze geklärt und vom Kunden bestätigt bzw. genehmigt sind. Beginnt die Anforderungsermittlung bzw. “Elicitation“. Hier werden alle möglichen Quellen genutzt um Kundenanforderungen zu sammeln. Die wichtigste Quelle neben z.B. Marktanalysen und eventuell bereits vorhandenen Projekt-Dokumentationen, sind jedoch immer die Stakeholder selbst.

2.1.2 Analyse

Die gesammelten Anforderungen werden im nächsten Schritt, der Analyse, untersucht. Essentieller weise prüfen wir hier, ob eine Anforderung (immer noch) in das „große Ganze“ passt. Sind die gefundenen Anforderungen mit den Grundsätzen (aus Schritt 0) vereinbar? Sollte dies nicht der Fall sein müssen sie angepasst oder aussortiert werden. Wenn Anforderungen in das „Big Picture“ passen, ist die Qualität einer jeden Anforderung aus technischer und unternehmensstrategischer Sicht sicherzustellen. Wir bei novamusHR01 verwenden hier gerne die DEEP- oder SMART-Techniken. Außerdem müssen z.B. Konflikte und Überlappungen der Anforderungen untereinander beseitig bzw. geklärt werden. Die verbesserten und dadurch meist auch veränderten Anforderungen werden dann immer wieder den Stakeholdern vorgelegt und bestätigt, wodurch sich eventuelle erneute Änderungen ergeben. Bei diesem iterativen Vorgehen entsteht also ein Zyklus zwischen der Anforderungsanalyse und der -Ermittlung. Dies wirkt zwar ungewollt bzw. unnötig aufwendig ist jedoch notwendig, um die spätere Kundenzufriedenheit sicherzustellen.

2.1.3 Validierung

Wenn nach einigen bis vielen Iterationen dann ALLE Anforderungen VOLLSTÄNDIG und RICHTIG dokumentiert sind, werden die Anforderungen „Key Stakeholder“ wie fachlichen Endnutzern („Users“) und technischen Umsetzern (z.B. Entwicklern) und Management-Vertretern „Sponsor“ zur finalen Genehmigung bzw. Validierung vorgelegt. Im Idealfall werden nach einer kurzen Diskussion und kleinen Änderungen die Anforderungen per Unterschrift als Ganzes final „approved“ und können nun an die, für die Realisierung Verantwortlichen übergeben werden.

2.1.4 Dokumentation

Wie zu sehen findet parallel zu den RE-Aktivitäten immer eine Dokumentation statt. Dies ist absolut notwendig, um zu mindestens keine Anforderungen zu verlieren bzw. zu vergessen und Anforderungen stets aktuell zu halten.

2.1.5 Management

Ebenso findet immer parallel ein Anforderungs-Management bzw. eine Verwaltung statt. Das RE lebt von einer ständigen bzw. inkrementellen Anpassung und Verbesserung der Anforderungen. Dies darf jedoch nicht „aus dem Ruder laufen“. Wenn Änderungen an Anforderungen vorgenommen werden, sollte dies überwacht und nur mit Genehmigung stattfinden. Hier empfehlen wir bei komplexen Projekten die Einführung eines „Change-Management-Prozess“ (wie etwa nach der ITIL). Wenn Zweifel aufkommen, ob bereits geänderte Anforderungen immer noch den Ursprungswunsch des Kunden widerspiegeln, sollte eine Rückverfolgung zu früheren Versionen bis hin zum Original über eine Versionskontrolle möglich sein. Gerade in komplexen Projekten wird dies auf Basis von spezieller Requirements-Management-Software auf
Datenbank-basis sichergestellt, wie z.B. mit “Jira”, “ReQtest” oder “IBM Rational”. Aber auch eine Realisierung mittels Programmen wie Word und/oder Excel ist machbar und von uns in der Praxis erfolgreich genutzt worden.

Aus diesen Aktivitäten ergibt sich folgende Visualisierung zum RE-Vorgehensmodell:

3 Fazit

Bedingt durch die sich ständig ändernden technischen Möglichkeiten, ist es selbst für technikaffine Menschen schwerer geworden, technologisch up-to-date zubleiben und den Überblick zu behalten. Dies gilt erst recht für die Kollegen aus den Fachabteilungen. Es ist aufgrund zunehmender Digitalisierung und kürzeren Halbwertszeiten zu erwarten, dass diese Tendenzen sich auch weiter verstärken werden. Daher sind von den Kunden vollumfänglich vorformulierte Anforderungen in Form eines Lastenheftes, kaum noch zu erwarten und auch nicht mehr zeitgemäß. Heute, in dieser sog. VUCA-Welt, sind zunehmend schnelle Lösungen und agile Vorgehen gefragt und auch viel zielführender, um unsere Kunden bei der Erreichung ihrer langfristigen unternehmerischen Ziele zu unterstützen.
Zwar werden weiterhin Situationen es rechtfertigen Lasten- und Pflichtenhefte anzufertigen, aber wir von der novamusHR01 empfehlen klar - unter der Berücksichtigung der zuvor genannten Gründe - in den meisten Fällen ein Vorgehen nach dem Requirements Engineering.
Sollten Sie Unterstützung in der Anforderungsanalyse und/oder dem Anforderungsmanagement benötigen, dann kommen Sie gern jeder Zeit auf uns zu.