Requirements Engineering and Cost Estimation - Grundlagen

Grundlagen des Requirements Engineering

Wie jede andere Fachdisziplin verfügt auch das Requirements Engineering über Begrifflichkeiten und Grundlagen, die vertraut sein müssen, bevor es möglich ist, in die fachlichen Tiefen einzutauchen.

Definition & Abgrenzung des Requirements Engineering

Requirements Engineering ist eine vielfältige Disziplin mit umfangreichen und verschiedenartigen Aufgaben. Um diese möglichst umfassend abzudecken, bedient sie sich an Einflüssen und „Erfahrungen aus der Systemtechnik, der Psychologie, der Betriebswirtschaft, dem Marketing, dem Produktmanagement, dem Projekt­management und natürlich der Informatik“ .

Die Literatur kennt verschiedene Definitionen, die im Detail variieren. Gemeinsam sind ihnen folgende Eckpunkte:

Requirements Engineering ist ein

• kooperativer, iterativer Prozess,
• um durch die Identifizierung von Stakeholdern und ihren Bedürfnissen sowie Wünschen
• systematisch das Ziel eines geplanten Systems zu entdecken.

Unter System ist an dieser Stelle nicht nur eine Software oder ein Produkt gemeint, sondern es ist unter Umständen von wesentlich größeren Ausmaßen, wie einem Flughafen, einem Auto oder einem umfassenden menschlichen System die Rede.

Das Ziel des Requirements Engineering ist also, dass alle relevanten Anforderungen für das System bekannt und im erforderlichen Detaillierungsgrad verstanden sind. Das bedeutet, das alles, was das System können soll, ermittelt und die Erkenntnisse üblicherweise nach Vorschriften und Richtlinien dokumentiert wurde. Die generierten qualitativ guten – in der Realität wahrscheinlich aber nicht perfekten – Requirements werden in einer möglichst einfach analysierbaren, kommunizierbaren und implementierbaren Form festgehalten und erlauben, das Projekt mit einem akzeptablen Risiko durchzuführen. Im Requirements Engineering geht es um ‘designing the right thing’, im Gegensatz zum Software Engineering, dessen Ziel ‘designing the thing right’ ist.

Die ‚richtigen‘ Anforderungen können leider nicht in einer Phase von einer Person an einem Ort generiert werden, sondern es handelt sich um einen kontinuierlichen Prozess, an dem viele Menschen beteiligt sind. Die dafür nötigen Aktivitäten sind auch nicht linear – z.B. am Anfang oder am Ende einer Softwareentwicklung – sondern typischerweise begleitend zum Projektverlauf mit Rücksprüngen und Wieder­holungen. Die prozesshafte Qualität steht, wie die folgende Definition veranschaulicht, im Vordergrund:

software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation .

Requirements Engineering bedeutet strukturiertes Ermitteln, Dokumentieren, Spezifizieren und Abstimmen von Anforderungen. Letzteres heißt, alle beteiligten Stakeholder sind sich in der jeweils aktuellen Projektsituation im Klaren darüber, was für Anforderungen an das System gestellt werden und sie stimmen ausreichend überein, dass die zusammengetragenen Anforderungen auch genau die sind, die umgesetzt werden sollen. Die Validierung von Requirements und die Herstellung eines Konsens über die dokumentierten Erwartungshaltungen der beteiligten Personen hilft das Risiko zu minimieren, dass das System schlussendlich nicht den Wünschen und Bedürfnissen der Stakeholder entspricht und vom Kunden nicht abgenommen wird. Nachdem Entwicklung immer konstante Veränderung bedeutet, sowohl durch die unterschiedlichen Phasen, aber auch durch die Veränderungen des Projekts sowie der Anforderungen umfasst Requirements Engineering auch die systematische Verwaltung und Adaption von Anforderungen.

Gründe für Requirements Engineering

Wenn Requirements nicht professionell bearbeitet werden, entsteht häufig der Eindruck, dass Applikationen unter anderem aufgrund vieler Änderungen mindestens drei Mal entwickelt werden: Die Projektkosten vervielfachen sich, kein Ende ist in Sicht und der Auftraggeber wird langsam ungehalten. Dadurch steigt der Druck auf das Projekt, der Ton zwischen den Stakeholdern wird möglicherweise gehässig und es beginnt das Finger Pointing. Die Entwickler sind frustriert, weil sie zum x-ten Mal den Code für die gleiche Sache ändern müssen und die „Technical Debt“ steigt ständig an. Irgendwann kommen Zweifel auf, ob das Projekt überhaupt erfolgreich abgeschlossen werden kann.

Im Requirements Engineering geht es genau darum, eben beschriebenes, katastrophales Projekt zu verhindern. Denn Nachlässigkeit, Fehler oder Miss­verständnisse im Umgang mit Anforderungen ziehen immer einen Rattenschwanz an Folgeproblemen nach sich. Und nicht zu vergessen, ungleich höhere Kosten.

Kosten der Fehlerkorrektur nach Projektphasen

Die Grafik zeigt auf der x-Achse den zeitlichen Ablauf eines IT-Projekts von den Requirements über Design, Implementierung, Testing bis zur Instandhaltung. Die y-Achse bildet die Kosten einer Korrektur von Missständen im Verhältnis zueinander ab. Wird also ein Fehler in der Phase der Requirements Ermittlung festgestellt, betragen die Kosten 1. In Relation dazu steigen die Kosten in der Designphase bereits auf 5, in der Implementierungsphase auf 10. Spätestens da explodieren die Korrekturkosten förmlich, so dass sie in der Testingphase bereits bei 50 und in der Instandhaltung gar bei 200 sind. Das heißt, je später Missstände aufgedeckt werden, desto höher ist der Aufwand diese zu reparieren.

Um aus dem Ruder laufenden Projekten Einhalt zu gebieten, zahlt es sich daher aus, in das Requirements Engineering zu investieren. Vor allem wenn in Betracht gezogen wird, dass aufgrund von Versäumnissen im Anforderungsmanagement immer noch etwa ⅔ aller Softwareprojekte in Zeit, Umfang und Budget nicht erfolgreich sind bzw. ganz scheitern. Symptome für mangelhaftes Requirements Engineering sind, dass die Anforderungen die Kundenwünsche nicht wiederspiegeln und die Diskrepanz unbemerkt bleibt. Ungenaue, missverständliche Requirements sind einer der Gründe, warum Projekte nicht zu dem Ergebnis kommen, das gewünscht ist. Wenn ‚Selbstverständliches‘ nicht explizit dokumentiert wird oder die Beteiligten sich dem Zeitdruck beugen, bringt auch das ein zu entwickelndes System in Gefahr.

Hingegen ist ein professionelles Requirements Engineering die Basis für erfolgreiche Systementwicklung, z.B. Design, Entwicklung und Testing, sowie Unterstützung beim zeitgerechten Aufdecken und Beheben potentieller Risiken. Anforderungsanalyse zwingt Stakeholder Requirements zu reviewen und fördert die Abstimmung zwischen den Beteiligten. Dabei können die Korrektheit und Vollständigkeit des geplanten Systems getestet sowie frühzeitig Fehler und Lücken entdeckt werden, deren Korrektur zu einem späteren Zeitpunkt wesentlich teurer wäre. Darüber hinaus liefert das Requirements Engineering die Grundlage für das Projektmanagement, z.B. die Ressourcenschätzung/-planung (Kosten, Personal, Kompetenzen, Equipment, …).

Kernaktivitäten des Requirements Engineering

Neben der Identifizierung, Dokumentierung und Abstimmung des Systems und des Systemkontexts inkl. der Kontextgrenzen umfassen die eben schon erwähnten Kernaktivitäten des Requirements Engineering die Schritte: Anforderungen

• ermitteln (Kapitel 3),
• dokumentieren (Kapitel 4),
• prüfen und abstimmen (Kapitel 5) sowie
• verwalten (Kapitel 6).

Kernaktivitäten des Requirements Engineering

Warum es sinnvoll ist, strukturiert Anforderungen zu ermitteln, zeigt schon das Milch-Beispiel in der Einleitung. Je genauer wir wissen, wer – nämlich Kunden, User oder andere Stakeholder – betroffen ist bzw. was deren Bedürfnisse und Wünsche sind, desto klarer wird unser Bild vom zu entwickelnden System. Im Schritt Ermitteln sollen mit verschiedenen Techniken sowohl existierende, als auch potenzielle Anforderungen an das Softwaresystem, genauer die Systemeigenschaften und Rahmenbedingungen, aufgedeckt werden.

Anforderungen dokumentieren (auch spezifizieren genannt), geschieht meist nach Vorschriften oder Standards und beugt dem Schwund von Wissen vor. In Projekten wechseln Mitarbeiter, sie werden krank, sie vergessen und damit verschwinden Informationen. Studien zeigen, dass wir – wenn wir glauben, Wissen sei elektronisch gespeichert – besonders schnell vergessen. Die Aktivitäten des Festhaltens und Analysierens liefern einerseits einen Gesamtüberblick bzw. bewahren Detailtiefe, andererseits bieten sie die Grundlage der Übereinstimmung von Stakeholdern. Wie Requirements dargestellt werden bzw. welche Formen eine Dokumentation haben kann, hängt stark vom jeweiligen Projekt und den darin herrschenden Gegebenheiten ab.

Diese Anforderungsbasis wird im nächsten Schritt gegen die Zielstellung, das System und den Systemkontext sowie auf Widersprüche geprüft, um Konsistenz, Vollständigkeit oder formale Korrektheit zu gewährleisten. Diese Bewertung dient der Qualitätssicherung von Requirements. In einer weiteren Iteration werden die Anforderungen mit den Stakeholdern abgestimmt, so dass wir sichergehen können, dass alle relevanten Anforderungen für das System bekannt und in erforderlichen Detaillierungsgrad verstanden sind. In diesen Bereich fällt üblicherweise auch die Aufwandschätzung, die in Softwareprojekten aufgrund der gewohnten Missstände nach wie vor Anlass vieler Witze ist.

Die in die Umsetzungsphase übernommenen Anforderungen dienen als Grundlage für die Implementierung. Im Idealfall werden sie statusbasiert bearbeitet, bei Änderungen versioniert und regelmäßig gereviewt. Veränderungen werden über einen vereinbarten Change Prozess eingepflegt. Das schließt ein, dass alle Beteiligten jederzeit Zugriff auf die letzte gültige Version haben und diese auch identifizieren können. Wir sprechen daher vom Requirements verwalten.

Innerhalb eines Projekts durchlaufen die Anforderungen diese Kernaktivitäten nicht zwingend in dieser Reihenfolge, auch wenn dies in den vielen Fällen so sein wird. Die einzelnen Schritte können in einander übergehen, mal einen Schritt überspringen, später darauf zurückkommen usw. Je nach Herangehensweise gibt es kleinere oder größere Abweichungen von dem etappenweise ablaufenden Modell. Besonders in agilen Projekten sind manche Phasen weniger umfangreich bzw. verwobener angelegt. Die Verantwortung für das Durchlaufen aller Anforderungen durch die vier Kernaktivitäten, in welcher Form auch immer, liegt beim verantwortlichen Requirements Engineer.

Anforderungen

Für Anforderungen (engl. Requirements) gibt es eine noch unüberschaubarere Anzahl an Definitionen. Laut Wörterbuch ist ein Requirement etwas, das sich jemand wünscht oder braucht, also ein Bedarf nach etwas.

Requirements formen ein zu entwickelndes System. Ohne ihre detaillierte Spezifikation ist nicht fassbar, was gewünscht ist und das System kann nicht geliefert werden. Es braucht eine ganz klare Vorstellung der notwendigen Merkmale, Funktionen und Rahmenbedingungen, damit die Umsetzung dem entsprechen kann, was gefordert ist. Je eindeutiger eine Anforderung an ein System der jeweiligen Quelle entlockt werden kann, desto eher gelingt es, ein bestimmtes ‚Problem‘ zu lösen oder ein Ziel zu erreichen. Bereits in der Einleitung wurde sichtbar, dass in diesem Kontext nicht nur gemeint ist, dass etwas nicht funktioniert, sondern eventuell auch, dass es etwas noch nicht gibt, wie die Möglichkeit zu schaukeln. In einem solchen Fall wäre das Ziel, der Wunsch zu schaukeln. Die dafür notwenigen Anforderungen sind laut Grafik nicht ‚vollständig‘ erhoben, verstanden und umgesetzt worden, weshalb das System nicht nach den Wünschen des Kunden gestaltet werden kann. Im Idealfall wäre aber das Ergebnis eine Schaukel, mit der jemand tatsächlich schaukeln kann, auch wenn selbst der Kunde das zu Beginn nicht kommunizieren konnte.

Zusammenfassend lassen sich Anforderungen folgendermaßen definieren:

Requirements are […] a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.

Anforderungen beeinflussen unmittelbar den Systementwicklungsprozess. Sie bilden die Grundlage für viele weitere Schritte, wie Kommunikation, Optimierung des Kunden-/Usernutzens, Ausschreibung und Vertragsgestaltung, Systemarchitektur, Test und Abnahme, Systemintegration und Wartung oder Fehlerbehebung und Weiterentwicklung.

Wichtig ist die Unterscheidung zwischen Anforderung und Lösung. Requirements bzw. das Lastenheft entstehen im so genannten Problemraum, in dem die Bedürfnisse der Stakeholder bzw. der Nutzen des anstrebenswerten Systems verortet ist. An dieser Stelle wird nicht beschrieben, wie diese Wünsche umgesetzt bzw. die Probleme aus der Welt geschafft werden, sondern die Lösung ist häufig noch durch verschiedene Ansätze möglich. Zuerst meist vage wird der Problemraum im Laufe der Lösungskonzeption klarer eingegrenzt.

Im Gegensatz dazu umfasst der Lösungsraum, wie die Anforderungen implementiert werden, also die Eigenschaften und Merkmale des zu entwickelnden Systems. Die Festlegung eines Lösungskonzeptes bestimmt damit die Lösungsspezifikation, das Pflichtenheft, das Design usw.

Bei einer Vermischung von Problem und Lösung kommt es zum Strukturbruch, der meist schwerwiegende Folgen für den Projektverlauf zur Folge hat.

Relation Problem-Anforderung-System

Das Problem bzw. das gewünschte Ziel ist der Auslöser für die Anforderung. Eine Anforderung stellt Forderung an das zu entwickelnde System. Dieses System ist wiederum die Lösung für das zugrundeliegende Problem oder Ziel.

In der Praxis werden Anforderungen häufig schon auf ein ganz bestimmtes System hingeschrieben. Anwender stellen sich bereits ein konkretes System vor und formulieren die Requirements dementsprechend. Aufgrund der vorab überlegten Lösung, die sicher nicht bei allen Stakeholdern dieselbe ist, weichen die jeweiligen Anforderungen wahrscheinlich gravierend voneinander ab und stellen daher bei Nichtentdeckung ein Risiko für das Projekt da.

Lebenszyklus & Zustände

Anforderungen entstehen üblicherweise im Laufe eines Entwicklungsprojekts und beeinflussen in hohem Maße dessen weiteren Verlauf. Sie sind die Grundlage vieler Entwicklungstätigkeiten und steuern damit zu einem nicht unerheblichen Teil das Geschehen. Änderungen in den Anforderungen führen häufig auch zu Änderungen der gesamten Projektsituation.

Um Veränderungen abzubilden und den Entwicklungsprozess besser steuern zu können, empfiehlt es sich, den Progress einer Anforderung zu segmentieren. Wie bei Menschen lässt sich das ‚Leben‘ eines Requirements in unterschiedliche Abschnitte unterteilen. Diese Stadien werden im Requirements Management als Zustände bezeichnet.

Relation Problem-Anforderung-System

Die Existenz einer Anforderung ist im Vergleich zu einem menschlichen Leben überschaubar und einfach. Meist machen sie erst das Einführen unzähliger Zustände zur vermeintlich besseren Kontrolle komplex. Diese führen dazu, dass Stakeholder im Meer der verschiedenen Zustände quasi untergehen, weil sie außer für ‚Zustandsexperten‘ nicht mehr auseinanderzuhalten sind. Eine derartige Über­bürokratisierung des Lebenszyklus eines Requirements erhöht das Risiko von Fehlzuordnung oder Falschdiagnose, das den Projektfortschritt unnötig verzögern kann. Eine Anpassung der Zustände an das jeweilige Projekt bzw. die darin gelebte Arbeitsweise erweist sich meist als hilfreich, solange alle regelmäßig damit hantierenden Beteiligten ohne Verwirrung mit den Zuständen umgehen können. In der Praxis bewährt sich eine Reduktion auf die essentiellen Kernzustände eines Requirements, um die Komplexität zu minimieren, Missverständnisse zu vermeiden und den gemeinschaftlichen Arbeitsrhythmus effizienter zu gestalten.

Arten von Anforderungen

Grundlegend werden drei Typen von Requirements unterschieden:

• Funktionale Anforderungen

Diese beziehen sich auf das Ergebnis eines Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll. Dazu gehören Funktions-, Verhaltens- und Strukturanforderung.

• Nicht-funktionale Anforderungen

Requirements, die ein Qualitätsmerkmal beschreiben, das nicht durch funktionale Anforderungen abgedeckt wird, werden als nicht-funktionale oder qualitative Anforderungen bezeichnet, z.B. Performance, Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit, Portabilität usw.

• Randbedingungen

Damit sind Anforderungen gemeint, die den Lösungsraum auf den relevanten Kontext beschränken, um die funktionalen und qualitativen Requirements zu erfüllen.

Alternative Möglichkeiten Requirements einzuteilen, sind unter anderem nach ihrem Inhalt (z.B. Qualitätsanforderungen, Anforderungen an die Benutzeroberfläche oder an sonstige Lieferbestandteile) bzw. ihrer rechtlichen Verbindlichkeit (z.B. verpflichtende, gewünschte, beabsichtige Anforderungen). Eine in der Praxis übliche Klassifizierung findet außerdem nach Attributen , wie Detaillierungsgrad oder Priorität, statt.

Kommunikationstheroretische Grundlagen

Wie die moderne Welt immer öfter und intensiver unter Beweis stellt, hängt in ihr alles mit allem zusammen. Dabei handelt es sich nicht um kausale Verbindungen, sondern die Relationen sind weit verwobener und komplexer. Die Systemtheorie geht von einer lebendigen statt einer mechanischen Weltsicht aus, womit sich auch die Realität im Requirements Engineering von vielschichtigen Projekten gut abbilden lässt. Zudem konstruiert sich jedes Individuum seine eigene Wirklichkeit, weshalb sich die Bilder, wie die Welt ist, in den menschlichen Köpfen gravierend unterscheiden.

Sprache dient als Transportmedium für den Austausch dieser mannigfaltigen ‚Weltsichten‘. Laut dem Shannon-Weaver-Kommunikationsmodell aus den 1940ern verschlüsselt der Sender eine Nachricht und der Empfänger dekodiert sie. Um Information weitergeben zu können, ist ein gemeinsamer ‚Code‘ notwendig. Weil aber viele Einflussfaktoren auf den sprachlichen Code wirken, unter anderem kulturelle Hintergründe, individuelle Erfahrungen sowie (fachliches) Vorwissen, sind Störungen der Kommunikation vorprogrammiert.

Zur Verdeutlichung des eigenen Bildes der Realität und der gegebenen Kommunikationshemmnisse lade ich Sie ein, sich einen Baum vorzustellen. Dieses Bild eines Baums in Ihrem Kopf bitte ich Sie nun, möglichst detailliert aufzuzeichnen oder zu beschreiben und mit dem Ihrer Kollegen zu vergleichen. Dabei werden Sie wahrscheinlich feststellen, dass Ihre Bäume grundlegend voneinander abweichen. Vielleicht handelt es sich bei dem einen um einen Laubbaum, beim anderen um einen Nadelbaum. Ein Bild ist das eines Mammutbaums, eines von einem Bonsai, ein anderes einer Kokospalme. Ihre Vorstellungen der Wirklichkeit sind konstruiert und Ihre Blickwinkel höchst individuell. Selbst wenn Sie präzisere Begrifflichkeiten auswählen, bieten diese keine Garantie, dass die Bilder Ähnlichkeiten aufweisen oder gar deckungsgleich sind.

Je ähnlicher die Parameter des gemeinsamen Kommunikationscodes sind, desto höher ist die Erfolgschance des Informationsaustauschs. Je größer die Differenzen sind, desto öfter kommt es zu Missverständnissen. Deshalb ist es wichtig, sich bewusst auf einen gemeinsamen Code zu einigen, um in Projekten die Kommunikation zu ermöglichen bzw. zu erleichtern.

Wie der Inhalt eines Austausches verstanden bzw. interpretiert wird, damit beschäftigt sich das Kommunikationsquadrat von Schulz von Thun, das auch als ‚Vier-Ohren-Modell‘ bekannt ist. Dieses Modell besagt, dass jede Äußerung bzw. Nachricht immer vier Botschaften oder Ebenen enthält: Sachinhalt, Selbstoffenbarung, Beziehung und Appell. Bei Requirements ist vor allem der Sachinhalt von Interesse, d.h. aber nicht, dass dieser auch in der Kommunikation im Vordergrund stehen muss.

Kommunikation erfolgt in der Regel mündlich oder schriftlich. Ersteres ist wesentlich flüchtiger (denken Sie zum Bespiel an das Spiel ‚Stille Post‘), gleichzeitig erleichtern zusätzliche Kommunikationswege, wie Gestik, Mimik oder Tonfall sowie die unkomplizierte Möglichkeit von Rückkopplung, die Interpretation des Gesagten. Bei der Verschriftlichung bestehen weniger Redundanzen und keine bis kaum direkte Rückmeldungen.

Die natürliche, menschliche Bequemlichkeit macht auch vor der Kommunikation keinen Halt, weshalb sie von Fokussierung und Vereinfachung geprägt ist. Da beide stark auf das individuelle und damit häufig sehr unterschiedliche Vorwissen aufbauen, sind abweichende Interpretationen eine logische Konsequenz.

Die Literatur des Requirements Engineering spricht nun davon, dass „fehlerfreie und vollständige Anforderungen […] die Basis für eine erfolgreiche Systementwicklung“ sind. Vor dem Hintergrund einer konstruierten Wirklichkeit und den gängigen Kommunikationsmodellen ist das unrealistisch. Das alltägliche Leben erfordert außerdem vor allem fertige Arbeitsschritte, dem agilen Motto ‚Better done than perfect!‘ entsprechend. Genau in diesem Wiederspruch bewegt sich der für Requirements Zuständige permanent und versucht, mit angemessenem Aufwand und die kommunikativen Gegebenheiten berücksichtigend so präzise Anforderungen wie möglich zu generieren. Dabei muss er einkalkulieren, dass eine erhöhte Aufmerksamkeit sowie viele Feedbackschleifen für ein wechselseitiges Verständnis notwendig sind. Denn wenn zu viel Wert auf die Beschreibung der Anforderungen gelegt wird, besonders häufig bei Technikern mit dem entsprechenden Fachwissen, arten Spezifikationen umfangsmäßig aus und verlieren sich in Detailverliebtheit. Wird zu wenig Augenmerk auf Requirements gelegt, bleiben sie meist vage oder abstrakt oder basieren auf nur teilweise bekannten Geschäftsprozessen.

Anforderungen an einen Requirements Engineer

An allen möglichen Stellen in Unternehmen begegnen uns Anforderungen, in Geschäftsprozessen, in Rollenbeschreibungen usw.; dementsprechend gibt es auch solche für den Requirements Engineer, der je nach Umfeld auch System-/ Anforderungsanalytiker, Business Analyst, Produktmanager oder Product Owner genannt wird.

Wenn in einem Projekt auf professionelles Requirements Engineering verzichtet wird, steigt die Wahrscheinlichkeit massiv, dass dieses ‚baden‘ geht. Je nach Größe und Bedeutung von solchen Projekten reißen diese eventuell auch die ganze Organisation mit in den Abgrund. Um das zu verhindern und eine erfolgreiche Systemanalyse sowie Systemumsetzung zu gewährleisten, gibt es dafür Profis. Diese dienen als ‚Übersetzer‘ zwischen verschiedenen Fachsprachen, als Vermittler zwischen Welten und Perspektiven. Wie Dolmetscher sorgen sie im Großen und Ganzen dafür, dass sich Business und IT ‚verstehen‘. Requirements Engineers nehmen daher in Projekten eine relevante interne und/oder externe Schnittstelle (aber nicht die des Projektmanagers) ein, in der sie direkt mit allen Stakeholdern, wie Auftraggeber, Kunden, Nutzer, Systemarchitekten, Entwickler, Tester usw., zu tun haben.

Laut dem International Requirements Engineering Board, das sich mit der Standardisierung des Wissens im Fachbereich beschäftigt, braucht ein Requirements Engineer neben fachlichen und methodischen Kenntnissen folgende Kompetenzen , um seinen Job erfolgreich absolvieren zu können:

• Analytisches Denken
• Selbstbewusstsein
• Empathie
• Moderationsfähigkeit
• Überzeugungsfähigkeit
• Kommunikationsfähigkeit
• Konfliktlösungsfähigkeit

Besonders die letztgenannten Fähigkeiten erfordern ein gewisses Maß an Selbstreflexion und persönlicher Weiterbildung, deren Auswirkungen aber auf keinen Fall unterschätzt werden sollten. Investitionen in diesen Bereichen machen sich sicher bezahlt und unterscheiden herausragende Requirements Engineers von durchschnittlichen.

Vorgehensmodelle

Projekte variieren auch in ihrer Herangehensweise, wobei sich zwei große Gruppen unterscheiden lassen:

• schwergewichtige oder konventionelle Vorgehensmodelle

z.B. Wasserfallmodell, V-Modell. Alle Anforderungen werden vor der Entwurfs- oder Realisierungsphase erhoben und es besteht die Vorstellung des Requirements Engineering als abgeschlossene Phase.

• leichtgewichtige bzw. agile Vorgehensmodelle

Z.B. eXtreme Programming, Scrum, Kanban. Requirements Engineering wird als kontinuierlicher, begleitender Prozess gesehen und die Erhebung von Anforderungen erfolgt mit der Implementierung.

Detaillierte Beschreibungen der Herangehensweisen sowie ihrer Vor- und Nachteile finden sich in der Literatur.

Ziele, Informanten & System

Mein Motto als Organisationsentwicklerin – ‚The best ideas are already in your head – set them free!’ – passt auch hervorragend für das Requirements Engineering. In beiden Fällen geht es nicht darum, die Welt oder konkreter die Bedürfnisse und Wünsche der Stakeholder neu zu erfinden, sondern mit dem zu arbeiten, was bereits da ist. Das ist aber meist leichter gesagt als getan. Vor allem so lange nicht klar ist, um welche Ideen, Vorstellungen und Visionen es sich genau handelt und wie sie aus den jeweiligen Köpfen herauszubekommen sind. Ein kurzer Dialog aus dem Buch ‚Alice im Wunderland‘ veranschaulicht das. Alice fragte da:

‚Würdest du mir bitte sagen, wie ich von hier aus weitergehen soll? (…)‘ ‚Das hängt zum großen Teil davon ab, wohin du möchtest‘, sagte die Katze. ‚Ach, wohin ist mir eigentlich gleich –‘, sagte Alice. ‚Dann ist es auch egal, wie du weitergehst‘, sagte die Katze.

Vieles ist unplanbar. Die heutige Welt mit ihrer immer rascher wachsenden Komplexität sowie den permanenten Ansprüchen sich und Unternehmen weiterzuentwickeln, erzeugt den Eindruck der Instabilität und das Gefühl der Unsicherheit. An lange stabile Phasen wie in der Vergangenheit gibt es nur mehr vage Erinnerungen, weshalb oftmals auf unvorhersehbare Situationen mit Improvisation reagiert wird. Dennoch sollte grundsätzlich in Softwareprojekten und damit im Requirements Engineering eine bekannte und damit wegweisende Ausrichtung angestrebt werde. Mit Laotse heißt das: ‚Nur wer sein Ziel kennt, findet den Weg.‘

Bereits vor dem ‚eigentlichen‘ Start der Systemanalyse sind einige Schritte zu berücksichtigen, um nicht das falsche Haus abzureißen bzw. ein ungewünschtes oder ungeeignetes System zu entwickeln. Üblicherweise beginnen viele Projekte schon mit Zeitdruck, weil unter anderem aufgrund von Diskussion, ob sie überhaupt durchgeführt werden sollen oder nicht, das Loslegen verzögert wird. Dabei ist mindestens so wichtig, wie die Entscheidung, ob ein Projekt umgesetzt werden soll, wie was genau gemacht werden soll und warum. Diese Überlegungen werden häufig mit den Worten – ‚Was wir brauchen, ist eh klar!‘ – übersprungen. Doch erst diese Klärungsphase verhindert die immens unangenehme Situation, dass nach unzähligen durchgearbeiteten Wochen und Monaten mit Höchstleistungen, der Kunde dann das System nicht abnimmt, es am Markt vorbei entwickelt wurde oder gänzlich nicht funktioniert. Viele Projekte werden also zu schnell gestartet, ohne die für ein erfolgreiches Projekt unumgängliche Ziel-, Stakeholder- und Kontextanalyse.

Ziele

Das Wissen, zum Beispiel was beim Kunden oder Nutzer anders sein wird, wenn das gewünschte System ausgeliefert ist, wofür es das Projekt überhaupt braucht oder wer davon profitieren wird und wie, ist die Voraussetzung für das Sammeln von Anforderungen. Eine Projektvision und Projektziele dienen als Leitlinie, da es, wie bereits erwähnt, ohne Kenntnis des Ziels unmöglich ist, sich auf den Weg in die dafür notwenige Richtung zu machen. Diesem Ziel werden dann die Anforderungen untergeordnet, anhand dessen wird strukturiert und priorisiert. Ohne definiertes und vereinbartes Ziel sind die Eigenschaften und die Qualität des Produkts bis zu einem gewissen Grad zufällig. Wenn die Entwicklung nicht markt- bzw. kundenorientiert stattfindet, ist der Erfolg fragwürdig. Zielgerichtetes Arbeiten ist die Grundlage für eine systematische Entwicklung und die Wahl der Ziele hat entscheidenden Einfluss auf das entstehende Ergebnis sowie den Entwicklungsprozess. Eine starke Vision und klare Ziele stimulieren außerdem Projektteams, die aufgrund der Ausrichtung bzw. Identifikation mit erhöhter Motivation effektiver arbeiten und qualitativ hochwertigere Resultate liefern.

Daher liegt die Aufmerksamkeit des Requirements Engineering bei Projektbeginn darin, die wichtigsten Kunden, Märkte und Wettbewerber zu identifizieren und zu verstehen, eventuell als Teil der Marketingspezifikation. Das dabei entstehende Knowhow gilt es in weiterer Folge, mit den Beteiligten, vor allem dem Projektmanager abzustimmen. Vorsicht ist dabei geboten, denn Ziele sind Anforderungen auf abstrakter Ebene. Ebenso wie für Anforderungen gilt es, die Ziele zu verschriftlichen und Qualitätskriterien einzuhalten. Damit ist dann eine solide Ausgangsbasis für die folgende Requirements Analyse geschaffen. Ohne diese Grundlage befindet sich der Requirements Engineer wie im Nebel und startet quasi den Versuch, die Bewältigung eines Projekts im Blindflug zu absolvieren. Schon aus Eigeninteresse, um bei der Erfolgsmessung des Requirements Engineering zu bestehen, wird er die Ziele für das System bzw. Projekt einfordern. Wenn diese Ziele nur vage sind, z.B. weil sie nicht dokumentiert und/oder abgestimmt sind, ist es sehr wahrscheinlich, dass viele Ressourcen beim Versuch verbraucht werden, etwas zu erreichen, dass keiner so genau kennt. Neben hohen Kosten entsteht dabei Frustration, die jede spätere Korrektur der Projektausrichtung mühsam gestaltet.

Folgende Einflüsse auf Ziele und Visionen gilt es zu berücksichtigen:

• Kunden (deren Ziele, Umfeld usw.)
• Strategie (Unternehmen, Markt usw.)
• Wettbewerb
• Produkte (Produktalter, Innovationsgrad, Änderungsumfang, Verfügbarkeit, Kostenstruktur usw.)
• Technologie
• Verfügbare Ressourcen (Zeit, Kompetenzen, Personal, Verfügbarkeit von Technologien/Komponenten usw.)

Die Vorgangsweisen zur Ermittlung von Zielen sind zahlreich und von den jeweiligen Rahmenbedingungen abhängig. Es bieten sich unter anderem Kreativitäts- oder Re-Use-Techniken an, um damit den mehrstufigeren Prozess zu gestalten:

• Involvierte Menschen, Dokumente und Systeme systematisch erheben
• Beschreibung der Ist-Situation neutral und ohne Beurteilung
• Bewertung der Situation durch Sammeln der subjektiven Aspekte wie Schwierigkeiten oder Potentiale
• Ziele definieren

Konkurrierende Ziele führen immer zu Einbußen beim möglichen Ergebnis, vor allem bei nicht-funktionalen Anforderungen aufgrund des wechselseitig starken Einflusses. Entscheidend ist daher, Widersprüche gegen einander abzuwiegen und mit Prioritäten zu versehen. In einem preissensitiven Markt werden zum Beispiel Herstellungskosten meist wichtiger als Qualitätskriterien eingestuft, auch wenn beide Anforderungen grundsätzlich wichtig sind. Die Beteiligten in der Umsetzung müssen diese Ziele kennen, um die kundenspezifischen Wünsche auch erfüllen zu können.

Bei Projektzielen geht es nicht nur darum, auf das Bekannte zu setzen, sondern das große Ganze im Blick zu haben. Folgendes Beispiel veranschaulicht das:

Sie sind in einer fremden Stadt und wollen zu einer bestimmten Sehenswürdigkeit, kennen sich aber nicht aus. Das ist die Problembeschreibung. Für diese gibt es nun mehrere bekannte Lösungsmöglichkeiten: zum einen die klassische Karte aus Papier zum Zusammenfalten, zum anderen ein Smart Phone mit einer Karten-App. Je nachdem, was Sie im Kopf haben, unterscheiden sich die Anforderungen:

Im Fall der Karte lauten die Ansprüche,

• dass sie faltbar ist, damit sie in einer Tasche verstaut werden kann,
• dass sie eine möglichst hohe Stabilität aufweist, damit sie nicht gleich zerreißt,
• dass der Maßstab für einen Fußgänger passend ist, d.h. wahrscheinlich, nur die Abbildung der sehenswerten Innenstadt, aber auch nicht jedes Baums.

Wenn ein Mobiltelefon zur Verfügung steht, wünscht sich der Nutzer möglicherweise

• eine Anbindung an eine drahtlose Verbindung,
• eine Anwendung, die Karten erstellt,
• das passende Kartenmaterial des Zielorts,
• die Möglichkeit, Start- und Zielort einzugeben, sowie
• dass das System in der Lage ist, eine Route zu erstellen und anzuzeigen.

Die Unterscheidung zwischen Problemen und Lösungen ist wie beim Arbeiten mit Anforderungen, auch für die Ziele relevant. Ebenso handelt es sich bei beiden Abläufen um iterative Prozesse, in die die Parameter des Systems sowie die unterschiedlichen Stakeholder einbezogen werden müssen. Eine Vision und Ziele sind schrittweise zu gestalten. Als Requirements Engineer empfiehlt es sich, Informationen in überschaubare Happen zu verpacken und dementsprechend zu ‚servieren‘. So sind sie leichter ‚verdaulich‘ und die Beteiligten können leichter abgeholt und zufrieden gestellt werden.

Wie im Beispiel sichtbar wurde, gelten neben Qualitätskriterien, die nicht nur für Anforderungen, sondern auch für Ziele wichtig sind, weitere Aspekte:

• Lösungsneutralität
• Inklusion einschränkender Rahmenbedingungen
• Realistische Erreichbarkeit

Der Darstellung von Zielen sind keine Grenzen gesetzt. Zu berücksichtigen ist, ein dem Projekt angemessener Umfang, die entsprechende Dokumentationsform sowie eine möglichst präzise Beschreibung, damit die Verständlichkeit für alle Beteiligte gegeben ist.

Stakeholder

Erfolgreiche Projekte haben zum richtigen Zeitpunkt, die richtigen Menschen für die richtigen Aufgaben involviert. Die Menschen sind zentral für jedes Projekt, als Auftraggeber und Kunde deren Ausgangs- und Endpunkt. Die Technik ist in den meisten Fällen das Hilfsmittel, das sich den Menschen anpassen sollte.

Alle Personen oder Organisationen, die die Anforderungen des geplanten Systems direkt oder indirekt beeinflussen, sind Stakeholder dieses Systems. Neben den bereits erwähnten Auftraggebern und Kunden umfasst diese Gruppe auch Architekten, Entwickler, Tester, Nutzer, Betreiber, Schulungspersonal usw. Weitere gängige Bezeichnungen sind Systembetroffene bzw. -beteiligte, Wissensträger oder Interessensvertreter. Stakeholder sind dementsprechend fast immer die wichtigste Quelle für Requirements.

Um Stakeholder ausfindig zu machen, ist es sinnvoll, beim Projektstart den Projektleiter sowie andere schon zu Beginn aktive Personen heranzuziehen sowie jeden weiteren Stakeholder nach noch relevanten Personen zu befragen. Für einen Requirements Engineer sind unter anderem folgende Fragen hilfreich: Wer steht hinter den Anforderungen für das zu entwickelnde System? Wer wird es nach der Fertigstellung benutzen? Wer profitiert (ökonomisch) von dem System? Darauf aufbauend erstellt dieser eine Stakeholderliste, in der Daten wie Name, Funktion bzw. Projektrolle, Kontakt, zeitliche bzw. räumliche Verfügbarkeit, Relevanz, Wissens­gebiet sowie -umfang und die jeweiligen Interessen sowie Ziele im Projekt vermerkt sind. Sind viele Ansprechpartner in einem Projekt vorhanden, ist es sinnvoll, diese zu klassifizieren, z.B. mit dem Stakeholdermodell von Babou Srinivasan .

Schlussendlich gilt es, die ausgewählten Ansprechpersonen mit dem Projektmanager bzw. dem zuständigen Management abzustimmen. Für eine effektive Arbeit ist es entscheidend, zu überprüfen, dass die gelisteten Beteiligten wirklich einen Beitrag leisten und ihre Expertise nicht von anno dazumal ist oder von ihnen nicht kommuniziert werden kann. Wenn allerdings wichtige Stakeholder übersehen werden, fehlen potentiell gewisse Anforderungen und das entwickelte System bleibt unvollständig. Die Konsequenz sind kostenintensive und aufwendige Nacharbeiten, wenn diese überhaupt möglich sind und es nicht zum Scheitern des Projekts kommt.

Zu Beginn gilt es als Requirements Engineer, das Eis zu brechen und die Projektbeteiligten an Board zu bringen. Dafür ist es notwendig, die Sprache der Stakeholder zu sprechen und sich in das Fachgebiet einzuarbeiten. Während des Projekts müssen dann die Kontakte gepflegt werden, indem das Knowhow, die Zeit und der Einsatz, die die Stakeholder einbringen, anerkannt werden. Stakeholder-Relationship-Management ist für das gute Funktionieren von Projekten essentiell und erfordert vom Prozessverantwortlichen eine wertschätzende Haltung im Umgang mit Stakeholdern. Wenn mit Betroffenen Verantwortung geteilt wird, ihnen Aufgaben delegiert werden und sie in Entwicklungen einbezogen sind, bindet sie das an das Projekt und hält dadurch ihr Interesse hoch. Es ist dementsprechend eine der Aufgabe des Requirements Engineer, die Stakeholder über das Projekt auf dem Laufenden zu halten und Arbeitsergebnisse verständlich an alle zu kommunizieren. Klare Vereinbarungen unterstützen die Zusammenarbeit. Es empfiehlt sich daher, je nach Verhältnis eine Art Abkommen zu erstellen, um die Verbindlichkeit in beide Richtungen zu verstärken.

System & Systemkontext

Die Anforderungen der Stakeholder liegen nicht auf der Straße, sondern müssen erarbeitet werden. Eine weitere Voraussetzung dafür ist, die Grenzen des gewünschten Systems aufzuzeigen bzw. festzulegen. Dafür sind die sich aus der relevanten Umgebung ergebenden Bedingungen zu identifizieren, da diese direkte Auswirkungen auf die Anforderungen haben.

Systemkontext

Eine Vorstellung der gewünschten Zukunft ermöglicht eine Annahme, wie das fertige System in die reale Umgebung integriert sein wird, wie Schnittstellen ausschauen könnten, wie einzelne Teile in Relation zueinander stehen. So können alle Aspekte bestimmt werden, die Auswirkungen auf das gewünschte System und damit die Anforderungen ausüben. Um die Anforderungsspezifikation einwandfrei und umfassend durchführen zu können, sind die Zusammenhänge zwischen allen relevanten Merkmalen im geplanten System und Systemkontext zu entschlüsseln und festzuhalten.

Unter Systemkontext wird der Ausschnitt der Wirklichkeit (die Systemumgebung, in die das Zielsystem eingebettet wird) bezeichnet, der für das Verständnis und die Beschreibung der Anforderung des geplanten Systems relevant ist und nicht im Rahmen der Entwicklung dieses Systems gestaltet werden kann. Mögliche Aspekte des Systemkontexts sind Stakeholder, bereits vorhandene Systeme im Betrieb, Prozesse (z.B. technische oder unternehmerische), vorgegebene Ereignisse sowie Dokumente (wie Gesetze, Standards usw.).

Die Ermittlung aller relevanten Faktoren liegt in der Verantwortung des Requirements Engineer. Werden Kontextcharakteristika übersehen bzw. fehlerhafte oder unzu­reichende einbezogen, hat das meist schwerwiegende Folgen bei der Inbetriebnahme des Systems. Das ‚Füttern‘ des Zielsystems mit unvollständigen oder inkorrekten Annahmen führt in vielen Fällen schlussendlich sogar zum Versagen des Systems.

Die Abgrenzung des Kontexts sorgt für einen groben Rahmen für die weitere Analyse, denn der Ursprung aller Anforderungen eines zu entwickelnden Systems liegt im spezifischen Systemkontext. Je kompletter der Kontext von Requirements bekannt ist, umso geringer ist die Wahrscheinlichkeit, dass diese falsch interpretiert werden und daraus andere verheerende Konsequenzen entstehen.

System- und Kontextgrenzen

Um Klarheit über den Systemkontext zu gewinnen, gilt es diesen in beide Richtungen – also vom zu entwickelnden System (Systemgrenze) sowie vom bedeutungslosen Teil der realen Umgebung (Kontextgrenze) – zu separieren.

System- und Kontextgrenze

Zwei Abgrenzungsprozesse, um den Systemkontext zu bestimmen:

• Systemabgrenzung

Systemgrenze unterscheidet, was sich innerhalb des Systems befindet und was nicht mehr, also Teil des Umfelds ist.

• Kontextabgrenzung

Welcher Teil der Systemumgebung kontextrelevant bzw. für das geplante System unerheblich ist und somit keinen Einfluss auf die Requirements des Zielsystems hat, gibt die Kontextgrenze an.

Der Systemkontext liegt dementsprechend zwischen der Systemgrenze und der Kontextgrenze. Dieser beinhaltet alle Faktoren, die die Requirements des zu entwickelnden Systems entscheidend bestimmen bzw. nicht durch den Entwicklungs­prozess verändert werden können. Aspekte innerhalb des Systemkontexts sind unter Umständen die Hardware und Software des geplanten Systems, Geschäftsprozesse, technische Prozesse, Stakeholder, Organisations­strukturen und/oder Bestandteile der Infrastruktur. Differenziert wird außerdem zwischen einem logischen und einem physikalischen Kontext. Der erste beschäftigt sich mit dem, was mit Nachbar­systemen kommuniziert wird, der zweite mit den Kanälen und Übertragungsmedien, mit denen das Zielsystem mit den angrenzenden Systemen verbunden ist.

Je vollständiger und präziser eine Kontextabgrenzung ist, desto leichter wird die Spezifikation des zu entwickelnden Systems. Für komplexe Systeme ist das unter Umständen dennoch nur beschränkt möglich. In jedem Fall erfordert die System- und Kontextabgrenzung meist mehrere Runden mit den relevanten Stakeholdern, um eine möglichst exakte Abgrenzung vorzunehmen.

Jedes System verfügt über eine mehr oder weniger große Anzahl an Schnittstellen, an denen es mit der Umgebung bzw. Nachbarsystemen interagiert. An diesen Punkten auf der Systemgrenze erfolgt die Bereitstellung der Funktionalitäten an die Umgebung, die Überwachung des Umfelds, die Beeinflussung von Umgebungs­parametern sowie die Steuerung von Prozessen im Systemkontext. Die Schnittstellen können unter anderem Mensch-Maschine, Hardware oder Software miteinander verbinden.

Wenn gewisse Schnittstellen bzw. Funktionen oder Merkmale eines Systems nur vage oder noch gar nicht bekannt sind, ist von Grauzone in der Systemabgrenzung die Rede. Eine zeitweise Unschärfe kann auch bei der Kontextgrenze bestehen, wenn angrenzende Systeme noch nicht vorhanden bzw. klar beschreibbar sind. Dann erfolgen Annahmen, die unbedingt als solche gekennzeichnet sein müssen, um diese im Zuge des Projektfortschritts so früh wie möglich durch Fakten zu ersetzen. Es gibt Stakeholder, die sich ungern festlegen und deshalb gerne Grauzonen aufrech­terhalten. Aufgabe des Requirements Engineer ist es in solchen Situationen hartnäckig zu bleiben, um klare Verhältnisse zu schaffen. Ungenauigkeiten bei der Systemabgrenzung müssen im Laufe des Requirements Engineering ausgeräumt werden. Bezogen auf den Kontext ist eine vollständige und präzise Abgrenzung in komplexen Systemen nicht möglich und es bleiben gewisse Systemeinflüsse für einzelne Teile der Umgebung unbestimmbar.

Wenn sich während einem Projekt zum Beispiel der Umfang oder die Wirkung der noch offenen Schnittstellen und/oder Funktionen verändert, so kann dies zu einer Verschiebung der gesamten Grauzone im Systemkontext führen. Sind für bestimmte Faktoren der Umgebung die Relationen zum Zielsystem fraglich, ist von der Grauzone der Kontextabgrenzung die Rede. Im agilen Setting sind die Grauzonen zu Beginn eines Projekts sehr groß und werden erst von Iteration zu Iteration reduziert, denn es wird keine umfassende Systemabgrenzung am Projektstart durchgeführt.

Um den Systemkontext zu dokumentieren, eignen sich unterschiedliche Methoden, sowohl natursprachlicher, als auch grafischer Art. Empfehlenswert sind standardisierte grafische Beschreibungen, z.B. Use-Case-Diagramme, Datenfluss Diagramme oder UML Klassendiagramme. In der Praxis werden häufig mehrere Darstellungsformen kombiniert, um die Verständlichkeit für alle Stakeholder sicherzustellen.