Requirements Engineering: Erste wichtige Schritte bei RE

Das Thema Requirements Engineering habe ich in Teil 1 damit begonnen, welche Gründe es gibt, RE durchzuführen. Das ist zwar schon mal gut zu wissen, aber es bleibt die Frage zu klären, wie man sinnvoll beginnt. In der Regel nutzen viele das Requirements Engineering schon intuitiv ganz gut, wenngleich es an der ein oder anderen Stelle noch Verbesserungsbedarf gibt. Um die einzelnen Schritte greifbarer zu machen, möchte ich ein Beispielprojekt einführen, welches ich immer wieder aufgreifen werde.

Das Projekt, welches in der Blogserie als Beispiel dienen wird, ist die Planung eines Teamevents. Ein Team, bestehend aus zehn Personen (inkl. 1 Teamleiter und gleichzeitig Projektleiter), will den verdienten Erfolg des letzten Jahres feiern und gemeinsam ein Teamevent durchführen. Klar ist, dass nicht alle an der Planung teilhaben können, weshalb es der Teamleiter und damit Projektleiter in die Hand nimmt, ein Zwei-Tages-Teamevent zu organisieren.

Der Projektleiter stellt sich als Erstes zwei wichtige Fragen:

1. Wer hat berechtigtes Interesse am Teamevent?
   
2. Was wird benötigt, damit das Teamevent erfolgreich ist?
   
   
   

Kommunikationsprobleme mit dem Kunden

Diese zwei Fragen führen zu den folgenden drei Punkten, die ich als Erstes bei einem neuen Projekt angehe:

1. Kommunikationsgrundlage schaffen
2. Stakeholder erkennen und einbinden
3. Ziele definieren und festhalten

Ob ich diese drei Punkte bei jedem Projekt auch immer in der Reihenfolge bearbeite, entscheide ich immer je nach Projekt. Eine Kommunikationsgrundlage zu schaffen, passiert bei mir meist während der Gespräche mit dem Kunden. Wir erkennen hier gemeinsam Missverständnisse oder Fachbegriffe, die in ein gemeinsames Glossar geschrieben werden, um so eine „gemeinsame Sprache“ zu entwickeln. In den meisten Projekten umfasst ein solches Glossar, welches über das gesamte Projekt (oder länger) aktuell gehalten werden muss und gültig ist, verschiedene Fachbegriffe, Abkürzungen, Synonyme und fast noch wichtiger Homonyme.

Steakholder, Stickholder, Stakeholder – ja das war‘s

Die Definition der Stakeholder ist das Ergebnis zu Frage 1 (Wer hat berechtigtes Interesse am Teamevent?). Stakeholder sind essenziell wichtig für den Erfolg des Projekts und müssen nicht zwingend nur Personen sein. Ein Stakeholder hat berechtigtes Interesse am Projekt, wenn er beispielsweise 

• Nutzer des Ergebnisses,
• Finanzier des Projekts oder auch
• Eine zu beachtende Richtlinie ist.

Die landläufige Meinung über die Anzahl der Stakeholder je Projekt beträgt etwa zwei bis drei. In unserem Fall wären das vermutlich das Team, der Teamleiter und vielleicht das Unternehmen. Die reale Zahl beläuft sich auf mindestens das Dreifache. Beim Beispielprojekt könnten die Stakeholder sein (nicht abschließend):

• Mitarbeiter des betreffenden Teams
• Teamleiter
• Mitarbeiter anderer Bereiche/Teams
  › Aufgrund gemeinsamer Projekte
• Unternehmen
  › Aufgrund „Ausfall“ der Mitarbeiter und Finanzierung des Events
• Familie der Mitarbeiter
  › i.d.R. LebensgefährtenInnen und Kinder
• Eventanbieter
  › GoKart-Bahn, Gastwirt, Hotelier
• Versicherungstechnische Begrenzungen
  › Gesetze
• Bereichsleiter
  › Aufgrund Genehmigung des Teamevents

Wenn wir uns noch etwas mehr Zeit nehmen, werden wir sicherlich auf noch mehr Stakeholder kommen, aber in diesem Fall soll das genügen.

Wie soll ich mir die Stakeholder merken?

Die Frage ist einfach zu beantworten: Aufschreiben. Dabei empfiehlt es sich einen zentralen Ablageort zu wählen, da das Dokument im Laufe des Projekts immer wieder genutzt und angepasst werden wird. Ich habe mir angewöhnt folgende Informationen je Stakeholder abzulegen: 

Information
Typ	Natürliche Person, Juristische Person, Systeme oder Dokumente/Richtlinien
Name
Vorname	Nur bei Personen sinnvoll
Ansprechpartner	Falls unterschiedlich zur Person oder es eine Richtlinie ist
Relevanz	Hoch Normal Niedrig
Funktion (Rolle)	Endnutzer Editoren Admin Entscheidungsträger Projektleiter …
Zeitliche und räumliche Verfügbarkeit
Wissensgebiet und -Umfang
Ziele und Interessen im Projekt
E-Mail
Telefon

In unserem Beispielprojekt könnte ich folgendes für den Teamleiter notieren:

Information	Stakeholder Teamleiter
Typ	Natürliche Person
Name	Leiter
Vorname	Team
Ansprechpartner	Teamleiter
Relevanz	Normal
Funktion (Rolle)	Projektleiter
Zeitliche und räumliche Verfügbarkeit	Werktäglich zwischen 08:00 und 18 Uhr in Raum R1234
Wissensgebiet und -Umfang	Hat schon mehrere Events organisiert Erfahren in organisatorischen Prozessen im Unternehmen
Ziele und Interessen im Projekt	Zufriedene und entspannte Mitarbeiter Gewachsener Zusammenhalt innerhalb des Teams
E-Mail	Team.Leiter@company.fiktiv
Telefon	+49 123 / 456 789

Für ein beliebiges Teammitglied könnte das wie folgt aussehen:

Information	Stakeholder Teammitglied
Typ	Natürliche Person
Name	Mitglied
Vorname	Team
Ansprechpartner	Teammitglied
Relevanz	Hoch
Funktion (Rolle)	Endnutzer
Zeitliche und räumliche Verfügbarkeit	Werktäglich zwischen 10:00 und 16 Uhr in Raum R5678
Wissensgebiet und -Umfang	Neu im Unternehmen und noch offen für alles Sehr aktiv unterwegs
Ziele und Interessen im Projekt	Aktives und sportliches Teamevent Nicht zu viele Tage aufgrund Familie und Kinder
E-Mail	Team.Mitglied@company.fiktiv
Telefon	+49 123 / 987 654

Einen der zwei wichtigsten Punkte haben wir nun beleuchtet: Wer ist für mein Projekt wichtig? Nebenbei pflegen wir auch noch ein Glossar, damit wir uns nicht missverstehen. Nur wenn ich weiß, wer am Ende entscheidet, ob das Projekt ein Erfolg wird, kann ich diese Personen auch fragen beziehungsweise Dokumente auch lesen. Daraus ergeben sich dann meine Ziele, die ich mit Frage zwei herausfinden will und in Teil drei beantworte.

 

Die Blogserie im Überblick

Teil 1: Requirements Engineering – Gründe für RE und auch dagegen 
Teil 2: Requirements Engineering – Erste wichtige Schritte bei RE
Teil 3: Requirements Engineering – Zielmodelle nutzen, um Anforderungen zu definieren
Teil 4: Requirements Engineering – Dokumentation der Anforderungen
Teil 5: Requirements Engineering – Erfahrungen mit RE in der Praxis des IT-Umfelds