Requirements Engineering and Cost Estimation - Ziele

Ziele, Informanten & System

Mein Motto als Organisationsentwicklerin – ‚The best ideas are already in your head – set them free!’ – passt auch hervorragend für das Requirements Engineering. In beiden Fällen geht es nicht darum, die Welt oder konkreter die Bedürfnisse und Wünsche der Stakeholder neu zu erfinden, sondern mit dem zu arbeiten, was bereits da ist. Das ist aber meist leichter gesagt als getan. Vor allem so lange nicht klar ist, um welche Ideen, Vorstellungen und Visionen es sich genau handelt und wie sie aus den jeweiligen Köpfen herauszubekommen sind. Ein kurzer Dialog aus dem Buch ‚Alice im Wunderland‘ veranschaulicht das. Alice fragte da:

‚Würdest du mir bitte sagen, wie ich von hier aus weitergehen soll? (…)‘ ‚Das hängt zum großen Teil davon ab, wohin du möchtest‘, sagte die Katze. ‚Ach, wohin ist mir eigentlich gleich –‘, sagte Alice. ‚Dann ist es auch egal, wie du weitergehst‘, sagte die Katze.

Vieles ist unplanbar. Die heutige Welt mit ihrer immer rascher wachsenden Komplexität sowie den permanenten Ansprüchen sich und Unternehmen weiterzuentwickeln, erzeugt den Eindruck der Instabilität und das Gefühl der Unsicherheit. An lange stabile Phasen wie in der Vergangenheit gibt es nur mehr vage Erinnerungen, weshalb oftmals auf unvorhersehbare Situationen mit Improvisation reagiert wird. Dennoch sollte grundsätzlich in Softwareprojekten und damit im Requirements Engineering eine bekannte und damit wegweisende Ausrichtung angestrebt werde. Mit Laotse heißt das: ‚Nur wer sein Ziel kennt, findet den Weg.‘

Bereits vor dem ‚eigentlichen‘ Start der Systemanalyse sind einige Schritte zu berücksichtigen, um nicht das falsche Haus abzureißen bzw. ein ungewünschtes oder ungeeignetes System zu entwickeln. Üblicherweise beginnen viele Projekte schon mit Zeitdruck, weil unter anderem aufgrund von Diskussion, ob sie überhaupt durchgeführt werden sollen oder nicht, das Loslegen verzögert wird. Dabei ist mindestens so wichtig, wie die Entscheidung, ob ein Projekt umgesetzt werden soll, wie was genau gemacht werden soll und warum. Diese Überlegungen werden häufig mit den Worten – ‚Was wir brauchen, ist eh klar!‘ – übersprungen. Doch erst diese Klärungsphase verhindert die immens unangenehme Situation, dass nach unzähligen durchgearbeiteten Wochen und Monaten mit Höchstleistungen, der Kunde dann das System nicht abnimmt, es am Markt vorbei entwickelt wurde oder gänzlich nicht funktioniert. Viele Projekte werden also zu schnell gestartet, ohne die für ein erfolgreiches Projekt unumgängliche Ziel-, Stakeholder- und Kontextanalyse.

Ziele

Das Wissen, zum Beispiel was beim Kunden oder Nutzer anders sein wird, wenn das gewünschte System ausgeliefert ist, wofür es das Projekt überhaupt braucht oder wer davon profitieren wird und wie, ist die Voraussetzung für das Sammeln von Anforderungen. Eine Projektvision und Projektziele dienen als Leitlinie, da es, wie bereits erwähnt, ohne Kenntnis des Ziels unmöglich ist, sich auf den Weg in die dafür notwenige Richtung zu machen. Diesem Ziel werden dann die Anforderungen untergeordnet, anhand dessen wird strukturiert und priorisiert. Ohne definiertes und vereinbartes Ziel sind die Eigenschaften und die Qualität des Produkts bis zu einem gewissen Grad zufällig. Wenn die Entwicklung nicht markt- bzw. kundenorientiert stattfindet, ist der Erfolg fragwürdig. Zielgerichtetes Arbeiten ist die Grundlage für eine systematische Entwicklung und die Wahl der Ziele hat entscheidenden Einfluss auf das entstehende Ergebnis sowie den Entwicklungsprozess. Eine starke Vision und klare Ziele stimulieren außerdem Projektteams, die aufgrund der Ausrichtung bzw. Identifikation mit erhöhter Motivation effektiver arbeiten und qualitativ hochwertigere Resultate liefern.

Daher liegt die Aufmerksamkeit des Requirements Engineering bei Projektbeginn darin, die wichtigsten Kunden, Märkte und Wettbewerber zu identifizieren und zu verstehen, eventuell als Teil der Marketingspezifikation. Das dabei entstehende Knowhow gilt es in weiterer Folge, mit den Beteiligten, vor allem dem Projektmanager abzustimmen. Vorsicht ist dabei geboten, denn Ziele sind Anforderungen auf abstrakter Ebene. Ebenso wie für Anforderungen gilt es, die Ziele zu verschriftlichen und Qualitätskriterien einzuhalten. Damit ist dann eine solide Ausgangsbasis für die folgende Requirements Analyse geschaffen. Ohne diese Grundlage befindet sich der Requirements Engineer wie im Nebel und startet quasi den Versuch, die Bewältigung eines Projekts im Blindflug zu absolvieren. Schon aus Eigeninteresse, um bei der Erfolgsmessung des Requirements Engineering zu bestehen, wird er die Ziele für das System bzw. Projekt einfordern. Wenn diese Ziele nur vage sind, z.B. weil sie nicht dokumentiert und/oder abgestimmt sind, ist es sehr wahrscheinlich, dass viele Ressourcen beim Versuch verbraucht werden, etwas zu erreichen, dass keiner so genau kennt. Neben hohen Kosten entsteht dabei Frustration, die jede spätere Korrektur der Projektausrichtung mühsam gestaltet.

Folgende Einflüsse auf Ziele und Visionen gilt es zu berücksichtigen:

• Kunden (deren Ziele, Umfeld usw.)
• Strategie (Unternehmen, Markt usw.)
• Wettbewerb
• Produkte (Produktalter, Innovationsgrad, Änderungsumfang, Verfügbarkeit, Kostenstruktur usw.)
• Technologie
• Verfügbare Ressourcen (Zeit, Kompetenzen, Personal, Verfügbarkeit von Technologien/Komponenten usw.)

Die Vorgangsweisen zur Ermittlung von Zielen sind zahlreich und von den jeweiligen Rahmenbedingungen abhängig. Es bieten sich unter anderem Kreativitäts- oder Re-Use-Techniken an, um damit den mehrstufigeren Prozess zu gestalten:

• Involvierte Menschen, Dokumente und Systeme systematisch erheben
• Beschreibung der Ist-Situation neutral und ohne Beurteilung
• Bewertung der Situation durch Sammeln der subjektiven Aspekte wie Schwierigkeiten oder Potentiale
• Ziele definieren

Konkurrierende Ziele führen immer zu Einbußen beim möglichen Ergebnis, vor allem bei nicht-funktionalen Anforderungen aufgrund des wechselseitig starken Einflusses. Entscheidend ist daher, Widersprüche gegen einander abzuwiegen und mit Prioritäten zu versehen. In einem preissensitiven Markt werden zum Beispiel Herstellungskosten meist wichtiger als Qualitätskriterien eingestuft, auch wenn beide Anforderungen grundsätzlich wichtig sind. Die Beteiligten in der Umsetzung müssen diese Ziele kennen, um die kundenspezifischen Wünsche auch erfüllen zu können.

Bei Projektzielen geht es nicht nur darum, auf das Bekannte zu setzen, sondern das große Ganze im Blick zu haben. Folgendes Beispiel veranschaulicht das:

Sie sind in einer fremden Stadt und wollen zu einer bestimmten Sehenswürdigkeit, kennen sich aber nicht aus. Das ist die Problembeschreibung. Für diese gibt es nun mehrere bekannte Lösungsmöglichkeiten: zum einen die klassische Karte aus Papier zum Zusammenfalten, zum anderen ein Smart Phone mit einer Karten-App. Je nachdem, was Sie im Kopf haben, unterscheiden sich die Anforderungen:

Im Fall der Karte lauten die Ansprüche,

• dass sie faltbar ist, damit sie in einer Tasche verstaut werden kann,
• dass sie eine möglichst hohe Stabilität aufweist, damit sie nicht gleich zerreißt,
• dass der Maßstab für einen Fußgänger passend ist, d.h. wahrscheinlich, nur die Abbildung der sehenswerten Innenstadt, aber auch nicht jedes Baums.

Wenn ein Mobiltelefon zur Verfügung steht, wünscht sich der Nutzer möglicherweise

• eine Anbindung an eine drahtlose Verbindung,
• eine Anwendung, die Karten erstellt,
• das passende Kartenmaterial des Zielorts,
• die Möglichkeit, Start- und Zielort einzugeben, sowie
• dass das System in der Lage ist, eine Route zu erstellen und anzuzeigen.

Die Unterscheidung zwischen Problemen und Lösungen ist wie beim Arbeiten mit Anforderungen, auch für die Ziele relevant. Ebenso handelt es sich bei beiden Abläufen um iterative Prozesse, in die die Parameter des Systems sowie die unterschiedlichen Stakeholder einbezogen werden müssen. Eine Vision und Ziele sind schrittweise zu gestalten. Als Requirements Engineer empfiehlt es sich, Informationen in überschaubare Happen zu verpacken und dementsprechend zu ‚servieren‘. So sind sie leichter ‚verdaulich‘ und die Beteiligten können leichter abgeholt und zufrieden gestellt werden.

Wie im Beispiel sichtbar wurde, gelten neben Qualitätskriterien, die nicht nur für Anforderungen, sondern auch für Ziele wichtig sind, weitere Aspekte:

• Lösungsneutralität
• Inklusion einschränkender Rahmenbedingungen
• Realistische Erreichbarkeit

Der Darstellung von Zielen sind keine Grenzen gesetzt. Zu berücksichtigen ist, ein dem Projekt angemessener Umfang, die entsprechende Dokumentationsform sowie eine möglichst präzise Beschreibung, damit die Verständlichkeit für alle Beteiligte gegeben ist.

Stakeholder

Erfolgreiche Projekte haben zum richtigen Zeitpunkt, die richtigen Menschen für die richtigen Aufgaben involviert. Die Menschen sind zentral für jedes Projekt, als Auftraggeber und Kunde deren Ausgangs- und Endpunkt. Die Technik ist in den meisten Fällen das Hilfsmittel, das sich den Menschen anpassen sollte.

Alle Personen oder Organisationen, die die Anforderungen des geplanten Systems direkt oder indirekt beeinflussen, sind Stakeholder dieses Systems. Neben den bereits erwähnten Auftraggebern und Kunden umfasst diese Gruppe auch Architekten, Entwickler, Tester, Nutzer, Betreiber, Schulungspersonal usw. Weitere gängige Bezeichnungen sind Systembetroffene bzw. -beteiligte, Wissensträger oder Interessensvertreter. Stakeholder sind dementsprechend fast immer die wichtigste Quelle für Requirements.

Um Stakeholder ausfindig zu machen, ist es sinnvoll, beim Projektstart den Projektleiter sowie andere schon zu Beginn aktive Personen heranzuziehen sowie jeden weiteren Stakeholder nach noch relevanten Personen zu befragen. Für einen Requirements Engineer sind unter anderem folgende Fragen hilfreich: Wer steht hinter den Anforderungen für das zu entwickelnde System? Wer wird es nach der Fertigstellung benutzen? Wer profitiert (ökonomisch) von dem System? Darauf aufbauend erstellt dieser eine Stakeholderliste, in der Daten wie Name, Funktion bzw. Projektrolle, Kontakt, zeitliche bzw. räumliche Verfügbarkeit, Relevanz, Wissens­gebiet sowie -umfang und die jeweiligen Interessen sowie Ziele im Projekt vermerkt sind. Sind viele Ansprechpartner in einem Projekt vorhanden, ist es sinnvoll, diese zu klassifizieren, z.B. mit dem Stakeholdermodell von Babou Srinivasan .

Schlussendlich gilt es, die ausgewählten Ansprechpersonen mit dem Projektmanager bzw. dem zuständigen Management abzustimmen. Für eine effektive Arbeit ist es entscheidend, zu überprüfen, dass die gelisteten Beteiligten wirklich einen Beitrag leisten und ihre Expertise nicht von anno dazumal ist oder von ihnen nicht kommuniziert werden kann. Wenn allerdings wichtige Stakeholder übersehen werden, fehlen potentiell gewisse Anforderungen und das entwickelte System bleibt unvollständig. Die Konsequenz sind kostenintensive und aufwendige Nacharbeiten, wenn diese überhaupt möglich sind und es nicht zum Scheitern des Projekts kommt.

Zu Beginn gilt es als Requirements Engineer, das Eis zu brechen und die Projektbeteiligten an Board zu bringen. Dafür ist es notwendig, die Sprache der Stakeholder zu sprechen und sich in das Fachgebiet einzuarbeiten. Während des Projekts müssen dann die Kontakte gepflegt werden, indem das Knowhow, die Zeit und der Einsatz, die die Stakeholder einbringen, anerkannt werden. Stakeholder-Relationship-Management ist für das gute Funktionieren von Projekten essentiell und erfordert vom Prozessverantwortlichen eine wertschätzende Haltung im Umgang mit Stakeholdern. Wenn mit Betroffenen Verantwortung geteilt wird, ihnen Aufgaben delegiert werden und sie in Entwicklungen einbezogen sind, bindet sie das an das Projekt und hält dadurch ihr Interesse hoch. Es ist dementsprechend eine der Aufgabe des Requirements Engineer, die Stakeholder über das Projekt auf dem Laufenden zu halten und Arbeitsergebnisse verständlich an alle zu kommunizieren. Klare Vereinbarungen unterstützen die Zusammenarbeit. Es empfiehlt sich daher, je nach Verhältnis eine Art Abkommen zu erstellen, um die Verbindlichkeit in beide Richtungen zu verstärken.

System & Systemkontext

Die Anforderungen der Stakeholder liegen nicht auf der Straße, sondern müssen erarbeitet werden. Eine weitere Voraussetzung dafür ist, die Grenzen des gewünschten Systems aufzuzeigen bzw. festzulegen. Dafür sind die sich aus der relevanten Umgebung ergebenden Bedingungen zu identifizieren, da diese direkte Auswirkungen auf die Anforderungen haben.

Systemkontext

Eine Vorstellung der gewünschten Zukunft ermöglicht eine Annahme, wie das fertige System in die reale Umgebung integriert sein wird, wie Schnittstellen ausschauen könnten, wie einzelne Teile in Relation zueinander stehen. So können alle Aspekte bestimmt werden, die Auswirkungen auf das gewünschte System und damit die Anforderungen ausüben. Um die Anforderungsspezifikation einwandfrei und umfassend durchführen zu können, sind die Zusammenhänge zwischen allen relevanten Merkmalen im geplanten System und Systemkontext zu entschlüsseln und festzuhalten.

Unter Systemkontext wird der Ausschnitt der Wirklichkeit (die Systemumgebung, in die das Zielsystem eingebettet wird) bezeichnet, der für das Verständnis und die Beschreibung der Anforderung des geplanten Systems relevant ist und nicht im Rahmen der Entwicklung dieses Systems gestaltet werden kann. Mögliche Aspekte des Systemkontexts sind Stakeholder, bereits vorhandene Systeme im Betrieb, Prozesse (z.B. technische oder unternehmerische), vorgegebene Ereignisse sowie Dokumente (wie Gesetze, Standards usw.).

Die Ermittlung aller relevanten Faktoren liegt in der Verantwortung des Requirements Engineer. Werden Kontextcharakteristika übersehen bzw. fehlerhafte oder unzu­reichende einbezogen, hat das meist schwerwiegende Folgen bei der Inbetriebnahme des Systems. Das ‚Füttern‘ des Zielsystems mit unvollständigen oder inkorrekten Annahmen führt in vielen Fällen schlussendlich sogar zum Versagen des Systems.

Die Abgrenzung des Kontexts sorgt für einen groben Rahmen für die weitere Analyse, denn der Ursprung aller Anforderungen eines zu entwickelnden Systems liegt im spezifischen Systemkontext. Je kompletter der Kontext von Requirements bekannt ist, umso geringer ist die Wahrscheinlichkeit, dass diese falsch interpretiert werden und daraus andere verheerende Konsequenzen entstehen.

System- und Kontextgrenzen

Um Klarheit über den Systemkontext zu gewinnen, gilt es diesen in beide Richtungen – also vom zu entwickelnden System (Systemgrenze) sowie vom bedeutungslosen Teil der realen Umgebung (Kontextgrenze) – zu separieren.

System- und Kontextgrenze

Zwei Abgrenzungsprozesse, um den Systemkontext zu bestimmen:

• Systemabgrenzung

Systemgrenze unterscheidet, was sich innerhalb des Systems befindet und was nicht mehr, also Teil des Umfelds ist.

• Kontextabgrenzung

Welcher Teil der Systemumgebung kontextrelevant bzw. für das geplante System unerheblich ist und somit keinen Einfluss auf die Requirements des Zielsystems hat, gibt die Kontextgrenze an.

Der Systemkontext liegt dementsprechend zwischen der Systemgrenze und der Kontextgrenze. Dieser beinhaltet alle Faktoren, die die Requirements des zu entwickelnden Systems entscheidend bestimmen bzw. nicht durch den Entwicklungs­prozess verändert werden können. Aspekte innerhalb des Systemkontexts sind unter Umständen die Hardware und Software des geplanten Systems, Geschäftsprozesse, technische Prozesse, Stakeholder, Organisations­strukturen und/oder Bestandteile der Infrastruktur. Differenziert wird außerdem zwischen einem logischen und einem physikalischen Kontext. Der erste beschäftigt sich mit dem, was mit Nachbar­systemen kommuniziert wird, der zweite mit den Kanälen und Übertragungsmedien, mit denen das Zielsystem mit den angrenzenden Systemen verbunden ist.

Je vollständiger und präziser eine Kontextabgrenzung ist, desto leichter wird die Spezifikation des zu entwickelnden Systems. Für komplexe Systeme ist das unter Umständen dennoch nur beschränkt möglich. In jedem Fall erfordert die System- und Kontextabgrenzung meist mehrere Runden mit den relevanten Stakeholdern, um eine möglichst exakte Abgrenzung vorzunehmen.

Jedes System verfügt über eine mehr oder weniger große Anzahl an Schnittstellen, an denen es mit der Umgebung bzw. Nachbarsystemen interagiert. An diesen Punkten auf der Systemgrenze erfolgt die Bereitstellung der Funktionalitäten an die Umgebung, die Überwachung des Umfelds, die Beeinflussung von Umgebungs­parametern sowie die Steuerung von Prozessen im Systemkontext. Die Schnittstellen können unter anderem Mensch-Maschine, Hardware oder Software miteinander verbinden.

Wenn gewisse Schnittstellen bzw. Funktionen oder Merkmale eines Systems nur vage oder noch gar nicht bekannt sind, ist von Grauzone in der Systemabgrenzung die Rede. Eine zeitweise Unschärfe kann auch bei der Kontextgrenze bestehen, wenn angrenzende Systeme noch nicht vorhanden bzw. klar beschreibbar sind. Dann erfolgen Annahmen, die unbedingt als solche gekennzeichnet sein müssen, um diese im Zuge des Projektfortschritts so früh wie möglich durch Fakten zu ersetzen. Es gibt Stakeholder, die sich ungern festlegen und deshalb gerne Grauzonen aufrech­terhalten. Aufgabe des Requirements Engineer ist es in solchen Situationen hartnäckig zu bleiben, um klare Verhältnisse zu schaffen. Ungenauigkeiten bei der Systemabgrenzung müssen im Laufe des Requirements Engineering ausgeräumt werden. Bezogen auf den Kontext ist eine vollständige und präzise Abgrenzung in komplexen Systemen nicht möglich und es bleiben gewisse Systemeinflüsse für einzelne Teile der Umgebung unbestimmbar.

Wenn sich während einem Projekt zum Beispiel der Umfang oder die Wirkung der noch offenen Schnittstellen und/oder Funktionen verändert, so kann dies zu einer Verschiebung der gesamten Grauzone im Systemkontext führen. Sind für bestimmte Faktoren der Umgebung die Relationen zum Zielsystem fraglich, ist von der Grauzone der Kontextabgrenzung die Rede. Im agilen Setting sind die Grauzonen zu Beginn eines Projekts sehr groß und werden erst von Iteration zu Iteration reduziert, denn es wird keine umfassende Systemabgrenzung am Projektstart durchgeführt.

Um den Systemkontext zu dokumentieren, eignen sich unterschiedliche Methoden, sowohl natursprachlicher, als auch grafischer Art. Empfehlenswert sind standardisierte grafische Beschreibungen, z.B. Use-Case-Diagramme, Datenfluss Diagramme oder UML Klassendiagramme. In der Praxis werden häufig mehrere Darstellungsformen kombiniert, um die Verständlichkeit für alle Stakeholder sicherzustellen.