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
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.