Erhebungstechniken im RE

Transkript

1 Erhebungstechniken im RE Interview Grundsätzlich können Interviews je nach Fragestellung eher offen (Orientierung nur an groben Leitfaden) oder sehr strukturiert sein (Fragenkatalog). Es sind auch Mischformen möglich. Außerdem kann ich Gruppeninterview oder Einzelinterview unterschieden werden. Gruppeninterview o Vorgegebenes Thema wird in der Gruppe diskutiert o Moderator leitet das Gespräch und stellt Fragen, hakt bei Unklarheiten nach Einzelinterview Interviewergebnisse werden gewöhnlich aufgenommen (z.b. Audioaufnahme) und dann schriftlich festgehalten. Geeignete Gruppe steht für Befragung zur Verfügung. Vorbereitung des Interviews (z.b. in Form eines Interview-Leitfadens) Interviewer/Moderator Evtl. Protokollant Kunde, Nutzer, Entwickler, sonstige Stakeholder Je nach Fragestellung zur Vorbereitung des Interviewers Interviewleitfaden Sehr flexible, kann sowohl für erste Orientierung in der Domäne (z.b. offenes Gruppeninterview) als auch für gezielte Informationsbeschaffung genutzt werden. Bei Bedarf können viele Details erhoben werden. Kontakt zu verschiedenen Stakeholdern wird hergestellt. Nachteil Erfolg abhängig von Verfügbarkeit und Offenheit der Interviewpartner Verzerrung der Informationen durch subjektive Meinungen Verzerrung wenn Auswahl der Interviewpartner nicht repräsentativ

2 Modellierung/Prototyping Erstellung einer frühen Version des Systems Demonstration der relevanten Eigenschaften o UI -> Mockup o Ein-/Ausgabe -> Automaten Ziel: Grundlegende Idee ausprobieren, Technische Machbarkeit zeigen, Kommunikation mit Stakeholdern Horizontale Prototypen: Alle Funktionen sind angerissen (z.b. GUI Mockup) aber nicht in der Tiefe implementiert Vertikale Prototypen: Nur wenige Funktionen sind implementiert, dafür aber in nahezu vollem Umfang Throwaway vs. Evolutionary Protyping: Prototype wegwerfen oder weiterentwickeln Grundlegende Funktionalität des Systems oder Systemteilen muss (teilweise) bekannt sein Designer, Entwickler, Anwender Informelle Beschreibung des Systems, der technischen Herausforderungen, Ziele o.ä. Vergleichssysteme : Hohe Nutzerzufriedenheit Frühe Validierung der Anforderungen Gefahr, dass schlecht entwickelter Prototyp überlebt Viele Anforderungen lassen sich mit Prototypen evtl. schlecht abbilden (z.b. nichtfunktionale) Zu frühe Einschränkung des Lösungsraumes Zu Hohe Erwartungen bzgl. des Entwicklungsstandes können geweckt werden

3 Beobachtung Das interessante Phänomen kann überhaupt beobachtet werden Falls die Beobachtung beim Kunden stattfindet: Kunde erlaubt die Beobachtung Evtl. datenschutzrechtliche Einschränkungen (potentielle) Anwender des Systems : Requirements Engineer kann sich unmittelbar ein Bild machen : Evtl. sehr zeitaufwendig Beobachtung wird durch Anwesenheit des Beobachters beeinflusst Im Normalfall kann nur kleiner Ausschnitt beobachtet werden (evtl. keine Sonderfälle) Verzerrung durch subjektive Interpretation

4 Analyse von Vorgänger/Konkurenzprodukten Anforderungen werden auf Basis bestehender Anforderungsdokumente und/oder bestehender Softwaresysteme erhoben/geändert. Software kann Vorgängerprodukt oder Fremdsoftware sein. Anforderungsdokument von Vorgängerprodukten noch erhalten Es gibt überhaupt vergleichbare Software (schwierig bei sehr spezifischen oder innovativen Produkten) Anforderungen weichen nicht zu stark von den ursprünglichen Anforderungen ab, bzw. die ursprünglichen Anforderungen sind richtig umgesetzt worden. Benutzer/Entwickler/Anforderungsingenieure der Vorgängersoftware Dokumentation des Vergleichssystem (Nutzer-/Entwicklerdokumentation) Andere Artefakte des Vergleichssystem (Modelle, Code, etc.) Evtl. Bugreports, CRs, Erfahrungsberichte etc. Bei bewährten Systeme haben sie die Anforderungen stabilisiert und sind schon vervollständigt. Benutzer sind an vorhandene Funktionen/Konzepte gewöhnt Evtl. unnötige Einschränkung des Lösungsraums Schlechte Lösungen werden u.u. übernommen

5 Schriftliche Befragung Verwendung von Fragebögen um Meinungen, Wissen und Verhalten von Menschen zu erheben. Die Fragebögen werden normalerweise an einen vorab festgesetzte kreis verteilt. Grundsätzlich sind offene und geschlossene (Antwortmöglichkeiten vorgegeben) Fragen möglich. Einige Informationen über die Domäne und die Probleme sind schon vorhanden (um den Fragebogen zu konstruieren). Gegenbeispiel: Generische Fragebögen z.b. um allgemeine Informationen zum Kunden vorab zu bekommen. Geeignete Zielgruppe für die Fragebögen steht zur Verfügung und kann kontaktiert werden. Fragenbogenersteller Zielgruppe für Befragung (im Prinzip alle Stakeholder möglich) Auswerter Evtl. für die Vorbereitung der Fragebögen Einfache Möglichkeit eine große Anzahl an Menschen zu befragen, die u.u. örtlich verteilt sind. Relativ geringe Kosten Rücklaufquote von Fragebögen häufig gering Keine Kontrolle ob der Fragebogen von der richtigen Person ausgefüllt wurde Nicht vorgesehene Aspekte werden nicht erhoben (teilweise durch offene Fragen möglich) Es kann nicht nachgehakt werden. Zielverfeinerung/-abstraktion Templates/Checklisten