Anforderungen gibt es nicht

Wird nicht die gesamte Profession sehr häufig „Requirements Engineering“ oder „Anforderungsmanagement“ genannt? Was bedeutet dann diese Überschrift? Das kann doch nicht des Autors Ernst sein!

Ist es auch nicht – zumindest nicht so ganz. Der Titel dieses Aufsatzes ist inspiriert durch den Artikel des Bloggers Tony Heap: „There‘s No Such Thing as a Requirement“ (www.its-all-design. com/theres-no-such-thing-as-a-requirement/). Tony Heap schreibt in diesem Artikel, dass es letztlich immer um Design gehe. Auch wenn Stakeholder ihre Vorstellungen und Wünsche an das System bekannt geben, dann sind das Design-Ideen, die gut sein können oder auch nicht. Es gibt immer eine Option – man könnte immer auch eine andere Lösung finden. Deshalb: Es gibt keine Anforderungen.

Um Tony Heap’s Aussagen genauer beurteilen zu können, wollen wir uns zunächst den Begriff der „Anforderung“ näher ansehen. Laut Duden ist eine „Anforderung“ ein „Anspruch an jemandes Leistung“. Wenden wir diese Bedeutung auf die IT-Analyse an. Wer ist es, der einen Anspruch stellt – und an wen wird dieser Anspruch gestellt? Da gibt es zunächst einen Auftraggeber, der eine bestimmte Aufgabe stellt. In der Regel ist es die Entwicklung einer Software, durch die Wert für die jeweilige Organisation geschaffen werden soll. Daneben gibt es zumeist eine Reihe weiterer Ansprüche (= Anforderungen), die an die Software gestellt werden. Diese Ansprüche werden einerseits vom Auftraggeber selbst formuliert, andererseits aber auch von Personengruppen, die – explizit oder implizit – von diesem dazu ermächtigt wurden. Üblicherweise fassen wir diese unter dem Begriff „Stakeholder“ zusammen. Diesen Begriff wollen wir auch in weiterer Folge verwenden. Es ist die Aufgabe des Analytikers, die Anforderungen der Stakeholder zu sammeln. Aber auch bei größter Anstrengung werden die so ermittelten Anforderungen die erforderliche Lösung nicht vollständig beschreiben.

Vergleichen wir diese Situation mit einem geplanten Autokauf. Auch hier werden wir als Käufer verschiedene Ansprüche haben, die individuell unterschiedlich sind: Einmal wird es das Platzangebot sein, das besonders wichtig ist. Das andere Mal die PS-Zahl, die Umweltfreundlichkeit, die Geländegängigkeit, der Preis oder andere Faktoren. Aber niemals werden die „Anforderungen“, die wir als Käufer haben, das Auto vollständig beschreiben. Es wird viele Elemente geben, die wir als gegeben voraussetzen und die wir niemals als Anforderungen formulieren würden. Daneben gibt es immer auch Leistungselemente, von denen wir uns gerne überraschen lassen – die wir nach dem Kauf am Produkt schätzen, die wir vor dem Kauf aber ebenfalls nicht als Anforderungen festgehalten hätten. Ebenso wie einem Autokäufer geht es einem Stakeholder in einem Software-Projekt. Er weiß, welche Aufgabe das Produkt erfüllen soll und er hat die eine oder andere Idee (bzw. den Anspruch), auf welche Weise das passieren soll. Niemals aber werden diese Ideen des Stakeholders – die „Anforderungen“ – das Produkt vollständig beschreiben können.

Innerhalb eines Software-Projekts ist es die Aufgabe der IT-Analyse, die geplante Lösung so zu beschreiben, dass sie im Anschluss (oder auch teilweise parallel) von der Entwicklung implementiert werden kann. Diese Lösung muss allerdings den genannten Ansprüchen (den „Anforderungen“) des Auftraggebers bzw. der übrigen Stakeholder genügen. Deshalb ist es ein wesentlicher Teil der Aufgabe eines IT-Analytikers, diese Anforderungen zu sammeln, sie zu ordnen und in richtigem Umfang zu dokumentieren. Wir sehen also, dass die Analyse die „Anforderungen“ des Auftraggebers entgegennimmt und daraus ein System-Design erstellt, das in weiterer Folge von der Entwicklung in eine Software-Lösung umgesetzt wird.

Wenn aber, wie wir gesehen haben, die Anforderungen der Stakeholder die Lösung nicht vollständig beschreiben, was sind dann die restlichen Bestandteile, die das Design der Lösung ausmachen? Folgende Punkte sind in diesem Zusammenhang zu nennen:

1. Wissen über das Fachgebiet: Jedes Fachgebiet funktioniert nach einem gewissen Regelwerk. Das kann einerseits in Gesetzen niedergeschrieben sein, es kann sich aus einem allgemein anerkannten „State of the Art“ ergeben oder es kann ganz einfach in der Natur des Fachgebietes begründet sein. Es ist die Aufgabe des IT-Analytikers, sich dieses Wissen anzueignen und, darauf aufbauend, das Design der Lösung zu bauen.
2. Kreativität und Ideen: Je nach Art der Aufgabenstellung fließen immer auch – in geringerem oder größerem Ausmaß – eigene Ideen der Analytiker, wie man die Aufgabenstellung besser bewältigen könnte, in das Lösungsdesign ein.
3. Kombination von „Anforderungen“, „Wissen“ und „Ideen“ zu einem System. Dieses Zusammenfügen der drei Grundelemente ist die Haupttätigkeit des IT-Analytikers.

Drei Dinge sind es also, die in das Lösungsdesign einfließen: „Anforderungen“, „Wissen“, „Ideen“. Nach der Kombination dieser drei Elemente ist die Lösung vollständig beschrieben. Sehr häufig werden diese drei Elemente unter dem Begriff der „Anforderungen“ zusammengefasst. Es handelt sich jedoch um drei Dinge, die unterschiedliche Quellen haben, die auf unterschiedliche Art und Weise ermittelt werden und die auch unterschiedlich behandelt werden müssen. Deshalb ist es zweckmäßig, diese drei Dinge auch unterschiedlich zu benennen.

Ein „Alles ist Anforderung“ ist ebenso wenig hilfreich wie ein „Anforderungen gibt es nicht“.

Soweit zunächst zu den Anforderungen aus der Sicht der IT-Analyse. Wie sieht es aber mit der Entwicklung aus. Gibt es auch hier „Anforderungen“? Wiederholen wir an dieser Stelle noch einmal, was „Anforderung“ bedeutet: Eine Anforderung ist ein „Anspruch an jemandes Leistung“. Wo ist nun der Anspruch an die Leistung der Entwicklung festgeschrieben? Es ist der Output der IT-Analyse, also das Design der Lösung, das die geforderte Leistung der Entwicklung beschreibt. Wenn man so möchte, könnte man also auch das Design der Lösung als „Anforderungen“ bezeichnen.

Tatsächlich schlägt das auch der Business Analysis Body of Knowledge“ (BABOK-Guide) so vor: Der Begriff „Design“ wird nur für „technisches Design“ verwendet. Das fachliche Design wird als „Anforderungen“ bezeichnet. Wir plädieren hier jedoch für eine klare Trennung der Begriffe: „Anforderungen“ sind die Ansprüche des Auftraggebers bzw. der Stakeholder an die Software. Diese Anforderungen werden von der IT-Analyse gemeinsam mit Wissen über das Fachgebiet und eigenen Ideen zum „fachlichen Design“ kombiniert, das als fachliche Vorgabe für die Entwicklung dient.