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.

Begriffsklärung

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):

Aufgabenbeschreibungen werden dazu verwendet, ein genaues Bild von der zu lösenden Aufgaben zu bekommen. Es gibt verschiedene Ansatzmöglichkeiten. Zum einen kann man die Aufgabe textuell beschreiben, oder man nutzt bestimmte Beschreibungsformen zur Darstellung des Sachverhalts. Der Schwerpunkt liegt bei der Präsentation und Analyse. Man betrachtet in der Regel einen Sachverhalt, analysiert diesen anhand der Präsentationsform. Die Präsentationsform gibt einen Rahmen vor, in den man den Sachverhalt umwandeln muss. Stärken der Aufgabenbeschreibungen liegen klar im Präsentieren der Ergebnisse. Die Entwickler erhalten Ergebnisse, mit denen sie direkt arbeiten können, und die nicht noch umgeformt werden müssen. Im Folgenden werden drei Formen der task description an Hand eines Beispiels ausarbeiten: Szenarios, Use Case und Essential Use Case Als Bespiel dient mir der Sachverhalt: ‚Ausleihen eines Films mit Hilfe eines Videothekenautomaten’

• Szenarios:

„Ich, möchte mir einen Film von Robi Williams ansehen. Ich weiß den Titel nicht mehr, aber ich weiß, dass es eine Komödie ist. Ich gehe also zum Katalogsystem und gebe meine Kennung und mein Passwort ein. Ich verstehe nicht, warum ich mein Passwort eingeben muss, denn ich kann den Film sowieso nicht ausleihen, ohne meine Benutzerkarte später einzuschieben. Egal, wenn mein Passwort also verifiziert ist, bekomme ich verschiedene Möglichkeiten nach Titel, Schauspiele, Filmart und dem Datum zu suchen, aber nicht die Möglichkeit in Kombinationen zu suchen. Ich wähle die Möglichkeit mit dem Autor zu suchen, weil die Suche mit der Filmart eine zu unübersichtliche Trefferzahl geben wird. Nach ungefähr einer Minute der Suche gibt der Katalog mir aus, dass er keine Einträge mit dem Schauspiele Robi Williams findet und zeigt mir weiter eine Liste mit Einträgen, die meiner Suche ähnlich sind. Beim Betrachten der Liste merke ich, dass ich den Vornamen des Autors falsch geschrieben habe. Er heißt Robin und nicht Robi Williams. Ich wähle den gewünschten Eintrag und das System fragt mich nach meiner Karte. Nachdem sie rein gesteckt hab und meine Kennung und mein Passwort eingegeben habe und diese verifiziert sind kann ich am Schalter meinen Film abholen.“

• Use Case Diagramme:

Hier wird der Sachverhalt in textueller Form beschrieben:

1. Das System verlangt Username und Passwort

2. Der Benutzer gibt seine Daten ein

3. Das System verifiziert die Daten

4. Das System zeigt ein Menu an Auswahlmöglichkeiten an

5. Der Benutzer wählt „Film ausleihen“

6. Das System zeigt die Suchfunktion an

7. Der User wählt „Suche mit Schauspieler“

8. Der System gibt die Suchmaske aus

9. Der User gibt die Daten ein

10. Das System gibt das Suchresultat aus

11. Der User wählt den gewollten Film

12. Das System fragt nach der Nutzerkarte

13. Das System verlangt Username und Passwort

14. Der Benutzer gibt seine Daten ein

15. Das System verifiziert die Daten

16. Das System sendet eine Bearbeitungsanfrage an den Schalter

17. Der User beendet das Programm

4. Wenn das Passwort falsch ist

4.1 Das System gibt eine Fehlermeldung

4.2 Das System geht zurück zu Schritt 1

5. Wenn der User die Filmdetails schon weiß

5.1 Der User wählt das Menu zur Eingabe der Filmdetails

5.2 Das System gibt das Menu aus

5.3 Der User gibt die Details ein

5.4 Das System geht zu Schritt 12

• 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