Nachdem wir im letzten Beitrag geklärt haben, warum Requirements-Engineering an sich wichtig ist, erläutern wir nun im Speziellen die Arbeit eines Requirements-Engineers, liebevoll auch „REler“ genannt.

Als Requirements-Engineer nehmen wir eine Rolle als Mittler zwischen den Welten ein. Wir verbinden die verschiedenen Bereiche miteinander, halten Kontakt zu den unterschiedlichen Stakeholder-Gruppen und sorgen dafür, dass Ihr Projekt zum Erfolg wird.

Stakeholder sind alle direkt oder indirekt vom System “Betroffenen“, also z. B. Benutzer der künftigen Systems, Programmierer, die herstellende Firma, der Kunde usw. Folglich haben sie unterschiedliche Wünsche an das geforderte System. Mit ihnen zu kommunizieren und all diese Wünsche zu dokumentieren sorgt dafür, dass eine gemeinsame Basis für das zu spezifizierende System geschaffen wird. Nur wenn die Anforderungen ausreichende Qualität aufweisen, ergibt es Sinn, mit der Entwicklung zu starten. Qualitätskriterien sind unter anderem Vollständigkeit (Ist jede notwendige Information vorhanden?), Notwendigkeit (Braucht man diese Anforderung wirklich?) oder Realisierbarkeit (Lässt sich die Anforderung technisch/finanziell im Rahmen des Projekts überhaupt umsetzen?).

So sorgen wir dafür, dass das Produkt am Ende auch auf dem Markt (oder bei internen Programmen im Unternehmen) abgenommen wird. Welche Features soll es besitzen? Was soll es können und was soll es auf keinen Fall tun? Soll das Navigationsgerät nur Straßenkarten aus Europa besitzen oder muss es auch nach Übersee auslieferbar sein? Diese Fragen und noch viele mehr klären wir im Vorfeld und während des Projektverlaufs.

Zum Ermitteln der Anforderungen gibt es verschiedene Vorgehensweisen. Wir haben Kreativitätstechniken, z. B. Brainstorming, was sicher jeder von uns schon einmal gemacht hat, oder auch Befragungstechniken, wie etwa Interviews oder Fragebögen. Außerdem gibt es noch Beobachtungstechniken, bei denen der REler beispielsweise die Stakeholder bei ihrer Arbeit beobachten und mit dokumentieren kann, wenn diese ihre Arbeit schwer in Worte fassen können oder schlichtweg keine Zeit haben, selbst über ihre Arbeit zu erzählen. Dies ist besonders dann sinnvoll, wenn ein Altsystem überholt werden soll.

Zu guter Letzt gibt es noch die artefaktbasierten und die unterstützenden Techniken. Als artefaktbasierte Technik kommt beispielsweise die „Systemarchäologie“ zum Einsatz, bei der auf Basis des existierenden Systems Anforderungen ermittelt werden. Die unterstützenden Techniken (z.B. SOPHIST-REgelwerk, Workshops, Use-Case-Modellierung, etc.) dienen hingegen der Qualitätsverbesserung der ermittelten Anforderungen und können beliebig mit oben genannten Ermittlungstechniken kombiniert werden.

Am besten ist es, mehrere Ermittlungsarten zu verwenden, um möglichst viele und vollständige Anforderungen zusammen zu tragen. Um das zu bewerkstelligen, ist die Kommunikation unter allen Projektbeteiligten unabdingbar. Und hier lauert eine Herausforderung für uns als REler. Denn Kommunikation ist nicht gleich Kommunikation.

Ein einfaches Beispiel: Im Projekt ist die Rede von einem Kunden. Für den Projektleiter ist es nun der nicht registrierte Laufkunde, der über die Ladenschwelle tritt und etwas kaufen möchte, für den Entwickler ist es vielleicht der registrierte, mit einem eigenen Account eingeloggte Kunde. Je nach eigener Erfahrung hat jeder ein anderes explizites Bild eines Begriffs im Kopf, welches er sprachlich genau so weiter geben wird, wie er es sieht. Dieses Phänomen nennt sich Darstellungstransformation. An einem so einfachen Beispiel wie dem oben genannten wird klar, dass im Projekt selbst für scheinbar einfache Begriffe eine eindeutige Bedeutung festgelegt werden muss.

Abbildung 1: Begriffsmodell am Beispiel einer Bibliothek

Anhand anschaulicher Begriffsmodelle (siehe Abbildung 1) und einem sorgfältig erarbeiteten Glossar stellen wir sicher, dass solche Darstellungstransformationen so weit wie möglich vermieden werden. Stellen Sie sich nur vor, was passieren würde, wenn erst gegen Ende des Projekts heraus käme, dass man ständig aneinander vorbei redet und bereits ein Großteil des Codes fertiggestellt ist und deswegen komplett umgeschrieben werden müsste..

Wie Sie sehen, steckt eine ganze Menge hinter dem Requirements-Engineering. Im nächsten Teil dieser Serie werden wir erläutern wie wir die aufgespürten Anforderungen Dokumentieren, Prüfen/Abstimmen und Verwalten.

Bis dahin alles Gute!

Ihre SOPHISTen

—————————————–
RE für Einsteiger (Teil 1) – Requirements-Engineering kurz und knackig auf den Punkt gebracht
RE für Einsteiger (Teil 3) – Warum Dokumentation essentiell ist
RE für Einsteiger (Teil 4) – Anforderungen prüfen und abstimmen: Prüfungsangst ist nichts für REler
RE für Einsteiger (Teil 5) – Anforderungen verwalten: Requirements-Management leicht gemacht
RE für Einsteiger (Teil 6) – SOPHISTen erzählen aus ihrem Projektalltag