Kommentieren Sie diesen Artikel
Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!
Kommentar hinterlassenDas 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:
Diese zwei Fragen führen zu den folgenden drei Punkten, die ich als Erstes bei einem neuen Projekt angehe:
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.
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
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):
Wenn wir uns noch etwas mehr Zeit nehmen, werden wir sicherlich auf noch mehr Stakeholder kommen, aber in diesem Fall soll das genügen.
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 |
|
|
|
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 |
|
|
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 |
|
|
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.
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
Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!
Kommentar hinterlassen