next up previous contents
Next: 8.7 Umgang mit Risiken Up: 8. Anforderungsbestimmung Previous: 8.5 Analyse der Anforderungen

Unterabschnitte

8.6 Grundtechniken

Dieser Abschnitt skizziert das Repertoire von Basistechniken, die zur Anforderungsbestimmung zur Verfügung stehen. Der Einsatz dieser Techniken kann in sehr verschiedenen Zusammenhängen und zu verschiedenen Zwecken erfolgen; ebenso kann die konkrete technische Ausprägung recht unterschiedlich sein. Auf alle diese Aspekte können wir hier nicht näher eingehen.

8.6.1 Befragungstechniken

Befragungstechniken sind tendenziell analytikergetrieben, d.h. die Aktivität, die die Richtung bestimmt, in der die Anforderungsanalyse fortschreitet, geht überwiegend vom Analytiker aus.

Die klassische Technik zur Systemanalyse in diesem Zusammenhang ist das Interview. Interviews mit Benutzern streben an, direkt von den einzelnen betroffenen Anwendern möglichst präzise und unverfälschte Auskünfte über deren Anforderungen zu bekommen. Demgegenüber wird bei Interviews mit Kontaktpersonen nur je ein Vertreter einer ganzen Personengruppe interviewt. Dieses Verfahren ist effizienter, führt aber auch eher zu inkorrekter und unvollständiger Information.

Umfragen in Freitextform oder mittels Fragebogen sind ebenfalls ein recht effizienter Weg, Anforderungsinformationen zu erhalten und erlauben die Einbeziehung einer recht großen Zahl von Anwendern. Wegen der fehlenden Interaktion sind sie jedoch nur zur Klärung von Fragen geeignet, bei denen voraussichtlich alle relevanten Alternativen bereits bekannt sind.

Gespräche im Marketing und auf Messen sind ähnlich zu beurteilen wie Interviews mit Kontaktpersonen. Sie haben den zusätzlichen Vorteil, daß der betreffende Anwender meist ein aktives und produktorientiertes Interesse an dem Gespräch hat, jedoch den Nachteil, das der Detaillierungsgrad eventuell zu gering bleibt und ein zweites Gespräch zur Klärung späterer Rückfragen oft schwer möglich ist.

8.6.2 Sammeltechniken

Bei Sammeltechniken geht die Aktivität vom Anwender aus. Diese Klasse von Techniken eignet sich deshalb vor allem zur Verfeinerung von Anforderungskatalogen bei bereits existierender Software, also zur Vorbereitung einer neuen Softwareversion.

An Quellen zum Sammeln von Anforderungen steht erstens die Hotline (telefonisch oder per Email) zur Verfügung. Hieraus können vor allem existierende Schwachstellen der Software im Hinblick auf die Benutzerschnittstelle und Dokumentation entdeckt werden. Wünsche von einzelnen Benutzern decken hingegen vor allem fehlende Funktionalität ab. Die Qualität solcher Information ist gut, weil die Anforderungen aus konkreten praktischen Problemen erwachsen. Noch besser zu beurteilen sind oft Wünsche von organisierten Benutzergruppen, weil hier die Wünsche bereits durch Diskussion gefiltert und ausgereift sind. In vielen Fällen legen Benutzergruppen ganze Entwurfsvorschläge vor.

8.6.3 Gruppentechniken

Gruppentechniken, zumeist in Form gemeinsamer Sitzungen von Analytiker(n) und mehreren Anwendern, balancieren die Aktivität zwischen beiden Gruppen. Die Anforderungsbestimmung kann partnerschaftlich vorgenommen werden. Das ist bei Interviewtechniken meist deshalb nicht möglich, weil einzelne Anwender nicht genügend Initiative in die Diskussion einbringen, um sie sinnvoll zu steuern.

Die klassische Perspektive von Gruppensitzungen besagt, daß zwar Analytiker und Anwender ein Team bilden sollen, die Verantwortung für die Herstellung des Anforderungskatalogs aber letztendlich bei den Analytikern liegt.

Partizipatorischer Entwurf dreht dies quasi um: Die Analytiker werden eher als Zuarbeiter der Anwender betrachtet, die in einem demokratischen Prozeß ,,ihre`` Anforderungen definieren sollen. Die Idee des partizipatorischen Entwurfs ist vor allem im skandinavischen Raum populär.

8.6.4 Beobachtungstechniken

Beobachtungstechniken machen die Anforderungsbestimmung quasi implizit: Es werden nicht verbal Ansichten über Anforderungen zwischen Analytikern und Anwendern ausgetauscht, sondern die Anwender tun die Arbeit, die das Softwaresystem unterstützen soll und die Analytiker extrahieren die Anforderungen aus ihren Beobachtungen dieser Arbeit. Dieses Paradigma ist bei weitem nicht immer einsetzbar, hat dann aber den Vorzug, praxisrelevante Anforderungen mit hoher Wahrscheinlichkeit sichtbar zu machen.

Beispiele sind Benutzbarkeitslabors, in denen existierende Software und Prototypen als Grundlage für konkrete Anforderungsbestimmungen dienen. Damit verwandt ist die Technik der Protokollauswertung, die als Beobachtungsgrundlage Daten benutzt, die von speziell instrumentierten Programmen mit Einverständnis der Benutzer während derer normaler Arbeit gesammelt wurden. Diese Techniken eignen sich besonders zum Ausbügeln einzelner Schwächen von Software, die zu Fehlern bei der Arbeit führen, und zur Verbesserung von Benutzerschnittstellen.

Reichen diese Möglichkeiten nicht aus, so kann Feldbeobachtung helfen, bei der Anwender direkt in ihrer Arbeit beobachtet werden, um Anforderungen zu ermitteln. Problematisch an Feldbeobachtungen kann erstens der hohe Aufwand sein und zweitens die Tatsache, daß viele Anwender unter Beobachtung befangen sind, sich unwohl fühlen und deshalb möglicherweise nicht so arbeiten wie sonst üblich.

Eine verfeinerte Feldbeobachtungsmethode ist das ,,in die Lehre gehen``[BH95]: Ein Analytiker begleitet den Anwender bei seiner täglichen Arbeit wie ein Lehrling, der alle Arbeitsgänge erst verstehenlernen muß. Bereits das bloße Zuschauen liefert gute Informationen darüber, worauf es ankommt und zwar sowohl in großen Strukturen, als auch in Details. Zusätzlich ermöglichst das In-die-Lehre-Gehen Zugriff auf die Erfahrungen des Anwenders durch direkte Nachfragen. Ein Sich-beobachtet-Fühlen wird eher vermieden als bei normaler Feldbeobachtung, weil das In-die-Lehre-Gehen anerkennt, daß der Anwender, nicht der Analytiker, der Experte auf seinem Gebiet ist. Beyer und Holtzblatt schildern als mögliche Probleme erstens das Fallen in andere Beziehungsmodelle als Lehrer/Lehrling, zweitens das Abgleiten ins Abstrakte anstatt der Behandlung konkreter Fälle bei Nachfragen und drittens zu allgemeine Nachfragen des Analytikers anstatt Anbieten einer konkreten Interpretation, die der Anwender dann akzeptieren, ablehnen oder modifizieren kann.

8.6.5 Hilfsmittel

Es gibt (abgesehen von konkreten Werkzeugen und Notationen für spezifische Methoden) eine Reihe von Hilfsmitteln, die sich recht vielseitig einsetzen lassen.

Reservierte Räume. Soweit eine Anforderungsbestimmung ganz oder weit überwiegend in einem einzigen Gebäude stattfindet, ist ein gutes Hilfsmittel ein ständig dafür reservierter Raum. Erstens bietet dies Gelegenheit, eine Vielzahl von Zeichnungen, Notizen, etc. an den Wänden aufzuhängen, was eine besonders überschaubare und diskussionsfördernde Aufbewahrungsart der Zwischenergebnisse darstellt. Zweitens fördert ein solcher Raum das Zusammengehörigkeitsgefühl der Beteiligten und kann deshalb helfen, Kommunikations- und Kooperationsbarrieren abzubauen.

Prototypen sind das Mittel der Wahl, wenn es darum geht, kritische, aber ungenügend verstandene Konzepte zu prüfen, die eine wichtige Rolle in der anvisierten Software spielen sollen. In schwierigen Fällen kann man mehr oder weniger vollständige Prototypen eines Systems oder Systemteils bauen, zumeist wird man jedoch Scheinprototypen erstellen, deren Funktionalität getürkt ist und sich auf die Bearbeitung einer kleinen Zahl ,,festverdrahteter`` Anwendungsfälle beschränkt. Besonders hilfreich sind Prototypen von Benutzerschnittstellen. Prototypen lassen sehr viele Aspekte des Entwurfs bereits in die Anforderungsanalyse einfließen, was durchaus nützlich und kostensparend sein kann, obwohl es natürlich die Gefahr birgt, wichtige Implementationsentscheidungen zu früh und deshalb falsch zu treffen.

Papierprototypen sind Mengen von aus Papier ausgeschnittenen, beschrifteten und bemalten Schnipseln, die als Bausteine zur Veranschaulichung vorgeschlagener Systemfunktionen dienen. Diese Methode hat sich als sehr nützliches Hilfsmittel zur Beschleunigung und Konkretisierung der Diskussion über direkt benutzersichtbare Funktionalität erwiesen und wirkt vor allem durch Unterstützung der Vorstellungskraft und Vermeidung von Mißverständnissen.

Elektronisches Pflichtenheft: Wenn die betroffene Anwendergruppe aus eifrigen Computerbenutzern besteht, kann es hilfreich sein, ständig den aktuellen Stand der Anforderungsdiskussion elektronisch verfügbar zu halten; am besten als leicht erforschbares Hypertextdokument. Eine solche Maßnahme erlaubt, eine größere Zahl von Benutzern über einen längeren Zeitraum an der Diskussion lose zu beteiligen und kann deshalb gute zusätzliche Hinweise erbringen. Ein elektronisches Pflichtenheft ist vor allem dann wichtig, wenn der Entwurf der Software bereits nach Teilen der Anforderungsbestimmung beginnt, denn veraltete Papierdokumente sind eine fürchterliche Quelle von Fehlern.

Elektronische Diskussionsgruppen sind ebenfalls ein gutes Mittel, mehr Personen in den Prozeß einzubeziehen. Sie verringern außerdem durch ihren asynchronen Charakter eventuell den Zeitbedarf und vermeiden durch ihre Schriftform, daß Diskussionsbeiträge verlorengehen. Problematisch ist die Steuerung der Gewichtung: Zuwenig Aktivität in den Diskussionsgruppen macht sie wertlos, zuviel macht sie ineffizient.

Video kann ein unterstützendes Hilfsmittel bei vielen Techniken zur Anforderungsbestimmung sein. Anwender auf Videoband ,,mit nach Hause zu bringen`` (also zum Softwarehersteller) ermöglicht ggf. die Einbeziehung zusätzlicher Analytiker zu schwierigen Einzelfragen und die Klärung von im Nachhinein auftretenden Fragen (sowohl während der Anforderungsbestimmung als auch bei der Entwicklung und sogar in der Wartung) [BCW95]. Allerdings dürfen die Kosten für eine geeignete Verwaltung der Videoaufzeichnungen nicht unterschätzt werden. In Benutzbarkeitslabors erlauben Videoaufzeichnungen den Aufbau einer Bibliothek von ,,kritischen Anwendungsfällen``, für die im Systementwurf später geeignete Lösungen gesucht werden müssen.


next up previous contents
Next: 8.7 Umgang mit Risiken Up: 8. Anforderungsbestimmung Previous: 8.5 Analyse der Anforderungen
Lutz Prechelt
1999-04-13