Anforderungen aus Dokumenten gewinnen
Tags: paper, qualitative
Kategorie Promotion | 1 Kommentar »
Vor einiger Zeit versprach ich in meinem Bericht über die diesjährige deutsche Software Engineering Konferenz auch meine Arbeit hier vorzustellen. Im Gegensatz zu den sonst hier üblichen Themen hat sich das Paper primär mit dem Anforderungsmanagement beschäftigt. Deshalb heute zunächst ein kurzer Überblick über ein Teilgebiet des Anforderungsmanagement – die Gewinnung von Anforderungen.
Das Anforderungsmanagement (engl. Requirements Engineering) hat sich über die Jahre von einer Teildisziplin des Software Engineering hin zu einer eigenen Wissenschaftsdisziplin entwickelt. Deshalb gibt es auch eine Reihe von internationalen Konferenzen, die sich ausschließlich damit beschäftigen. In Deutschland gibt es auch einige Lehrstühle zu dem Thema, aber es gibt, glaube ich, keine eigene Hauptkonferenz zum Thema.
Das Anforderungsmanagement kann man in mehrere Teilgebiete unterteilen (nach Kotonya und Sommerville):
- Gewinnung/Extrahierung von Anforderungen (engl. Requirements Elicitation)
- Analyse und Definition von Anforderungen (engl. Requirements Analysis and Negotiation)
- Dokumentation von Anforderungen (engl. Requirements Documentation)
- Validierung von Anforderungen (engl. Requirements Validation)
In jedem dieser Teilgebiete wurde in den letzten 20 Jahren enorm viel Wissen angehäuft, auch wenn viel davon bis heute nicht in der Praxis angekommen ist. Klar ist, dass man sich wiederum auf eines der Gebiete beschränken muss. Ich habe in meiner Studie untersucht, wie man im Rahmen des Requirements Elicitation Anforderungen aus vorhandenen Dokumenten gewinnen kann.
Es gibt von Zhang ein wunderbares Paper über die bis heute bekannten Techniken zur Erhebung von Anforderungen und wann man welche davon einsetzen sollte. Er unterscheidet die Techniken in 4 Kategorien:
- observational, also z.B. die zukünftigen Nutzer der Software beobachten
- conversational, also z.B. mit den zukünftigen Nutzern der Software sprechen
- analytic, also z.B. die Aufgabenstellung immer feiner untergliedern
- synthetic, also z.B. aus vorhandenen Teilwissen die Anforderungen ableiten
Weiterhin sagt Zhang, dass man Requirements Elicitation noch in 2 Teilphasen einteilen muss und Techniken nicht unbedingt für beide Phasen gut geeignet sein müssen:
- Problemanalyse
- Produktspezifikation
Allgemein gilt, dass man mit den zukünftigen Nutzern sprechen sollte, wenn man Zugang zu ihnen hat. Dazu zählt auch, dass man die Nutzer bei ihrer Arbeit beobachtet, damit man die aktuellen Probleme versteht, bevor man nach einer Lösung, z.B. durch Einführung einer neuen oder geänderten Software, sucht.
Problem dabei ist, dass man nicht immer Zugang zu den zukünftigen Nutzern hat. Dies ist typischerweise immer dann der Fall, wenn man für einen Massenmarkt produziert (Standardsoftware) und nicht eine Software für einen speziellen Kunden schreibt (engl. bespoke project). In verschiedenen Büchern zum Requirements Engineering und Software Engineering liest man dann, dass man versuchen soll auf vorhandene Dokumente zurückzugreifen, um die Problemanalyse auf Basis des dort kodierten Wissens durchzuführen.
Schaut man dann etwas tiefer in die vorhandene Methodenliteratur stellt man fest, dass es fast gar keine Untersuchungen gibt, wie man denn nun effektiv Dokumente analysiert. Reicht es zum Beispiel aus, die Dokumente einfach zu lesen? Mein Bauch sagt mir, dass das nicht sehr effektiv sein kann, denn meist hat man schon nach wenigen Tagen den größten Teil bzw. die Details eines Buches oder Artikels vergessen. Sinnvoller erscheint, mit einer strukturierten Methode den Text zu bearbeiten, um ihn umfassend zu analysieren und auch selbst ein Verständnis aufzubauen. Dies mag sich hochtrabend anhören, aber die meisten Studenten haben ein eigenes System entwickelt, indem sie etwa wichtige Textpassagen im Buch farblich hervorheben oder sich Notizen zum Text machen.
Tatsächlich gibt es bis heute lediglich 2 dokumentierte Techniken, um Anforderungen aus Dokumenten zu gewinnen. In einer bereits etwas älteren Studie haben Rayson et al. untersucht, ob man Natural Language Processing (NLP) Algorithmen verwenden kann (Wikipedia Eintrag zu NLP). Vereinfacht gesprochen haben sie untersucht, ob man mit Spracherkennung Anforderungen aus vorhandenen Dokumenten gewinnen kann. Prinzipiell geht dies natürlich, allerdings erhält man nach solch einer automatisierten Analyse lediglich eine vom Rechner erzeugte Liste, die man dann nochmal selbst untersuchen muss, ob denn alles relevant ist. Ein ganz klarer Vorteil ist natürlich, dass das Verfahren auch bei sehr umfangreichen Dokumenten funktioniert. Nachteil ist, dass man selbst kaum ein Verständnis für die Domain aufbaut, da man die Dokumente nicht selbst liest, sondern lediglich eine automatisch erzeugte Zusammenfassung betrachtet.
Eine anders geartete Technik nennt sich Content Analysis und wurde von O’Shea und Exton ebenfalls zur Gewinnung von Anforderungen verwendet. Hier geht der Untersucher durch den Text und ordnet Textteile Kategorien zu. Die Kategorien werden vor der eigentlichen Analyse aufgestellt. Nachdem der Text kategorisiert wurde, schaut man, welche Kategorien häufig verwendet wurden und geht davon aus, dass diese Kategorien dann wichtige Anforderungen beschreiben. O’Shea und Exton haben so zum Beispiel eine Reihe von Fehlerberichten analysiert, um Anforderungen an eine Software abzuleiten. Nachteil ist, dass man durch die fixen Kategorien etwas eingeschränkt ist. Auch ist es fraglich, ob wirklich immer die am häufigsten verwendeten Kategorien die wichtigsten Anforderungen repräsentieren.
In meinem Paper habe ich dem Kanon an Methoden nun eine 3. Technik hinzugefügt. Was ich aber genau getan habe, verrate ich dann in meinem nächsten Beitrag.
[…] meinem letzten Beitrag hatte ich gezeigt, dass es nur relativ wenige konkrete Techniken gibt, um Anforderungen aus Dokumenten zu gewinnen. Dies ist verwunderlich, da in Lehrbüchern zum Anforderungsmanagement existierende Dokumente als […]