Anforderungen an Softwareprodukte klar definieren Requirements Engineering für Projektleiter
Die Merkmale der neuen Software sind festgelegt, der Funktionsumfang ist in Form von Use Cases modelliert. Als nächstes geht es darum, die Use Cases weiter zu detaillieren und daraus klare, für die Entwickler verständliche Anforderungen abzuleiten. Wie Sie dazu vorgehen, erklären Bettina Zastrow und Elisabeth Wagner in diesem dritten und abschließenden Teil der Artikelfolge.
Anforderungen an Softwareprodukte klar definieren Requirements Engineering für Projektleiter
Die Merkmale der neuen Software sind festgelegt, der Funktionsumfang ist in Form von Use Cases modelliert. Als nächstes geht es darum, die Use Cases weiter zu detaillieren und daraus klare, für die Entwickler verständliche Anforderungen abzuleiten. Wie Sie dazu vorgehen, erklären Bettina Zastrow und Elisabeth Wagner in diesem dritten und abschließenden Teil der Artikelfolge.
Die Formulierung realistischer, eindeutiger und vollständiger Anforderungen hilft dem Projektleiter, der eine Software in Auftrag gibt, tatsächlich das System zu bekommen, das er will. Der erste Teil dieser Serie zeigt, wie die Software und die Rahmenbedingungen aus der Perspektive der Nutzer definiert werden. Der zweite Teil beschreibt die Formulierung der Use Cases: Was will welcher Akteur mit dem System tun? In diesem dritten und letzten Teil der Artikelfolge geht es darum, das Ziel der Softwareentwicklung aus Sicht der Entwickler zu beschreiben.
Sind die Use Cases fertig modelliert und zu Features zusammengefasst, lassen sich daraus die Anforderungen ableiten. Jedem Use Case werden dabei üblicherweise eine oder mehrere Anforderungen zugeordnet.
Mit Anforderungen sind hier standardisierte Sätze gemeint, die Ansprüche und Wünsche der Benutzer an die Funktionalitäten einer Software beschreiben. Auch Schnittstellen zu angrenzenden Systemen und eigenständige Systemprozesse sind zu berücksichtigen. Darüber hinaus können Vorgaben von außen existieren, z.B. aus firmeninternen Regelwerken, die ebenfalls als Anforderungen formuliert werden.
Definition: funktionale und nichtfunktionale Anforderungen
Ein Use Case beschreibt Funktionen, die ein Akteur mithilfe des Systems ausführen möchte. Daraus abgeleitete Anforderungen werden als "funktionale Anforderungen" bezeichnet. Sie beschreiben jeweils einen der folgenden drei Fälle:
- eine Interaktion zwischen dem Benutzer und dem System,
- eine Interaktion zwischen dem System und einem anderen System oder
- eine selbstständige Systemaktion aufgrund eines zeitlichen oder ereignisgesteuerten Auslösers.
Darüber hinaus ergeben sich weitere Anforderungen, z.B. rechtlicher, kultureller, sicherheitstechnischer Art, usw., die für die Anwendungsentwicklung bekannt sein müssen. Diese Anforderungen außerhalb der Use Cases werden als "nichtfunktional" bezeichnet (siehe Abschnitt "Nichtfunktionale Anforderungen berücksichtigen").
Funktionale Anforderungen ermitteln
Wünsche und Vorgaben der Stakeholder lassen sich am besten in Einzelinterviews ermitteln. Als Diskussionsgrundlage kann eine Liste der Use Cases dienen. Projektleiter und Stakeholder nehmen dabei die gleiche Perspektive auf das System ein und erarbeiten gemeinsam die Anforderungen aus der Nutzerperspektive, z.B. indem sie die Workflows zu den jeweiligen Use Cases durchgehen: Was sind z.B. für den Use Case "Nutzer registriert sich am System" die Voraussetzungen, was passiert im Hintergrund und was ist das Ergebnis?
Die Schwierigkeit ist hier häufig, exotische Anforderungen einzudämmen und die maßgeblichen Aspekte im Auge zu behalten, wie z.B. bei obigem Beispiel "Systemregistrierung" die Regeln für die Kennwortsicherheit.
Das Arbeitsergebnis ist eine Liste von Anforderungen aus dieser Nutzerrolle. Soweit möglich, sind die Anforderungen direkt im Format der SOPHIST® Satzschablone zu erfassen (siehe Abschnitt "Qualitätskriterien"). Anderenfalls reichen auch komplette Sätze aus, welche die Rolle, die Aktion und ggf. die Bedingung für die Ausführung beschreiben. Das Augenmerk ist dabei auf die vollständige Erfassung aller Anforderungen zu richten, die sich aus dem jeweiligen Use Case ergeben. Geschulte SW-Entwickler können hier gut unterstützen. Prüfung, Konsolidierung und Ergänzungen erfolgen in einem späteren Schritt.
Um die Nachvollziehbarkeit zu gewährleisten, ist es ratsam, jede Anforderung bei der Erfassung mit einer Quellenangabe zu versehen. Dies ist auch später nützlich bei der Vergabe von Prioritäten.
Ein typischer Stolperstein ist die Schwierigkeit, Anforderungen am Rande des Spektrums zu erkennen und einzubeziehen. Am unteren Ende sind dies die banal erscheinenden Anforderungen, wie z.B. die Druckfunktion oder die Onlinehilfe, die so selbstverständlich sind, dass vergessen wird, sie explizit zu erwähnen. Am oberen Ende steht die Bedienbarkeit, auch als "Usability" bezeichnet. Zur Usability gehört es, die Benutzeroberfläche nach den Gesetzen der visuellen Wahrnehmung aufzubauen und effiziente Funktionen zu gestalten, die mit wenigen Schritten ausführbar sind.
Christian Singer
11.02.2016