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

  • User Productivity
  • Strategy

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

Microsoft SharePoint

Verwandte Artikel

microsoft-teams-vs-zoom
  • 19 Oktober 2020
  • User Productivity
  • Video Conferencing, Microsoft Teams

Microsoft Teams vs. Zoom

In Zeiten zunehmender Remote-Arbeit werden Tools für die Teamzusammenarbeit immer beliebter. Aber was ist besser, Microsoft Teams oder Zoom?

VIP sein bei Adobe: Was der Value Incentive Plan seinen Nutzern bringt

Vereinfachte Lizenzverwaltung inklusive: Adobe VIP ist das Lizenzprogramm von Adobe für Unternehmen jeder Unternehmensgröße.

CorelDRAW Graphics Suite 2020 – starke Grafik-Tools für viele Branchen

Eine Lösung auch für Enterprise-Unternehmen: was die CorelDRAW Suite 2020 alles kann