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.