Anforderungsermittlung (nicht nur für dein Abschlussprojekt) – IT-Berufe-Podcast #159

Um die Ermittlung und Dokumentation von Anforderungen für
Projekte geht es in der einhundertneunundfünfzigsten Episode des
IT-Berufe-Podcasts.
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