Übersicht Anforderungsanalyse

Die wesentliche Struktur und Techniken der Anforderungsanalyse in knappe Stichworte verpackt.

Direktlink zum Bild (z.B. Rechtsklick -> In neuem Tab öffnen)

Auf eine nähere Erläuterung der einzelnen Punkte möchte ich an dieser Stelle verzichten.

Übersicht Wissen

Bei der Wissenserhebung ist es wichtig, dass man unterscheiden kann, welche Arten von Wissen es gibt und wie man an dieses gelangen kann. So sind Fachbücher und andere Texte oft nicht wirklich hilfreich. In diesem Fall muss das Wissen von den Experten selbst stammen. Neben den Klassikern wie Interviews und Fragebögen gibt es interessante Ansätze, um vor allem an implizites Wissen zu gelangen. Vor allem durch Spiele kann man so zu Erkenntnissen gelangen, die der Experte von sich aus nie genannt oder nicht hätte formulieren können.

Direktlink zum Bild (z.B. Rechtsklick -> In neuem Tab öffnen)

Analysis-Synthesis-Bridge-Model

Das Brückenmodell beschreibt das Vorgehen während der Anforderungsanalyse, insbesondere der Recherche und des Prototypings. Es ist im wesentlichen eine Vierfeldertafel:

Die Tafel beschreibt die Schritte, die es zu beachten gilt.

1. Man benötigt detaillierte Kenntnisse über die aktuelle Situation, in welcher die Software eingesetzt werden soll. Um Probleme zu beheben, ist es absolut notwendig, diese zunächst genau zu verstehen.
2. Die Situation muss modelliert werden. Es entsteht ein deskriptives Modell, welches die Realität auf das wesentliche reduziert. Dies heißt auch, dass zu behebende Probleme mit modelliert werden und deren Behebung im Modell möglich ist.
3. Aufgrund dieses Modells gilt es Lösungen zu finden und diese in das Modell zu integrieren. Um sicherzugehen, dass ein Ansatz auch wirklich funktioniert, ist hier ein Prototyp ein geeigneter Ansatz.
4. Die gefundenen Lösungen müssen auf ihre Realitätsnähe geprüft werden. Dies beinhaltet selbstverständlich, dass die modellierte Lösung auch wirklich funktioniert. Aber auch andere Aspekte sind wichtig: Wird der Nutzer die Software auch wirklich so nutzen, dass das Problem gelöst wird? Wird dies in angemessener Zeit möglich sein? Sind hierfür ausführliche Schulungen notwendig? Neben der Effektivität der Lösung ist somit auch immer ihre Effizienz in Bezug auf ihre Benutzbarkeit zu beachten.

Unser Vorgehen bei Tweedback

Die ersten drei Schritte macht jeder Software-Entwickler intuitiv richtig. Das Problem ist vor allem der vierte. Auch wir sind bei Tweedback sauber der Vorgabe gefolgt: Wir haben das Problem analysiert, modelliert und eine Lösung auf dem Modell erarbeitet.

Wir haben uns bewusst gemacht, welche Probleme es in Vorlesungen gibt und detailliert beschrieben, welche Fragestellungen bei Studenten aufkommen. Anschließend haben wir die Dozenten betrachtet und uns mit dem Problem auseinandergesetzt, dass diese sich nicht auf Feedback-Bildschirme konzentrieren können, sondern Auf-einen-Blick-Übersichten benötigen.

Das Problem mit dem vierten Schritt

Das Ergebnis war eine detaillierte Vorstellung von Nachrichten, die zwischen Studenten und Dozenten ausgetauscht werden müssen. Diese gilt es nun ein- und auszugeben. Folglich versucht man möglichst knappe und intuitive Darstellungsmöglichkeiten und Eingabemasken zu entwickeln.

Was an sich nicht verwerflich klingt ist aber schnell falsch gemacht: Man baut auf sein eigenes Wissen um Programm- und Nachrichtenstruktur. Man kennt die einzelnen Funktionen des Programmes und bildet diese auf knapp bemessene Formulare ab. Für die Direktevaluierung fragt man sich vor allem eines: Würde ich Funktion x auf der Programmoberfläche finden? Diese Frage unterstellt aber, dass der Nutzer um Funktion x weiß. Dies ist aber vor allem am Anfang keineswegs der Fall.

Nicht „Wie mache ich was?“, sondern „Was kann ich machen?“

Und hier ist vor allem der vierte Schritt wichtig: Man muss sich bewusst werden, wer in welcher Situation mit der Oberfläche arbeiten muss. Es geht darum zu erkennen, was ein Nutzer von einem Programm erwartet. Da er keinerlei Vorwissen über interne Abläufe und Funktionen mitbringt, sucht der Nutzer auf der Oberfläche nach Möglichkeiten, seine Erwartungen umzusetzen. Dabei gilt es ihn an die Hand zu nehmen und Möglichkeiten aufzuzeigen.

Wir wussten um unsere Konzepte: Wir haben die Formulare zur Teilnahme an einer Veranstaltung und Erzeugung neuer Veranstaltungen nebeneinander gestellt. Wir wussten, wann welches zu nutzen ist. Die Frage, ob jeder Nutzer überhaupt den Unterschied versteht, stellt man sich hingegen nicht mehr. Auch unsere nächste Darstellung war für uns klar: Man kann bereits dargestellte Rückmeldungen anderer unterstützen. Folglich sucht man diese Möglichkeit in der darstellenden Feedback-Wolke. Weiß ein Nutzer allerdings nichts von dieser Möglichkeit, wird ihm diese auch verborgen bleiben.

Erwischt man sich bei solchen Problemen, redet man sich schnell damit raus, dass es sich nur um einen Prototypen handele. Aber das verschärft das Problem: Man gewöhnt sich an ein Konzept und hält es für selbstverständlich. Bei der Implementierung möchte man schnell und effizient arbeiten, man möchte fertig werden. Daher ist es aber gerade so wichtig, dass eine effiziente Darstellung des Programms und seiner Funktionen möglichst früh zu durchdenken und zu implementieren. Es sind vor allem Details, die bei der Fertigstellung gerne mal vergessen werden.

Aller Anfang…

Auch empfiehlt es sich, Stakeholder (von dem Projekt betroffene) und andere Quellen für das nötige Wissen aufzulisten. Man muss sich klar darüber werden, wer für welche Bereiche zuständig ist, als Ansprechpartner bei Fragen dienen kann und unbedingt nach seinen persönlichen Anforderungen befragt werden muss. Auch Dokumente jeder Art sollten nicht vergessen werden. Handbücher, Berichte, Lehrbücher, wissenschaftliche Arbeiten – all diese Dinge können den Einstieg in ein Thema sehr erleichtern.

Textdokumente

Texte können viel über ein Aufgabengebiet verraten. Während das Lesen das persönliche Verständnis verbessern kann, gibt es auch analytischere Ansätze:

Strukturanalyse

Schon das Inhaltsverzeichnis kann wichtige Teilbereiche des Themas und ihre Zusammenhänge verdeutlichen.

Inhaltsanalyse

Aus dem Text lassen sich vor allem relevante Begriffe extrahieren. Diese können innerhalb späterer Entwicklungsphasen genutzt werden und so das Verständnis verbessern (z.B. Klassennamen, Relationen etc.). Die Erstellung eines Glossars bietet sich an dieser Stelle an.

Probleme

Textdokumente müssen auch kritisch betrachtet werden. Sie sind oft aus Sicht der Experten geschrieben und für den Laien oft unverständlich, da diesem nötiges Basiswissen fehlt. Schlimmer ist es, wenn man aus einem Text die falschen Konzeptualisierung schlussfolgert. Da Texte keine Rückfragen erlauben, können eventuelle Missverständnisse zunächst nicht ausgeräumt werden.

Konzeptualisierung

Ein wichtiger Begriff der Wissenserhebung ist die Konzeptualisierung. Sie beschreibt das Verständnis von bestimmten Dingen im Kontext eines bestimmten Problems. Es ist somit eine Form der Abstraktion, einem Beschränken auf das Wesentliche einer Sache. Eine genauere Erklärung findet sich auf der Seite der ARTM-Friends.

Experten als Wissensquelle

Eine sehr wichtige Wissensquelle sind die Experten des entsprechenden Gebiets. Sie sind die einzigen, die wirklich sichere Einblicke in ein Thema ermöglichen und wesentliche Anforderungen auflisten können.

Hierbei sollte man beachten, dass verschiedene Expertentypen unterschiedliche Standpunkte und Meinungen zu ein und dem selben Thema haben können. Es ist somit immer empfehlenswert, eine ausgeglichene Auswahl zu treffen und z.B. sowohl den Manager als auch den einfachen Angestellten zu befragen, auch wenn diese jeweils bereits über genug Wissen über ein bestimmtes Thema verfügen.

Einfache Wissenserhebungsmethoden

Ein einfacher und wirkungsvoller Einstieg in ein Thema ist die einfache Beobachtung. Beim sogenannten „Work-Shadowing“ verfolgt man einen Experten bei seiner normalen Arbeit. Man beobachtet, macht Notizen oder stellt Zwischenfragen, um ein detailliertes Bild des Arbeitsablaufs zu bekommen. Hierbei kann man vor allem implizites Wissen (Wissen um eine Sache oder Tätigkeit, die schwer oder gar nicht zu beschreiben ist) und Prozesswissen (man lernt, wie etwas gemacht wird).

Bei einem Interview kann man viel explizites Wissen erheben, also vor allem Wissen, welches der Experte bewusst und als relevant einschätzt. Neben dem Prozesswissen kann der Experte im Interview auch Konzeptwissen mitteilen. Man lernt also nicht nur wie, sondern ob und warum bestimmte Dinge gemacht werden.

Eine spezielle Form des Interviews ist das „Structured Hierarchical Interviewing for Requirement Analysis“ (SHIRA). Es ist eine einfache Herangehensweise, bei der man nicht viel Vorwissen benötigt. Man stellt hierbei drei Fragen zu interessanten Konzepten:

1. Was ist das Konzept x?
2. Welche Eigenschaft sollte x haben? (z.B. einfach bedienbar)
3. Wie muss x sein, um diese Eigenschaft zu erfüllen?

Man erfährt so etwas über wichtige Konzepteigenschaften und wie diese zu erreichen sind.

Fragebögen sind eine gute Möglichkeit, schnell, günstig und unaufdringlich eine Vielzahl an Interviews zu simulieren.

Ausgeklügelte Wissenserhebungsmethoden

Diese Methoden nutzen bestimmte psychologisch geprägte Techniken, um vor allem auch implizites Wissen zu erhalten.

So werden beim Card-Sorting mehrere relevante Konzepte auf Karten geschrieben. Der Experte hat nun die Aufgabe, diese Karten auf diversen Stapeln zusammenzufassen und diese anzuordnen. Hierbei kann man viel implizites Konzeptwissen erheben, da die Ordnung oft nach Gefühl und weniger nach klar benennbaren Kategorien erfolgt.

Beim Triadic-Elicitation werden drei Konzeptkarten gewählt. Der Experte soll nun sagen, in welcher Eigenschaft sich zwei der Karten gleichen, die dritte aber unterscheidet. Auch hier wird viel Fantasie benötigt um die Aufgabe zu erfüllen. Dies offenbart daher oft Eigenschaften, die vom Experten sonst als nicht-relevant betrachtet wurden oder ihm gar nicht bewusst waren.

Das Repertory-Grid verdeutlicht Konzepte, Attribute und die Beziehungen untereinander. Hierbei wird eine Liste von Konzepten jeweils mit einer Liste von Attributen bewertet:

Anschließend sollen die Bewertungen vom Experten analysiert werden: Gibt es vielleicht einen Grund, warum die Konzepte x, y, z in den Attributen a und b so schlecht abschneiden?

Fazit

Es gibt viele Möglichkeiten an Wissen zu kommen. In aller Regel wird man sich mit Interviews begnügen. Ist jedoch ein tiefgreifenderes Verständnis für ein langfristiges Projekt notwendig, ist es hilfreich um die vielen kleinen Tricks zu wissen, die auch verborgene Erkenntnisse an die Oberfläche bringen.

Quellen

Dieser Artikel basiert auf meinen Erkenntnissen und Mitschriften aus Vorlesungen an der Universität Rostock. Maßgeblich für dieses Thema ist die Vorlesung „Requirements Engineering“ des Lehrstuhls für Softwareentwicklung.

Anforderungen vollständig und korrekt zu dokumentieren hat aber auch weitere Zwecke:

• Dokumente können als Vertragsbestandteil zwischen Dienstleistern und Kunden dienen
• ermöglicht eine zuverlässigere Einschätzung des Entwicklungsaufwandes
• Entwickler haben eine genaue und vollständige Liste der umzusetzenden Funktionen
• Softwaretester haben realitätsnahe Qualitätsvorgaben

Kategorisierung von Anforderungen

Betrachten wir übliche Anforderungen genauer, gibt es vor allem zwei Kategorien, die auffallen: „Der Administrator soll neue Nutzer hinzufügen können.“ bezeichnet klar, was das Programm können soll. Hier haben wir eine konkrete Forderung, die der Entwickler umsetzen und abhaken kann. Dem gegenüber stehen weniger klare Forderungen wie „Auch ungeschultes Personal soll die Software effizient einsetzen können.“ Hier steht der Entwickler vor einem Problem, da sich die Anforderung nicht eindeutig prüfen lässt. Zur Vereinfachung wird daher oft versucht, messbare Parameter in solche Formulierungen einzubringen: „Ungeschultes Personal soll innerhalb von drei Minuten einen neuen Nutzer anlegen können.“

Genannte Unterteilung ist auch in der Literatur sehr üblich und wird oft folgendermaßen benannt:

Funktionale Anforderungen

Die Anforderung beschreibt, was das Produkt tun soll (eine bestimmte Produktfunktion).

Nichtfunktionale Anforderungen

Die Anforderung beschreibt eine Eigenschaft des Produktes oder einer bestimmten Funktion.

Ob Vertragsdetails wie die Entwicklungszeit eine nichtfunktionale Anforderung darstellen ist strittig. Meist werden sie jedoch nicht dazu gezählt.

Was es zu erfassen gilt

Wie und in welchem Umfang Anforderungen dokumentiert werden sollten ist unterschiedlich. Um jedoch nichts wichtiges zu vergessen, bietet sich eine vollständige Liste üblicher Fakten an, die über Produkte erhoben werden können.

Eine Empfehlung des Aufbaus eines Dokuments zur Erfassung von Anforderungen gibt der Standard IEEE 830-199:

Table of Contents

1. Introduction
   1. Purpose
   2. Scope
   3. Definitions, acronyms, and abbreviations
   4. References
   5. Overview
2. Overall description
   1. Product perspective
   2. Product functions
   3. User characteristics
   4. Constraints
   5. Assumptions and dependencies
3. Specific requirements
4. Appendix

aus [IEEE 830-199]

Die Vorgehensweise

Ist man sich nicht klar, wie man zu den gewünschten Ergebnissen kommen kann, ist eine systematische Vorgehensweise empfehlenswert (vgl. [Pfleeger 2001]):

In den benannten Phasen wird im wesentlichen folgendes getan:

1. Was soll das Endprodukt leisten? Wer soll es nutzen oder ist anderweitig betroffen und sollte daher befragt werden?
2. Hier erfolgt eine konkrete Auflistung der Probleme durch die betroffenen Kunden (von einem Produkt betroffene Menschen werden auch „Stakeholder“ genannt). Dies entspricht einer Liste an Produktfunktionen und -eigenschaften und entspricht somit dem Lastenheft.
3. Die Entwickler müssen prüfen, inwieweit die Anforderungen umsetzbar sind.
4. Die gesammelten Erkenntnisse werden dokumentiert und überprüft. Dies ergibt ein für Verträge oft maßgebliches Pflichtenheft, in dem der Entwickler konkret aufzählt, welche Leistungen erbracht werden sollen.

Qualitätsansprüche

Eine erfolgreiche Anforderungsanalyse sollte im wesentlichen drei Eigenschaften erfüllen (vgl. [Jarke 1995]). Während und vor allem nach der Fertigstellung der Dokumente, sollte man sich einige Fragen stellen:

• Ist die Spezifikation wirklich vollständig?
• Sind die Anforderungen formal dargestellt und somit allgemein verständlich?
• Habe ich auch wirklich umgesetzt, was der Kunde von mir wollte? Habe ich die Kundensicht beachtet?

Kann man jede dieser Fragen mit einem ehrlichen ja beantworten, sollte einer erfolgreichen Umsetzung nun nichts mehr im Weg stehen.