Die Rollen im Anforderungsmanagement

Neben den Anforderungsdokumenten haben wir auch noch die verschiedenen Rollen bei der Erstellung von Spezifikationen.

Auf der einen Seite haben wir den Kunden, der in seinem Lastenheft ein Problem beschreibt, das er gelöst haben will. Zusätzlich haben wir die Interessensgruppen, die ebenfalls ein Problem beschreiben, das sie allgemeingültig gelöst haben wollen.

Auf der anderen Seite haben wir das Projektteam mit jemandem, der sich mit dem ganzen Thema Requirements Engineering beschäftigt und versucht, überhaupt das Problem zu begreifen. Dann gibt es jemanden, der sich mit dem ganzen Systemdesign beschäftigt. Das ist jemand, der versucht, aus den Anforderungen eine Lösung zu definieren. Und dann haben wir einen Projektmanager, der halt in diesem ganzen Kontext noch versucht, das Team zum Erfolg zu führen.

Das zusammen ist genau die Schnittstelle, und wir sehen auch da: Auf der einen Seite liegen die Lastenhefte und auf der anderen Seite die Pflichtenhefte nach der klassischen Beschreibung.

Rollen im Anforderungsmanagement

Rollen im Anforderungsmanagement

Am Ende bilden die Rollen auch die Arbeitsergebnisse ab. Ein Requirements Engineer wird also die Anforderungsspezifikation (SRS) erschaffen. Ein Systemdesigner oder ein Systemarchitekt wird die Architekturspezifikation (SAS) schreiben, und der Projektmanager beschreibt in der Regel in seinem Projekthandbuch all die nichttechnischen Anforderungen an ein System.

Je komplexer Systeme werden oder je dynamischer ihre Funktion ist, desto wichtiger wird es, sich intensiv mit diesen Dokumenten und Spezifikationen zu beschäftigen. Ein System, das einen relativ einfachen Aufbau hat und auch keine großartige Dynamik besitzt, muss nicht in aller epischer Breite sämtliche oben beschriebenen Spezifikationen besitzen, wenn eigentlich klar ist, was wichtig ist. Das bedeutet aber, sie nicht komplett wegzulassen, sondern mit Sinn und Verstand nur das, was gebraucht wird, umzusetzen.

Je komplexer ein System wird oder gar je mehr Unterlieferanten dabei sind, also je mehr Menschen auch in diesem Projekt eingebunden sind, desto wichtiger werden Spezifikationen. Denn Spezifikationen sind am Ende nichts anderes als eine Dokumentation von Wissen.

Requirements-Engineering mit Word und Excel

Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Word und Excel zu arbeiten, was nicht immer einfach ist – und weswegen ich die nächsten Beiträge diesem Thema widmen möchte.

Ich werde im Folgenden die vielen Fragen aufgreifen, die sich um Requirements Engineering mit Word und Excel drehen.

Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.

Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe „traditionell“ – die Word- oder auch Excel-Werkzeuge.

Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.

Das Ziel dieser Episoden ist es, euch das nötige KnowHow und viele Tipps zu vermitteln, um eure Spezifikationen mit Word zu handhaben. Zunächst habe ich ein paar Begriffsklärungen und ein wenig Hintergrundwissen für Leser, die die vorangegangenen Beiträge noch nicht kennen.

Tolle Kombination: Lastenhefte und agile Methoden

Viele Projektleiter sind verunsichert, wenn sie ein Lastenheft mit ihren agilen Methoden bzw. Scrum vereinen sollen. Ist ein Lastenheft wirklich noch sinnvoll, wenn sich unsere Anforderungen ständig verändern? Wenn wir als Systemingenieure für das Erstellen eines Lastenheftes für ein komplexes System zwei bis sechs Monate brauchen, gibt es dann eine Möglichkeit, dabei agil vorzugehen? Und passt ein Lastenheft eigentlich mit Scrum zusammen?

Die Vorteile agiler Lastenhefte

Zunächst möchte ich eines vorwegnehmen: Ein Projekt ohne Lastenheft ist mit hoher Sicherheit zum Scheitern verurteilt. Das ist meine Erfahrung aus über 10 Jahren als Troubleshooter in der Automobilentwicklung.

Erst als ich mit den Teams begonnen habe, ein Lastenheft zu erstellen, ist allen klar geworden, was wirklich vom Auftraggeber gewünscht wurde. Dabei war es in allen Projekten und Unternehmen irrelevant, ob die Projekte klassisch oder agil verliefen und über Scrum gesteuert wurden. Das spricht eigentlich bereits für sich: Ja, du kannst bei der Erstellung eines Lastenheftes agil vorgehen!

Wenn über längere Zeit an einem Lastenheft gearbeitet wird, ist es sogar sehr sinnvoll, agile Methoden einzusetzen. Dadurch erhöht sich die Reife des Lastenheftes und oft sind die Teams auch deutlich schneller.

Ich selbst liebe es, mit agilen Methoden bei der Erstellung eines Lastenheftes zu arbeiten. Es spricht absolut nichts dagegen, sie einzusetzen. Ich nutze dazu folgende Methoden:

  • Sprints: Ich arbeite mit den Teams in Sprints von ein oder zwei Wochen.
  • Kanban: Wir nutzen ein gemeinsames Board und steuern die Aufgaben.
  • Design Pattern: Ich bringe meine Templates und Vorlagen mit in das Projekt.

 

Lastenhefte und Scrum? Unbedingt!

Das Lastenheft beschreibt das „Wünsch-Dir-Was“ des Auftraggebers, also der Person, die für das Projekt den Kunden darstellt. Das kann ein externer Kunde sein oder deine Marketing- und Produktmanagementabteilung. Diese Kunden bzw. Abteilungen bringen in einem Lastenheft ihre Wünsche nach bestem Wissen und Gewissen auf einen aktuellen Stand.

Aus meiner Sicht macht es dabei keinen Unterschied, wenn du Scrum als Management-Methode in deinem Projekt einsetzt – Scrum und Lastenhefte lassen sich sehr gut vereinbaren! Es ist also eher nebensächlich, ob dein Projekt klassisch oder über Scrum gesteuert wird: Beide Formen der Projektsteuerung profitieren von der Existenz eines Lastenheftes. Im Grunde handelt es sich hierbei nur um unterschiedliche Formen, ein Projekt umzusetzen.

Ziel eines Lastenheftes ist es, eine Basis für die Diskussion der Anforderungen zu liefern. Wenn dein Projekt beispielsweise mit Scrum gesteuert wird, ist das Lastenheft eine hervorragende Basis für das Produkt Backlog. Denn dort werden die oft sehr grob beschriebenen Anforderungen aus dem Lastenheft in die Storys übertragen und weiter diskutiert. Wenn dein Projekt Scrum einsetzt, ist also ein Lastenheft von deinem Auftraggeber sehr wertvoll.

Der Bauplan für Dein KI-Projekt
Von der Idee zum klaren KI-System

Anmeldung zum Newsletter

Alle ein bis zwei Monate versende ich einen Newsletter mit spannenden Informationen zum Systems und Requireements Engineering.
Bleib auch Du immer informiert, indem Du Dich in die Liste einträgst.
* einmal im Monat
* Konferenzen
* interessante Podcasts
* Webinare

Anmeldung zum Newsletter

Alle ein bis zwei Monate versende ich einen Newsletter mit spannenden Informationen zum Systems und Requireements Engineering.
Bleib auch Du immer informiert, indem Du Dich in die Liste einträgst.

Der KI-Footprint

Bauplan für
Dein KI-Projekt
Von der Idee zum klaren System
* einmal im Monat
* Konferenzen
* interessante Podcasts
* Webinare
Newsletter zum Requirements und Systems Engineering
5 Beispiele für Lastenhefte, die wirklich geholfen haben
Vorlagen aus der Praxis