Anforderungsermittlung (requirement elicitation)

Anforderungsermittlung (requirement elicitation)

https://oer-informatik.de/anforderungsanalyse-ermittlung

Anforderungsermittlung, Requirements Engineering, Umfeldanalyse, Systemkontext, Stakeholdermanagement, Interview, Fragebogen, Beobachtung, Kreativtechniken, IREB

https://bildung.social/@oerinformatik/109422853120283884

tl/dr; (ca. 19 min Lesezeit): Woher kommen Anforderungen, und mit welchen Techniken ermittelst Du sie systematisch? Der Artikel zeigt, wie Du Umfeld, Systemkontext und Stakeholder analysierst und welche Ermittlungstechnik – Interview, Fragebogen, Beobachtung, Workshop, Dokumentenanalyse oder Prototyp – zu welcher Situation passt [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Bestandteil einer mehrteiligen Reihe zu Requirements Engineering:

Dieser Artikel baut auf der Kann-Liste des Artikels Anforderungsanalyse auf.

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.

Als Grundlagen der Anforderungsermittlung kann ich nach Durchlesen des Artikels…

  • … die drei Schritte der Anforderungsermittlung (Umfeld und Systemkontext, Stakeholder, Anforderungen) nennen.

  • … Quellen für Anforderungen nennen: Stakeholder, Dokumente und bestehende Systeme.

  • … Techniken der Anforderungsermittlung nennen und beschreiben (Interview, Fragebogen, Beobachtung, Workshop, Dokumentenanalyse, Prototyp).

  • … für eine gegebene Situation eine passende Ermittlungstechnik auswählen und die Wahl begründen.

  • … Systemgrenze und Kontextgrenze unterscheiden.

  • … Methoden der Ist-Aufnahme nennen und auf eine Situation anwenden, konkrete Fragen für ein Auftaktgespräch formulieren und Schwachstellen eines bestehenden Systems beschreiben.

Darüber hinaus kann ich als Expertenwissen zur Anforderungsermittlung…

  • … Kreativtechniken wie Perspektivwechsel, Analogietechnik, Storyboard oder Personas zur Ermittlung einsetzen.

  • … Vor- und Nachteile der Ermittlungstechniken abwägen und Techniken sinnvoll kombinieren.

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, die in der Phase des Anforderungsmanagements behandelt werden müssen: neue Anforderungen bringen einen neuen Stakeholder zu Tage, Systemgrenzen werden verschoben usw. Die wesentlichen Aktivitäten sind in folgendem Aktivitätsdiagramm zusammengefasst:

UML-Aktivitätsdiagramm der Anforderungsermittlung: Umfeldanalyse durchführen, System abgrenzen, Stakeholder identifizieren und analysieren, Ziele ermitteln, Szenarien beschreiben, Anforderungen ermitteln; bei neuen Stakeholdern oder verschobenen Systemgrenzen zurück zu „System abgrenzen“ (mit KI erstellt)

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).1

interne Faktoren externe Faktoren
sachliche Faktoren
Kommunikation
nicht möglich		 Prozessbeschreibungen
interne Dokumente (QM-Handbuch, Projekthandbuch…)
Definition of Done
Coding Conventions
IT-Infrastruktur
bestehende Produkte
bestehende Verträge
…		 Gesetze
Verordnungen
Normen
Lizenzen
Wetter
…
Soziale Faktoren
Kommunikation
möglich		 Datenschutzbeauftragte
Entwickler*innen
QS-Team
Auftraggeber*innen
Marketing
Betriebsrat
Vertrieb
Softwarearchitekt
…		 Auftraggeber*innen
Lieferanten
Kund*innen
Anwender*innen
Kontrollorganisationen
Öffentlichkeit
NGOs
Nutzer*innen eines Alt-/Konkurrenzprodukts
…

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. Was Stakeholder genau sind, klärt der Abschnitt „Stakeholdermanagement“.

Systemkontextabgrenzung

Mit der Umfeldanalyse sollten 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.

Abgrenzung zwischen irrelevanter Umgebung, Systemkontext (inkl. Stakeholder, Randbedingungen, interagierende Systeme, Prozesse) und System

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 im 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 verstanden werden.

Stakeholdermanagement

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

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 der Umgang mit Stakeholdern einem eigenen Managementkreislauf (Plan-Do-Check-Act) folgt. 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 durch 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:

Nr Name Stakeholder
Stakeholdergruppe		 Kontaktdaten und Erreichbarkeit Fachgebiet und Umfang des Fachwissens Ziele und Interessen:
Risiko aus Sicht der Stakeholder
(positives Risiko: Erwartungen / negatives Risiko: Befürchtungen)		 Relevanz (Beschreibung) Macht/Einfluss (wenig/mittel/viel) Konfliktpotenzial (wenig/mittel/viel) Geplante Maßnahmen zur Einbindung / Eindämmung des SH
1 … … … … … … … …

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:

wenig
Einfluss		 mittel
Einfluss		 viel
Einfluss
wenig
Konfliktpotenzial
mittel
Konfliktpotenzial
viel
Konfliktpotenzial

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 Stakeholdern mit viel Einfluss und hohem Konfliktpotenzial. Sie können ein Projekt torpedieren - Ziel muss es sein, das Konfliktpotenzial dieser Stakeholdergruppe zu minimieren. Gute Anhaltspunkte für Maßnahmen des Stakeholdermanagements 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.

Wie Du Stakeholder identifizierst, ihre Erwartungen und Befürchtungen sammelst und ein Stakeholder-Portfolio auswertest, zeigt ausführlich der Artikel Stakeholder, Projektumfeld und Akzeptanz.

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 Gespräch mit einzelnen Stakeholdern oder kleinen Gruppen – offen (ohne festen Fragenkatalog), teilstrukturiert (mit Leitfaden) oder strukturiert (feste Fragen). Durch Nachfragen werden auch unklare oder unausgesprochene Anforderungen sichtbar; Interviews kosten aber viel Zeit je Person.

    • Fragebogen (Umfrage): zuvor festgelegte, meist geschlossene Fragen an viele Stakeholder gleichzeitig, auch online. Die Antworten lassen sich gut auswerten und vergleichen; neue, unerwartete Anforderungen findet man damit aber kaum.

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

    • Perspektivwechsel

    • Analogietechniken: anhand analoger/ähnlicher Situationen Anforderungen ableiten

    • Vorstellung von Prototypen (z. B. Papierprototyp, Mockup, Klickdummy): Stakeholder reagieren auf etwas Sichtbares und ergänzen oder korrigieren Anforderungen

    • 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

    • Mitarbeitenden der Fachdomäne

    • anderen Stakeholdern

  • Analyse der bestehenden Geschäftsprozesse über:

    • Anwender-Beobachtung (Feldbeobachtung): Nutzende werden bei ihrer echten Arbeit beobachtet, ggf. arbeitet man selbst eine Zeit lang mit (Apprenticing). So zeigen sich Abläufe und Probleme, die im Gespräch niemand erwähnt, weil sie selbstverständlich erscheinen.

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

    • Analyse bestehender 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 bestehender Dokumente, z.B.

    • Normen:

      • Usability (DIN EN ISO 9241-11:2018): Gebrauchstauglichkeit, also Effektivität, Effizienz und Zufriedenheit, mit der bestimmte Nutzende in einem bestimmten Nutzungskontext ihre Ziele erreichen
      • User Experience (DIN EN ISO 9241-210:2019): menschzentrierte Gestaltung interaktiver Systeme; User Experience umfasst dort die Wahrnehmungen und Reaktionen einer Person vor, während und nach der Nutzung

    • Gesetze und Verordnungen (z. B. DSGVO, Barrierefreiheitsrecht)

    • Lastenheft, Ausschreibungsunterlagen, Prozessbeschreibungen

    • Fehlerberichte, Supportanfragen und Bewertungen eines Vorgänger- oder Konkurrenzprodukts

Welche Ermittlungstechnik passt wann?

Keine Technik findet alle Anforderungen. Meist werden mehrere kombiniert, z. B. zuerst Dokumente auswerten, dann Interviews mit wenigen wichtigen Stakeholdern führen und die Ergebnisse mit einem Fragebogen bei vielen Nutzenden absichern.

Ermittlungstechniken im Vergleich
Technik geeignet, wenn … Vorteil Nachteil
Interview wenige wichtige Stakeholder viel Wissen haben Nachfragen möglich, auch Unausgesprochenes wird sichtbar zeitaufwendig, Ergebnis hängt von Fragen und Gesprächsführung ab
Fragebogen sehr viele oder räumlich verteilte Personen befragt werden sollen schnell, günstig, gut auswertbar, anonym möglich kaum Nachfragen, Anforderungen außerhalb der Fragen gehen verloren, oft geringer Rücklauf
Beobachtung Abläufe eingespielt und schwer zu beschreiben sind zeigt den tatsächlichen Ablauf statt der Vorstellung davon aufwendig, Beobachtete verhalten sich evtl. anders, Wünsche für die Zukunft bleiben verborgen
Workshop / Kreativtechniken Stakeholder mit unterschiedlichen Sichtweisen sich einigen müssen oder etwas Neues entstehen soll gemeinsames Verständnis, Konflikte werden früh sichtbar Terminfindung schwierig, dominante Personen können das Ergebnis prägen
Dokumentenanalyse / Altsystem es Vorgaben, Prozessbeschreibungen oder ein Vorgängersystem gibt ohne Termine mit Stakeholdern möglich, liefert Randbedingungen Dokumente können veraltet sein, Wünsche der Nutzenden fehlen
Prototyp Nutzende sich das Ergebnis schwer vorstellen können konkrete Rückmeldung, Missverständnisse fallen früh auf Aufwand für den Prototyp, Gefahr, dass er für das fertige Produkt gehalten wird

Als Methoden der Anforderungsanalyse bzw. Techniken der Anforderungsermittlung werden üblicherweise Interview, Fragebogen, Beobachtung, Workshop (z. B. mit Brainstorming), Dokumentenanalyse und Prototyp genannt.

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

  • 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 Auftraggebenden, Kund*innen, Anwendenden, Mitarbeitenden der Fachdomäne, Kontrollorganisationen, Verantwortlichen, Ausführenden usw.?

  • Welche Ziele verfolgen diese Stakeholder mit dem System? In welchen 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?

Ist-Aufnahme: den heutigen Zustand erfassen

Bevor ein neues System geplant wird, muss klar sein, wie heute gearbeitet wird. Die Ist-Aufnahme (Erhebung) sammelt dazu Fakten über Abläufe, Beteiligte, Daten und Technik; die Ist-Analyse bewertet sie und deckt Schwachstellen auf; daraus entsteht das Soll-Konzept mit den Anforderungen an das neue System. Die Methoden sind dieselben wie bei der Anforderungsermittlung, nur der Blick richtet sich auf den heutigen Zustand.

Methoden der Ist-Aufnahme auf eine Situation anwenden

Eine Methode nur zu nennen, genügt selten. Wenn Du sie anwendest, sagst Du, wen oder was Du wie untersuchst und was Du herausfinden willst. Beispiel: Die Essensausgabe einer Kantine soll durch eine Vorbestell-App ergänzt werden.

Methoden der Ist-Aufnahme mit Anwendung auf eine Situation
Methode Anwendung auf die Situation
Beobachtung An mehreren Tagen zur Mittagszeit die Ausgabe beobachten: Wie lange dauert ein Bezahlvorgang? Wann entstehen Schlangen? Welche Gerichte sind wann ausverkauft?
Interview Mit der Küchenleitung und dem Kassenpersonal sprechen: Wie wird heute geplant? Wo entsteht Mehrarbeit? Was wird weggeworfen?
Fragebogen / Online-Umfrage Viele Gäste kurz befragen: Wie zufrieden sind sie mit Wartezeit und Angebot? Würden sie vorbestellen, und mit welchem Gerät?
Dokumentenauswertung / Datenanalyse Kassendaten, Speisepläne und Abfalllisten der letzten Monate auswerten: Welche Gerichte werden wann wie oft verkauft?
Marktanalyse Vergleichbare Kantinen oder Apps ansehen, z. B. auf Fachmessen oder bei Anbietern: Welche Lösungen gibt es schon?
Fragen für das Auftaktgespräch formulieren

Im ersten Gespräch mit der Auftraggeberin oder dem Auftraggeber verschaffst Du Dir einen Überblick, damit ein Projektauftrag formuliert werden kann. Gute Fragen sind konkret und offen (W-Fragen), beziehen sich auf die Situation und lassen sich nicht mit „ja“ oder „nein“ beantworten. Ordne sie nach Bereichen, damit nichts fehlt:

Fragen für ein Auftaktgespräch nach Bereichen
Bereich Beispielfrage
Ziele Welches Problem soll das neue System vor allem lösen, und woran erkennen Sie später den Erfolg?
Organisation Wie läuft der Vorgang heute ab, wer ist daran beteiligt, und wie viele Vorgänge gibt es pro Tag?
Technik Welche Geräte, Programme und Schnittstellen nutzen Sie heute, und wo werden die Daten gespeichert?
Rahmen Welches Budget und welcher Zeitraum stehen zur Verfügung, und wer muss eingebunden werden (z. B. Betriebsrat, Datenschutz)?
Schwachstellen beschreiben

Bei der Schwachstellenanalyse suchst Du in den Ergebnissen der Ist-Aufnahme nach Ursachen für Fehler, Verzögerungen, Kosten und Risiken. Typische Schwachstellen sind:

  • Medienbrüche und Doppelerfassung: Daten werden von Papier in ein Programm oder zwischen Programmen von Hand übertragen; das kostet Zeit und erzeugt Fehler.

  • Veraltete Software oder Hardware: Der Hersteller liefert keine Updates mehr; Sicherheitslücken bleiben offen, und neue Schnittstellen fehlen.

  • Fehlende Verfügbarkeit: Das System fällt häufig aus oder ist nur an einem Ort bzw. zu bestimmten Zeiten erreichbar.

  • Fehlende Schnittstellen: Das System kann keine Daten mit anderen Systemen (z. B. Datensicherung, Buchhaltung) austauschen.

  • Bedienprobleme: Fehlbedienungen wegen unübersichtlicher Oberfläche oder fehlender Schulung.

  • Unsichere oder verstreute Datenhaltung: Daten liegen lokal, ohne Sicherung oder ohne Zugriffsschutz.

Beim Beschreiben nennst Du die Schwachstelle und ihre Folge in der Situation, zum Beispiel: „Die Bestellungen für Sonderessen werden auf Zetteln notiert und morgens von Hand in die Kassensoftware übertragen. Dabei gehen Zettel verloren, und die Küche kocht falsche Mengen.“ Aus jeder Schwachstelle lässt sich anschließend eine Anforderung an das neue System ableiten.

Wie geht es weiter?

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

… die Anforderungen zu dokumentieren (requirement documentation)

Leitfragen

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

Anforderungen kommen von Stakeholdern, aus Dokumenten und aus bestehenden Systemen. Du ermittelst sie mit Befragungstechniken (Interview, Fragebogen), Workshops mit Kreativtechniken und Prototypen, der Analyse bestehender Geschäftsprozesse (Beobachtung, Prozessdokumentation, Altsysteme), einer Marktanalyse und der Auswertung von Dokumenten wie Normen, Gesetzen, Lastenheft oder Fehlerberichten – siehe Abschnitt „Anforderungsermittlung“.

  1. Welche Stakeholder können Anforderungen an das Projekt stellen?

Stakeholder sind alle Personen oder Organisationen, die die Anforderungen beeinflussen oder vom System betroffen sind. Intern sind das z. B. Auftraggebende, Entwickler*innen, QS-Team, Datenschutzbeauftragte, Marketing, Vertrieb und Betriebsrat, extern z. B. Kund*innen, Anwender*innen, Lieferanten, Kontrollorganisationen, Öffentlichkeit und Nutzer*innen eines Alt- oder Konkurrenzprodukts – siehe Abschnitt „Umfeldanalyse“ und Abschnitt „Stakeholdermanagement“.

  1. Welche Ermittlungstechniken gibt es, und wie unterscheiden sich Interview und Fragebogen?

Übliche Ermittlungstechniken sind Interview, Fragebogen, Beobachtung, Workshop (z. B. mit Brainstorming und Kreativtechniken), Dokumentenanalyse und Prototyp. Ein Interview ist ein Gespräch mit einzelnen Stakeholdern oder kleinen Gruppen, bei dem Du nachfragen und auch Unausgesprochenes aufdecken kannst, das aber viel Zeit je Person kostet; ein Fragebogen erreicht mit festgelegten, meist geschlossenen Fragen viele Personen schnell und gut auswertbar, findet aber kaum neue, unerwartete Anforderungen – siehe Abschnitt „Welche Ermittlungstechnik passt wann?“.

  1. In welcher Situation eignet sich eine Beobachtung besser als eine Befragung?

Eine Beobachtung eignet sich, wenn Abläufe eingespielt und schwer zu beschreiben sind: Sie zeigt den tatsächlichen Ablauf statt der Vorstellung davon und macht Probleme sichtbar, die im Gespräch niemand erwähnt, weil sie selbstverständlich erscheinen. Wünsche für die Zukunft bleiben dabei allerdings verborgen – siehe Abschnitt „Welche Ermittlungstechnik passt wann?“.

  1. Was liegt innerhalb der Systemgrenze, was im Systemkontext, und was ist für das Projekt irrelevant?

Innerhalb der Systemgrenze liegen alle Anforderungen, die das System nach Projektabschluss erfüllen soll. Im Systemkontext liegen Stakeholder, interagierende Systeme, Randbedingungen und (Geschäfts-)Prozesse, die über Schnittstellen auf das System einwirken; jenseits der Kontextgrenze liegt die für das Projekt irrelevante Umgebung. Beide Grenzen können sich im Projektverlauf verschieben – siehe Abschnitt „Systemkontextabgrenzung“.

  1. Wie wendest Du Methoden der Ist-Aufnahme auf eine Situation an?

Du nennst die Methode und sagst, wen oder was Du wie untersuchst und was Du herausfinden willst: z. B. die Ausgabe zur Mittagszeit beobachten (Dauer, Schlangen), Küchenleitung und Kassenpersonal interviewen (Planung, Mehrarbeit), Gäste per Online-Umfrage befragen (Zufriedenheit, Interesse an Vorbestellung) und Kassendaten auswerten (Verkäufe je Gericht und Uhrzeit) – siehe Abschnitt „Methoden der Ist-Aufnahme auf eine Situation anwenden“.

  1. Wie formulierst Du Fragen für ein Auftaktgespräch, und wie beschreibst Du eine Schwachstelle?

Gute Fragen sind konkret, offen (W-Fragen) und auf die Situation bezogen; ordne sie nach Zielen, Organisation, Technik und Rahmen (Budget, Termine, Beteiligte), damit nichts fehlt. Eine Schwachstelle beschreibst Du, indem Du das Problem und seine Folge in der Situation nennst, etwa „Bestellungen werden auf Zetteln notiert und von Hand übertragen, dadurch gehen Bestellungen verloren und die Küche plant falsche Mengen“ – siehe Abschnitt „Fragen für das Auftaktgespräch formulieren“ und Abschnitt „Schwachstellen beschreiben“.

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Anforderungsermittlung (requirement elicitation)” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/anforderungsanalyse-ermittlung veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/projekt/anforderungsanalyse. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

  1. Diese Systematik wurde analog zu “Weniger schlecht Projekte managen” erstellt - Quelle siehe Literaturlinks↩︎

  2. Zitat aus dem IREB-Glossar↩︎

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen:

Tags:

You may also like...