Die Rolle des Requirements Engineers im Software-Projekt
Requirements Engineering ist ein zentraler Aspekt bei der Entwicklung von Individualsoftware und Produkten.
Egal ob in agilen Projekten oder Projekten nach dem klassischen Wasserfallmodell: sind sich Auftraggeber und Auftragnehmer nicht einig, was genau im Rahmen eines Projektes geliefert werden soll, so sind spätestens bei der Ablieferung der Resultate Diskussionen angesagt.
Mit der Einführung agiler Entwicklungsmethoden wurde das Bedürfnis nach strukturierter Erfassung und Verwaltung von Anforderungen immer wichtiger.
Dabei gibt es verschiedene Sichten zu berücksichtigen:
Aus diesem Bedürfnis heraus setzen wir in der Intersys auf ein Tool, welches sämtliche Anforderungen, Bedürfnisse und Sichten zusammenfassen kann. Dabei ist wichtig, dass jeder Stakeholder in der Lage sein sollte, eine eigene Sicht auf die ihn betreffenden Aspekte zu erhalten.
Das Requirements Engineering liefert die Grundlagen für das ganze System. In der Regel sind das die Geschäftsanforderungen des Kunden. Diese bilden auch die Grundlage für die Abnahmekriterien, welche belegen, dass das System erfolgreich nach den Bedürfnissen des Kunden gebaut wurde.
Aus vertraglicher Sicht sind Geschäftsanforderungen und Abnahmekriterien oftmals die Artefakte, welche rechtsverbindlich geregelt sind. Von ihnen leiten sich in der Folge sämtliche weitergehenden Anforderungen und Tests ab.
Das Modell, wie Anforderungen schlussendlich in funktionierende Software umgesetzt und getestet werden, sieht in der Intersys in etwa wie folgt aus:
Dem Requirements Engineer kommt beim gesamten Ablauf eine sehr zentrale Rolle zu, ist er doch ein wichtiges Bindeglied zum Kunden und bleibt mit diesem auch über den Abschluss des Projektes verbunden, um allfällige Weiterentwicklungen wiederum frühzeitig klar strukturieren zu können.
Software gestützte Arbeit
Ohne Software, welche den Requirements und den Entwicklungsprozess optimal unterstützt, geht heute keine Softwareentwicklung mehr. Software ist aber nie einfach Mittel zum Zweck. So hilft uns Software zu erkennen, ob zu den einzelnen Kundenanforderungen effektiv auch etwas programmiert wurde, wie aus der nächsten Graphik ersichtlich ist:
Die eingesetzte RE Software zeigt auf, ob für jedes EPIC auch eine Story vorhanden ist
So lässt sich sowohl der Projektfortschritt wie auch die Abdeckung optimal verfolgen und das Projekt ist generell besser «on Track».
Unerwünschte Projektverzögerungen lassen sich so sicher vermeiden.
Bei den individuellen Anforderungen wird weiter auf Standardisierung in den Beschreibungen gesetzt.
Damit werden Anforderungen universell verstanden und eindeutig identifizierbar.
Auch hier unterstützen uns Softwaretools im Umgang:
Beispiel einer Textschablone für Functional Requirements
Wer sind also die Kunden des Requirement Engineers?
Der Requirements Engineer hat verschiedene Stakeholder, die er mit seinen Leistungen beliefert:
- Der Auftraggeber (Kunde oder interner Produktmanager)
- Das Entwicklungsteam (inkl. Architekt)
- Die Testmanager
- Der Product Owner / der Projektleiter
Was ist der Mehrwert, welcher der Requirements Engineer gegenüber seinen Stakeholder erbringt?
- Er erzeugt ein gesamtheitliches Bild des Systems und ermöglicht es den Stakeholdern gleichzeitig, sich auf die für sie wichtigen Aspekte konzentrieren zu können
- Er liefert eine Sammlung von (hoffentlich) klar definierter Anforderungen für die gesuchte und zukünftige Lösung
- Er leistet einen wichtigen Beitrag, um sicher zu stellen, dass nichts vergessen geht und somit die Ziele nach Qualität, Kosten und Termine von allen involvierten Stakeholdern besser erreicht werden können
Wie erreicht der Requirements Engineer seine Ziele
Der Requirements Engineer verbringt zuerst mal eine nicht unerhebliche Zeit mit dem Auftraggeber, um ihn, seinen Geschäftsbereich, seine Arbeitsweise und seine Motivationen besser zu verstehen. Sämtliche dabei erhobenen Informationen wie Prozesse, Vorgaben, Geschäftsregeln, rechtliche Grundlagen, Beschreibungen bestehender IT-Systeme, Organisationsstrukturen usw. werden strukturiert festgehalten und vernetzt. Dazu werden verschiedene Diagrammtypen sowie Textvorlagen und Prosatexte verwendet. Abgeleitet daraus werden in einem ersten Schritt die Geschäftsanforderungen des Kunden. Diese sind oft wenig mit Technik verbunden, sondern zeigen auf, welchen Businessmehrwert der Kunde vom neuen System erwartet. Dieser Businessmehrwert soll auch messbar als Projektziel zwischen den beiden Parteien vereinbart werden.
Einzelne Teammitglieder (z.B. der Product Owner) werden im Rahmen dieser Tätigkeiten bereits einbezogen, um spezifische Fragen zu klären, selbst Know-how aufzubauen und für die Umsetzungsphase zum primären Ansprechpartner des Auftraggebers zu werden. Der Requirements Engineer zieht sich hier normalerweise etwas zurück, ist aber immer noch bemüht, allfällige Änderungen an den Anforderungen ins System einfliessen zu lassen.
Was ist aus Sicht agiles Vorgehen zusätzlich zu beachten?
Wird ein Projekt agil geführt, so kann sich der Scope des Projektes mit dem Projektfortschritt laufend verändern. Es gibt in diesem Fall kein «Gesamtsystem» mehr, das von Anfang an definiert und von allen beteiligten akzeptiert worden ist. Das resultierende Produkt entwickelt sich von Sprint zu Sprint, nimmt dabei Form an und kann vom Auftraggeber laufend noch angepasst werden.
In diesem Fall ist die Aufgabe des Requirement Engineers sicher zu stellen, dass sämtliche je geäusserten Anforderungen sauber erhoben, dokumentiert, abgeglichen und verwaltet werden. Gemeinsam mit dem Product Owner werden aus den Anforderungen EPIC’s erstellt und priorisiert. Gewisse Funktionalitäten werden dabei allenfalls nie das Licht der Welt erblicken, wenn sie für den Kunden in der Gesamtbetrachtung nicht so wirklich relevant sind.
Gerade in agilen Projekten ist eine saubere Projektkommunikation von höchster Wichtigkeit, sind doch noch mehr Stellen im Projekt involviert, die es inhaltlich zu synchronisieren gibt. Dieser Aufwand darf nicht unterschätzt werden, soll sichergestellt werden, dass alle involvierten Stakeholder dasselbe Verständnis haben.
