header-image

Requirements Engineering Anforderungen entwickeln und verwalten

Arbeitsbereiche Peterjohann Consulting, (C) Peterjohann Consulting, 2005-2017 width=

Das Requirements Engineering (RE – teilweise auch als Requirements Management bezeichnet) stellt eine eigenständige Disziplin innerhalb des Systems Engineering oder des Software Engineering dar. Das RE setzt sich damit auseinander, wie Anforderungen an ein (neu zu erstellendes) Produkt, eine Dienstleistung oder ein System zusammenzutragen und zu verwalten sind, um eine möglichst effiziente Umsetzung zu ermöglichen. Das RE ist aber keine exakte Disziplin mit genauen Vorgehensweisen, sondern angereichert mit vielen Ideen und Betrachtungsweisen aus anderen Gebieten wie beispielsweise dem Projektmanagement, der Linguistik oder der Psychologie.

Hier werden statt Requirements Engineering auch die Begriffe Anforderungsmanagement oder auch Business Analysis verwendet. In der Literatur werden zwar noch Unterscheidungen zwischen diesen Begriffen vorgenommen, die aber hier nicht betrachtet werden.

In der Praxis werden Sie eine große Anzahl von Vorlagen, Anleitungen, Beispielen, Checklisten, Mustern, Heuristiken etc. finden, die Ihnen das Leben mit den Anforderungen erleichtern sollen. Alle diese Hilfsmittel müssen dann an Ihr konkretes Projekt (entsprechend Ihrer Firmen- und Projektkultur) angepasst werden – dies sollte in der Regel ein erfahrener Requirements Engineer oder Berater vornehmen.

Zudem überschneidet sich das Requirements Engineering in erheblichem Maße mit den Disziplinen

  • Projektmanagement,
  • Qualitätsmanagement,
  • Risikomanagement sowie
  • Prozessmanagement.

Um erfolgreiche Produkte oder Systeme zu entwickeln, benötigen Sie daher Kenntnisse aus allen Bereichen.
Auf dieser Seite soll nur ein kurzer Blick auf das Requirements Engineering geworden werden.

Kleine Einblicke in das Requirements Engineering

Zu folgenden Themen finden Sie hier die Beschreibung einiger Elemente:


1. Basisdefinitionen

An dieser Stelle werden Ihnen die hier verwendeten Definitionen vorgestellt, da die Begriffe (leider) in der Praxis (und auch in der Literatur) miteinander vermischt werden.

Hier wird das RE in die Bereiche Anforderungsentwicklung und Anforderungsverwaltung unterteilt.

Unterteilung des Requirements Engineerings, (C) Peterjohann Consulting, 2006-2017

Abbildung 1.1: Unterteilung des Requirements Engineerings

Der zentrale Begriff im Requirements Engineering sind die Anforderungen (auch als Requirements bezeichnet). Diese können folgendermaßen definiert werden:

  • „Anforderungen sind Aussagen über eine Eigenschaft oder Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen.“
  • „Eine Anforderung ist eine Bedingung oder Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.“
  • „Eine Anforderung ist eine Eigenschaft, über die ein Produkt verfügen muss, um für die Interessenvertreter von Nutzen zu sein.“

Bei den Anforderungen selbst kann wiederum zwischen Produkt- und Prozessanforderungen unterschieden werden. Auf dieser Seite setze ich mich nur mit den Produktanforderungen auseinander – Prozessanforderungen werden auf meiner Projektmanagement-Seite angesprochen.

Weitere zentrale Begriffe sind:

  • Kunde (Benutzer, Anwender): derjenige, der das Produkt oder die Dienstleistung nutzen soll – er macht die Vorgaben
  • Stakeholder – einer der beliebtesten Begriffe des RE (oder auch der Softwareentwicklung): Interesseninhaber oder -vertreter; dies können sein: der Fachanwender oder die Fachabteilung, der Kunde, das Marketing, der Vertrieb, das Management, der Projektleiter, der Projektmitarbeiter, die Schnittstellen (!), …
  • Requirements Engineer (auch Systemanalytiker, Anforderungsingenieur, Business Analyst, Requirements Analyst): derjenige, der das zu erstellende Produkt, System oder die Dienstleistung beschreibt
  • Produkt: Arbeitsergebnis, das aus Prozessen resultiert
  • Prozess: Abfolge zusammengehöriger Tätigkeiten, die der Erreichung eines Ziels dient
  • Ziel: ein in der Zukunft liegender, gegenüber dem Gegenwärtigen im Allgemeinen veränderter, erstrebenswerter und angestrebter Zustand (Zielvorgabe)

Der Requirements Engineer ist der Vermittler zwischen Auftraggeber und Auftragnehmer: Er definiert, wie Lösungen aussehen könnten.

Von der Idee bis zur Lösung, (C) Peterjohann Consulting, 2006-2017

Abbildung 1.2: Von der Idee bis zur Lösung


2. Beschreibung von Anforderungen

Anforderungen gibt es viele – typischerweise werden in Projekten folgende Anforderungen betrachtet:

  • Funktionale Anforderungen
  • Nicht-funktionale Anforderungen
  • Technische Anforderungen
  • Anforderungen an die Benutzerschnittstelle
  • Qualitätsanforderungen
  • Anforderungen an sonstige Lieferbestandteile
  • Anforderungen an die Durchführung der Entwicklung
  • Rechtlich-vertragliche Anforderungen
  • Anforderungen an Personen/Mitarbeiter
  • Kunden- oder Geschäftsanforderungen
  • Lösungs-, Marketing- oder Systemanforderungen
  • Produkt- oder Komponentenanforderungen

2.1 Einteilung der Anforderungen

Üblicherweise werden alle Anforderungen an ein Produkt oder System (grob) in funktionale und nicht-funktionale Anforderungen unterteilt. Das IREB geht einen Schritt weiter und untergliedert die nicht-funktionalen Anforderungen in Qualitätsanforderungen und Randbedingungen. Es ergibt sich folgendes Bild /Ebert14/:

Einteilung der Anforderungen, (C) Peterjohann Consulting, 2017

Abbildung 2.1: Einteilung von Anforderungen

Während die funktionalen Anforderungen (vergleichsweise) einfach zu beschreiben sind, bereitet die Erfassung der nicht-funktionalen Anforderungen in der Praxis größere Probleme, da sie nicht einfach zu ermitteln sind und dennoch das Gesamtsystem entscheidend definieren.

2.2 Gute Anforderungen

Mit „guter Anforderung“ ist nicht die Anforderung gemeint, die besonders gut gefällt, sondern diejenige, die bei der Erstellung des Produkts (besonders gut) weiterhilft. Eine gute Anforderung genügt folgenden Kriterien – sie ist:

  • atomar
  • identifizierbar
  • vollständig (nach IEEE)
  • korrekt (nach IEEE)
  • klassifizierbar
  • konsistent (nach IEEE)
  • realisierbar
  • notwendig
  • priorisiert
  • eindeutig (nach IEEE)
  • verstehbar
  • gültig und aktuell
  • nachprüfbar (nach IEEE)
  • rück- und vorwärtsverfolgbar (nach IEEE)
  • (bewertet) (nach IEEE)

Besonders die auf die Nachprüfbarkeit sollte größten Wert gelegt werden, da hier schnell rechtliche Konsequenzen greifen: Wenn eine Anforderung nicht getestet und überprüft werden kann, führt dies zwangsläufig zu Unstimmigkeiten zwischen Kunden und Auftragnehmer.

2.3 Ein Prozess für das Requirements Engineering

Einen fest vorgegebenen Prozess (mit Einzelschritten und Aktivitäten) für das RE gibt es nicht. Allerdings kann die Anforderungsentwicklung als Abfolge von Tätigkeiten betrachtet werden. Bei der Anforderungsentwicklung werden die Anforderungen systematisch zusammengetragen und in eine Form gebracht, die die beteiligten Parteien (Auftraggeber und Auftragnehmer) verstehen und zur Durchführung ihres Vorhabens verwenden können.

Die Anforderungsentwicklung nach IREB, (C) Peterjohann Consulting, 2017

Abbildung 2.2: Die Anforderungsentwicklung (nach IREB /IREB15/)

Die Anforderungsentwicklung wird fortlaufend durchgeführt: ständig müssen Anforderungen (oder Änderungen daran) erfasst, überprüft und in eine ansprechende und dem Zielpublikum verständliche Form gebracht werden. Das RE liefert dabei nur Hilfsmittel – zum Verfassen guter Anforderungsdokumente werden entsprechend ausgebildete Mitarbeiter benötigt.


3. Die Anforderungsermittlung

Bei Anforderungsermittlung werden die (möglichen) Anforderungen für zu entwickelnde System oder Produkt zusammengetragen. Dabei werden nicht von vornherein Anforderungen ausgeschlossen, sondern der Ermittlung erfolgt zunächst lösungsneutral.
Am Ende der Anforderungsermittlung gibt es eine Sammlung von Anforderungen für das zu entwickelnde Produkt.

3.1 Das Kano-Modell

Das Kano-Modell (nach Noriaki Kano, 1978) dient der Analyse von Kundenwünschen und basiert auf Kundenbefragungen und statistischen Auswertungen. In diesem Modell werden die Kundenanforderungen in drei Arten von Anforderungen (auch Faktoren oder Merkmale genannt) unterteilt:

  • Basisanforderungen (expected or basic requirements) sind selbstverständlich vorausgesetzte Systemmerkmale („unbewusstes Wissen“)
  • Leistungsanforderungen (normal or performance requirements) sind explizit geforderten Systemmerkmale („bewusstes Wissen“)
  • Begeisterungsanforderungen (delightful or excitement requirements) sind Systemmerkmale, die der Stakeholder nicht kennt, diese erst während der Benutzung entdeckt und dann Begeisterung bei ihm hervorrufen („unterbewusstes Wissen“)

Grafisch umgesetzt ergibt sich das Kano-Diagramm.

Das Kano-Diagramm: Darstellung, (C) Peterjohann Consulting, 2014-2017

Abbildung 3.1: Das Kano-Diagramm: Darstellung

Im Kano-Diagramm wird der Erfüllungsgrad der (Kunden-)Anforderungen der Kundenzufriedenheit gegenübergestellt. Selbst wenn die Basisanforderungen (rote Linie) immer vollständig erfüllt sind, führt dies nicht zur Erhöhung der Kundenzufriedenheit. Anders die Leistungsanforderungen (blaue Linie): Werden diese im Produkt umgesetzt, so können sie zur Erhöhung der Kundenzufriedenheit beitragen. Allerdings führt die unvollständige Umsetzung dieser Anforderungen zur Unzufriedenheit beim Kunden. Die Begeisterungsanforderungen (grüne Linie) hingegen tragen unmittelbar zur Kundenzufriedenheit bei, selbst wenn sie nur unzureichend umgesetzt wurden.

Die Begeisterungsanforderungen werden im Laufe der Zeit zu Leistungsanforderungen und schließlich zu Basisanforderungen.

Die Anforderungen im Kano-Modell können folgendermaßen charakterisiert werden:

Die Anforderungen im Kano-Modell, (C) Peterjohann Consulting, 2014-2017

Abbildung 3.2: Die Anforderungen im Kano-Modell

Beispiele für die drei Anforderungsarten im Kano-Modell:

Beispiele für Anforderungen im Kano-Modell, (C) Peterjohann Consulting, 2014-2017

Abbildung 3.3: Beispiele für Anforderungen im Kano-Modell

3.2 Ermittlungstechniken

Um Anforderungen zu ermitteln, können verschiedene Techniken (auch: Werkzeuge und Methoden, Tools and Techniques) eingesetzt werden (siehe Abbildung 3.4). Generell werden nicht alle Techniken innerhalb eines Vorhabens eingesetzt, sondern nur diejenigen, die sinnvoll erscheinen.

Die Ermittlungstechniken nach IREB, (C) Peterjohann Consulting, 2017

Abbildung 3.4: Die Ermittlungstechniken (nach IREB /IREB15/)

Die Erläuterung einiger Techniken erfolgt in der → Basis-Präsentation zum Requirements Engineering.

3.3 Das Glossar

Bei der Ermittlung der Anforderungen sollte bereits ein Glossar (mit)erstellt werden, welches alle (wichtigen) Begriffe enthält.


4. Die Anforderungsdokumentation

Bei der Anforderungsdokumentation werden die ermittelten Anforderungen in eine Form gebracht, die es erlaubt sowohl mit den Kunden/Stakeholdern wie auch mit den Entwicklern ein Gesamtbild des zu erstellenden Produkts zu generieren.

Die Dokumentationsformen nach IREB, (C) Peterjohann Consulting, 2017

Abbildung 4.1: Die Dokumentationsformen (nach IREB /IREB15/)


5. Das Prüfen und Abstimmen von Anforderungen

Das Prüfen und Abstimmen von Anforderungen dient der Zusammenstellung von abgestimmten Anforderungen, die zur Umsetzung gebracht werden können. Dabei müssen Inkonsistenzen beseitigt und abschließend die Anforderungen mit Hilfe der Stakeholder priorisiert werden.

Die Ziele beim Prüfen und Abstimmen von Anforderungen nach IREB, (C) Peterjohann Consulting, 2017

Abbildung 5.1: Die Ziele beim Prüfen und Abstimmen von Anforderungen (nach IREB /IREB15/)

Als Prüftechniken können eingesetzt werden:

Die Prüftechniken nach IREB, (C) Peterjohann Consulting, 2017

Abbildung 5.2: Die Prüftechniken (nach IREB /IREB15/)

Dabei werden alle „manuellen“ Prüfungen unter dem Begriff Reviews zusammengefasst.


6. Die Anforderungsverwaltung

Die beste Anforderungsentwicklung bringt wenig, wenn die entstandenen Anforderungen „statisch“ bleiben, d.h. nicht kontrolliert und konsequent in das Produkt einfließen (können). Mit dieser Aufgabe setzt sich die Anforderungsverwaltung auseinander, die wiederum in zwei Blöcke untergliedert werden kann:

  • Basisfunktionen: Umsetzung der Anforderungen in ein Produkt
  • Change Management: Erfassen und Umsetzen von Änderungen

Die generellen Aufgaben der Anforderungsverwaltung sind in der nachfolgenden Grafik dargestellt.

Die Aufgaben der Anforderungsverwaltung, (C) Peterjohann Consulting, 2017

Abbildung 6.1: Die Aufgaben der Anforderungsverwaltung (nach /Wiegers05/)

6.1 Basisfunktionen

Sind die Anforderungen in ausgearbeiteter Form zusammengetragen, so sollten diese auch systematisch in das Produkt einfließen. Wichtig hierbei ist die Nachverfolgung der (Umsetzung der) Anforderungen, um so das fertiggestellte Produkt testen zu können und auch vom Kunden abnehmen zu lassen.

Folgende Analysen über die Anforderungen sollten (jederzeit) im Projekt erstellt werden können:

  • Einflussanalyse: zeigt auf, wie sich Anforderungen bei der Umsetzung auf die gesamte Lösung auswirken
  • Abdeckungsanalyse: liefert ein Maß für den Projektfortschritt, da die Anzahl der erfüllten Anforderungen zu der Gesamtanzahl der Anforderungen in Relation gesetzt wird. Leider führt diese Analyse oftmals zu Missverständnissen
  • Nutzenanalyse: sie beantwortet die Frage, warum die einzelnen Anforderungen überhaupt in das Produkt aufgenommen wurden

Der zentrale Begriff der Anforderungsverwaltung ist sicherlich die Verfolgbarkeit (engl. traceability), die von der Kundenanforderung bis zur Produkteigenschaft die einzelnen Umsetzungsschritte transparent macht. Hierzu sollten pro Anforderung folgende Merkmale notiert werden:

  • Eindeutige ID
  • Bezeichnung
  • Zuordnung zu einem Projekt oder Produkt
  • Quelle
  • Status

6.2 Zustände von Anforderungen

Anforderungen haben immer einen Status: Hierüber wird der Bearbeitungszustand festgehalten.

Ein Zustandsmodell für Anforderungen - Generell, (C) Peterjohann Consulting, 2013-2017

Abbildung 6.2: Ein Zustandsmodell für Anforderungen (generell)

In der konkreten Ausgestaltung könnte ein Zustandsmodell dann folgende Ausgestaltung haben:

Ein Zustandsmodell für Anforderungen - Beispiel, (C) Peterjohann Consulting, 2013-2017

Abbildung 6.3: Ein Zustandsmodell für Anforderungen (Beispiel)

Im Normalfall durchläuft eine Anforderung alle Zustände von „Angelegt“ bis „Abgeschlossen“. Dabei wird an einer Stelle geprüft, ob die Anforderung zur Umsetzung gelangt oder ob sie nicht weiter betrachtet wird.

6.3 Change Management

Die Disziplin, die sich mit den Änderungen an den Anforderungen (im Requirements Engineering und auch im Projektmanagement) auseinandersetzt, heißt „Change Management“ oder „Change Request Management“ (das deutsche Wort Änderungsverwaltung wird weniger häufig benutzt; zum Change Management als organisatorisches Veränderungswesen gibt es → auf der Change-Management-Seite dieser Website einige Anmerkungen) – der Begriff deutet schon an, dass nicht nur das einmalige Erfassen und Weiterreichen von Anforderungen aufwendig ist, sondern auch das zielgerichtete Aufnehmen und Weiterverarbeiten von Änderungen an den Anforderungen. Tatsächlich bedingen die Änderungen die eigentlichen Schwierigkeiten innerhalb eines Projekts und sind daher immer „Chefsache“.

Auch für das Change Management kann ein Regelsatz angegeben werden:

  • Legen Sie alle Anforderungen gesammelt an einer Stelle ab
  • Ermöglichen Sie eine Analyse der Änderungen an den Anforderungen
  • Auch Änderungen müssen – wie die ursprünglichen Anforderungen selbst – ermittelt, analysiert, validiert und spezifiziert werden und durchlaufen somit den gleichen Prozess
  • Bündeln Sie die Änderungen, d.h. planen Sie auch die Zeitpunkte, an denen Änderungen eingebracht werden dürfen
  • Über die Umsetzung von Änderungen entscheiden festgelegte Instanzen, im Zweifel der Projektleiter und der Lenkungsausschuss
  • Setzen Sie einen Termin, ab dem Änderungen nicht mehr akzeptiert werden (können)
  • Zeigen Sie auf, welchen Einfluss die Änderungen auf das Produkt selbst und auf das Projekt haben

Nach Beendigung des Projekts sollten die nicht mehr umgesetzten Änderungen in das Change Management des nachgelagerten Teils des Produktlebenszyklus einfließen, um so die Wartung und (potenzielle) Weiterentwicklung zu erleichtern.


7. Anmerkungen zum RE

Das RE ist noch eine recht junge Disziplin, was die Forschung und wissenschaftliche Fundamentierung anbetrifft. Gleichzeitig überschneidet sich das RE mit einigen anderen Gebieten – aus diesen Gründen werden hier einige Aspekte zum RE aufgeführt, die sich nicht unmittelbar aus der reinen Theorie ergeben.

7.1 Anforderungen und Software-Vorgehensmodelle

Bei der Softwareentwicklung werden inzwischen eine große Anzahl unterschiedlicher Vorgehensmodelle verwendet, die sich insbesondere dahingehend unterscheiden, wie viele Dokumente erstellt und damit Anforderungen aufgenommen werden. Abgesehen von dem „agilen Vorgehensmodell“ werden jedoch immer Anforderungen erfasst, wenn auch zu unterschiedlichen Zeitpunkten. Die nachfolgende Abbildung verdeutlicht dies.

Vorgehensmodelle und Anforderungen, (C) Peterjohann Consulting, 2006-2017

Abbildung 7.1: Vorgehensmodelle und Anforderungen (nach /Ebert14/)

7.2 Die Umsetzung von RE in der Praxis

Nur wenige Firmen betreiben ein ausgereiftes Requirements Engineering. Die Ursachen für mangelhaftes Requirements Engineering sind:

  • Das Requirements Engineering sollte in einem Vorgehensmodell (Erstellungsvorgaben von der Idee zum Betrieb eines Systems) eingebettet sein. Wenn dieses bereits fehlt, stehen die Anforderungen im „leeren“ Raum
  • Der Erfassung von Anforderungen basiert auf sprachlichen, d.h. textuellen Methoden. Nun sind die die meisten Techniker nicht unbedingt Germanisten und nicht gewohnt, ihre Ideen klar und allgemeinverständlich zu formulieren
  • Die meisten am Markt verfügbaren RE-Tools ermöglichen derzeit noch kein vollständiges Roundtrip-Engineering (von der Erfassung zur Versionierung, Abänderung bis zum Betrieb) und bieten für die Entwickler nur eingeschränkten Nutzen

7.3 Die deutsche Sprache

Das Requirements Engineering hat viel mit (der richtigen Verwendung) der deutschen Sprache zu tun. Entsprechend beschäftigten sich einige Autoren (in Deutschland insbesondere Chris Rupp /Rupp09, Rupp14/) mit dem adäquaten Einsatz von linguistischen Methoden im RE. Aber auch ein generelles Verständnis der deutschen Sprache kann bei der Erstellung von guten Anforderungen hilfreich sein. Ergänzend können hierfür einige „Deutschbücher“ der Literaturliste unter
Hobbyrunde (Rubrik „|Deutsch für …“) auf der privaten Website des Autors hinzugezogen werden.

7.4 Verwandte Themen

Der Zweig der (technischen) Dokumentation setzt sich mit ähnlichen Aufgabenstellungen wie das RE auseinander. Zwar gibt es inzwischen sogar einen eigenständigen Studiengang „Technische Dokumentation“, aber ansonsten wird dieser Bereich kaum wahrgenommen.

Die Verwandtschaft des RE zum Gebiet der technischen Dokumentation ermöglicht es aber, auch interessante Methoden zur Darstellung zu verwenden, so z.B. das XML-basierte DITA. Weitere Informationen finden sich auch unter www.doku.info. Als Literatur kann beispielsweise

  • /Juhl15/ Dietrich Juhl: Technische Dokumentation: Praktische Anleitung und Beispiele, Springer, Berlin 3. Auflage 2015, ISBN 978-3-662-46864-7

herangezogen werden.


8. Die Verbände zur Business Analysis und zum Requirements Engineering

Rund um die Business Analysis und das Requirements Engineering sind einige Verbände entstanden, die sich um die Definition und Strukturierung der Inhalte bemühen.
In Deutschland sind vor allem folgende drei Verbände relevant:

  1. Das International Requirements Engineering Board (IREB)
  2. Das International Institute of Business Analysis (IIBA)
  3. Das Project Management Institute (PMI)

Alle drei Verbände haben jeweils eine Basiswerk zur Beschreibung des zur BA und zum RE gehörenden Inhalts (IREB: /IREB15/, IIBA: /BBG15/, PMI:/BAPG15/) und geben jeweils Personenzertifikate heraus, die nach Bestehen einer Prüfung erlangt werden können.

Eine Bewertung der Verbände wird hier nicht vorgenommen, kann aber beim Autor abgefragt werden.

8.1 Die Strukturierung der Aufgaben zur BA und zum RE

Die drei Verbände unterteilen die Aufgaben in der Business Analysis und im Requirements Engineering in einzelne Bereiche. Diese heißen …

  • beim IREB Hauptaktivitäten,
  • beim IIBA Knowledge Areas (Übersetzung: Wissensgebiete) und
  • beim PMI Domains (eigene Übersetzung: Domänen).

Die Aufgabenunterteilung der drei Verbände zur BA und zum RE, (C) Peterjohann Consulting, 2017

Abbildung 8.1: Die Aufgabenunterteilung der drei Verbände zur BA und zum RE

Auf den folgenden drei Grafiken sind die Unterteilungen der BA und des REs der Verbände dargestellt. Die Zahlen in den grünen Kreisen geben jeweils das Buchkapitel des dazugehörigen Basiswerks wieder.

Hierzu:

  • Die Unterteilung in die Bereiche ist nicht als strenger Ablauf zu interpretieren
  • Jedem Bereich sind mehrere Werkzeuge und Methoden (Tools and Techniques) zugeordnet
  • Bei allen drei Verbände ist das Basiswerk zuletzt 2015 erschienen
  • Die Unterteilungen sind nicht „gleich gewichtet“: Bei allen Verbänden steht die Ermittlung (Elicitation) im Vordergrund

Die vier Hauptaktivitäten im RE nach IREB, (C) Peterjohann Consulting, 2017

Abbildung 8.2: Die vier Hauptaktivitäten im RE nach IREB /IREB15/

Beim IREB fehlt eine vorgelagerte oder übergeordnete Planungsstufe, die festlegt, welche Werkzeuge und Methoden im konkreten Einzelprojekt verwendet werden sollen.

Die sechs Wissensgebiete nach IIBA, (C) Peterjohann Consulting 2017

Abbildung 8.3: Die sechs Wissensgebiete nach IIBA /BBG15/

Das IIBA beschäftigt sich stark mit der Einbettung der Anforderungen in den Organisationskontext, die konkrete Umsetzung wird weniger stark adressiert.

Die fünf Domänen in der BA nach PMI, (C) Peterjohann Consulting, 2017

Abbildung 8.4: Die fünf Domänen in der BA nach PMI /BAPG15/

Die fünf Domänen der BA nach PMI ähneln den sechs Wissensgebieten des IIBA sehr stark. Auch die Tasks mit den Werkzeugen und Methoden sind vergleichsweise ähnlich aufgebaut.

8.2 Die Zertifizierungen der Verbände

Die drei Verbände vergeben Zertifikate an Personen. Zu diesen Zertifizierungen gibt es eine Übersicht → hier auf dieser Website unter der Rubrik „Extras | Zertifizierungen“.


9. Häufige Fragen und Antworten zur Business Analysis und Requirements Engineering

Einige Fragen zur BA und zum RE werden häufig (nicht nur von Einsteigern) gestellt – diese werden hier wiedergegeben.

  • F: Ist die Nutzung von RE nach den Standards (IREB, CBAP, PMI-PBA) kostenfrei?
    A: Ja – es fallen keine Lizenzgebühren an.
  • F: Kann ich BA und RE außerhalb von Softwareentwicklungsprojekten einsetzen?
    A: Ja.
  • F: Ist eine Schulung zur BA und RE empfehlenswert?
    A: Ja.
  • F: Ab wann „lohnt“ sich Requirements Engineering?
    A: Fragen Sie mich.
  • F: Welche Literatur ist empfehlenswert?
    A: Fragen Sie mich.

A. Ressourcen

A.1 Meine Präsentationen und Veröffentlichungen

A.1.1 Meine öffentlichen RE-Präsentationen

Die nachfolgende Basis-Präsentation gibt Ihnen einen ersten Einblick in das Requirements Engineering. Weitere, umfangreichere Präsentationen und Schulungsunterlagen werden nur auf Nachfrage weitergereicht.

InhaltVersionStandSeitenGrößeTyp
Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) update0.9603/20172481,3 MB pdf (pdf)
Requirements Engineering: Spezifikationen – Eine Anleitung0.5012/2016440,3 MB pdf (pdf)
Agiles Requirements Engineering – Eine Übersicht0.1005/2014840,8 MB pdf (pdf)
Stakeholdermanagement – Eine Übersicht0.1003/20151380,8 MB pdf (pdf)

A.1.2 Meine Veröffentlichungen und Vorträge zum RE

Requirements Engineering – die Entwicklungen seit 2000 und ein Blick in die Zukunft (Vortrag am 07.10.2015)

/AK-REQ-2015-Status-Quo/ Requirements Engineering & die Entwicklungen seit 2000:
Präsentation, 44 Seiten pdf

Wie kommen die Anforderungen auf die Website? Requirements Engineering für WordPress-Entwickler (Vortrag am 15.02.2017)

/WP-Meetup-RE-und WP-17/ Wie kommen die Anforderungen auf die Website? Requirements Engineering für WordPress-Entwickler: Präsentation, 22 Seiten pdf


A.2 Literatur

Die Anzahl an verfügbarer Literatur (Bücher) zum Requirements Engineering ist in den letzten Jahren gewachsen, was ein Indiz für das steigende Interesse an diesem Themengebiet ist.

  1. /Alexander02/ Ian Alexander, Richard Stevens: Writing Better Requirements, Addison-Wesley Professional, Boston, Massachusetts 2002, ISBN 978-0-321-13163-8
  2. /Alexander09/ Ian Alexander, Ljerka Beus-Dukic: Discovering Requirements: How to Specify Products and Services John Wiley, Hoboken, New Jersey 2009, ISBN 978-0-470-71240-5
  3. /BAPG15/ Project Management Institute: Business Analysis For Practitioners: A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2015, ISBN 978-1-62825-069-5
  4. /Balzert08/ Helmut Balzert: Lehrbuch der Softwaretechnik: Softwaremanagement, Spektrum Akademischer Verlag, Heidelberg 2. Auflage 2008, ISBN 978-3-8274-1161-7
  5. /Balzert09/ Helmut Balzert: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, Spektrum Akademischer Verlag, Heidelberg 3. Auflage 2009, ISBN 978-3-8274-1705-3
  6. /Balzert11/ Helmut Balzert: Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und Betrieb, Spektrum Akademischer Verlag, 3. Auflage Heidelberg 2011, ISBN 978-3-8274-1706-6
  7. /BBG09/ IIBA: A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 2009, ISBN 978-0-9811292-1-1
  8. /BBG12-d/ IIBA: Leitfaden zum Business Analysis Body of Knowledge: BABOK 2.0, Dr. Götz Schmidt, Wettenberg 2012, ISBN 978-3-921313-81-7
  9. /BBG15/ IIBA: A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 3rd Edition 2015, ISBN 978-1-927584-02-6
  10. /Beatty12/ Joy Beatty, Anthony Chen: Visual Models for Software Requirements, Microsoft Press, Redmond, Washington 2012, ISBN 978-0-7356-6772-3
  11. /Bergsmann14/ Johannes Bergsmann: Requirements Engineering für die agile Softwareentwicklung: Methoden, Techniken und Strategien, dpunkt, Heidelberg 2014, ISBN 978-3-86490-149-2
  12. /Blais11/ Stephen Blais: Business Analysis: Best Practices for Success, John Wiley, Hoboken, New Jersey 2011, ISBN 978-1-118-07600-2
  13. /Cadle14a/ James Cadle, Malcolm Eva, Keith Hindle, Debra Paul: Business Analysis BCS, The Chartered Institute for IT, London 3rd Edition 2014, ISBN 978-1-78017-277-4
  14. /Cadle14b/ James Cadle, Debra Paul, Paul Turner: Business Analysis Techniques: 99 Essential Tools for Success, BCS, The Chartered Institute for IT, London 2nd Edition 2014, ISBN 978-1-78017-273-6
  15. /Carkenord09/ Barbara A. Carkenord: Seven Steps to Mastering Business Analysis, J. Ross Publishing, Fort Lauderdale, Florida, 4th Edition 2009, ISBN 978-1-60427-007-5
  16. /Carkenord16/ Barbara A. Carkenord: PMI-PBA Exam Prep, Premier Edition, Rmc Publications, Burnsville, Minnesota, 2nd Edition 2016, ISBN 978-1-943704-01-9
  17. /Cockburn00/ Alistair Cockburn: Writing Effective Use Cases, Addison-Wesley Longman, Amsterdam 2000, ISBN 978-0-201-70225-5
  18. /Davis05/ Alan M. Davis: Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House Publishing, New York 2005, ISBN 978-0-932633-64-4
  19. /Ebert12/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, spezifizieren, analysieren und verwalten, dpunkt, Heidelberg 4. Auflage 2012, ISBN 978-3-89864-812-7
  20. /Ebert14/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 5. Auflage 2014, ISBN 978-3-86490-139-3
  21. /Gause89/ Donald C. Gause, Gerald M. Weinberg: Exploring Requirements. Quality before Design, Dorset House Publishing, New York 1989, ISBN 978-0-932633-13-2
  22. /Gause93/ Donald C. Gause, Gerald M. Weinberg: Software Requirements. Anforderungen erkennen, verstehen und erfüllen, Hanser, München 1993, ISBN 978-3-446-17113-8
  23. /Gerstbach15/ Ingrid Gerstbach, Peter Gerstbach: Basiswissen Business-Analyse: Probleme lösen, Chancen nutzen, Redline, München 2015, ISBN 978-3-86881-574-0
  24. /Gilb05/ Tom Gilb: Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage, Butterworth-Heinemann, Burlington, Massachusetts 2005, ISBN 978-0-7506-6507-0
  25. /Girvan17/ Lynda Girvan, Debra Paul: Agile and Business Analysis: Practical Guidance for IT Professionals, BCS, The Chartered Institute for IT, London 2017, ISBN 978-1-78017-322-1
  26. /Got02/ Ellen Gottesdiener: Requirements by Collaboration, Addison-Wesley Professional, Boston, Massachusetts 2002, ISBN 978-0-201-78606-4
  27. /Got05/ Ellen Gottesdiener: The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements, Goal/QPC, Salem, New Hampshire 2005, ISBN 978-1-57681-060-6
  28. /Grady06/ Jeffry O. Grady: System Requirements Analysis, Academic Press Inc., Burlington, Massachusetts 2006, ISBN 978-0-12-088514-5
  29. /Grady13/ Jeffrey O. Grady: System Requirements Analysis, Elevier Science, London 2nd Edition 2013, ISBN 978-0-12-417107-7
  30. /Grande14/ Marcus Grande: 100 Minuten für Anforderungsmanagement: Kompaktes Wissen nicht nur für Projektleiter und Entwickler, Springer Vieweg, Wiesbaden 2. Auflage 2014, ISBN 978-3-658-06434-1
  31. /Haber15/ Reinhard Haberfellner, Oliver L. de Weck, Ernst Fricke, Siegfried Vössner: Systems Engineering: Grundlagen und Anwendung, Orell Füssli, Zürich 13. Auflage 2015, ISBN 978-3-280-04068-3
  32. /Hammer13/ Ulrike Hammerschall, Gerd Beneken: Software Requirements, Pearson Studium, München 2013, ISBN 978-3-86894-151-7
  33. /Hanschke16/ Inge Hanschke, Gunnar Giesinger, Daniel Goetze: Business Analyse – einfach und effektiv, Hanser, München 2. Auflage 2016, ISBN 978-3-446-44345-7
  34. /Herrmann12/ Andrea Herrmann, Eric Knauss, Rüdiger Weißbach: Requirements Engineering und Projektmanagement, Springer, Berlin 2012, ISBN 978-3-642-29431-0
  35. /Hood05/ Colin Hood, Rupert Wiebel: Optimieren von Requirements Management & Engineering mit dem HOOD Capability Model, Springer, Berlin 2005, ISBN 978-3-540-21178-5
  36. /Hood07a/ Colin Hood, Chris Rupp, Susanne Mühlbauer, Gerhard Versteegen (Hrsg.): ix-Studie Anforderungsmanagement, Heise, Hannover 2. Auflage 2007, keine ISBN
  37. /Hood07b/ Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz: Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes, Springer, Berlin 2007, ISBN 978-3-540-47689-4
  38. /Hossen07/ Rosemary Hossenlopp, Kathleen B. Hass: Unearthing Business Requirements: Elicitation Tools and Techniques, Management Concepts, Washington, DC 2007, ISBN 978-1-56726-210-0
  39. /Hruschka14/ Peter Hruschka: Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2014, ISBN 9978-3-446-43807-1
  40. /Hull10/ Elisabeth Hull, Jeremy Dick, Kenneth Jackson: Requirements Engineering, Springer, Berlin 3rd Edition 2010, ISBN 978-1-84996-404-3
  41. /IREB15/ siehe /Pohl15a/
  42. /Jonasson12/ Hans Jonasson: Determining Project Requirements. Mastering the BABOK and the CBAP Exam, Auerbach Publications, New York 2nd Edition 2012, ISBN 978-1-4398-9651-8
  43. /Jonasson16/ Hans Jonasson: CBAP Certification and BABOK Study Guide, Taylor & Francis, London 2016, ISBN 978-1-4987-6725-5
  44. /Kotonya98/ Gerald Kotonya, Ian Sommerville: Requirements Engineering, John Wiley, Hoboken, New Jersey 1998, ISBN 978-0-471-97208-2
  45. /Kuper13/ Kupe Kupersmith, Paul Mulvey, Kate McGoey: Business Analysis For Dummies, John Wiley & Sons, Hoboken, New Jersey 2013, ISBN 978-1-118-51058-2
  46. /Larson15/ Elizabeth Larson, Richard Larson: PMI-PBA Certification Study Guide, Watermark Learning, Minneapolis, Minnesota 2015, ISBN 978-0-578-15547-0
  47. /Larson16/ Elizabeth Larson, Richard Larson: CBAP Certification Study Guide v3.0, Watermark Learning, Minneapolis, Minnesota 2016, ISBN 978-0-692-69145-8
  48. /Leffing03/ Dean Leffingwell, Don Widrig: Managing Software Requirements. A Use Case Approach, Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2003, ISBN 978-0-321-12247-6
  49. /Leffing07/ Dean Leffingwell: Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley Professional, Boston, Massachusetts 2007, ISBN 978-0-321-45819-3
  50. /Leffing10/ Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, Boston, Massachusetts 2010, ISBN 978-0-321-63584-8
  51. /Moore06/ James W. Moore: The Road Map to Software Engineering: A Standards-Based Guide, John Wiley, Hoboken, New Jersey 2006, ISBBN 978-0-471-68362-9
  52. /Niebisch13/ Thomas Niebisch: Anforderungsmanagement in sieben Tagen: Der Weg vom Wunsch zur Konzeption, Springer, Berlin 2013, ISBN 978-3-642-34856-3
  53. /Nielsen16/ Klaus Nielsen: Achieve Business Analysis Certification: The Complete Guide to PMI-PBA, CBAP and CPRE Exam Success, J. Ross Publishing, Fort Lauderdale, Florida 2016, ISBN 978-1-60427-111-9
  54. /Partsch10/ Helmuth Partsch: Requirements-Engineering systematisch: Modellbildung für softwaregestützte Systeme Springer, Berlin 2. Auflage 2010, ISBN 978-3-642-05357-3
  55. /Patton14/ Jeff Patton: User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media, Cambridge, Massachusetts 2014, ISBN 978-1-4919-0490-9
  56. /Patton15/ Jeff Patton: User Story Mapping: Nutzerbedürfnisse besser verstehen als Schlüssel für erfolgreiche Produkte, O’Reilly, Köln 2015, ISBN 978-3-95875-067-8
  57. /PMG-BA17/ Project Management Institute: The PMI Guide to Business Analysis, Project Management Institute, Philadelphia, Pennsylvania 2017, erscheint in Q4/2017, ISBN noch offen
  58. /Pohl08/ Klaus Pohl: Requirements Engineering. Grundlagen, Prinzipien, Techniken, dpunkt, Heidelberg 2. Auflage 2008, ISBN 978-3-89864-550-8
  59. /Pohl10/ Klaus Pohl: Requirements Engineering, Springer, Berlin 2010, ISBN 978-3-642-12577-5
  60. /Pohl15a/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering – Foundation Level, dpunkt, Heidelberg 4. Auflage 2015, ISBN 978-3-89864-771-7
  61. /Pohl15b/ Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam – Foundation Level – IREB compliant, Rocky Nook, Santa Barbara, California 2nd Edition 2015, ISBN 978-1-937538-77-4
  62. /REPG16/ Project Management Institute: Requirements Management: A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2016, ISBN 978-1-62825-089-3
  63. /Robertson04/ Suzanne Robertson, James Robertson: Requirements-Led Project Management. Discovering David’s Slingshot, Addison-Wesley Professional, Boston, Massachusetts 2004, ISBN 978-0-321-18062-9
  64. /Robertson06/ Suzanne Robertson, James Robertson: Mastering the Requirements Process, Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2006, ISBN 978-0-321-41949-1
  65. /Robertson12/ Suzanne Robertson, James Robertson: Mastering the Requirements Process, Addison-Wesley Professional, Boston, Massachusetts 3rd Edition 2012, ISBN 978-0-321-81574-3
  66. /Rupp09/ Chris Rupp: Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser, München 5. Auflage 2009, ISBN 978-3-446-41841-7
  67. /Rupp13/ Chris Rupp: Systemanalyse kompakt, Springer Vieweg, Berlin 3. Auflage 2013, ISBN 978-3-642-35445-8
  68. /Rupp14/ Chris Rupp: Requirements-Engineering und -Management. Aus der Praxis von klassisch bis agil, Hanser, München 6. Auflage 2014, ISBN 978-3-446-43893-4
  69. /Rupp15/ Chris Rupp (und die Sophisten): Requirements-Engineering: Die kleine RE-Fibel, Hanser, München 2015, ISBN 978-3-446-44450-8
  70. /Rupp16/ Chris Rupp (und die Sophisten): Requirements-Engineering: Die kleine RE-Fibel, Sophist, Nürnberg, 3. Auflage 2016, keine ISBN
  71. /Rüping13/ Andreas Rüping: Dokumentation in agilen Projekten: Lösungsmuster für ein bedarfsgerechtes Vorgehen, dpunkt, Heidelberg 2013, ISBN 978-3-86490-040-2
  72. /Schien01/ Bruno Schienmann: Anforderungsmanagement: Prozesse – Techniken – Werkzeuge, Addison-Wesley, München 2001, ISBN 978-3-8273-1787-2
  73. /Schmied08/ Jürgen Schmied, Paul-Roux Wentzel, Michael Gerdom: Mit CMMI Prozesse verbessern! Umsetzungsstrategien am Beispiel Requirements Engineering, dpunkt, Heidelberg 2008, ISBN 978-3-89864-538-6
  74. /Schwinn11/ Hans Schwinn: Requirements Engineering: Modellierung von Anwendungssystemen, Oldenbourg Wissenschaftsverlag, München 2011, ISBN 978-3-486-58893-4
  75. /Sommer97/ Ian Sommerville, Pete Sawyer: Requirements Engineering. A Good Practice Guide, John Wiley, Hoboken, New Jersey 1997, ISBN 978-0-471-97444-4
  76. /Unterauer14/ Markus Unterauer: Workshops im Requirements Engineering. Methoden, Checklisten und Best Practices für die Ermittlung von Anforderungen, dpunkt, Heidelberg 2014, ISBN 978-3-86490-231-4
  77. /Versteeg01/ Gerhard Versteegen, Knut Salomon, Rainer Hundold: Change Management bei Software-Projekten, Springer, Berlin 2001, ISBN 978-3-540-67809-0
  78. /Versteeg03/ Gerhard Versteegen (Hrsg.), Alexander Heßeler, Colin Hood, Christian Missling, Renate Stücka: Anforderungsmanagement, Springer, Berlin 2003, ISBN 978-3-540-00963-4
  79. /Weese17/ Susan A. Weese, Terri Wagner: CBAP / CCBA Certified Business Analysis Study Guide, John Wiley & Sons, Hoboken, New Jersey 2nd Edition 2017, ISBN 978-1-119-24883-5
  80. /Weilkins14/ Tim Weilkins: Systems Engineering mit SysML/UML: Anforderungen, Analyse, Architektur, dpunkt, Heidelberg 3. Auflage 2014, ISBN 978-3-86490-091-4
  81. /Wiegers03/ Karl E. Wiegers: Software Requirements, Microsoft Press, Redmond, Washington 2nd Edition 2003, ISBN 978-0-7356-1879-4
  82. /Wiegers05/ Karl E. Wiegers: Software-Requirements, Microsoft Press Deutschland, München 2005, ISBN 978-3-860-63594-0
  83. /Wiegers06/ Karl E. Wiegers: More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, Redmond, Washington 2006, ISBN 978-0-7356-2267-8
  84. /Wiegers13/ Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978-0-7356-7966-5
  85. /Withall07/ Stephen J. Withall: Software Requirement Patterns. Best Practices, Microsoft Press, Redmond, Washington 2007, ISBN 978-0-7356-2398-9
  86. /Young01/ Ralph R. Young: Effective Requirements Practices, Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2001, ISBN 978-0-201-70912-4
  87. /Young03/ Ralph R. Young: The Requirements Engineering Handbook, Artech House Publishers, Norwood, Massachusetts 2003, ISBN 978-1-5805-3266-2
  88. /Young06/ Ralph R. Young: Project Requirements: A Guide to Best Practices, Management Concepts, Washington D.C. 2006, ISBN 978-1-56726-169-8

A.3 Weblinks

Folgende Weblinks sind für die Business Analysis und das Requirements Engineering nützlich:

A.3.1 Fachorganisationen und -verbände

A.3.2 Allgemeine Informationen

A.3.3 Regelmäßig stattfindende Messen und Kongresse

A.3.4 Firmen, die Dienstleistungen anbieten

Hier sind nur Firmen aufgeführt, die neben ihren eigenen Dienstleistungen auch einen „neutralen Inhalt“ auf ihrer Website haben.

A.3.5 Tools

Hier werden nur wenige Tools gelistet; am Markt sind einige Dutzend vertreten.

  • /DOORS/ DOORS, Tool der Firma IBM
  • /Jama/ Jama, Tool der Firma jamasoftware
  • /objectiF/ objectiF RM, Tool der Firma microTOOL
  • /Polarion/ Polarion, Tool der Firma Siemens

Legende zu den Weblinks
/ / Verweis auf eine Website (generell)
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website