Das Requirements Engineering (RE) stellt eine eigenständige Disziplin innerhalb des Systems Engineerings oder des Software Engineerings dar. Das RE setzt sich damit auseinander, wie Anforderungen an ein (neu zu erstellendes) Produkt, eine Dienstleistung oder ein System zu entwickeln 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.
In dieser Beschreibung wird das Requirements Engineering der Business Analysis (auch Business Analyse, kurz BA) gleichgesetzt. In der Literatur werden zwar teilweise Unterscheidungen zwischen diesen Begriffen vorgenommen, die aber hier nicht betrachtet werden.
Wo kann ich Sie unterstützen?
Falls Sie Ihr Requirements Engineering professionalisieren möchten, stehe ich Ihnen ebenso zur Verfügung wie bei der unmittelbaren Umsetzung Ihres Vorhabens. Referenzen erhalten Sie auf Anfrage – erste Einblicke aber bereits hier.
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 → Vorhaben oder 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,
- → Produktmanagement,
- → 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 geworfen werden — die Inhalte und Darstellungen basieren im Wesentlichen auf meiner Übersichtspräsentation, die hier heruntergeladen werden kann:
| Inhalt | Typ |
|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 
|
1. Einleitung und Grundlagen
Im Requirements Engineering gibt es eine Reihe von grundlegenden Begriffen, die man kennen sollte, wenn man Requirements Engineering betreiben möchte. Diese werden in diesem Abschnitt vorgestellt.
1.1 Definitionen
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.
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 werden in erster Linie die Produktanforderungen beschrieben.
1.2 Die Einordnung des Requirements Engineerings
Das Requirements Engineerings kann als Teildisziplin des Systems Engineerings oder auch des Software Engineerings gesehen werden (Abbildung 1.1). Somit ist Requirements Engineering nicht auf die Entwicklung von Software beschränkt, sondern umfasst auch die Entwicklung von Systemen, die Hardware umfassen.
Abbildung 1.1: Die Einordnung des Requirements Engineerings (nach Wiegers /Wiegers13/)
Auch wenn es in Abbildung 1.1 nicht (explizit) wiedergeben ist: Auch die Entwicklung von → Dienstleistungen kann durch das Requirements Engineering unterstützt werden.
1.3 Die Unterteilung des Requirements Engineerings
Hier wird das Requirements Engineering in die Bereiche Anforderungsentwicklung (Requirements Development) und → Anforderungsverwaltung (→ Requirements Management) unterteilt, wobei diese wiederum in die vier Haupttätigkeiten (auch Hauptaktivitäten) …
- Ermitteln (Eliciting),
- Dokumentieren (Documenting),
- Validieren (Validating, früher: → Prüfen und Abstimmen) und
- Verwalten (Managing)
untergliedert werden können (Abbildung 1.2, die blau hinterlegten Nummern geben die zugehörigen Abschnitte auf dieser Seite an).
Abbildung 1.2: Die Unterteilung des Requirements Engineerings
Die vier Hauptaktivitäten des Requirements Engineerings nach → IREB sind in Tabelle 1.3 beschrieben.
Abbildung 1.3: Die vier Hauptaktivitäten nach IREB /IREB21/
1.4 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.
Abbildung 1.4: Die Anforderungsentwicklung (nach IREB /IREB-24/)
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 Anforderungen und Anforderungsdokumente werden entsprechend ausgebildete Mitarbeiter benötigt.
1.5 Einige zentrale Begriffe des Requirements Engineerings
Folgende Begriffe zum Requirements Engineering sind von zentraler Bedeutung:
- → 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 → Projektmanager / → 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)
1.6 Der Requirements Engineer
Der Requirements Engineer ist der Vermittler zwischen Auftraggeber und Auftragnehmer: Er definiert, wie Lösungen aussehen sollen / könnten.
Abbildung 1.5: Von der Idee bis zur Lösung
In Abbildung 1.5 ist bereits ein Kernproblem des Einsatzes von Requirements mit dargestellt: Ist der Requirements Engineer mehr auf Kunden oder auf Entwickler-Seite zu sehen?
1.7 Die Charakterisierung 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
- …
1.7.1 Die Klassifikation der Anforderungen
In der Business Analysis werden die Anforderungen vier → Anforderungstypen (Types of Requirements, Requirements Types) zugeordnet. Nach → IIBA und → PMI sind dies (Abbildung 1.6):
- Business Requirements (“Geschäftsanforderungen”, “Betriebliche Anforderungen” /BBG17‑d/): Hiermit werden die Anforderungen beschrieben, die aus dem Organisations- / Unternehmenskontext kommen
- Stakeholder Requirements (“Anforderungen der Stakeholder”, “Stakeholder-Anforderungen” /BBG17‑d/): Anforderungen der Stakeholder; diese Anforderungen sind eher am Problem und weniger an der Lösung orientiert
- Solution Requirements (“Lösungsanforderungen”): Anforderungen zur Beschreibung der Lösung; diese sind wiederum unterteilt in die Unterkategorien (Sub Categories)
- Functional Requirements (“Funktionale Lösungsanforderungen”)
- Non-functional Requirements (“Nicht-funktionale Lösungsanforderungen”)
- Transition Requirements (“Übergangsanforderungen”, “Überleitungsanforderungen” /BBG17‑d/): Anforderungen, um den Übergang zur neuen Lösung zu ermöglichen
Anmerkung:
Es werden im Praxisalltag eher die englischen Begriffe verwendet, die deutschen Übersetzungen sind daher “uneinheitlich”.
Abbildung 1.6: Anforderungstypen nach IIBA und PMI
Die vier Anforderungstypen stehen in einer hierarchischen Beziehung zueinander: Die Business Requirements stehen über den Stakeholder Requirements und die wiederum über den Solution Requirements (Abbildung 1.4). Die Transition Requirements dienen dazu, die Umsetzung von Stakeholder oder Solution Requirements zu ermöglichen und sind somit nicht aus den anderen Requirements ableitbar.
Die Pfeile in Abbildung 1.7 symbolisieren Verweise oder auch Ableitungen: Hierüber ist es möglich, die einzelnen Anforderungen in einen Kontext zu bringen, sie werden “traceable” (nachverfolgbar).
Abbildung 1.7: Anforderungstypen (hierarchisch) nach IIBA und PMI
Üblicherweise werden alle Lösungsanforderungen an ein Produkt oder System (grob) in die → Anforderungsarten 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 /IREB21, Ebert19/:
Abbildung 1.8: 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.
1.7.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 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.
1.7.3 Die Perspektiven von Anforderungen
Anforderungen können aus drei Sichten (Perspektiven) beschrieben werden: Die Struktur‑, die Funktions- und die Verhaltenssicht. Die drei Perspektiven hängen zusammen und sollten als Ganzes betrachtet werden.
Abbildung 1.10: Die drei Perspektiven von Anforderungen
Eine Erläuterung der drei Perspektiven ist nachfolgend dargestellt (Abbildung 1.7). Je nach Perspektive bieten sich zur Beschreibung unterschiedliche Modelle an (dritte Spalte in der Abbildung).
Abbildung 1.11: Die drei Perspektiven von Anforderungen — Erläuterung (nach IREB /IREB15/)
1.8 Die Verbände zum Requirements Engineering und zur Business Analysis
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:
- Das International Requirements Engineering Board (IREB)
- Das International Institute of Business Analysis (IIBA)
- Das Project Management Institute (PMI)
Alle drei Verbände haben jeweils (mindestens) ein Basiswerk zur Beschreibung des zum RE und zur BA gehörenden Inhalts (IREB: /IREB21/, IIBA: /BBG15/, PMI: /BAPG15/ und /PMG-BA17/) und geben jeweils Personenzertifikate heraus, die nach Bestehen einer → Prüfung erlangt werden können.
2. Der Start eines Requirements-Projekts
Der → Start eines RE-Projekts findet vor dem “klassischen” Requirements Engineering mit drei Schritten des Requirements Engineerings (Ermitteln, Dokumentieren, Validieren) statt (Abbildung 2.1).
Abbildung 2.1: Einordnung des Starts eines RE-Projekts
Der Start eines Requirements-Projekts oder ‑Vorhabens beginnt mit einigen Tätigkeiten, die immer durchgeführt werden sollten.
Dazu gehören:
- Bestimmung der → Vision und des Ziels des RE-Vorhabens
- Bestimmung des Systems und des Systemkontexts
- Bestimmung der Stakeholder
- Bestimmung von → Personas / Szenarios
- Anlegen / Ausbauen eines Glossars
- Aufbau eines übergeordneten → Use Cases
- Einsatz des → Kano-Modells
- Zusammenstellen / Berechnen der “passenden” → Ermittlungstechniken
- Beginn mit dem Ermitteln der Anforderungen
In diesem Abschnitt werden einige dieser Tätigkeiten beleuchtet. Eine ausführlichere Beschreibung zum Start eines RE-Projekts finden Sie auf dieser Website im Beitrag “→ Der Start eines Requirements-Projekts”.
2.1 Das System und der Systemkontext
Anforderungen dienen zur Beschreibung eines Systems, welches durch einen Kontext und eine Umgebung entsprechende Grenzen besitzt. Nur für das System relevante Teile müssen detailliert erfasst und beschrieben werden.
Abbildung 2.2: System und → Systemkontext
Die Begriffe haben folgende Bedeutung:
- System: Dies ist der gestalt- oder veränderbare Teil der Realität
- Systemgrenze: Die Systemgrenze trennt den gestaltbaren und veränderbaren Teil der Realität (“das System”) von den nicht veränderbaren Aspekten
- Systemkontext: Der Teil der Umgebung des Systems, der für Definition und Verständnis der Systemanforderungen relevant ist, selbst aber nicht gestalt- oder veränderbar ist, wird als Systemkontext bezeichnet
- Kontextgrenze: Die Kontextgrenze grenzt den relevanten vom irrelevanten Teil der Systemumgebung ab
- Umgebung: Für Anforderungen irrelevanter Teil der Systemumgebung
Eine ausführliche Beschreibung zum System und Systemkontext finden Sie auf dieser Website im Beitrag “→ System und Systemkontext”.
2.2 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 (“unterbewusstes 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 (“unbewusstes Wissen”)
Grafisch umgesetzt ergibt sich das → Kano-Diagramm.
Abbildung 2.3: 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:
Abbildung 2.4: Die Anforderungen im Kano-Modell
Beispiele für die drei Anforderungsarten im Kano-Modell:
Abbildung 2.5: Beispiele für Anforderungen im Kano-Modell
Eine ausführliche Beschreibung zum Kano-Modell finden Sie auf dieser Website im Beitrag “→ Das Kano-Modell”.
2.3 Das Glossar
Spätestens bei der Ermittlung der Anforderungen sollte ein → Glossar (mit)erstellt werden, welches alle (wichtigen) Begriffe des betrachteten Fachgebiets enthält.
In ein Glossar gehören:
- (Kontextspezifische) Fachbegriffe
- Abkürzungen und Akronyme
- Alltägliche Begriffe, die im gegebenen Kontext eine spezifische Bedeutung haben
- Synonyme (mehrere Worte haben eine Bedeutung); hier sollte auch festgelegt werden, dass nur ein Begriff/Wort verwendet werden soll
- Homonyme (ein Wort hat mehrere Bedeutungen)
Weitere Informationen finden Sie auf der Webseite zu den → Glossaren.
3. Das Ermitteln von Anforderungen
Bei der → Anforderungsermittlung werden die (möglichen) Anforderungen für ein zu entwickelndes 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 Vor dem Start des Ermittelns
Vor dem Start der Anforderungsermittlung muss der → Aufwand, die → Dauer und die → Qualität der Ermittlungstätigkeiten bestimmt werden. Darüber sind auch die Kosten für die Anforderungsermittlung festgelegt.
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 verwendet, sondern nur diejenigen, die sinnvoll erscheinen.
Abbildung 3.4: Die Ermittlungstechniken (nach IREB /IREB21/)
Eine Zuordnung von Ermittlungstechniken zu dem Vorwissen der Auftraggeber und Auftragnehmer liefert Ebert /Ebert19, Ebert22/ (Abbildung 3.5).
Abbildung 3.5: Zuordnung Ermittlungstechniken nach Ebert /Ebert19, Ebert22/
Die vier Quadranten können wie folgt charakterisiert werden:
- Dem Auftragnehmer sind diese Anforderungen bekannt, dem Auftraggeber nicht
- Sowohl dem Auftraggeber als auch dem Auftragnehmer sind diese Anforderungen unbekannt
- Dem Auftraggeber sind diese Anforderungen bekannt, dem Auftragnehmer nicht
- Sowohl dem Auftraggeber als auch dem Auftragnehmer sind diese Anforderungen bekannt
Die Erläuterung einiger Techniken erfolgt in der → Basis-Präsentation zum Requirements Engineering. Eine ausführliche Beschreibung zu den Ermittlungstechniken finden Sie auf dieser Website im Beitrag → Ermittlungstechniken für das Requirements Engineering. Das Ermitteln selbst wird ausführlich in dem Beitrag → Das Ermitteln von Anforderungen beschrieben.
4. Das Dokumentieren von Anforderungen
Das → Dokumentieren von Anforderungen beschäftigt sich mit zwei Aspekten:
- Zum einen mit Einzelanforderungen
- Zum anderen mit dem Zusammenstellen von (Einzel-)Anforderungen in einem Dokument
Abbildung 4.1: Aspekte des Dokumentierens
4.1 Das Dokumentieren von Einzelanforderungen
Einzelanforderungen können entweder …
- natürlichsprachlich,
- modellbasiert oder
- als Mischform beschrieben werden.
Abbildung 4.2: Die Dokumentationsformen (nach IREB /IREB21/)
In der Praxis werden alle Formen eingesetzt.
4.1.1 Die Satzschablone
→ Satzschablonen dienen der Erfassung von Einzelanforderungen: Durch Vorgaben einer formalen (syntaktischen) Struktur werden einzelne Anforderungen in vorgegebener Art und Weise in jeweils einem Satz beschrieben.
Bei Rupp /Rupp14/ wird die Satz- oder → Anforderungsschablone wie folgt definiert:
“Eine Anforderungsschablone ist ein Bauplan, der die Struktur eines einzelnen Anforderungssatzes festlegt.”
Abbildung 4.3: Die → Satzschablone
Wenn Satzschablonen konsequent und richtig eingesetzt werden, reduziert sich der Interpretationsspielraum erheblich — die Anforderungen werden eindeutiger.
4.2 Das Zusammenstellen von (Einzel-)Anforderungen in einem Dokument
Beim IREB /IREB15/ wird ein Ergebnis der Dokumentation als Anforderungsdokument oder Anforderungsspezifikation bezeichnet und folgendermaßen definiert:
“Eine Anforderungsspezifikation ist eine systematisch dargestellte Sammlung von Anforderungen (typischerweise für ein System oder eine Komponente), die vorgegebenen Kriterien genügt.”
In der Anforderungsspezifikation somit werden die ermittelten Anforderungen in eine Form gebracht, die es erlaubt, sowohl mit den Kunden / Stakeholdern als auch mit den Entwicklern ein Gesamtbild des zu erstellenden Produkts zu generieren. Hierzu können Gliederungsvorlagen für Dokumente eingesetzt werden — in der Praxis werden (im deutschsprachigen Raum) häufig verwendet:
- Das Volere-Template von Suzanne und James Robertson /VOLERE/
- Die Struktur für Software Requirements Specification (SRS) nach IEEE 830‑1998
- Die Dokumentenstruktur nach dem → V‑Modell XT /V‑Modell-XT/
Im deutschsprachigen Raum werden Anforderungsdokumente häufig auch als → Lastenheft und → Pflichtenheft bezeichnet — Eine Beschreibung dieser Begriffe finden Sie in dem Beitrag “→ Lastenheft und Pflichtenheft”.
Eine vertiefende Beschreibung des Dokumentierens von Einzelanforderungen finden Sie auf dieser Website im Beitrag “→ Das Dokumentieren von Anforderungen”.
5. Das Validieren von Anforderungen
Das Validieren (früher: 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 nochmals überprüft und priorisiert werden.
Abbildung 5.1: Die → Ziele beim Prüfen und Abstimmen von Anforderungen (nach IREB /IREB15/)
Bei Prüfen und Abstimmen stehen drei Qualitätsaspekte im Vordergrund:
- Inhalt
- Dokumentation
- Abgestimmtheit
Für die drei Qualitätsaspekte gibt es jeweils eigene Prüfkriterien, die wie eine Art Checkliste abgearbeitet werden können (Abbildung 5.2).
Abbildung 5.2: Die drei Qualitätsaspekte von Anforderungen (nach IREB /IREB21/)
Das IREB benennt vier Aspekte der → Anforderungsvalidierung (Abbildung 5.3). Diese sollten bei der Planung und Durchführung der Validierung beachtet werden.
Abbildung 5.3: Die vier Aspekte der Anforderungsvalidierung (nach IREB /IREB21/)
Als Validierungstechniken zur (inhaltlichen Prüfung) können eingesetzt werden (Abbildung 5.4):
- → Reviews
- Exploration (Prüfung durch Prototypen oder andere greifbare Artefakte)
- Probe-Entwicklung
Abbildung 5.4: Die Techniken zur Validierung von Anforderungen (modifiziert nach IREB /IREB21/)
Die “manuellen” Prüfungen werden häufig unter dem Begriff Reviews zusammengefasst.
Anmerkung: Die Überprüfung der Struktur wird als → Audit bezeichnet.
Eine vertiefende Beschreibung des Validierens von Anforderungen finden Sie auf dieser Website im Beitrag “→ Das Validieren von Anforderungen”.
6. Das Verwalten von Anforderungen
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 (Requirements Management) 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 Abbbildung 6.1 dargestellt.
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 (Impact Analysis): Sie zeigt auf, wie sich Anforderungen bei der Umsetzung auf die gesamte Lösung auswirken
- Abdeckungsanalyse (Coverage Analysis): Sie liefert ein Maß für den Projektfortschritt, da die Anzahl der erfüllten Anforderungen zu der Gesamtanzahl der Anforderungen in Relation gesetzt wird
- Nutzenanalyse (Benefit Analysis): Sie beantwortet die Frage, warum die einzelnen Anforderungen überhaupt in das Produkt aufgenommen wurden
Der zentrale Begriff der Anforderungsverwaltung ist sicherlich die → Verfolgbarkeit (→ Traceability), die von der Kundenanforderung bis zur Produkteigenschaft die einzelnen Umsetzungsschritte transparent macht. Hierzu sollten pro Anforderung zumindest folgende → Anforderungsattribute notiert werden:
- Eindeutige ID
- Name / Bezeichnung
- Zuordnung zu einem Projekt, einem Vorhaben oder einem Produkt
- Quelle
- Status
6.2 Zustände von Anforderungen
Einzelne Anforderungen haben immer einen Status: Hierüber wird der Bearbeitungszustand festgehalten.
Abbildung 6.2: Ein Zustandsmodell für Anforderungen (generell)
In der konkreten Ausgestaltung könnte ein Zustandsmodell dann folgende Ausgestaltung haben:
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 Projektmanager / 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.
Eine vertiefende Beschreibung des Verwaltens von Anforderungen finden Sie auf dieser Website im Beitrag “→ Anforderungsverwaltung — Requirements Management”.
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. Abbildung 7.1 verdeutlicht dies.
Abbildung 7.1: Vorgehensmodelle und Anforderungen (nach /Ebert22/)
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 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 /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
(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. Anmerkungen zu den Fachverbänden
Rund um die Business Analysis und das Requirements Engineering sind einige Fachverbände entstanden, die sich um die Definition und Strukturierung der Inhalte bemühen. Hier werden einige Gegenüberstellungen vorgenommen, Bewertungen jedoch nicht: Diese können aber beim Autor abgefragt werden.
8.1 Die Strukturierung der Aufgaben zum RE und zur BA
Die drei Fachverbände unterteilen die Aufgaben im Requirements Engineering und in der Business Analysis in einzelne Bereiche. Diese heißen bei …
- dem IREB Hauptaktivitäten /IREB-24, IREB21/,
- dem IIBA Knowledge Areas (Übersetzung: → Wissensgebiete) /BBG15, BBG17‑d/ und
- dem PMI Domains (eigene Übersetzung: Domänen) /BAPG15/.
Abbildung 8.1: Die Aufgabenunterteilung der drei Fachverbände zum RE und zur BA
Auf den folgenden drei Grafiken sind die Unterteilungen des REs und der BA der Fachverbände dargestellt. Die Zahlen in den grünen Kreisen geben jeweils das Buchkapitel oder den Buchabschnitt 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
- Beim IREB ist das zentrale Basiswerk zuletzt 2021, bei den beiden anderen Fachverbänden 2015 erschienen
- Die Unterteilungen sind nicht “gleich gewichtet” — Aber: Bei allen Fachverbänden steht das Ermitteln / die Ermittlung (Elicitation) von Anforderungen im Vordergrund
Das IREB benennt vier Hauptaktiväten (Abbildung 8.2), es fehlt jedoch eine vorgelagerte oder übergeordnete Planungsstufe, die festlegt, welche Werkzeuge und Methoden im konkreten Einzelprojekt verwendet werden sollen.
Abbildung 8.2: Die vier Hauptaktivitäten im RE nach IREB /IREB20/
In Abbildung 8.3 sind die Wissensgebiete des IIBA dargestellt. Generell beschäftigt sich das IIBA stark mit der Einbettung der Anforderungen in den Organisationskontext, die konkrete Umsetzung wird weniger stark adressiert.
Abbildung 8.3: Die sechs Wissensgebiete nach IIBA /BBG15/
Die fünf Domänen der BA nach PMI ähneln den sechs Wissensgebieten des IIBA sehr stark. Auch die darunterliegen Tasks (hier in Abbildung 8.4 nicht dargestellt) mit den Werkzeugen und Methoden sind ähnlich wie beim IIBA aufgebaut.
Abbildung 8.4: Die fünf Domänen in der Business Analysis nach PMI /BAPG15/
8.2 Die Zertifizierungen der Fachverbände
Die drei Fachverbände vergeben Zertifikate an Personen. Zu diesen → Zertifizierungen gibt es eine Übersicht auf dieser Website im Beitrag den “→ Zertifizierungen”.
9. Häufig gestellte Fragen und Antworten (FAQ) zum Requirements Engineering und zur Business Analysis
Einige Fragen zum Requirements Engineering und zur Business Analysis 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 RE und BA außerhalb von Softwareentwicklungsprojekten einsetzen?
A: Ja. Hier ist insbesondere das → Systems Engineering zu nennen. - F: Ist eine Schulung zum RE und / oder zur BA empfehlenswert?
A: Ja. Da das RE kein abgeschlossenes Themengebiet darstellt, ist es schwierig herauszufinden oder herauszufiltern, welche RE-Elemente in dem eigenen Kontext benötigt werden. Entsprechend sollten die Schulungen an den eigenen Kontext angepasst werden. - F: Ab wann “lohnt” sich Requirements Engineering?
A: Fragen Sie mich. - F: Welche Literatur ist empfehlenswert?
A: Fragen Sie mich. - F: Wie starte ich ein Requirements-Engineering-Projekt richtig?
A: Sie können ein Requirements-Engineering-Vorhaben oder ‑Projekt mit Einzelschritten beginnen, die auf meiner Webseite “→ Start eines Requirements-Projekts” beschrieben sind. - F: Wie führe ich (professionelles) Requirements Engineering ein?
A: Fragen Sie mich. - F: Wie bestimme ich den Reifegrad meines Requirements Engineerings?
A: Fragen Sie mich. - F: Gibt es einfache Merkregeln / Tipps für das Requirements Engineering, die unbedingt beachtet werden sollen?
A: Ja — bei unterschiedlichen Fachverbänden und Autoren gibt es Merkregeln oder Tipps, die auf meiner Webseite “→ Merkregeln für das Requirements Engineering” beschrieben sind. - F: Muss ein Requirements-Engineering-Handbuch oder Requirements-Engineering-Leitfaden in meiner Organisation / in meinem Unternehmen vorhanden sein?
A: Sollten Sie Requirements Engineering professionell betreiben wollen, so müssen die Regeln und Vorgaben schriftlich fixiert werden — hierfür bietet sich ein Requirements-Engineering-Handbuch an.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine Präsentationen und Veröffentlichungen
Zum Requirements Engineering habe ich einige → Präsentationen, Ausarbeitungen und Beiträge verfasst, von denen ein Teil hier für den privaten Gebrauch zur Verfügung gestellt werden.
A.1.1 Meine öffentlichen RE-Präsentationen
Die nachfolgende RE-Basispräsentation gibt Ihnen einen ersten Einblick in das Requirements Engineering. Zusätzlich werden hier einige weitere Präsentationen ergänzend zur Verfügung gestellt.
| Inhalt | Version | Stand | Seiten | Größe | Typ |
|---|---|---|---|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 0.96 | 03/2017 | 248 | 1,3 MB |
|
| Requirements Engineering: Spezifikationen – Eine Übersicht | 1.50 | 12/2016 | 44 | 0,3 MB |
|
| Requirements Engineering: Werkzeuge und Methoden – Eine Übersicht | 0.20 | 12/2018 | 32 | 0,4 MB |
|
| Requirements Engineering: Die Literatur(liste) | 1.40 | 06/2024 | 30 | 0,2 MB |
|
| Agilität: Agiles Requirements Engineering – Eine Übersicht | 0.10 | 05/2014 | 84 | 0,8 MB |
|
| Projektmanagement: Stakeholdermanagement – Eine Übersicht | 0.10 | 03/2015 | 138 | 0,8 MB |
|
| Agilität: Personas – Eine Übersicht | 0.20 | 06/2018 | 48 | 0,5 MB |
|
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
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
A.2 Literatur
Die Anzahl an verfügbarer Literatur (Bücher) zum Requirements Engineering und zur Business Analysis ist in den letzten Jahren gewachsen, was ein Indiz für das steigende Interesse an diesem Themengebiet ist.
- /Alexander02/ Ian Alexander, Richard Stevens: Writing Better Requirements, Addison-Wesley Professional, Boston, Massachusetts 2002, ISBN 978–0‑321–13163‑8
- /Alexander09/ Ian Alexander, Ljerka Beus-Dukic: Discovering Requirements. How to Specify Products and Services, John Wiley & Sons, Hoboken, New Jersey 2009, ISBN 978–0‑470–71240‑5
- /Balzert08/ Helmut Balzert: Lehrbuch der Softwaretechnik. Softwaremanagement, Spektrum Akademischer Verlag, Heidelberg 2. Auflage 2008, ISBN 978–3‑8274–1161‑7
- /Balzert09/ Helmut Balzert: Lehrbuch der Softwaretechnik. Basiskonzepte und Requirements Engineering, Spektrum Akademischer Verlag, Heidelberg 3. Auflage 2009, ISBN 978–3‑8274–1705‑3
- /Balzert11/ Helmut Balzert: Lehrbuch der Softwaretechnik. Entwurf, Implementierung, Installation und Betrieb, Spektrum Akademischer Verlag, 3. Auflage Heidelberg 2011, ISBN 978–3‑8274–1706‑6
- /BAPG15/ Project Management Institute: Business Analysis For Practitioners. A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2015, ISBN 978–1‑62825–069‑5
- /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
- /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
- /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
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /Beatty12/ Joy Beatty, Anthony Chen: Visual Models for Software Requirements, Microsoft Press, Redmond, Washington 2012, ISBN 978–0‑7356–6772‑3
- /Bergsmann18/ Johannes Bergsmann: Requirements Engineering für die agile Softwareentwicklung. Methoden, Techniken und Strategien, dpunkt, 2. Auflage Heidelberg 2018, ISBN 978–3‑86490–485‑1
- /Bergsmann23/ Johannes Bergsmann: Requirements Engineering für die agile Softwareentwicklung. Methoden, Techniken und Strategien, dpunkt, Heidelberg 3. Auflage 2023, ISBN 978–3‑86490–929‑0
- /Blais11/ Stephen Blais: Business Analysis. → Best Practices for Success, John Wiley & Sons, Hoboken, New Jersey 2011, ISBN 978–1‑118–07600‑2
- /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
- /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
- /Cadle20/ James Cadle, Malcolm Eva, Keith Hindle, Debra Paul: Business Analysis, BCS, The Chartered Institute for IT, London 4th Edition 2020, ISBN 978–1‑78017–510‑2
- /Cadle21/ James Cadle, Debra Paul, Jonathan Hunsley, Adrian Reed, David Beckham, Paul Turner: Business Analysis Techniques. 123 Essential Tools for Success, BCS, The Chartered Institute for IT, London 3rd Edition 2021, ISBN 978–1‑78017–569‑0
- /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
- /Carkenord16/ Barbara A. Carkenord: PMI-PBA Exam Prep, Premier Edition, RMC Publications, Burnsville, Minnesota 2nd Edition 2016, ISBN 978–1‑943704–01‑9
- /Cockburn00/ Alistair Cockburn: Writing Effective Use Cases, Addison-Wesley Longman, Amsterdam 2000, ISBN 978–0‑201–70225‑5
- /Cox23/ Alison Cox: Business Analysis For Dummies, John Wiley & Sons, Hoboken, New Jersey 2nd Edition 2023, ISBN 978–1‑119–91248‑4
- /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
- /Dick17/ Jeremy Dick, Elisabeth Hull, Kenneth Jackson: Requirements Engineering, Springer, Berlin 4th Edition 2017, ISBN 978–3‑319–61072‑6
- /Ebert14/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 5. Auflage 2014, ISBN 978–3‑86490–139‑3
- /Ebert19/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 6. Auflage 2019, ISBN 978–3‑86490–562‑9
- /Ebert22/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 7. Auflage 2022, ISBN 978–3‑86490–919‑1
- /Fitzpatrick13/ Rob Fitzpatrick: The Mom Test. How to talk to customers & learn if your business is a good idea when everyone is lying to you, Createspace Independent Publishing Platform, North Charleston, South Carolina 2013, ISBN 978–1‑4921–8074‑6
- /Fitzpatrick16/ Rob Fitzpatrick: Der Mom Test. Wie Sie Kunden richtig interviewen und herausfinden, ob Ihre Geschäftsidee gut ist – auch wenn Sie dabei jeder anlügt, Createspace Independent Publishing Platform, Leipzig 2016, ISBN 978–1‑5336–9725‑7
- /Gause89/ Donald C. Gause, Gerald M. Weinberg: Exploring Requirements. Quality before Design, Dorset House Publishing, New York 1989, ISBN 978–0‑932633–13‑2
- /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
- /Gerstbach15/ Ingrid Gerstbach, Peter Gerstbach: Basiswissen Business-Analyse. Probleme lösen, Chancen nutzen, Redline, München 2015, ISBN 978–3‑86881–574‑0
- /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
- /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
- /Girvan24/ Linda Girvan, Debra Paul: Agile and Business Analysis. Practical guidance for IT professionals, BCS, The Chartered Institute for IT, London 2nd Edition 2024, ISBN 978–1‑78017–617‑8
- /Got02/ Ellen Gottesdiener: Requirements by Collaboration, Addison-Wesley Professional, Boston, Massachusetts 2002, ISBN 978–0‑201–78606‑4
- /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
- /Grady06/ Jeffry O. Grady: System Requirements Analysis, Academic Press, Burlington, Massachusetts 2006, ISBN 978–0‑12–088514‑5
- /Grady13/ Jeffrey O. Grady: System Requirements Analysis, Elevier Science, London 2nd Edition 2013, ISBN 978–0‑12–417107‑7
- /Grady16/ Jeffrey O. Grady: System Verification. Proving the Design Solution Satisfies the Requirements, Academic Press, Burlington, Massachusetts 2nd Edition 2016, ISBN 978–0‑12–804221‑2
- /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
- /Haberfellner18/ Reinhard Haberfellner, Olivier L. de Weck, Ernst Fricke, Siegfried Vössner: Systems Engineering. Grundlagen und Anwendung, Orell Füssli, Zürich 14. Auflage 2018, ISBN 978–3‑280–04179‑6
- /Haberfellner19/ Reinhard Haberfellner, Olivier L. de Weck, Ernst Fricke, Siegfried Vössner: Systems Engineering. Fundamentals and Applications, Springer International Publishing, Basel 2019, ISBN 978–3‑030–13430‑3
- /Hammer13/ Ulrike Hammerschall, Gerd Beneken: Software Requirements, Pearson Studium, München 2013, ISBN 978–3‑86894–151‑7
- /Hanschke16/ Inge Hanschke, Gunnar Giesinger, Daniel Goetze: Business Analyse – einfach und → effektiv. Geschäftsanforderungen verstehen und in IT-Lösungen umsetzen, Hanser, München 2. Auflage 2016, ISBN 978–3‑446–44345‑7
- /Hanschke24/ Inge Hanschke, Daniel Goetze: Business Analyse – einfach und effektiv. Geschäftsanforderungen verstehen und in IT-Lösungen umsetzen, Hanser, München 3. Auflage 2024, ISBN 978–3‑446–47396‑6
- /Herrmann12/ Andrea Herrmann, Eric Knauss, Rüdiger Weißbach: Requirements Engineering und Projektmanagement, Springer, Berlin 2012, ISBN 978–3‑642–29431‑0
- /Herrmann22/ Andrea Herrmann: Grundlagen der Anforderungsanalyse. Standardkonformes Requirements Engineering, Springer Fachmedien, Wiesbaden 2022, ISBN 978–3‑658–35459‑6
- /Hood05/ Colin Hood, Rupert Wiebel: Optimieren von Requirements Management & Engineering mit dem HOOD Capability Model, Springer, Berlin 2005, ISBN 978–3‑540–21178‑5
- /Hood07a/ Colin Hood, Chris Rupp, Susanne Mühlbauer, Gerhard Versteegen: ix-Studie Anforderungsmanagement, Heise, Hannover 2. Auflage 2007, keine ISBN
- /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
- /Hossenlopp07/ Rosemary Hossenlopp, Kathleen B. Hass: Unearthing Business Requirements. Elicitation Tools and Techniques, Management Concepts, Washington D.C. 2007, ISBN 978–1‑56726–210‑0
- /Hofer21/ Stefan Hofer, Henning Schwentner: Domain Storytelling. A Collaborative, Visual, and Agile Way to Build Domain-Driven Software, Addison-Wesley Professional, Boston, Massachusetts 2021, ISBN 978–0‑13–745891‑2
- /Hofer23/ Stefan Hofer, Henning Schwentner: Domain Storytelling. Gemeinschaftlich, visuell und agil zu fachlich wertvoller Software, dpunkt, Heidelberg 2023, ISBN 978–3‑86490–958‑0
- /Hruschka14/ Peter Hruschka: → Business Analysis und Requirements Engineering. Prozesse und Produkte nachhaltig verbessern, Hanser, München 2014, ISBN 9978–3‑446–43807‑1
- /Hruschka19/ Peter Hruschka: Business Analysis und Requirements Engineering. Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
- /Hruschka23/ Peter Hruschka: Business Analysis und Requirements Engineering. Prozesse und Produkte nachhaltig verbessern, Hanser, München 3. Auflage 2023, ISBN 978–3‑446–47692‑9
- /Hull10/ Elisabeth Hull, Jeremy Dick, Kenneth Jackson: Requirements Engineering, Springer, Berlin 3rd Edition 2010, ISBN 978–1‑84996–404‑3
- /IREB15/ siehe /Pohl15a/
- /IREB21/ siehe /Pohl21/
- /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
- /Jonasson16/ Hans Jonasson: CBAP Certification and BABOK Study Guide, Taylor & Francis, London 2016, ISBN 978–1‑4987–6725‑5
- /Jonasson19/ Hans Jonasson: Determining Project Requirements. Mastering the BABOK and the CBAP Exam, CRC Press, Boca Raton, Florida 2nd Edition 2019, ISBN 978–1‑4987–6725‑5
- /Kotonya98/ Gerald Kotonya, Ian Sommerville: Requirements Engineering. Processes and Techniques, John Wiley & Sons, Hoboken, New Jersey 1998, ISBN 978–0‑471–97208‑2
- /Krallmann17/ Achim Krallmann, Diana Dockter, Alexander Ritter: Modellbasiertes Requirements Engineering. Von der Anforderung zum ausführbaren → Testfall, entwickler.press, Frankfurt 2017, ISBN 978–3‑86802–805‑8
- /Kupersmith13/ Kupe Kupersmith, Paul Mulvey, Kate McGoey: Business Analysis For Dummies, John Wiley & Sons, Hoboken, New Jersey 2013, ISBN 978–1‑118–51058‑2
- /Larson15/ Elizabeth Larson, Richard Larson: PMI-PBA Certification Study Guide, Watermark Learning, Minneapolis, Minnesota 2015, ISBN 978–0‑578–15547‑0
- /Larson16/ Elizabeth Larson, Richard Larson: CBAP Certification Study Guide v3.0, Watermark Learning, Minneapolis, Minnesota 2016, ISBN 978–0‑692–69145‑8
- /Lauenroth16/ Kim Lauenroth, Fabian Schreiber, Felix Schreiber: Maschinen- und Anlagenbau im digitalen Zeitalter. Requirements Engineering als systematische Gestaltungskompetenz für die Fertigungsindustrie, VDE Verlag, Berlin 2016, ISBN 978–3‑8007–4154‑0
- /Leffingwell03/ 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
- /Leffingwell07/ Dean Leffingwell: Scaling Software Agility. Best Practices for Large Enterprises, Addison-Wesley Professional, Boston, Massachusetts 2007, ISBN 978–0‑321–45819‑3
- /Leffingwell10/ 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
- /Lovelock19/ Christina Lovelock, Debra Paul: Delivering Business Analysis. The BA Service Handbook, BCS, The Chartered Institute for IT, London 2019, ISBN 978–1‑78017–468‑6
- /Moore06/ James W. Moore: The Road Map to Software Engineering. A Standards-Based Guide, John Wiley & Sons, Hoboken, New Jersey 2006, ISBBN 978–0‑471–68362‑9
- /Naumann18/ Axel-Bruno Naumann: Business-Analyse. Systematisches Anforderungsmanagement für nutzerorientierte Lösungen, Dr. Götz Schmidt, Wettenberg 2018, ISBN 978–3‑945997–11‑6
- /Niebisch13/ Thomas Niebisch: Anforderungsmanagement in sieben Tagen. Der Weg vom Wunsch zur Konzeption, Springer, Berlin 2013, ISBN 978–3‑642–34856‑3
- /Niebisch24/ Thomas Niebisch, Jens Kawelke: Anforderungsmanagement in sieben Tagen. Requirements Engineering im Zeitalter der KI, Springer, Berlin 2. Auflage 2024, ISBN 978–3‑662–68870‑0
- /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
- /Partsch10/ Helmuth Partsch: Requirements-Engineering systematisch. Modellbildung für softwaregestützte Systeme Springer, Berlin 2. Auflage 2010, ISBN 978–3‑642–05357‑3
- /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
- /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
- /PMG-BA17/ Project Management Institute: The PMI Guide to Business Analysis, Project Management Institute, Philadelphia, Pennsylvania 2017, ISBN 978–1‑62825–198‑2
- /PMG-BA23/ Project Management Institute: Business Analysis for Practitioners. A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2nd Edition 2023, ISBN 978–1‑62825–808‑0
- /Pohl08/ Klaus Pohl: Requirements Engineering. Grundlagen, Prinzipien, Techniken, dpunkt, Heidelberg 2. Auflage 2008, ISBN 978–3‑89864–550‑8
- /Pohl10/ Klaus Pohl: Requirements Engineering. Fundamentals, Principles, and Techniques, Springer, Berlin 2010, ISBN 978–3‑642–12577‑5
- /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
- /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
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering. Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /REPG16/ Project Management Institute: Requirements Management. A Practice Guide, Project Management Institute, Philadelphia, Pennsylvania 2016, ISBN 978–1‑62825–089‑3
- /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
- /Robertson06/ Suzanne Robertson, James Robertson: Mastering the Requirements Process, Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2006, ISBN 978–0‑321–41949‑1
- /Robertson12/ Suzanne Robertson, James Robertson: Mastering the Requirements Process, Addison-Wesley Professional, Boston, Massachusetts 3rd Edition 2012, ISBN 978–0‑321–81574‑3
- /Robertson18/ Suzanne Robertson, James Robertson: Business Analysis Agility. Solve the Real Problem, Deliver Real Value, Addison-Wesley Professional, Boston, Massachusetts 2018, ISBN 978–0‑13–484706‑1
- /Rupp12/ Chris Rupp, Stefan Queins: → UML 2 glasklar. Praxiswissen für die UML-Modellierung, Hanser, München 4. Auflage 2012, ISBN 978–3‑446–43057‑0
- /Rupp13/ Chris Rupp: Systemanalyse kompakt, Springer Vieweg, Berlin 3. Auflage 2013, ISBN 978–3‑642–35445‑8
- /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
- /Rupp15/ Chris Rupp (und die Sophisten): Requirements-Engineering. Die kleine RE-Fibel, Hanser, München 2015, ISBN 978–3‑446–44450‑8
- /Rupp16/ Chris Rupp (und die Sophisten): Requirements-Engineering. Die kleine RE-Fibel, Sophist, Nürnberg, 3. Auflage 2016, keine ISBN
- /Rupp20/ Chris Rupp: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, Hanser, München 7. Auflage 2020, ISBN 978–3‑446–45587‑0
- /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
- /Schienmann01/ Bruno Schienmann: Anforderungsmanagement. Prozesse – Techniken – Werkzeuge, Addison-Wesley, München 2001, ISBN 978–3‑8273–1787‑2
- /Schmidt14/ Götz Schmidt: Organisation und Business Analysis – Methoden und Techniken, Dr. Götz Schmidt, Wettenberg 15. Auflage 2014, ISBN 978–3‑921313–93‑0
- /Schmidt20/ Götz Schmidt: Organisation und Business Analysis – Methoden und Techniken, Dr. Götz Schmidt, Wettenberg 16. Auflage 2020, ISBN 978–3‑945997–17‑8
- /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
- /Schwinn11/ Hans Schwinn: Requirements Engineering. Modellierung von Anwendungssystemen, Oldenbourg Wissenschaftsverlag, München 2011, ISBN 978–3‑486–58893‑4
- /Sommerville97/ Ian Sommerville, Pete Sawyer: Requirements Engineering. A → Good Practice Guide, John Wiley & Sons, Hoboken, New Jersey 1997, ISBN 978–0‑471–97444‑4
- /Tremp18a/ Hansruedi Tremp: Lehrbuch Requirements Engineering Teil 1. Agiler und klassischer Werkzeugbaukasten zur Planung, Ermittlung und Dokumentation von Anforderungen, Books on Demand, Norderstedt, 3. Auflage 2018, ISBN 978–3‑7448–2055‑4
- /Tremp18b/ Hansruedi Tremp: Lehrbuch Requirements Engineering Teil 2. Agiler und klassischer Werkzeugbaukasten zur Verwaltung, Objektorientierten Analyse und Qualitätssicherung von Anforderungen, Books on Demand, Norderstedt 2018, ISBN 978–3‑7460–6357‑7
- /Tremp19/ Hansruedi Tremp: Lehrbuch Requirements Engineering. Agiler und klassischer Werkzeugbaukasten zur Planung, Ermittlung, Analyse, Modellierung, Dokumentation und Qualitätssicherung von Anforderungen, Books on Demand, Norderstedt 2019, ISBN 978–3‑7392–2783‑2
- /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
- /Unterauer19/ Markus Unterauer: Workshops im Requirements Engineering. Methoden, Checklisten und Best Practices für die Ermittlung von Anforderungen, dpunkt, Heidelberg 2. Auflage 2019, ISBN 978–3‑86490–695‑4
- /Versteegen03/ Gerhard Versteegen, Alexander Heßeler, Colin Hood, Christian Missling, Renate Stücka: Anforderungsmanagement, Springer, Berlin 2003, ISBN 978–3‑540–00963‑4
- /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
- /Weilkins14/ Tim Weilkins: Systems Engineering mit SysML/UML. Anforderungen, Analyse, Architektur, dpunkt, Heidelberg 3. Auflage 2014, ISBN 978–3‑86490–091‑4
- /Wiegers03/ Karl E. Wiegers: Software Requirements, Microsoft Press, Redmond, Washington 2nd Edition 2003, ISBN 978–0‑7356–1879‑4
- /Wiegers05/ Karl E. Wiegers: Software-Requirements, Microsoft Press Deutschland, München 2005, ISBN 978–3‑860–63594‑0
- /Wiegers06/ Karl E. Wiegers: More About Software Requirements. Thorny Issues and Practical Advice, Microsoft Press, Redmond, Washington 2006, ISBN 978–0‑7356–2267‑8
- /Wiegers13/ Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978–0‑7356–7966‑5
- /Wiegers21/ Karl Wiegers: Software Development Pearls. Lessons from Fifty Years of Software Experience, Addison-Wesley Professional, Boston, Massachusetts 2021, ISBN 978–0‑13–748777‑6
- /Wiegers23/ Karl Wiegers, Candase Hokanson: Software Requirements Essentials. Core Practices for Successful Business Analysis, Addison-Wesley Professional, Boston, Massachusetts 2023, ISBN 978–0‑13–819028‑6
- /Williamson17/ Brian Williamson: PMI-PBA Exam Practice Test and Study Guide, CRC Press, Boca Raton, Florida 2017, ISBN 978–1‑138–05447‑9
- /Williamson23/ Brian Williamson: PMI-PBA Exam Practice Test and Study Guide, Auerbach, Boca Raton, Florida 2023, ISBN 978–1‑032–47655‑1
- /Winter19/ Helen Winter: The Business Analysis Handbook, Techniques and Questions to Deliver Better Business Outcomes, Kogan Page, London 2019, ISBN 978–0‑7494–9706‑4
- /Winter23/ Helen Winter: The Business Analysis Handbook. Techniques and Questions to Deliver Better Business Outcomes, Kogan Page, London 2nd Edition 2023, ISBN 978–1‑3986–1014‑9
- /Winteroll21/ Marcus Winteroll: Requirements Engineering für Dummies, Wiley-VCH, Weinheim 2021, ISBN 978–3‑527–71635‑7
- /Withall07/ Stephen J. Withall: Software Requirement Patterns. Best Practices, Microsoft Press, Redmond, Washington 2007, ISBN 978–0‑7356–2398‑9
- /Young01/ Ralph R. Young: Effective Requirements Practices, Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2001, ISBN 978–0‑201–70912‑4
- /Young03/ Ralph R. Young: The Requirements Engineering Handbook, Artech House Publishers, Norwood, Massachusetts 2003, ISBN 978–1‑5805–3266‑2
- /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
Nachfolgend aufgeführte Weblinks sind für das Requirements Engineering und die Business Analysis nützlich.
A.3.1 Fachorganisationen und ‑verbände
- /IREB/ International Requirements Board (IREB), deutsch und englisch
- /IREB-24/, /#IREB-24/, /#IREB-CPRE-FL-24/ IREB – International Requirements Engineering Board: Lehrplan / Syllabus zum CPRE-FL, Version 3.2.0 vom Februar 2024 (deutsch, pdf-Datei, 51 Seiten)
- /#IREB-CPRE-FL-Handbuch-24/ IREB – International Requirements Engineering Board: Handbuch für das CPRE Foundation Level nach dem IREB-Standard, Version 1.2.0 vom Mai 2024 (deutsch, pdf-Datei, 174 Seiten)
- /IIBA/ International Institute of Business Analysis (IIBA), German Chapter, deutsch und englisch
- /PMI-PBA/ Project Management Institute (PMI), Seite zum Zertifikat PMI-PBA, englisch
- /GI-FG-RE/ Fachgruppe Requirements der Gesellschaft für Informatik (2.1.6)
- /AK-REQ/ Arbeitskreis Requirements der Gesellschaft für Informatik, Regionalgruppe München
- /INCOSE/ International Council of Systems Engineering (INCOSE), englisch
A.3.2 Allgemeine Informationen
- /BA-Podcasts/ Podcasts bei Gerstbach Business Analyse, Österreich
- /BA-Times/ BA Times
- /Easy-RE/ Requirements Engineering – Der Frei-Tags-Blog. Autor: Ralf Baumann
- /Modern-Analyst/ Modern Analyst
- /Process-Impact/ Process Impact – die Website von Karl E. Wiegers /Wiegers03, Wiegers13/
- /RE-Buch/ RE-Buch: die Website von Klaus Pohl zu seinem RE-Buch /Pohl08/
- /ReqIF/ ReqIF – Requirements Interchange Format; universelles Austauschformat für Requirements; entwickelt / getragen von der HIS (Hersteller Initiative Software der deutschen Automobilhersteller), inzwischen OMG-Standard
- /SEBoK/ Guide to the Systems Engineering Body of Knowledge (SEBoK)
- /#Sophist-Wissen-For-Free/ Fa. Sophist: Webseite mit einigen Broschüren und Postern rund um das RE
- /SwissQ/ Studien der SwissQ über “Software Development Trends” (Agile, Requirements,Testing)
- /V‑Modell-XT/ Das V‑Modell XT/VOLERE/ Das Volere-Template (von Robertson), vgl. /Robertson06, Robertson12/
- /#Wiki-Anforderungsmanagement/ Anforderungsmanagement / Requirements Management in der deutschen Wikipedia
- /#Wiki-BA/ Business Analyse in der deutschen Wikipedia
- /#Wiki-Kategorie-Anforderungsmanagement/ Kategorie Anforderungsmanagement in der deutschen Wikipedia
A.3.3 Regelmäßig stattfindende Messen und Kongresse
- /BBC/ Building Business Capability, USA
- /Berliner-RE/ Berliner Requirements Engineering Symposium, Berlin
- /RE-Conf/ Requirements Conference, München, Veranstalter: Hood GmbH, München
- /RE-Days/ Sophist Days (früher: Requirements Days), Nürnberg, Veranstalter: Sophist GmbH, Nürnberg
- /RE-Int-Conf/ Requirements Conference, jährliche, an wechselnden Orten weltweite Wissenschaftskonferenz/RE-Int-Work-Conf/ International Working Conference on Requirements Engineering (REFSQ)
- /BA-Camp/ BA Camp Österreich, Wien, Unkonferenz zur Business Analyse, Veranstalter: Gerstbach Business Analyse GmbH, Weidling (bei Wien)
- /Modern-RE/ Modern RE, Konferenz Requirements Engineering (in Berlin), Veranstalter: HLMC Events GmbH, Oberhaching (bei München)
- /European-BA-Day/ European Business Analysis Day, Konferenz zur Business Analyse in englischer Sprache in Frankfurt, Veranstalter: masVenta Business GmbH, Alsdorf (bei Aachen)
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.
- /Hood/ Hood GmbH, München
- /Sophist/ Sophist GmbH, Nürnberg
- /SWPM/ Software Process Management, Stuttgart
- /System-Guild/ The System Guild
A.3.5 RE-Tools
Hier werden nur wenige RE-Tools gelistet; am Markt sind einige Dutzend vertreten — eine ausführliche → Liste findet sich auf der Website Makingofsoftware.
- /DOORS/ DOORS, Tool der Firma IBM
- /Windchill/ Windchill RV&S, Tool der Firma PTC
- /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 (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 24.05.2021 © Peterjohann Consulting, 2005–2024
