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.