Requirements Engineering
Erste wichtige Schritte bei RE

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 Beispielprojekt

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

Fazit

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

  • Dienstag 03 Dezember 2019

Kommentieren Sie diesen Artikel

Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!

Kommentar hinterlassen

Autor

Henrik Krumbholz Senior Consultant SharePoint

  • 13 November 2019
  • Henrik Krumbholz
  • User Productivity

Requirements Engineering: Gründe für und gegen RE

Requirements Engineering (RE) meint das Anforderungsmanagement im Rahmen eines Projektes. Wir zeigen, wie und warum RE sinnvoll ist und in welchen Situationen es Anwendung finden sollte.

So steuern und kontrollieren Sie Assets in der Adobe Creative Cloud und Document Cloud
  • 04 Juni 2019
  • Tobias Hübner
  • Publisher Advisory, User Productivity
  • Adobe

So steuern und kontrollieren Sie Assets in der Adobe Creative Cloud und Document Cloud

In der Adobe Creative Cloud und Document Cloud gibt es Tools, um die Verbreitung von Assets zu kontrollieren. Wir erklären, wie sie funktionieren.

Einführung in PowerApps
  • 16 Mai 2019
  • User Productivity, Unified Communications
  • PowerApps, SharePoint

Einführung in PowerApps

PowerApps ist ein Microsoft Dienst zur Erstellung von Business-Apps für Ihr Unternehmen. Hier erfahren Sie alles zu den Vorteilen und Anwendungsbereichen.