Anforderungsermittlung (requirement elicitation)

tl/dr; (ca. 11 min Lesezeit): Welche Techniken gibt es, um Anforderungen zu ermitteln, dokumentieren, gliedern, validieren und messbar zu machen? Welche Kriterien werden an gute fachgerechte und überprüfbare Anforderungen angelegt?

Dieser Artikel ist Bestandteil einer mehrteiligen Reihe zu Requirements Engineering:

• Grundlagen Anforderungsanalyse: Wozu dient Anforderungsanalyse und welche Anforderungsarten und Qualitätsmerkmale gibt es?

• (dieser Artikel) Haupttätigkeit Ermittlung: Woher kommen Anforderungen und mit welchen Techniken ermittle ich sie systematisch?

• Haupttätigkeit Dokumentation: Auf welche Arten können Anforderungen dokumentiert werden?

• Haupttätigkeiten Validierung und Verwaltung: Wie kann die Qualität der Anforderungen überprüft werden, wie priorisiere ich sie, und wie verwalte ich sie im Projektverlauf?

Haupttätigkeit 1: Anforderungsermittlung (requirements elicitation)

Woher kommen die Anforderungen an das System, mit welchen Techniken kann ich Anforderungen erheben und ermitteln? Durch systematisches Vorgehen können Anforderungen gewonnen, detailliert und verfeinert werden. Auch Konflikte und Abhängigkeiten zwischen Anforderungen können so früh entdeckt werden.

Dabei wird bei größeren Projekten in einem Dreischritt vorgegangen:

• Analyse von Umfeld und Systemkontext

• Analyse der Stakeholder

• Analyse der Anforderungen

Diese Aktivitäten folgen einander, jedoch ergeben sich häufig Rücksprünge, in der Phase des Anforderungsmanagements behandelt werden müssen: neue Anforderungen bringen einen neuen Stakeholder zu Tage, Systemgrenzen werden verschoben usw. Die wesentlichen Aktiviäten sind in folgendem Aktivitätsdiagramm zusammengefasst:

Projektumfeld und Systemkontext

Projekte finden nicht im luftleeren Raum statt, die zu schaffenden Systeme sollen mit ihrem Umfeld interagieren oder vom Umfeld genutzt werden. Daher gilt es zunächst, das Umfeld zu analysieren, um herauszufinden, von welchen Seiten Anforderungen an ein System gestellt werden können.

Je nach Projektumfeld und Stakeholder sollten dabei möglichst mehrere Techniken und unterschiedliche Gruppen einbezogen werden.

Umfeldanalyse

Ein systematischer Weg, das Umfeld zu analysieren, ist das Befüllen eines Umfeldportfolios mit sachlichen und sozialen Umfeldfaktoren sowie nach Faktoren innerhalb des Projekts (direkt/intern) und außerhalb des Projekts (mittelbar/extern).¹

Bei den sachlichen und sozialen Faktoren lohnt ein Blick auf die Randbedingungen - häufig finden sich zu jeder Rubrik Umfeldfaktoren. Zum Teil sind die Umfeldfaktoren unmittelbar Stakeholder für das Projekt, zum Teil leiten sich Stakeholder aus Umfeldfaktoren ab. Aber was sind eigentlich Stakeholder?

Systemkontextabgrenzung

Mit der Umfeldanalyse sollte in weiten Teilen die Schnittstellen unseres Systems festgelegt sein. Wichtig ist es im nächsten Schritt, sich zu verdeutlichen, welche Faktoren Bestandteil des Systems selbst sind, welche im Systemkontext liegen (also im für das Projekt relevanten Teil des Umfelds) und welche für das Projekt irrelevant sind.

Sämtliche Anforderungen, die das System nach Abschluss des Projekts erfüllen soll, befinden sich innerhalb der Systemgrenze. Die betrachtete Umgebung wird nach außen hin durch die Kontextgrenze abgegrenzt. Sie legt fest welcher Teil der Umwelt für das Projekt irrelevant ist. Innerhalb des Systemkontexts befinden sich die Stakeholder, interagierende Systeme, Randbedingungen, sowie (Geschäfts-)Prozesse, die Einfluss auf das System haben. Diese interagieren über definierte Schnittstellen über die Systemgrenze mit dem System selbst.

Durch fehlende Informationen und Erfahrungen, neue Erkenntnisse oder sich verändernde Bedingungen können sich an den Rändern von System- und Kontextgrenze Grauzonen befinden. Zudem verschieben sich die Grenzen Projektverlauf: Einige Anforderungen, die zunächst eingeplant wurden, können vielleicht nicht umgesetzt werden (andere werden zusätzlich umgesetzt). Das verschiebt die Systemgrenze. Oft wird auch erst im Projektverlauf klar, welche Randbedingung und welche Stakeholder tatsächlich für das Projekt relevant sind. Hierdurch kann sich die Kontextgrenze verschieben.

Das Verständnis des Kontexts ist so wichtig, dass das IREB das 4. Prinzip des Requirement-Engineerings benannt hat:

Prinzip 4: Kontext - Systeme können nicht isoliert betrachtet werden.

Stakeholdermanagement

Wer sind Stakeholder? Das IREB-Glossar definiert das so:²

A person or organization who influences a system’s requirements or who is impacted by that system. Note: Influence can also be indirect. For example, some stakeholders may have to follow instructions issued by their managers or organizations.

Stakeholder stellen auf der einen Seite Anforderungen an das System, auf der anderen Seite haben Sie auch Erwartungen oder Befürchtungen zum Projekt. Sie verfolgen eigene Ziele, für den Projekterfolg ist daher wichtig, dass dem Umgang mit Stakeholdern einem eigenen Management-Kreis (Plan-Do-Arc-Check) zugeteilt wird. Schön dargestellt ist dies z.B. im Lehrbuch zu “Projektmanagement (IPMA)” von Dittmann/Dirbanis, deren Systematik ich hier übernehme:

Im ersten Schritt müssen die Stakeholder identifiziert werden. Stakeholder finden sich über über die Umfeldanalyse (siehe oben), Checklisten, Organigramme, Geschäftsprozessdokumentationen, Stakeholderbefragung zu weiteren Stakeholdern.

Im zweiten Schritt werden die Befürchtungen und Erwartungen der Stakeholder an das System zusammengetragen. Hieraus lassen sich später Ziele der Stakeholder ableiten.

Im dritten Schritt werden die Stakeholder kategorisiert nach Macht/Einfluss und Konfliktpotenzial. Das wird zunächst Tabellarisch zusammengetragen:

Leichter auswertbar ist diese Tabelle, wenn wir Macht/Einfluss und Konfliktpotenzial in drei Gruppen (viel/mittel/wenig oder 3/2/1) aufteilen und in Form einer Stakeholdermatrix auftragen:

Je nach Anordnung im Portfolio sollte in der Kommunikation mit den Stakeholdern eine angepasste Strategie angewendet werden. Hierzu dient der vierte Schritt: die Maßnahmenplanung.

Besonderes Augenmerk liegt dabei auf Stakeholder mit viel Einfluss und hohem Konfliktpotenzial. Sie können ein Projekt tropedieren - Ziel muss es sein, das Konflikpotenzial dieser Stakeholdergruppe zu minimieren. Gute Anhaltspunkte für Maßnahmen des Stakeholdermanamgents finden sich z.B. in “Weniger schlecht Projekte managen” (siehe Quellen unten).

Und im fünften Schritt wird die Wirksamkeit der Maßnahmenplanung reflektiert - wie in allen Managementprozessen darf auch beim Stakeholdermanagement die Evaluierungsphase nicht fehlen. Waren die getroffenen Maßnahmen zur Einbindung / Eindämmung der Stakeholder erfolgreich? War die Kommunikation in Art, Qualität und Quantität zielführend? Welche Korrekturen am Stakeholderportfolio und der Stakeholdertabelle müssen umgesetzt werden?

Das zweite Prinzip des Requirement Engineering nach dem IREB sind Stakeholder: Im Requirement Engineering geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen.

Anforderungsermittlung

Mit der kategorisierten Liste an Stakeholdern kann es nun zur eigentlichen Hauptaufgabe kommen: die Anforderungen ermitteln.

Wir erhalten die Anforderungen von Stakeholdern, aus Dokumenten oder von Systemen. Hierbei helfen eine Reihe von Techniken:

• Befragungstechniken

  • Interview: Ein offenes Gespräch ohne festgelegten geschlossenen Fragenkatalog mit unterschiedlichen Stakeholdern

  • Umfrage (zuvor definierte Fragen) mit unterschiedlichen Stakeholdern

• Kreativtechniken für Workshop / Meeting / Brainstorming mit Stakeholdern

  • Perspektivwechsel

  • Analogietechniken: anhand analoger/ähnliche Situationen Anforderungen ableiten

  • Vorstellung von Prototypen

  • Storytelling: Emotionalisierung

  • Design Thinking

  • Storyboard: visuelle Vorlagen zum Entwurf von Abläufen (Drehbuch)

  • Personas, um einzelne Stakeholdergruppen im Blick zu haben (siehe auch Perspektivwechseltechnik)

• Workshop / Meeting / Brainstorming / Rollenspiele mit

  • Entwicklerteam

  • Mitarbeitern der Fachdomäne

  • anderen Stakeholdern

• Analyse der bestehenden Geschäftsprozesse über:

  • Anwender-Beobachtung

  • Analyse der Dokumentation von Geschäftsprozessen (z.B. Dokumente aus dem Qualitätsmanagement beteiligter Unternehmen, EPK, Flussdiagramme)

  • Analyse bestehnder Altsysteme

• Marktanalyse:

  • Gibt es bereits Konkurrenzprodukte? Dann können diese direkt analysiert werden

  • In welchen Bereichen gibt es vergleichbare / ähnliche Geschäftsprozesse, die analysiert werden können?

• Auswertung bestehnder Dokumente, z.B.

  • Normen:

    • Usability (ISO 9231 -11): Erfahrungen während der Nutzung
    • User Experience (ISO 9231 -210): Erfahrungen vor, während und nach der Nutzung

  • Gesetze

Wichtig ist bei der Anforderungsermittlung insbesondere, dass der Blick aufs Ganze erweitert wurde:

• Wer sind die Stakeholder (also diejenigen, die ein Interesse an dem System haben oder von diesem betroffen sind)? Wer ist in die Geschäftsprozesse eingebunden: wer sind die Auftraggeber, Kunden, Anwender, Mitarbeiter der Fachdomäne, Kontrollorganisationen, Verantwortliche, Ausführende usw. ?

• Welche Ziele verfolgen diese Stakeholder mit dem System? In welche Szenarien nutzen Sie das System? Welche Anforderungen ergeben sich daraus?

• Haben alle Projektbeteiligten ein gemeinsames Verständnis des Systems, haben sie eine gemeinsame Sprache / ein einheitliches Vokabular und meinen alle mit jedem Begriff das gleiche?

• Welche konkurrierenden / widersprüchlichen Anforderungen gibt es?

• Wurde das System im Gesamtkontext mit den umgebenden anderen Systemen betrachtet?

• Welche Randbedingungen werden angenommen (muss zusätzlich erfasst werden!)? Randbedingungen können z.B. technischer, rechtlicher, kultureller, organisatorischer, ökologischer oder physikalischer Natur sein (keine abschließende Liste!).

• Welche realistischen Änderungen der Randbedingungen müssen berücksichtigt werden?

Wie geht es weiter?

Die Anforderungen liegen auf dem Tisch. Im folgenden Blogpost wird es darum gehen, …

… die Anforderungen zu dokumentieren (requirement documentation)

Leitfragen

• Welche Möglichkeiten der Anforderungsermittlung gibt es? (“Woher kommen die Anforderungen?”)

• Welche Stakeholder können Anforderungen an das Projekt stellen?

Weitere Literatur zu Requirement-Engineering

• Das deutschsprachige Handbuch des IREB (Martin Glinz, Hans van Loenhoud, Stefan Staal, Stan Bühne: Handbuch für das CPRE Foundation Level nach dem IREB-Standard) findet sich hier als PDF

• Das Grundlagenbuch (auch zur Zertifizierung) für Anforderungsanalyse ist: Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering, dPunkt Verlag Heidelberg, ISBN 978-3-86490-814-9

• Weitere Unterlagen des International Requirement Engineering Boards zur Zertifizierung als “Certified Professional for Requirements Engineering Foundation Level”: https://www.ireb.org/de/cpre/foundation/, insbesondere Lehrplan und Glossar

• Karen Dittmann / Konstantin Dirbanis: Projektmanagement (IPMA) - Lehrbuch für Level D und Basiszertifikat (GPM), Haufe Verlag Freiburg, 1. Auflage 2020 ISBN 978-3-648-14736-8

• Anne Schüßler / Peter Schüßler: Weniger schlecht Projekte managen, O’Reilly / dPunkt Verlag Heidelberg, 1. Auflage 2020 ISBN 978-3-96009-14-4

Quellen und offene Ressourcen (OER)

Die Ursprungstexte (als Markdown), Grafiken und zugrunde liegende Diagrammquelltexte finden sich (soweit möglich in weiterbearbeitbarer Form) in folgendem git-Repository:

https://gitlab.com/oer-informatik/uml/umlanwendungsfall.

Sie sind bei Namensnennung (Hannes Stein) zur Nutzung als Open Education Resource (OER) freigegeben gemäß der Creative Commons Namensnennung 4.0 International Lizenz (CC BY 4.0).