Was ist das Ziel der Anforderungserhebung?
Bei der Erhebung, im Lehrplan des IREB als Ermittlung bezeichnet, geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu verstehen und sicherzustellen, dass Anforderungen aus allen relevanten Quellen erfasst werden. Ein zentraler Punkt ist, implizite Wünsche und Erwartungen in explizite Anforderungen zu überführen [1]. Viele Probleme in Projekten entstehen nicht durch falsch umgesetzte Anforderungen, sondern durch Anforderungen, die nie jemand ausgesprochen hat, weil sie den Beteiligten selbstverständlich erschienen.
Die Erhebung ist kein einmaliger Schritt. Die Identifikation von Quellen ist laut Lehrplan ein iterativer und rekursiver Prozess, der ständig überprüft werden muss: Neue Stakeholder tauchen auf, Dokumente werden entdeckt, und mit wachsendem Verständnis entstehen neue Fragen. Voraussetzung ist ein gemeinsames Verständnis des Systemkontexts, siehe Systemkontext und Abgrenzung.
Welche Quellen für Anforderungen gibt es?
| Quellenart | Beispiele | Hinweis |
|---|---|---|
| Stakeholder | Benutzer, Auftraggeber, Management, Entwicklung, Behörden, Kunden, indirekt Betroffene | wichtigste Quelle, Rollen und Personen identifizieren |
| Dokumente | Prozessdokumentationen, Gesetze und Verordnungen, interne Richtlinien, Marktinformationen | enthalten oft Anforderungen, die niemand ausspricht |
| Systeme | bestehende Systeme und Altsysteme, Konkurrenzprodukte, Systeme aus anderen Branchen | zeigen tatsächliches Verhalten und Datenstrukturen |
Stakeholder sind die wichtigste Quelle. Der Lehrplan nennt typische Rollen wie Benutzer, Auftraggeber, Management, Entwicklung, Behörden und Kunden und weist darauf hin, dass auch Personen oder Organisationen, die vom System betroffen sind, als indirekte Stakeholder zu berücksichtigen sind [1]. Für Systeme mit Benutzeroberfläche sind die Endnutzenden besonders wichtig; sie werden nach ähnlichen Rollen, Aufgaben oder Verantwortlichkeiten gruppiert. Sind sie nicht einzeln identifizierbar, etwa bei einer öffentlichen App, helfen Personas als fiktive, archetypische Beschreibungen.
Was gehört in eine Stakeholder-Liste?
Stakeholder werden in einer aktuellen Liste geführt. Der Lehrplan nennt als Mindestinhalt Name, Funktion oder Rolle, Kontaktdaten, zeitliche und örtliche Verfügbarkeit während des Projekts, Relevanz, Fachgebiet und Umfang der Expertise sowie Ziele und Interessen im Projekt [1]. Die Verfügbarkeit wird oft vergessen, ist aber entscheidend: Ein wichtiger Stakeholder, der nur zu Projektbeginn erreichbar ist, verlangt eine andere Planung der Erhebung als einer, der laufend Feedback geben kann.
| Rolle | Ziele und Interessen | Verfügbarkeit | Relevanz |
|---|---|---|---|
| Projektleitende | schneller Überblick über Aufwand pro Projekt | wöchentlich eine Stunde | hoch |
| Mitarbeitende | einfache Erfassung, wenig Zusatzaufwand | punktuell für Tests | hoch |
| Buchhaltung | korrekte Daten für Rechnungen, Export ins Buchhaltungssystem | monatlich zum Abschluss | hoch |
| Datenschutzverantwortliche | Zugriffsrechte, Aufbewahrung, Auskunftsrechte | auf Anfrage | mittel |
| Informatikbetrieb | Betrieb, Updates, Schnittstellen | nach Absprache | mittel |
Quellen für die Identifikation von Stakeholdern sind Checklisten typischer Rollen, Organigramme, Prozessdokumentationen, Marktberichte und die bereits bekannten Stakeholder, die weitere nennen können. Eine Vorlage zur Stakeholderanalyse bietet flenio.ch unter Stakeholderanalyse; das Glossar erklärt den Begriff unter Stakeholder-Analyse.
Wie hilft das Kano-Modell bei der Erhebung?
Das Kano-Modell ordnet Anforderungen nach ihrer Wirkung auf die Zufriedenheit drei Kategorien zu. Der IREB-Lehrplan nennt Begeisterungsfaktoren, die unbewusst sind und nicht erwartet werden; Leistungsfaktoren, die bewusst sind und deren Erfüllung die Zufriedenheit steigert; sowie Basisfaktoren, die unterbewusst vorausgesetzt werden und deren Fehlen Unzufriedenheit auslöst [1]. Für die Erhebung ist diese Unterscheidung zentral, weil jede Kategorie andere Techniken verlangt.
| Kategorie | Merkmal | Geeignete Techniken |
|---|---|---|
| Basisfaktoren | werden vorausgesetzt und selten ausgesprochen | Beobachtung, Analyse bestehender Systeme und Dokumente |
| Leistungsfaktoren | werden bewusst genannt, mehr ist besser | Interviews, Fragebögen, Workshops |
| Begeisterungsfaktoren | werden nicht erwartet, überraschen positiv | Kreativitätstechniken, Prototypen, Design Thinking |
Wer nur Interviews führt, erfasst vor allem Leistungsfaktoren. Basisfaktoren bleiben verborgen, weil niemand auf die Idee kommt, sie zu erwähnen, etwa dass eine Zeiterfassung auch nach Mitternacht korrekt dem richtigen Tag zugeordnet werden muss. Begeisterungsfaktoren entstehen selten durch Befragung, sondern durch kreative Auseinandersetzung mit dem Problem. Begeisterungsfaktoren von heute werden zudem mit der Zeit zu Leistungs- und später zu Basisfaktoren.
Welche Erhebungstechniken gibt es?
| Kategorie | Techniken | Stärke | Grenze |
|---|---|---|---|
| Befragung | Interview, Fragebogen | Tiefe im Einzelgespräch, Breite mit Fragebogen | erfasst vor allem Bewusstes |
| Kollaboration | Workshop, Fokusgruppe | gemeinsames Verständnis, Konflikte früh sichtbar | dominante Personen, Abstimmungsaufwand |
| Beobachtung | Feldbeobachtung, Mitarbeit im Arbeitsalltag | zeigt tatsächliche Abläufe und Basisfaktoren | zeitaufwendig, Verhalten ändert sich unter Beobachtung |
| Artefaktbasiert | Dokumentenanalyse, Analyse bestehender Systeme | nutzt vorhandenes Wissen, unabhängig von Verfügbarkeit | Dokumente können veraltet sein |
| Kreativität und Design | Brainstorming, Analogien, Prototypen, Szenarien, Storyboards, Design Thinking | neue und innovative Anforderungen | braucht Moderation und Offenheit |
Der Lehrplan unterscheidet Erhebungstechniken, die vor allem Leistungs- und Basisfaktoren aus verschiedenen Quellen gewinnen, von Kreativitäts- und Designtechniken, die Ideen erzeugen und so häufig zu Begeisterungsfaktoren führen [1]. Zudem betont er, dass Techniken alle Arten von Anforderungen erfassen müssen: In der Praxis erhalten Qualitätsanforderungen und Randbedingungen oft zu wenig Aufmerksamkeit. Für Qualitätsanforderungen empfiehlt der Lehrplan ein Qualitätsmodell wie ISO/IEC 25010 als Checkliste; Randbedingungen findet man, indem man technische, rechtliche, organisatorische, kulturelle und umweltbezogene Einschränkungen betrachtet.
Wie wählt man die passende Technik?
Die Wahl hängt laut Lehrplan unter anderem von der Art des Systems, dem Entwicklungsmodell, den beteiligten Personen und der Organisationsstruktur ab; gute Ergebnisse entstehen meist durch eine Kombination [1]. Die folgende Matrix zeigt typische Situationen und bewährte Kombinationen.
| Situation | Empfohlene Kombination |
|---|---|
| Ablösung eines bestehenden Systems | Analyse des Altsystems, Beobachtung der Nutzung, Interviews mit Schlüsselpersonen |
| Neues Produkt für einen Markt | Interviews mit potenziellen Kunden, Personas, Prototypen, Design Thinking |
| Viele Stakeholder mit unterschiedlichen Interessen | Workshops mit Moderation, ergänzt durch Einzelinterviews bei Konflikten |
| Stark regulierte Umgebung | Dokumentenanalyse von Gesetzen und Normen, Interviews mit Fachstellen |
| Viele verteilte Nutzende | Fragebogen für Breite, Interviews für Tiefe, Analyse von Supportanfragen |
| Unklare Vorstellung beim Auftraggeber | Prototypen und Szenarien, iterative Validierung |
Wie führt man ein gutes Erhebungsinterview?
- 1Vorbereiten: Ziel klären, Rolle und Hintergrund der Person kennen, offene Fragen vorbereiten.
- 2Einsteigen: Zweck erklären, Vertraulichkeit klären, Dauer festlegen.
- 3Offen fragen: nach Aufgaben, Abläufen, Problemen und Zielen statt nach Lösungen.
- 4Konkretisieren: nach Beispielen, Ausnahmen, Häufigkeiten und Mengen fragen.
- 5Zusammenfassen: das Verstandene in eigenen Worten wiederholen und bestätigen lassen.
- 6Nachbereiten: Ergebnisse dokumentieren, offene Punkte festhalten, Ergebnisse zur Bestätigung zurückschicken.
Ein häufiger Fehler ist, nach Lösungen zu fragen: «Wie soll die Maske aussehen?» Wirksamer sind Fragen nach dem Problem und dem Ziel: «Was müssen Sie am Monatsende mit den erfassten Zeiten tun, und was hindert Sie heute daran?» So entstehen Anforderungen, die Raum für bessere Lösungen lassen. Dieser Gedanke entspricht dem IREB-Prinzip, Problem, Anforderung und Lösung in Denken und Dokumentation so weit wie möglich zu trennen.
Wie werden Konflikte zwischen Stakeholdern gelöst?
Erhebungstechniken allein garantieren nicht, dass die Anforderungen konsistent und abgestimmt sind. Widersprechen sich Stakeholder, ist das als Konflikt zu erkennen und zu lösen. Der Lehrplan beschreibt vier Aufgaben: Konflikt identifizieren, analysieren, lösen und die Lösung dokumentieren [1]. Für die Analyse hilft die Unterscheidung von Konfliktarten: Sach-, Daten-, Interessen-, Werte-, Beziehungs- und Strukturkonflikte.
| Technik | Beschreibung | Geeignet für |
|---|---|---|
| Einigung | Beteiligte finden gemeinsam eine Lösung | Sach- und Datenkonflikte |
| Kompromiss | jede Seite gibt etwas nach | Interessenkonflikte |
| Abstimmung | Mehrheit entscheidet | viele Beteiligte, gleichwertige Optionen |
| Entscheid der Hierarchie | eine übergeordnete Stelle entscheidet | Struktur- und festgefahrene Konflikte |
| Varianten | verschiedene Lösungen für verschiedene Gruppen | unterschiedliche Bedürfnisse ohne gemeinsamen Nenner |
Ergänzende Hilfstechniken sind etwa das Betrachten aller Fakten, eine Plus-Minus-Interessant-Bewertung oder eine Entscheidungsmatrix. Wichtig ist die Dokumentation der Entscheidung mit Begründung, damit der Konflikt nicht später erneut aufbricht. In Projekten mit klarer Governance hilft zudem eine definierte Eskalationsstufe, siehe Projektorganisation.
Erhebungsergebnisse festhalten
Ergebnisse aus Interviews und Workshops werden zeitnah dokumentiert und den Beteiligten zur Bestätigung zurückgegeben. Jede Anforderung erhält eine eindeutige Kennung und einen Verweis auf ihre Quelle, damit später nachvollziehbar ist, wer sie gestellt hat. In Flenio lassen sich Anforderungen als Aufgaben mit Quelle, Beschreibung und Status erfassen und Projekten zuordnen. Wie Anforderungen danach gut formuliert werden, zeigt der Beitrag Anforderungen formulieren. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.
Erhebung in Normen und öffentlichen Projekten
Die Norm ISO/IEC/IEEE 29148 beschreibt die Anforderungsprozesse über den Lebenszyklus, einschliesslich der Ermittlung von Stakeholder-Anforderungen, und legt fest, welche Informationsobjekte daraus entstehen [2]. In der Schweizer Bundesverwaltung gehört die Erhebung der Stakeholderinteressen zu den Ergebnissen, die HERMES für Projekte vorsieht [3]. Für öffentliche Projekte bedeutet das: Die Erhebung muss nachvollziehbar dokumentiert sein, damit sie bei Freigaben und Beschaffungen als Grundlage dient.
Unabhängig vom Rahmen gilt: Die Erhebung ist erst abgeschlossen, wenn die Ergebnisse von den Stakeholdern bestätigt sind. Ein kurzer Bestätigungsschritt nach jedem Interview oder Workshop verhindert, dass Missverständnisse unbemerkt in die Dokumentation einfliessen.