Anforderungs- und Bedarfsanalyse
Die Anforderungs- und Bedarfsanalyse lässt sich in die Gruppe der Informationsbedarfsanalyse einordnen. Sie wird in der Softwarekonzeption eingesetzt, um Bedarf und Anforderung an ein zu konzipierendes System herauszukristallisieren.
Inhaltsverzeichnis
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 werden 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.
- Kontextanalyse:
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 erhobenen 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 Videothekautomaten’
- 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 habe und meine Kennung und mein Passwort eingegeben habe und diese verifiziert sind, kann ich am Schalter meinen Film abholen.“
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)
Die Aufgabenanalyse geht noch einen Schritt weiter als die Aufgabenbeschreibung. Der Schwerpunkt liegt auch hier bei der Analyse und bei der Präsentation. Hierunter werden Techniken zur Erforschung kognitiver Prozesse und physischer Handlungen verstanden. Im Gegensatz zur Aufgabenbeschreibung ist der Detail-Grad höher. Sharp (2007) beschreibt den Grundgedanken folgendermaßen: „It is used to analyze the underlying rationale and purpose of what people are doing: what are they trying to achieve, why are they trying to achieve it, and how are they going about it? “
- Hierarchical Task Analysis:
Eine spezielle Form der Aufgabenanalyse ist die Hierarchical Task Analysis (HTA). Annett und Duncan (1967) haben diese Analysemethode konzipiert, um Bedarf zu identifizieren. Bei diesem Konzept bricht man eine komplexe Aufgabe in die untersten Formen der Aufgabe herunter. Aus diesen Subaufgaben werden dann ‚Pläne’ zusammengestellt, die Systemabläufe in Bezug auf das konzipierende System abbilden sollen. Hierbei werden nicht nur systembezogene Aufgaben herausgestellt, sondern auch alle anderen, die zur Bewältigung des Systems wichtig sind. Es steht weniger die Phase der Datenerhebung im Vordergrund, als vielmehr die Kombination von Analyse und Präsentation. Durch das Schema der Subtasks erhält man die genauen Bausteine, die ein System bewältigen werden muss, und die Aufgabe verliert an Komplexität.
Das Herunterbrechen der Aufgabe ‚Film ausleihen’ sieht wie folgt aus:
0. Film aus Videothek ausleihen
1. Zur Videothek gehen
2. Den gesuchten Film finden
2.1 in den Videothekensautomaten. Katalog einsteigen
2.2 in die Suchmaske einsteigen
2.3 Suchkriterien eingeben
2.4 das gesuchte Buch erkennen
2.5 Ort notieren
3. Zum korrekten Regal gehen und Buch nehmen
4. Mit dem Buch zum Ausleih-Schalter gehen
Mögliche Pläne wären:
Plan 0: do 1-3-4 if film isn’t on the shelf expected, do 2-3-4
Plan 2: do21.-2.4-2.5 if film isn’t identified do 2.2-2.3-2.4-2.5
In einem Diagramm sieht der Sachverhalt folgermaßen aus:
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
--FloEckert 23:24, 17. Apr. 2008 (CEST)