Lesedauer 4 Minuten

Wenn du an einem Projekt arbeitest, sollten deine Alarmglocken spätestens dann anspringen, wenn etwas, auf gut Österreichisch, »eh klar« ist. Misstraue Dingen, die »eh klar« sind. »Eh klar« ist allzu oft der erste Schritt ins Desaster, und um das zu vermeiden, lohnt es sich, den Prozess des Requirements Engineering kennenzulernen.

Dabei handelt es sich um einen standardisierten Prozess, der sich mit dem Ermitteln, Dokumentieren, Prüfen und Verwalten von Anforderungen beschäftigt.

Aber was ist eine Anforderung? Das ist doch eigentlich auch »eh klar«, oder nicht?

Definition

Auch wenn es »eh klar« zu sein scheint, hier sicherheitshalber trotzdem eine genaue Definition für den Begriff. Nach dem IEEE Standard 610.12-1990 handelt es sich bei einer Anforderung um:

(1) Eine Bedingung oder Fähigkeit, die von einem Benutzer gebraucht wird, um ein Problem zu lösen oder ein Ziel zu erreichen.

(2) Eine Bedingung oder Fähigkeit, über die ein System oder eine Systemkomponente verfügen oder sie erfüllen muss, um einen Vertrag, einen Standard, eine Spezifikation oder andere formell erfasste Dokumente zu erfüllen.

(3) Eine dokumentierte Repräsentation einer Bedingung oder einer Fähigkeit, wie in (1) oder (2) beschrieben. [Übersetzung durch den Verfasser dieses Beitrags]

Abgesehen vom Begriff der Anforderung kommt im Requirements Engineering auch die Bezeichnung Stakeholder vor. Dabei handelt es sich um jene Stellen, die auf irgendeine Weise Einfluss auf ein zu entwickelndes System oder Produkt (bzw. seine Anforderungen) haben. Dabei kann ein Stakeholder eine Person, aber auch eine ganze Organisation sein.

Wer sind die Stakeholder?

Eine der ersten Aufgabe im Requirements Engineering ist die Identifizierung dieser Stakeholder und sie in den Prozess mit einzubeziehen.

Aber wer die sind, ist doch normalerweise »eh klar«, oder nicht?

Angenommen, du sollst eine Software programmieren, die von der Belegschaft einer Firma genutzt werden soll. Da Stakeholder auch ganze Organisationen und Firmen sein können, ist die Sache doch eh klar, nicht wahr? Eine Firma, ein Stakeholder, fertig!

Leider nein.

In so einem Kontext tritt eine Firma nicht homogen auf, sondern besteht aus verschiedenen Gruppen mit teilweise unterschiedlichen Interessen. Daraus ergeben sich naturgemäß auch unterschiedliche Stakeholder.

Ohne Anspruch auf Vollständigkeit kann es sich dabei um folgende Personen oder Gruppen handeln:

• Angestellte – also jene Personen, welche die Software tatsächlich im Alltag nutzen (müssen)
• Geschäftsführung – wie heißt es so schön: Wer zahlt, schafft an
• Arbeitnehmervertretung / Betriebsrat – ein Beispiel für Stakeholder in Gestalt einer Gruppe. Meist müssen unterschiedliche rechtliche Rahmenbedingungen geklärt werden (z. B. der Datenschutz, falls eine Software Daten der User erfassen würde)
• Du – ja, auch du als Hersteller zählst zu den Stakeholdern, denn letztlich bist du es, der sich über die Realisierbarkeit von Anforderungen Gedanken machen musst.

Diese Aufzählung ist natürlich noch lange nicht vollständig. Je nach Art eines Produktes kann sich noch eine ganze Reihe von weiteren Stakeholdern ergeben, die Einfluss nehmen können – und werden. Wenn es beispielsweise nicht um eine Software, sondern um Büromöbel geht, wäre auch ein/e ArbeitsmedizinerIn ein sinnvoller Stakeholder, um etwa Fragen der Ergonomie zu klären.

Ein Sack voll Flöhe

Du wirst vermutlich einsehen, dass es mitunter schwierig sein kann, all diese Stakeholder zufriedenzustellen, denn alle haben unterschiedliche Prioritäten. Dabei können – und werden – sich auch Konflikte ergeben:

Die Geschäftsführung als Auftraggeber möchte natürlich eine billige Lösung. Idealerweise ermöglicht sie, wenn es z. B. um Software geht, auch die Kontrolle und Messung der Arbeitsleistung der Angestellten.

Das ist der Moment, in dem der Betriebsrat sein Veto einlegt und auf den Datenschutz pocht.

Die Angestellten sind meist jene, die sich (leider allzu oft zurecht) übergangen fühlen und Neuerungen eher skeptisch bis ablehnend gegenüberstehen. Oder, falls sie aufgeschlossen sind, haben sie ihre eigenen Wünsche und Vorstellungen. Diese wiederum gefallen vielleicht der Geschäftsführung nicht, weil sie z. B. zu teuer sind oder für unnötig erachtet werden.

Und die Entwickler oder Hersteller nehmen manchmal die Rolle der Spielverderber ein, wenn sie klarstellen, dass manche Anforderungen nicht oder nur mit gewaltigem Aufwand realisierbar sind.

Wenn solche Konflikte oder Widersprüche erst spät in der Entwicklung zu Tage kommen, ist das natürlich eine Katastrophe. Es kommt zu Verzögerungen, Kostenexplosionen oder gar zu Projektabbrüchen. Und bestimmt werden auch Leute angebrüllt.

Die Aufgabe eines Requirements Engineers ist es, diesen Sack voll Flöhe zu bändigen und all die Interessen unter einen Hut zu bringen. Noch bevor die eigentliche Entwicklung beginnt, müssen die Anforderungen klar und eindeutig formuliert werden und idealerweise von allen (!) Stakeholdern akzeptiert werden.

Durch die möglichst klaren und einfachen Formulierungen sollten auch die meisten Widersprüche frühzeitig erkannt und ausgebügelt werden. Denn wie bei den Konflikten gilt auch hier: Widersprüche, die erst spät erkannt werden, sind teuer.

Außerdem fungieren dokumentierte Anforderungen gewissermaßen auch als Vertrag, auf den sich alle Beteiligten verständigt haben. Denn es ist schriftlich festgehalten, was gewünscht ist und was gemacht wird.

Das Wichtigste: Du lässt keine Anforderung unter den Tisch fallen, weil sie ja eh klar ist.

Ein Beispiel aus der Realität

Nehmen wir an, du bist Requirements Engineer und sollst den Bau einer (Tief-)Garage betreuen. Als Stakeholder identifizierst du z. B. den Architekten, den Baumeister und einige andere Personen und Gruppen. Bezüglich der Anforderungen ermittelst du die Anzahl der gewünschten Stellplätze, das Material für den Bodenbelag und die Wände, die Anzahl der Säulen zur Stützung der Decke. Indem du beispielsweise die Anzahl der Stellplätze mit der zur Verfügung stehenden Fläche abgleichst, sorgst du dafür, dass es zu keinen Widersprüchen kommt.

Bestimmt fallen dir noch viele andere Dinge ein, die für den Bau einer Garage nötig sind. Aber, Hand aufs Herz, dachtest du auch an die Einfahrt?

Natürlich könnte man jetzt sagen, natürlich muss eine Garage auch eine Einfahrt haben, dass ist doch eh klar.

Offenbar nicht immer.

Im Jahr 2008 gab es in den Medien Meldungen über einen Schildbürgerstreich in Prag. So berichteten z. B. die Presse oder der Standard davon, dass beim Bau einer Garage die Einfahrt vergessen worden war.

Natürlich wissen wir nicht, was hier im Hintergrund tatsächlich abgelaufen ist. Aber klar ist, dass dadurch große Mehrkosten entstanden sind. Einerseits, weil die Garage nicht genutzt werden konnte, andererseits, weil die Behebung dieses »Mangels« die nachträgliche Konstruktion der Einfahrt über ein Nachbargrundstück nötig machte. Statt nur ein einzelnes Bauprojekt abzuwickeln, sah man sich also plötzlich mit zwei davon konfrontiert.

Du kannst aber davon ausgehen, dass gute und gewissenhafte Requirements Engineers so etwas hätte verhindern können. Denn sie hätten dafür gesorgt, dass so etwas Grundlegendes nicht einfach übergangen wird.

Dieses Beispiel illustriert, dass es beim Ermitteln von Anforderungen so etwas wie »eh klar« nicht geben darf.

Lesetipp

Wenn du nun Lust darauf bekommen hast, mehr über das Requirements Engineering zu erfahren oder gar die Zertifizierung (Foundation Level) anstrebst, sei dir das Buch »Basiswissen Requirements Engineering« von Klaus Pohl und Chris Rupp (ISBN-13: 978-3864908149) ans Herz gelegt.

Das könnte dich auch interessieren