objectif Requirements Modeller

Transkript

1 objectif Requirements Modeller Mit Professionalität punkten: Das methodische Konzept 1

2 Inhalt Das methodische Konzept des objectif Requirements Modellers Seite 3 Herausforderung Requirements Engineering Seite 3 Ja, aber warum mit Modellen? Seite 3 Wo bleibt der Text? Seite 4 objectif Requirements Engineering Prozess: Das Vorgehen zum Tool Seite 5 Ausgangspunkt: Projektauftrag Seite 5 Vollständigkeit im Visier: Systemkontext Stakeholder Ziele Seite 5 Iterativ stabilisieren: Ziele Szenarien Anforderungen Seite 7 Parallel detaillieren: Anforderungen Systemarchitektur Seite 8 Per Vorlagen auf Knopfdruck: Auswertungen Dokumente Seite 9 Bringen wir es auf den Punkt Seite 10 Quellen Seite 11 Copyright Seite 12 2

3 Das methodische Konzept des objectif Requirements Modellers Herausforderung Requirements Engineering Requirements Engineering hat sich in den vergangenen Jahren zu einer eigenständigen, hoch professionellen Disziplin entwickelt. Und das aus gutem Grund. Immer mehr Unternehmen erkennen: Requirements Engineering ist die erste und entscheidende Weichenstellung im Projekt. Alle nachfolgenden Projektergebnisse bauen auf den Anforderungen auf. Die Ziele eines Requirements Engineers sind heute weiter gesteckt als noch vor wenigen Jahren. Heute geht es darum: Projektrisiken frühzeitig zu reduzieren, eine solide Basis für die Kosten- und Terminplanung zu schaffen, die Erwartungen der Stakeholder weitgehend zu erfüllen, baubare Lösungen spezifizieren. Um diese Ziele zu erreichen, muss der Requirements Engineer vor allem eines liefern: Anforderungen in hoher Qualität das heißt Anforderungen, die relevant, verständlich, korrekt, konsistent, vollständig, prüfbar, realisierbar und verfolgbar sind. Wie sieht der Weg dorthin aus? Nachfolgend lernen Sie einen Prozess für das Requirements Engineering kennen, der sich in Hinsicht auf die Begriffsbildung und die zu erstellenden Artefakten am Basiswissen orientiert, das für eine IREB-Zertifizierung als Requirements Engineering Professional gefordert wird (siehe [Pohl, Rupp 2011]). Die Artefakte, die nach diesem Prozess entstehen, können Sie mit dem objectif Requirements Modeller erstellen. Ja, aber warum mit Modellen? Der Prozess setzt in großem Umfang auf den Einsatz von Modellen. Der Gedanke dahinter: Auf dem Weg zu guten Anforderungen müssen Sie zunächst das Bermudadreieck des Requirements Engineering sicher durchqueren. Das heißt, Sie müssen Mittel finden gegen: Bild 1: Da müssen Sie durch die Komplexität des zu entwickelnden Systems, mangelndes oder oberflächliches Verständnis, schlechte Kommunikation mit den Stakeholdern und im Team. Komplexität reduziert man durch Abstraktion. Ein großartiges Mittel, um zu abstrahieren, sind grafische Modelle. Sie konzentrieren sich jeweils auf eine Perspektive und blenden bewusst Aspekte des Systems aus. 3

4 Was das Verständnis angeht: Wenn man als Requirements Engineer sagen wir Befragungen von Stakeholdern durchgeführt und die Antworten fein säuberlich in eine Liste eingetragen hat, dann kann man dem Trugschluss erliegen, dass man allein durch das Dokumentieren Ziele und Bedarf der Stakeholder schon verstanden hätte. Aber ist das wirklich so? Für echtes Verständnis ist es hilfreich, die Stakeholder und ihre Ziele um bei diesem Beispiel zu bleiben in eine grafische Darstellung zu bringen. Darin kann man dann sonst vielleicht unerkannt gebliebene Abhängigkeiten und Zielkonflikte erkennen, abbilden und ihnen auf den Grund gehen. Und wie sieht es mit dem Kommunikationsproblem aus? Heißt es nicht immer: Ein Bild sagt mehr als tausend Worte? Sind Modelle für die Kommunikation mit Stakeholdern nicht genau das richtige Instrument? Der Spruch ist reichlich überstrapaziert und er stimmt auch nur fast. Haben Sie zum Beispiel schon einmal versucht, mit Ihrem kaufmännischen Geschäftsführer oder Finanzvorstand über ein Klassendiagramm zu kommunizieren? Und wenn ja, spricht er jetzt noch mehr als tausend Worte mit Ihnen? Grafische Modelle sind bei der Kommunikation unschlagbar, wenn ja, wenn es die richtigen sind. Das heißt, wenn sie auf den jeweiligen Einsatzzweck und die Zielgruppe abgestimmt sind. Bei der Wahl der richtigen grafischen Ausdrucksmittel muss man hin und wieder das formale Korsett eines Standards wie UML (siehe [OMG 1]) oder SysML (siehe [OMG 2]) sprengen und sich für eine einfache und anschauliche Darstellung entscheiden. Dabei zählt nur, dass Sie von Ihren Stakeholdern verstanden werden, alle in Ihrem Requirements Engineering Team dieselbe grafische Sprache sprechen. Im objectif Requirements Modeller finden Sie neben einer Auswahl an UML/SysML-Diagrammen auch andere aufgaben- und zielgruppenbezogene Darstellungstechniken. Wo bleibt der Text? Die Nützlichkeit von Diagrammen schön und gut. Aber Sie können sich nicht vorstellen, dass Diagramme die textuelle Beschreibung von Anforderungen ersetzen können? Richtig, das sollen die Diagramme auch nicht. Das wichtigste Mittel zur Kommunikation mit Stakeholdern und im Team ist und bleibt die natürliche Sprache. Alle Artefakte wie Stakeholder, Ziele, Anforderungen, Testfälle etc. haben eine textuelle Beschreibung. Der objectif Requirements Modeller bietet Ihnen Formulare an, um die Beschreibungen schnell und einheitlich strukturiert zu erfassen. Diagramme werden meist parallel dazu erstellt und machen. Sie machen Beziehungen, Abhängigkeiten und Referenzen sichtbar, die in textuellen Beschreibungen kaum konsistent zu pflegen sind. Sie haben direkt in den Diagrammen, aber auch unabhängig davon Zugriff auf diese Texte. 4

5 objectif Requirements Engineering Prozess: Das Vorgehen zum Tool Nachfolgend lernen Sie den objectif Requirements Engineering Prozess im Überblick kennen, den wir bei der Entwicklung des Werkzeugs im Kopf hatten. Ausgangspunkt: Projektauftrag Gehen wir an den Anfang eines Projekts zu dem Punkt, an dem es noch nichts gibt außer einem Projektauftrag. Der begründet im günstigsten Fall das Projekt und beschreibt, was sich das Unternehmen oder der Kunde von dem zu entwickelnden System verspricht. Dazu enthält er (hoffentlich) den Business Case, also die betriebswirtschaftliche Rechtfertigung des Projekts und den terminlichen und finanziellen Rahmen. Wenn das neue System Geschäftsprozesse unterstützen soll, dann steht vermutlich im Projektauftrag, welche strategischen Ziele das Unternehmen mit der Neugestaltung der Prozesse verfolgt. Wenn es um die Entwicklung von Softwareprodukten oder softwareintensiven Systemen für den Markt geht, dann erläutert der Projektauftrag wahrscheinlich die zugrunde liegende Produktstrategie. Auf dieser Basis kann es dann losgehen mit dem Ermitteln der Anforderungen. Sie wissen ja: So einfach ist die Sache in der Unternehmensrealität leider nicht. Es ist einiges an Vorarbeit nötig, damit Sie: nicht nur irgendwelche, sondern die richtigen und relevanten Anforderungen ermitteln und das möglichst vollständig, wissen, wer die Anforderungen bewerten muss und mit wem Sie die Anforderungen abstimmen müssen. Anforderungen entwickeln, die finanziell, organisatorisch, personell und technisch realisierbar sind. Was ist konkret zu tun und was muss dabei herauskommen? Der objectif Requirements Engineering Prozess gibt darauf diese Antworten: Vollständigkeit im Visier: Systemkontext Stakeholder Ziele Anforderungen konkretisieren Ziele. Der Projektauftrag steckt mit den dort beschriebenen strategischen und wirtschaftlichen Zielen und dem skizzierten Scope des zu entwickelnden Systems nur einen groben Rahmen ab. Er ist meistens zu grob, um daraus konkrete Anforderungen abzuleiten. Zunächst müssen die Ziele gemeinsam mit den Stakeholdern detailliert werden. Stakeholder sind die Personen, Gruppen und Organisationseinheiten, die ein wie auch immer geartetes Interesse an dem zu entwickelnden System haben. Sie nehmen direkt oder indirekt Einfluss auf die Anforderungen. Aber ist jeder, der Ziele mit dem System verfolgt und durch Anforderungen Einfluss auf die Entwicklung nehmen will, tatsächlich ein relevanter Stakeholder? Um das zu entscheiden, müssen Sie die Umgebung des Systems den Systemkontext genau kennen. Wird der Systemkontext nicht vollständig definiert, werden auch die Anforderungen unvollständig bleiben. Bei der Analyse hilft ein Systemkontextdiagramm. Um den Systemkontext abzubilden, kann man Anwendungsfalldiagramme oder Blockdiagramme der UML/SysML verwenden. Wir finden eine Darstellung hilfreicher, die sich an den klassischen Datenflussplänen nach DeMarco orientiert. 5

6 Bild 2: Die ersten Schritte und Ergebnistypen des objectif Requirements Engineering Prozesses Das Systemkontextdiagramm beantwortet die Frage: Welche Elemente (dazu gehören u.a. fremde Systeme, aber auch Akteure) befinden sich in der Umgebung des geplanten Systems und sind für die Definition und das Verständnis der Anforderungen relevant? Wir haben in diesem Diagrammtyp speziell die Möglichkeit geschaffen, auch Regelungen, Normen und Standards abzubilden, die das zu entwickelnde System erfüllen muss. Bei der Definition des Systemkontextes ist noch eine weitere Frage zu beantworten: Was ist im System und was liegt außerhalb? Also, wie grenzt sich das System gegen seinen Kontext ab? Ist das geklärt und in der Beschreibung des Systems im Systemkontextdiagramm festgehalten, kann es losgehen mit der Analyse der Stakeholder und ihrer Ziele. Stakeholder verfolgen Absichten. Sie versprechen sich von einem zu entwickelnden System, dass es ihnen dabei hilft, diese Absichten umzusetzen. Damit das gelingt, muss das System aus Sicht eines Stakeholders spezielle Merkmale besitzen. Die Beschreibung eines solchen Merkmals vor dem Hintergrund der Absichten eines Stakeholders wird als ein Ziel bezeichnet. Eine Zielbeschreibung ist Text, der formularbasiert erfasst und somit einheitlich strukturiert wird. Um konkurrierende oder abhängige Ziele zu erkennen und Zielkonflikte zusammen mit den Stakeholdern zu lösen, hilft es, Ziele, ihre Verfeinerung und ihre Beziehungen untereinander in Zieldiagrammen abzubilden. Zieldiagramme sind im Kern UND/ODER- Bäume. 6

7 Iterativ stabilisieren: Ziele Szenarien Anforderungen Diagramme beschreiben ein System unter verschiedenen Aspekten. Geht es mit einem Aspekt nicht richtig voran, dann wechselt man und das ist eine besondere Stärke modellbasierter Methoden einfach den Blick. Also hakt es beim Verstehen oder Verfeinern von Zielen, dann hilft es, Szenarios für Ziele zu entwickeln. Szenarios beantworten die Frage: Wie wird ein Ziel in Interaktion mit dem System erreicht? Szenarios können als Anwendungsfälle der UML modelliert und formularbasiert mit strukturierten Texten spezifiziert werden. Oder man entwickelt dafür Aktivitätsdiagramme der UML. Sowohl aus Zielen als auch aus Szenarios lassen sich oft Anforderungen ableiten. Anforderungen können wiederum durch Szenarios beschreiben werden, um daraus möglicherweise detailliertere Anforderungen zu gewinnen. Das Vorgehen ist hier hochgradig iterativ. Genau wie Ziele werden auch Anforderungen nach einem einheitlichen Schema mit Text beschrieben. Aber je mehr Anforderungen entstehen, desto schwieriger wird es, Zusammenhänge zu erkennen und sich zu orientieren. Hier helfen Anforderungsdiagramme der SysML. Sie zeigen unter anderem: welche Anforderungen durch Verfeinern auseinander hervorgegangen sind, welche Anforderungen voneinander abgeleitet wurden, welche Stakeholder an den Anforderungen in welchem Maße interessiert sind, welche Testfälle zu einer Anforderung definiert sind, welche Anwendungsfalldiagramme eine Anforderung detaillieren. Bild 3: Schritte und Ergebnistypen der Anforderungsermittlung 7

8 Parallel detaillieren: Anforderungen Systemarchitektur Das ist aber noch nicht alles. In Anforderungsdiagrammen können Sie außerdem abbilden: welche Systemkomponenten beschrieben mit Block-, Package- oder Klassendiagrammen der UML/SysML eine Anforderung verfeinern, welche Systemkomponenten definiert als Blöcke im Sinne der SysML eine Anforderung erfüllen. Moment wie kommt zum Zeitpunkt der Anforderungsermittlung mit einem Mal die Systemarchitektur ins Spiel? Die Forderung nach Anforderungen, die auch realisierbar sind, legt es nahe, Anforderungen parallel zur Systemarchitektur zu detaillieren. Bild 4: Das Twin Peaks Model zum parallelen Verfeinern der Anforderungen und der Systemarchitektur Für die parallele Verfeinerung von Anforderungen und Systemarchitektur (nach dem Twin Peaks Model, siehe [Nuseibeh, 2001]) findet der Systemarchitekt im objectif Requirements Modeller die erwähnten Klassen- und Packagediagramme sowie Blockdefinitions- und interne Blockdiagramme vor. 8

9 Bild 5: Die Diagrammtypen für die Beschreibung der Systemarchitektur Per Vorlagen auf Knopfdruck: Auswertungen Dokumente Schließlich muss die Qualität der Anforderungen geprüft und die Anforderungen müssen dokumentiert werden. Die automatisch geführte Historie und die sichtbar gemachten Entwicklungszustände (die Zustandswechsel können Sie übrigens über eigene Zustandsautomaten steuern), helfen Ihnen, bei der Qualitätssicherung den Überblick zu behalten. Sind die Stakeholder-Ziele durch Anforderungen abgedeckt? Haben Sie alle Anforderungen eines Stakeholders tatsächlich erfasst? Das Tool hilft Ihnen, Fragen wie diese mithilfe von Auswertungen zu beantworten: Auswertungen sind dynamische Abfragen. Sie basieren auf Vorlagen wir nennen sie Abfragetypen, die der Tool-Administrator vorbereiten kann. Als Requirements Engineer passen Sie sie dann nur noch an Ihren Bedarf an. 9

10 Bild 6: Die letzten Schritte bis zum Lasten-/Pflichtenheft Ein Lastenheft, ein Pflichtenheft oder auch ein Vision-Dokument darauf läuft die Arbeit letztlich hinaus. Mit dem objectif Requirements Modeller erzeugen Sie ein solches Dokument in Microsoft Word einfach per Knopfdruck. Denn auch für Dokumente werden Vorlagen verwendet. Darin können Sie festlegen, welche Artefakte, Diagramme und Abfragen in das Dokument aufgenommen werden sollen. So erzeugen Sie sehr schnell eine aussagekräftige Dokumentation. Bringen wir es auf den Punkt Ermittlungstechniken, Prüftechniken, Soft Skills im Umgang mit Team und Stakeholdern die Techniken und Fähigkeiten, die ein Requirements Engineer heute beherrschen bzw. besitzen muss, sind vielfältig. Der toolunterstützte Prozess, den wir hier in a Nutshell vorgestellt haben, beleuchtet die ingenieurmäßigen Teile des Requirements Engineering Know-hows: Es ist ein Basisprozess, d. h., er enthält die Aktivitäten und Artefakte, die im Rahmen des Requirements Engineering unbedingt nötig sind. Er ist modellorientiert, folgt aber nicht blindlings einem Standard wie UML oder SysML. Er lässt sich gleichermaßen mit schwergewichtigen Prozessen und agilem Vorgehen kombinieren, sodass Sie ihn zur Grundlage Ihres eigenen Vorgehens machen können. Probieren Sie das Tool mit Prozess doch einfach aus. Wir freuen uns auf ein Feedback. 10

11 Quellen [Nuseibeh 2001] Bashar Nuseibeh:Weaving Together Requirements and Architectures, zum Zeitpunkt der Erstellung dieses Textes zu finden unter: [OMG 1] Object Management Group, UML Resource Page, [OMG 2] Object Management Group, OMG SysML Specifications, [Pohl, Rupp 2011] Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering, dpunkt.verlag, 3. korrigierte Auflage,

12 Copyright Die vorliegende Dokumentation ist urheberrechtlich geschützt. Ohne ausdrückliche schriftliche Genehmigung der microtool GmbH, Berlin, darf kein Teil dieser Publikation für Zwecke jeglicher Art vervielfältigt oder übertragen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln, elektronisch oder mechanisch, dies geschieht. objectif und microtool making IT better sind eingetragene Warenzeichen der microtool GmbH. Microsoft, Windows und Microsoft Office sind eingetragene Warenzeichen der Microsoft Corporation. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in dieser Publikation berechtigt ferner auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. 12