Quelltext der Seite Anforderungs- und Bedarfsanalyse

[[definition::Die Anforderungs- und Bedarfsanalyse lässt sich in die Gruppe der [[Informationsbedarfsanalyse]]n einordnen. Sie wird in der Softwarekonzeption eingesetzt, um Bedarf und Anforderung an ein zu konzipierendes 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 der Bedarfsaufdeckung zur 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, das 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 sich später in Form statistischer Auswertungen ein genaues Bild der Erhebungssituation machen. Will man sich einen breiten Überblick über die Situation verschaffen, 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 Designprozesses 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]]). Die 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 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 Schauspieler 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.“''


*'''[[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:'''

[[Bild:Essential usecase.jpg]]


===Aufgabenanalyse: (task analysis)===
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:
[[Bild:hierachical Task Analysis.jpg]]

== 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
--[[Benutzer:FloEckert|FloEckert]] 23:24, 17. Apr. 2008 (CEST)

[[category:Gesellschaftliche Aspekte von Information]]
[[category:Informationsarbeit]]

==verwandte Begriffe==
*[[broader::Analyse]]