Wir begrüßen Sie zurück an Bord auf der Reise mit unseren Anforderungen von ihrer Entstehung bis hin zum ausgewachsenen Stadium. Nun werden unsere ermittelten Anforderungen auf den Prüfstand geschickt, um ihre Qualität so hoch wie möglich zu halten.

Um Mängel rechtzeitig aufzudecken und frühzeitig entsprechende Korrekturmaßnahmen einzuleiten ist es sinnvoll, Anforderungen regelmäßig zu prüfen. Denn häufig besteht die Gefahr, dass Mängel und Fehler in den folgenden Entwicklungsphasen zu Folgefehlern führen. Wenn Sie verschiedene Prüftechniken einsetzen, können sie das Risiko verringern, auf der Basis solcher Fehler etwas nicht Gewünschtes zu entwickeln. Die Prüfung geht meist mit einem vergleichsweise geringen Kostenaufwand einher, wenn man im Gegenzug bedenkt, wie viele Ressourcen eine spätere Änderung kosten würde.

Für natürlichsprachliche Anforderungen kann man bei der Erstellung  eine Satzschablone verwenden, um Syntax und äußere Form zu kontrollieren. Die inhaltlichen Aspekte lassen sich mit dem REgelwerk hinterfragen. Diese beiden Werkzeuge helfen dabei, alle relevanten Informationen zu erfassen und „gute“ Anforderungen in Bezug auf Qualitätskriterien wie Prüfbarkeit, Eindeutigkeit oder Vollständigkeit (siehe z.B. ISO/IEC/IEEE 29148:2011) zu schreiben.

Wie so eine Satzschablone aussieht, zeigt folgende Abbildung:

Abbildung 1 Die SOPHIST Satzschablone (FunktionsMASTeR)

Die Satzschablone gibt der Anforderung eine gewisse Struktur und unterstützt dabei, floskelhafte Satzbestandteile von vornherein so gut es geht zu vermeiden, da die verwendeten Satzbausteine und ihre Reihenfolge vorgegeben sind. Als Anforderungsschreiber formt man die Aussagen der Stakeholder entsprechend um und verwendet zur Beschreibung der fachlichen Inhalte die Begriffe, die im Glossar dokumentiert wurden.

Das SOPHIST REgelwerk umfasst 18 Regeln, um eine Anforderung zu prüfen. Diese fordern den REler auf, Fragen an die Anforderung zu stellen: Wer handelt? Was sind seine Tätigkeiten für genau diese Anforderung? Was muss das System tun? Sind Mengen und Zahlen definiert? Die fünf wichtigsten Regeln können Sie der folgenden Grafik entnehmen. Erfahrungen der SOPHISTen aus zahlreichen Projekten haben gezeigt, dass diese sprachlichen Defekte zu den schwerwiegendsten Fehlern im Projektverlauf führen können.

Abbildung 2 Das SOPHIST REgelwerk – Die fünf wichtigsten Regeln

Man nimmt also jede einzelne Anforderung und geht sie Regel für Regel durch. Nach dem Hinterfragen der Anforderung mit den Regeln kann der REler die Anforderungen mit neuen Informationen ergänzen, bzw. zusätzliche Anforderungen schreiben. Auf diese neuen Anforderungen wendet der REler im weiteren Verlauf der Analyse das gleiche Vorgehen an.

Die erste Anforderung nach Schablone könnte beispielsweise lauten:

Das Bibliothekssystem muss dem Kunden die Möglichkeit bieten, ein Leihobjekt auszuleihen.

In unserem Beispiel kommen etwa Fragen danach auf, wie ein Kunde definiert ist, wie viele Leihobjekte auf er oder sie ausleihen darf, oder ob jeder Kunde jedes Leihobjekt ausleihen darf. Durch Hinterfragen könnten dann beispielsweise folgende Anforderungen herauskommen:

Das Bibliothekssystem muss dem Kunden die Möglichkeit bieten, ein oder mehrere Leihobjekte auszuleihen. <- Damit wird die Frage nach den  Zahlen und Mengen geklärt.

Die Frage nach der Kundenrolle lässt sich gut durch einen Glossareintrag lösen. Das könnte dann wie folgt aussehen:

Für das Bibliothekssystem muss ein Kunde eine natürliche Person sein, die im Bibliothekssystem registriert und angemeldet ist. Ein Kunde ist mit Vornamen, Nachnamen, Geburtsdatum und Adresse erfasst.

Bleibt also die Frage, ob ein Kunde jedes Leihobjekt ausleihen darf. Antworten könnten die ursprüngliche Anforderung wie folgt verfeinern:

Falls das Alter des Kunden mindestens der FSK eines Leihobjekts entspricht, muss das System dem Kunden die Möglichkeit bieten, ein oder mehrere Leihobjekte zu entleihen.

Falls das Alter des Kunden nicht der FSK eines Leihobjekts entspricht, muss das System dem Bibliothekar eine Fehlermeldung anzeigen.

Usw.

Anforderungen, welche nach Satzschablone formuliert wurden, sind weniger fehlerbehaftet (z. B. steht der Akteur immer fest) und die Regeln lassen sich an ihnen leichter anwenden. Formulieren Sie also erst anhand der Satzschablone und wenden Sie anschließend das Regelwerk an.

Eine weitere Technik in Projekten zur inhaltlichen Prüfung ist der Walkthrough – eine Technik zum Schaffen eines gemeinsamen Verständnisses der Anforderungen. Dies sollte regelmäßig geschehen, um die Anforderungen mit den Wünschen der Stakeholder abzustimmen.

Im Walkthrough leitet der Anforderungsautor die Stakeholder schrittweise durch die Anforderungen.  Die Stakeholder erhalten die Anforderungen vorher, um Notizen oder Fragen für die spätere Diskussionsrunde vorzubereiten zu können. Der Autor muss die Anforderungen bereits vor dem Vortrag mindestens einmal geprüft haben, um sie den Stakeholdern erläutern zu können. Durch seine Erläuterungen kann der Autor bereits während des Vortrags weitere Unstimmigkeiten oder Fehler entdecken. Der entscheidende Input muss allerdings von den Stakeholdern kommen, denn nur diese können die inhaltliche Richtigkeit der Anforderungen bestätigen. Die Ergebnisse der Abstimmung und Diskussion werden anschließend in die Anforderungen eingearbeitet.

Der Vorteil dieser Methode liegt klar im Wissensaustausch der Projektbeteiligten. Nachteil ist aber, dass diese Methode sehr abhängig vom Können des Autors und der Prüfer sein kann. Zudem kann der Autor während der Präsentation gezielt Unsicherheiten bei der Anforderungsdokumentation umgehen oder die Diskussion könnte bei unzureichender Moderation zu stark vom eigentlichen Sachthema abweichen.

Auch Simulationsmodelle oder Prototypen können zur Prüfung eingesetzt werden. Sie dienen dazu, das geplante Produkt für die Stakeholder zu veranschaulichen und erlebbar zu machen. Nicht jeder kann schließlich mit Tabellen, Diagrammen und jeder Menge Prosatext etwas anfangen. Eine navigierbare Webseite lässt sich beispielsweise gut in Powerpoint darstellen, indem man Hyperlinks zwischen den einzelnen Folien nutzt, um den Wechsel zwischen Webseiteninhalten zu zeigen. So erweckt der Prototyp den Anschein des „Durchklickens“, und Unstimmigkeiten können einfacher identifiziert werden.

Es stellt sich noch die Frage, wann eine Prüfung sinnvoll ist. Generell sollte nicht zu früh prüfen, da sich gerade zu Beginn eines Projektes Anforderungen noch stark verändern, bzw. genauer spezifiziert werden müssen. Also sollte man mit der Prüfung erst beginnen, wenn die Anforderungen eine gewisse Stabilität besitzen. Die ist meist dann gegeben, wenn die grundlegenden Ziele und der Umfang des Systems weitgehend geklärt sind. Natürlich müssen auch danach die Anforderungen regelmäßig erneut geprüft werden, zum Beispiel bevor zum nächsten Meilenstein die neue Version einer Spezifikation ausgeliefert wird.

Im nächsten Kapitel lesen Sie unseren letzten „Theorie-Teil“ über Requirements-Management, die Verwaltung von Anforderungen. Danach lassen wir Sie an unseren Erfahrungen mit RE/RM im Projektalltag teilhaben.

Bis dahin alles Gute wünschen Ihre SOPHISTen