Anforderungs- und Bedarfsanalyse

Die Anforderungs- und Bedarfsanalyse lässt sich in die Gruppe der Informationsbedarfsanalyseeinordnen. Sie wird in der Softwarekonzeption um Bedarf und Anforderung an ein zu konzeptionierendes System herauszukristallisieren.

Drei Begriffe stehen im Rahmen der Analyse im Mittelpunkt: Anforderung, Bedürfnis und Bedarf.

• Unter den Begriff Anforderung fallen sowohl technische, als auch ideelle Standards, die ein System erfüllen muss, um effektiv und effizient im Gebrauch zu sein.
• Unter Bedürfnis (des Nutzers) fasst man alle vom User als gut erachteten und geforderten Features zusammen, die das System umfassen soll.
• Der Bedarf des Nutzers geht über diese genannten Features hinaus und beinhaltet auch die Eigenschaften, die der Nutzer aus Unwissenheit oder Inkonsequenz nicht angegeben hat.
  • Sharp(2007) definiert Bedarf/ requirement wie folgt: „A requirement is a statement about an intended product that specifies what it should do or how it should perform. One of the aims of the requirement activity is to make the requirements as specific, unambiguous and clear as possible.”

---

Aufbau

Es gibt verschiedene Techniken/ Methoden zur Bedarfsaufdeckung zu besseren Softwarekonzeption. Grob lassen sich drei Phasen herausstellen:

• Datenerhebung
• Datenanalyse
• Präsentation

Methoden der Bedarfsanalyse

Jede Methode zeigt andere Ausprägungen und Stärken in den einzelnen Phasen auf:

Befragung:

Die Befragung ist eine indirekte Methode zur Ermittlung von Aussagen über einen Sachverhalt. Sie liefert zum einen sehr gute Ergebnisse in der Phase der Datenerhebung, zum anderen kann man mit ihr durch geschickte Konzeption der Fragen vorab Analysemöglichkeiten erstellen, die danach nur noch ausgewertet werden müssen. Hat man schon gewisse Hypothesen zum Bedarf, die man überprüfen will, so kann man sich ein Raster an geschlossenen Fragen anlegen, dass den Sachverhalt verifiziert oder falsifiziert. Vorab sollte ein Codierungsplan erstellt werden, bei dem Antwortmöglichkeiten mit Anforderungen mit Hilfe von Variabeln in Beziehung gesetzt werden.(siehe Benutzerforschung Dadurch kann man später in Form statistischer Auswertungen ein genauen Bild der Erhebungssituation machen. Will man sich einen breiten Überblick über die Situation schaffen, kann man offene Fragen dafür verwenden und so ein breites Feld abdecken. Die Präsentation kann – bei geschlossenen Fragen – durch den Einsatz von Diagrammen und Tabellen erfolgen. Bei offenen Fragen muss man diese neu analysieren und gegebenenfalls textuell präsentieren.

• Interviews:
• Fragebögen:

Beobachtungen:

Bei der Beobachtung wird die Realsituation der umzusetzenden Aufgabe betrachtet und es Schlüsse gezogen, warum die Aufgabe so und nicht anders bewältigt wird. Im Gegensatz zur Befragung liegt der Schwerpunkt hier in der Phase der Datenanalyse. Hier steht nicht der Kontakt mit dem Nutzer im Vordergrund, sondern man versucht anhand von Beobachtungen Merkmale herauszufinden, die zwar für den Arbeitsprozess wichtig sind, der Nutzer aber selbst als unwichtig oder normal wertet.

• direkte Beobachtung:

Alle Datensätze oder Situationen die mit der äußeren Bearbeitung der Aufgabe zu tun haben, werden als direkte Beobachtung bezeichnet.

• indirekte Beobachtung:

Jede Untersuchung der Metadaten zur Aufgabenbewältigung bezeichnet man als indirekte Beobachtung.

• Kontextanalys:

Diese Methode ist ein Teil der sieben Stufen des Nutzerorientierten Designprozess nach Beyer und Holtzblatt ( 1998 ). Die Kontextanalyse ist eine beliebte Technik um Bedarf aufzudecken, insbesondere in Bezug auf Aufdeckung von Bedarf in Relation zum Gebrauch. Die Kontextanalyse ist eine Herangehensweise, die eine ethnographische Annäherung bei der Datenerfassung mit einschließt und an Beobachtungen angelehnt ist. Sie ist so konzipiert, dass die Datenerfassung für den Designprozess und für den Ausbildungsprozess benutzt werden kann. Ihr Schwerpunkt liegt in den ersten beiden Phasen der Bedarfsanalyse (Datenerhebung und Datenanalyse). Grundlegende Idee hierbei ist, dass der Designer als ‚Ausbilder für den Benutzer’ fungiert, also vorab in seinen Gedankengang die Erlernbarkeit mit einbezieht. Ein typisches Format für die Kontextanalyse ist das Kontextinterview, welches eine Kombination aus Beobachtung, Diskussion und Rekonstruktion von vergangenen Situationen darstellt. „The best way to interpret these observation is to discuss them with me [,the analyst]” (Sharp 2007) Für diese Methode sind vier Prinzipien zentral: Kontext, Partnerschaft, Interpretation und Fokussion:

• • Kontext Das Kontextprinzip betont die Wichtigkeit des Ganges zum Arbeitsplatz, um sich ein Bild davon zu machen, was dort passiert.
  • Partnerschaft Das Partnerschaftsprinzip sagt, dass Entwickler und User in Bezug auf das Verständnis der Arbeit kollaborieren sollen
  • Interpretation Das Interpretationsprinzip sagt, dass Beobachtungen interpretiert werden und zwar in Bezug auf den Gebrauch im Design. Und diese Interpretation soll wieder mit Hilfe von User und Entwickler geschehen.
  • Fokussion Das Fokussionsprinzip sagt aus, dass man nie die Ziele des Projektes außer Acht lassen darf.

Die Analyseansätze unterliegen stark dem Partnerschaftsprinzip. Nutzer und Entwickler versuchen durch gemeinsame Überlegungen und Diskussionen von Bedürfnissen Bedarf aufzudecken um dies festzuhalten. Wichtig für die verhobenen Daten ist, dass sie auch weiter verarbeitet und in Beziehung gesetzt werden können, damit die Analyseprozesse präsentierbare Ergebnisse liefern können.

Aufgabenbeschreibungen (task description):

• Szenarios:
• Use Case Diagramme:
• Essential Use Cases:

Aufgabenanalyse: (task analyses)

• Hierarchical Task Analysis:

Quellen

• Sharp, Helen; Rogers, Yvonne; Preece, Jenny: Interaction Design – beyond human-computer interaction.; Hoboken, NJ [u.a.]: Wiley, 2007
• Carroll, John M: Making use, scenario based design of human-computer interactions MIT Press, Cambridge, Mass [u.a.]; 2000
• Beyer, Hugh; Holtzblatt, Karen: Contextual design – defining customer-centered systems; Kaufmann, San Francisco, Calif.; 1998
• Constantine, L. L., & Lockwood, L. A. D. Software for use: A practical guide to the models and methods of usage-centered design. ACM Press, New York, NY; 1999