Um die Ermittlung und Dokumentation von Anforderungen für Projekte geht es in der einhundertneunundfünfzigsten Episode des IT-Berufe-Podcasts.

Podcast: Play in new window | Download (Duration: 1:00:44 — 28.0MB)

Abonnieren: Apple Podcasts | Spotify | RSS

Inhalt

Spätestens für das Abschlussprojekt im dritten Ausbildungsjahr müssen alle Azubis in den IT-Berufen Anforderungen ermitteln. Wen man dabei berücksichtigen sollte, wie man die Anforderungen erhebt und wie man sie verständlich dokumentiert, das erkläre ich hier.

Qualität

Beginnen wir zunächst mit den Anforderungen selbst. Dabei starte ich gerne mit dem Begriff der Qualität. Qualität ist definiert als Übereinstimmung mit den Anforderungen. Dabei können diese Anforderungen von sehr unterschiedlichen Personen oder Personengruppen gestellt werden. Daher ist es wichtig, alle am Projekt beteiligten Personen zu befragen.

Anforderungen

Es gibt grundsätzlich zwei verschiedene Arten von Anforderungen: funktionale und nicht-funktionale. Funktionale Anforderungen beziehen sich direkt auf die zu erbringende Leistung des Produkts, bspw. die Möglichkeit, Text in einer Textverarbeitungssoftware fett darzustellen.

Nicht-funktionale Anforderungen beschreiben den ganzen Rest „drumherum“, also z.B. die Performance, Sicherheit, Stabilität, Fehlertoleranz, Benutzbarkeit usw. Sie sind meistens sehr schwer zu definieren, da sie oftmals nicht bewusst wahrgenommen, sondern einfach erwartet werden. Daher werden sie oft vergessen oder können nur schwer quantifiziert werden. Es ist unsere Aufgabe als Projektleiter diese Anforderungen trotzdem so gut es geht zu dokumentieren, damit es am Ende kein böses Erwachen gibt, wenn sie nicht umgesetzt sind.

Eine gute Übersicht über die zahlreichen möglichen nicht-funktionalen Anforderung bietet die Norm ISO 9126, die den Begriff der Softwarequalität definiert.

Stakeholder

Wer definiert überhaupt die Anforderungen an eine Software (oder allgemein an ein zu fertigendes Produkt)? Ein Stakeholder ist jede Person, Gruppe oder Institution, die an dem zu entwickelnden Produkt oder dessen Herstellungsprozess in irgendeiner Weise – positiv oder negativ – interessiert ist.

Hier kommt eine nicht vollständige Liste möglicher Stakeholder unserer Projekte.

• Kunde: Der Kunde bezahlt uns für das Projekt. Seine Anforderungen sollten wir auf jeden Fall berücksichtigen.
• Anwender: Der Anwender ist die Person, die letztendlich mit unserem Produkt täglich arbeiten muss.
• Management: Auch das Management könnte Anforderungen an unser Produkt stellen.
• Marketing: Aus dem Bereich des Marketings kommen Anforderungen wie die Corporate Identity.
• Entwickler: Die Entwickler haben ganz eigene Anforderungen, wie z.B. eine Versionverwaltung.
• Support: Der Support muss nach Einführung des Produkts den Anwendern Hilfestellung leisten und bringt seine ganz eigenen Anforderungen mit.
• Gesetzgeber: In fast jedem Projekt gilt es auch bestimmte Gesetze und Richtlinien einzuhalten.
• Standards: Gerade in der IT gibt es eine Fülle von Standards, an die wir uns halten sollten, z.B. HTTP für Webserver.
• Auditoren: Wirtschaftsprüfer und andere Auditoren stellen ebenfalls Anforderungen an unsere Software, wie z.B. die Nachvollziehbarkeit von Benutzeraktionen.
• Kulturkreis: Auch der Kulturkreis, in dem die Software eingesetzt wird, hat bestimmte Anforderungen. So kann sich z.B. die Sprache je nach Land deutlich unterscheiden.

Methoden zur Anforderungsermittlung

Wenn wir wissen, wenn wir nach Anforderungen fragen müssen, ist die nächste Aufgabe, die Anforderungen auch wirklich aus diesen Menschen herauszukommen. Dafür gibt es neben dem Interview auch verschiedene weitere Methoden.

• Interview: Die einfachste Methode ist wohl, den Stakeholder direkt zu befragen.
• Selbstaufschreibung: Wenn dies nicht möglich ist, kann er seine Anforderungen auch selbst verschriftlichen.
• Fragebogen: Etwas mehr Struktur bietet dabei eventuell ein vordefinierter Fragebogen.
• Brainstorming: Gerade zu Beginn eines Projekts kann sich ein Brainstorming zur allgemeinen Definition von Anforderungen anbieten.
• Mind-Mapping: Auch eine Mind-Map hilft vielleicht die verschiedenen Bereiche der Projektes zu betrachten.
• Apprenticing: Hierbei spielt der Anforderungsermittler „Azubi“ und lässt sich vom Anwender die Aufgaben erklären.
• Feldbeobachtung: Hierbei setzt sich der Anfoderungsermittler einfach neben den Anwender und beobachtet ihn bei seiner Arbeit.
• Workshop: In einem Workshop können mehrere Teilnehmer gemeinsam Anforderungen erarbeiten.
• Systemarchäologie: Wenn es schon ein bestehendes System gibt, können aus diesem Anforderungen für das neue System abgeleitet werden.
• Raten: Zuletzt kann es durchaus auch sinnvoll sein, einfach mal aufs Blaue drauflos zu raten.

Anforderungen an Anforderungen

Wenn wir nun wissen, wen wir was fragen müssen und wie wir dies tun können, müssen wir nur noch eine geeignete Form der Dokumentation der Anforderungen finden. Einige Anforderungen an die Definition der Anforderungen selbst folgen hier.

• eindeutig: Eine Anforderung soll immer eindeutig und nicht mehrdeutig sein, damit es keine Missverständnisse gibt.
• atomar: Anforderungen sollen nicht weiter unterteilbar sein.
• klein: Anforderungen dürfen nicht zu groß sein.
• schätzbar: Für die Projektplanung ist es wichtig, dass Anforderungen auch geschätzt werden können.
• unabhängig: Im besten Fall sind die Anforderungen unabhängig voneinander, damit die Umsetzung parallelisiert werden kann.
• nützlich: Die Anforderungen sollten auch einen echten Nutzen bringen.
• testbar: Wichtig ist auch festzulegen, wie die Umsetzung der Anforderungen geprüft werden kann.
• einheitlich: Zuletzt sollten Anforderungen immer gleichartig definiert werden. Wir schreiben keinen blumigen Roman.

Methoden zur Dokumentation von Anforderungen

Snow Cards aus dem Volere-Template

Snow Cards aus dem Volere-Template sind eine Möglichkeit, um Anforderungen detailliert zu definieren. Sie umfassen für jede Anforderung mehrere Felder, die ausgefüllt werden müssen. Damit ist eine Klassifizierung und Priorisierung sehr einfach möglich. Allerdings erfordern sie auch einen enormen Zeitinvest.

Allein das Inhaltsverzeichnis über die möglichen verschiedenen Anforderungen, die sich im Projekt ergeben können, ist mehrere Seiten lang. Auch wenn das Template selbst Geld kostet, kann dir die Übersicht der möglichen Anforderungen auf der Website vielleicht ein paar Hinweise geben, an was du in deinem Projekt noch denken musst.

User Stories

Eine einfache Möglichkeit, Anforderungen zu dokumentieren, stellen die User Stories aus dem Extreme Programming dar. Jede Anforderung besteht aus einem Satz, der aus der Sicht eines Anwenders beschreibt, was er mit der Software tun will und warum.

As a bank client,
I would like to log into the bank’s internet banking
in order to check my account balance.

Anhand dieser wenigen Informationen, die auch super auf kleine Karteikarten passen, können wir schon eine Priorisierung vornehmen, mögliche Alternativen finden und den Fokus auf die Umsetzung legen. Deswegen sind sie gerade in agilen Vorgehensmodellen wie Scrum, Kanban oder eXtreme Programming so beliebt.

MoSCoW

Außerdem kann man Anforderungen auch nach dem MoSCoW-System vorpriorisieren.

The system…
MUST have this
SHOULD have this if at all possible
COULD have this if it does not affect anything else
WON’T have this time but WOULD like in the future

Die MoSCoW-Methode finde ich sehr oft in Abschlussprojekten von IT-Azubis. Mit ihr lassen sich Anforderungen recht einfach priorisieren. Und oftmals reicht dies auch für den sehr begrenzten Umfang der Abschlussprojekte (80 bzw. 40 Stunden) aus.

Literaturempfehlung

Das Lehrbuch der Softwaretechnik* von Helmut Balzert hat zwar einen großen Umfang, beschreibt aber sehr gut das Vorgehen beim Requirements Engineering, also dem englischen Wort für Anforderungsermittlung. Die Buchreihe kann ich sehr empfehlen, auch wenn sie vielleicht eher an Studenten gerichtet ist und nicht so sehr an Auszubildende.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts