Requirements Engineering Methoden

Ein spannender Kommentar von Rolf Götz zum Artikel "Was und Wie" regt zum Nachdenken über Service-orientierte Archtektur (SOA) und Requirements Engineering an.

Ich denke, bei SOA sind Anforderungen für verschiedene Kontexte wichtig.
Zum einen im Kontext des Unternehmens, fokussiert auf die Geschäftsprozesse, zum anderen im Kontext jedes einzelnen Services.
- Unternehmenskontext: Welche Anforderungen ergeben sich durch die Geschäftsprozesse im Unternehmen an eine IT-Landschaft? Eine SOA hat den expliziten Auftrag, die Geschäftsprozesse duch Komposition verschiedener Services zu unterstützen.
- Service-Kontext: Die SOA zerlegt die Anforderungen des Unternehmens in verschiene Services und bildet die Anforderungen auf jeden einzelnen Service ab.
Die SOA beantwortet das "Was" der Anforderungen des Unternehmenskontexts durch ein "Wie" aus der Kombination von Services. Für jeden Service ergeben sich neue Anforderungen "Was".

Rolf: diese Kontexte sind andere Ebenen als die Abstraktionsebenen. Innerhalb eines Kontexts können Anforderungen auf allen Abstraktionsebenen formuliert werden.

In meinem (bislang einzigen expliziten) SOA-Projekt entwickelten wir eine modellbasierte Definition von Prozessen zur Bearbeitung von elektronischem Belegverkehr. Auf oberster Ebene bilden die Prozesse für Kunden sichtbare Verarbeitungsprozesse ab. Die einzelnen Schritte des Prozesses bestehen wiederum aus (technischeren) Prozessen. Prozesse rufen tiefere Prozesse, bis am untersten Ende Code-Routinen über Webservices gerufen werden. Die Tiefe der Aufrufhierarchie ist nicht im Voraus festgelegt.
Die IT stellt Services zur Verfügung, die von den Beratern vor Ort zu kundenspezifischen Verarbeitungsprozessen zusammengestellt werden.
Unsere Leistung war es, die möglichen Strukturen zu definieren, wie Prozesse und Webservices in Zusammenhang stehen können. Wir erstellten außerdem den Editor, mit dem die Prozesse erstellt und konfiguriert werden können.
In dieser Lösung gibt es die Geschäftsprozess-Sicht, deren Anforderungen durch die Berater beim Kunden definiert werden, sowie die Service-Sicht, die durch die Techniker in der IT zur Verfügung gestellt werden.

Für mich als Business Analyst ist SOA eine Besinnung auf die Regel, dass jede Software letztlich den Geschäftsprozess unterstützen muss. Die gesamte Software eines Unternehmens muss im Rahmen der Geschäftsprozesse nützlich sein und dazu zu einer Gesamt-Unterstützung für das Geschäft komponiert werden. Die IT hat den Auftrag, die Arbeit des Unternehmens zu unterstützen.
Die zahlreichen Artikel der Computerwoche zum Thema SOA und CIO haben genau das zum Thema, z. B. im Artikel "Prozessorientierung statt Produktionstiefe".
Ed Yourdon hat in seinem Blog im Artikel "CIO Insight’s predictions of 30 top IT trends for 2007" eine interessante Studie kommentiert, deren Top 1 Trend "Process improvement will be job No. 1" und Top 8 Trend "The division between IT and business will diminish" klar die Ausrichtung auf das Geschäft beschreiben.

Scheint so, dass mein Job als Business Analyst immer spannender und wichtiger wird :-)

Nicht-funktionale Anforderungen sind nach wie vor ein schwieriges Kapitel in jedem Pflichtenheft. Ich erlebe häufig, dass Kunden nicht an Qualität denken, bevor ich sie dazu zwinge ;-)
Schlimmer ist, dass sich auch viele Analytiker schwer tun, nicht-funktionale Anforderungen zu fassen.
In meinen letzten Projekten hatte ein paar spannende Berührungspunkte mit der Dienstleistungsqualität und so sind ein paar Gedanken entstanden, die ich hier in einen Artikel gieße.
Statt dem Begriff "nicht-funktionale Anforderungen" verwende ich gerne "Dienstleistungsqualität" oder allgemein "Qualität". Die Anforderungen klingen einfach zu sehr nach dem oberen Drittel der Abstraktionspyramide.

Qualität gibt es auf jeder Ebene
Qualität ist kein Ding von Lastenheften, die im Pflichtenheft durch eine funktionale Spezifikation "gelöst" werden.
Sicher gibt es Anforderungen, z. B. zur Sicherheit, die im Pflichtenheft (teilweise) durch Funktionalität gelöst werden, z. B. durch ein Login.
Im Allgemeinen gibt es aber auf jeder Ebene von Anforderungen ein "wie gut". (Siehe auch den lesenswerten Kommentar von Rolf Götz zum "Was und Wie".)
Z. B. lässt sich die Sicherheit nicht nur als Funktion beschreiben, die Sicherheitslücken schließt, sondern eben auch als Qualität des Codes, der keine Lücke offen lässt.
Ein anderes Beispiel ist die Erweiterbarkeit, die ein Kriterium von gutem Code ist.

Qualitätsanforderungen sind Risikofaktoren
Eine vergessene funktionale Anforderung führt zu Ärger und zu Nachbesserung. Eine vergessene Qualitätsanforderung führt zum Scheitern des Projekts!
In einem unserer Projekte plante unser Kunde eine Lösung für die interne Nutzung, besann sich dann gegen Ende des Projekts jedoch darauf, sie auch über das Internet jedermann zugänglich zu machen. Die Funktionalität blieb dieselbe, die Software musste nur ins Internet gestellt werden.
Niemand denkt an Sicherheitsaspekte, die plötzlich so wichtig werden wie die Funktionalität.
Plötzlich werden Qualitätsabteilungen hellhörig, die IT des Unternehmens wurde aufmerksam. Vorher unbeteiligte Personen schalten sich ein und die Software wird politisch relevant, die Kreise werden größer. Mit einem Mal ist eine erfolgskritische Anforderung "Sicherheit" relevant!
Unser Kunde ist baff und wir reden plötzlich mit vielen Menschen statt mit einem Kunden. Die Software muss (fast) neu geschrieben werden...

Qualitätsanforderungen sind einfach
Zumindest auf hoher Abstraktionsebenen ist es einfach, Qualitätsanforderungen aufzustellen. Damit sind zumindest die größten Risiken eines Projekts abgedeckt. Ich nutze eine Checkliste mit wenigen Aspekten wie Sicherheit, Usability, Effizienz, um die Anforderungen zu prüfen. Checklisten bieten z. B. DIN 66272 oder Volere.
Eine größere Herausforderung ist, die Qualität der Software messbar zu machen. Ich finde das Prinzip von GQM praktisch, ein anderer Ansatz ist Planguage von Tom Gilb.