Die neun Prinzipien im Requirements Engineering

Das Requirements Engineering (RE) umfasst vier Typen von Tätigkeiten: Anforderungen werden ermittelt, dokumentiert, analysiert und verwaltet. Zahlreiche Techniken unterstützen diese Tätigkeiten. Bei der Durchführung sind laut International Requirements Engineering Board (IREB)¹ neun Prinzipien zu beachten, die ausführlich im IREB Foundation Level Lehrplan Version 3.0.1² beschrieben und hier kurz zusammengefasst werden:

Prinzip 1: Werteorientierung

Anforderungen sind Mittel zum Zweck, kein Selbstzweck!

Requirements Engineering legt einen starken Fokus auf die Wertschöpfung einer Entwicklung. Der Wert einer konkreten Anforderung entspricht ihrem Nutzen abzüglich der Kosten für das Ermitteln, Dokumentieren, Validieren und Verwalten der Anforderung. Der Nutzen einer Anforderung wird durch den Grad bestimmt, den sie dazu beiträgt, dass ein System entwickelt wird, das die Wünsche und Bedürfnisse der Stakeholder erfüllt und gleichzeitig das Risiko von Fehlentwicklungen und Folgekosten reduziert.

Prinzip 2: Stakeholder

Im RE geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen!

Um die Wünsche und Bedürfnisse der Stakeholder zu verstehen, ist das Stakeholdermanagement eine Kernaufgabe im Requirements Engineering. Stakeholder sind alle Personen oder Organisationen, die von den Aktivitäten eines Unternehmens direkt oder indirekt betroffen sind oder ein Interesse an diesen Aktivitäten haben. Im Kontext einer Systementwicklung treten sie bspw. als Benutzer, Kunde, Auftraggeber, Betreiber oder Regulierungsbehörde auf. Und natürlich kann ein Stakeholder auch mehrere Rollen gleichzeitig ausfüllen.

Für Stakeholder-Rollen mit zu vielen Einzelpersonen oder bei unbekannten Einzelpersonen können fiktive, archetypische Beschreibungen – sogenannte Personas – definiert werden. Personas helfen dabei, Annahmen  zu treffen und Bedürfnisse, Einstellungen und Handlungen potentieller Anwender besser zu verstehen.

Grundsätzlich reicht es nicht aus, lediglich die Anforderungen der Endbenutzer oder Kunden zu berücksichtigen, denn so würden mit Sicherheit kritische Anforderungen anderer Stakeholder übersehen werden. Wichtig ist auch die Erkenntnis, dass Stakeholder unterschiedliche, sich ggf. auch widersprechende Bedürfnisse und Standpunkte haben können. Solche Konflikte – idealerweise so frühzeitig wie möglich – zu identifizieren und zu lösen, ist eine wichtige Aufgabe im Zuge von Prinzip 2.

Prinzip 3: Gemeinsames Verständnis

Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich!

Für die erfolgreiche Entwicklung von Systemen ist ein gemeinsames Verständnis der beteiligten Parteien – Stakeholder, Requirements Engineers und Entwickler – unerlässlich. Unterschieden werden zwischen einem

• explizitem Verständnis, das durch dokumentierte und vereinbarte Anforderungen gemeinsam erreicht wird, und
• implizitem Verständnis, das auf gemeinsamem Wissen über Bedürfnisse, Visionen, Kontext usw. basiert.

Domänenwissen, frühere erfolgreiche Zusammenarbeit, gemeinsame Kultur und Werte sowie gegenseitiges Vertrauen sind die Voraussetzungen für ein gemeinsames Verständnis, während geografische Distanz, Outsourcing oder große Teams mit hoher Fluktuation Hindernisse darstellen.

In der gelebten Praxis des Requirements Engineerings gibt es einige Praktiken wie

• die Nutzung von Glossaren,
• das Erstellen und Untersuchen von Prototypen,
• die Verwendung von bestehenden Systemen als Bezugspunkt,
• die gemeinsame Schätzung von Aufwänden zur Umsetzung von Anforderungen,
• oder kurze Feedbackzyklen,

die das gemeinsame Verständnis fördern.

Prinzip 4: Kontext

Systeme können nicht isoliert verstanden werden!

Systeme sind in einem Kontext eingebettet. Der Systemkontext beschreibt die Interaktion eines Systems mit seiner Umgebung. Die Festlegung von System und Systemgrenze, sowie relevanter und irrelevanter Systemumgebung ist wichtig, denn dadurch werden die Aspekte definiert, die im Rahmen einer Entwicklung zu beachten sind.

Anfangs ist die Systemgrenze oftmals nicht klar und im Laufe der Zeit kann sie sich sogar verschieben. Die Klärung und die Beachtung der Systemgrenze und die Definition des Scopes sind wichtige RE-Aufgaben. Bei der Systemspezifikation reicht es übrigens nicht aus, lediglich die Anforderungen innerhalb der Systemgrenze zu berücksichtigen, denn Änderungen im Kontext können sich auch auf Systemanforderungen auswirken.

Prinzip 5: Problem – Anforderung – Lösung

Ein unausweichlich ineinandergreifendes Tripel!

Probleme, Anforderungen und Lösungen sind eng miteinander verflochten und koexistieren. Neben dem bekannten Szenario mit einem Problem eines Stakeholders, der daraus resultierenden Definition von Anforderungen und der Entwicklung von Lösungen bspw. in der Form von Features, gibt es auch Szenarien in denen Lösungsideen Nutzerbedürfnisse erzeugen, die als Anforderungen ausgearbeitet und in eine konkrete Lösung umgesetzt werden müssen. Ein solches Szenario greift typischerweise bei Innovationen.

Requirements Engineers versuchen das Tripel aus Problem, Anforderung und Lösung beim Denken, Kommunizieren und Dokumentieren so weit wie möglich voneinander zu trennen, da eine solche Trennung die Abwicklung der RE-Aufgaben erleichtert.

Prinzip 6: Validierung

Nicht-validierte Anforderungen sind nutzlos!

Um das Risiko unzufriedener Stakeholder von Anfang an zu kontrollieren, muss müssen Anforderungen validiert werden.  Es gilt zu prüfen, ob

• die Wünsche und Bedürfnisse der Interessengruppen durch die Anforderungen ausreichend abgedeckt werden,
• Einigkeit über die Anforderungen besteht und
• die Kontextannahmen vernünftig sind.

Prinzip 7: Evolution

Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall!

Anforderungen ändern sich kontinuierlich, bspw. durch

• geänderte Geschäftsprozesse,
• Wettbewerber, die neue Produkte oder Dienstleistungen einführen,
• Kunden, die ihre Prioritäten oder Meinung ändern,
• Veränderungen in der Technologie,
• Änderungen von Gesetzen oder Vorschriften,
• Rückmeldungen der Stakeholder bei der Validierung,
• entdeckte Fehler,
• geänderte Bedürfnisse oder
• Feedback von Systembenutzern, die nach einer neuen oder geänderten Funktion fragen.

Requirements Engineers verfolgen daher zwei widersprüchliche Ziele: sinnvolle Änderungen zuzulassen und Anforderungen stabil zu halten.

Prinzip 8: Innovation

Mehr vom Gleichen ist nicht genug!

Gutes Requirements Engineering versucht Stakeholder zu begeistern. Im Kleinen gelingt dies durch das Streben nach nützlichen, neuen Funktionen und einer positiven User Experience, im Großen durch das Streben nach disruptiven Ideen.

Beim Thema Innovation empfiehlt sich ein Blick in das Kano-Modell. Es beschreibt den Zusammenhang zwischen Kundenzufriedenheit und der Erfüllung von Kundenanforderungen, indem es Produktmerkmale definiert, auf die Anwender unterschiedlich reagieren.

Prinzip 9: Systematische und disziplinierte Arbeit

Wir können im RE nicht darauf verzichten!

Es gibt nicht den einen Prozess oder das eine Verfahren im Requirements Engineering, das in jeder Situationen gut funktioniert. Um die Qualität eines Systems sicherzustellen, müssen  die Prozesse, Praktiken und Arbeitsprodukte gewählt werden, die der jeweiligen Situation am besten entsprechen. Systematisches und diszipliniertes Arbeiten bedeutet, das Vorgehen an das jeweilige Problem, den Kontext und die Arbeitsumgebung anzupassen und nicht stur immer die gleichen Verfahren und Praktiken zu verwenden.

Das Zusammenspiel der Prinzipien

Aus den genannten neun Prinzipien im Requirements Engineering ergeben sich eine ganze Reihe von Tätigkeiten:

“Systematische und disziplinierte Arbeit” wird zwar erst als Prinzip 9 genannt, bildet aber die Grundlage für die Profession des Requirements Engineers. Das IREB schreibt: “Agilität und Flexibilität sind keine gültigen Entschuldigungen für einen unsystematischen ad hoc Stil der Arbeit im RE.” Zum systematischen Arbeiten gehört es dazu, den RE-Prozess für das aktuelle Projekt zu konfigurieren und die passendsten Techniken und Praktiken auszuwählen. Disziplin bedeutet, diese auch sauber durchzuführen.

Fünf Prinzipien betreffen die Ermittlung der Anforderungen:

Damit die Wünsche und Bedürfnisse der erfolgsentscheidenden Stakeholder erfüllt werden können (Prinzip 2), müssen Sie diese Personen identifizieren und analysieren, und in die Ermittlung der Anforderungen einbeziehen. Damit es nicht zu viel wird, sollten Sie die Stakeholder(gruppen) priorisieren, damit sich daraus auch die Prioritäten ihrer Anforderungen herleiten lassen.

Das Ziel der Anforderungsermittlung sind genau genommen nicht die dokumentierten Anforderungen auf Papier, sondern vor allem ein gemeinsames Verständnis in den Köpfen (Prinzip 3). Die Anforderungsspezifikation kann als Hilfsmittel dazu beitragen, aber auch Prototypen und kurze Feedbackschleifen. Diese müssen Sie darum in die Ermittlung der Anforderungen ausdrücklich einplanen.

Zusätzlich zu den Anforderungen müssen die Stakeholder gemeinsam auch den Kontext des Systems betrachten, weil Systeme nicht isoliert verstanden werden können (Prinzip 4).

Probleme (in der Anwendungsdomäne), Anforderungen und Lösungen sind eng miteinander verknüpft, müssen aber während der Ermittlung und Dokumentation streng getrennt werden (Prinzip 5). Alle Beteiligten müssen sich immer im Klaren darüber sein, worüber sie gerade sprechen (sollen).

Natürlich sollten sich Requirements Engineers nicht damit begnügen, nur die Wünsche der Stakeholder zu protokollieren. Er muss danach streben, die Erwartungen der Stakeholder zu übertreffen. Dazu fördert er die Kreativität. Ein Mittel dafür kann es sein, nach dem Warum und dem Wozu von Anforderungen zu fragen. Eventuell kann man das dahinter liegende Probleme mit innovativen Lösungen noch besser lösen (Prinzip 8).

Drei Prinzipien unterstützen die Analyse der Anforderungen:

Das Requirements Engineering ist kein Selbstzweck, sondern soll Mehrwert schaffen (Prinzip 1). Auch jede einzelne Anforderung soll nach ihrem Wertbeitrag bewertet werden, also Nutzen minus Kosten. Die beschriebene Systemfunktionalität oder -eigenschaft kann direkt zu mehr Umsatz oder Kosteneinsparungen führen, aber auch Nutzen stiften durch die Verringerung von Risiken wie z. B. des Risikos von Nacharbeiten. Darum sollte der Requirements Engineer bei der Analyse der Anforderungen fragen:

• Welchen Nutzen bringt diese Anforderung?
• Nutzt es, noch mehr Requirements Engineering zu betreiben oder wissen wir genug?
• Ist das Restrisiko, also das Risiko für eine spätere Nachbearbeitung oder für Softwarefehler, das durch die noch fehlenden Details in den Anforderungen entstehen können, akzeptabel?

Da es beim Requirements Engineering darum geht, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen (Prinzip 2), gehört zur Analyse der Anforderungen nicht nur die Verifikation, ob man aus dem Problem vollständig und richtig die Anforderungen und daraus die Lösung hergeleitet hat, sondern auch die Validierung, die prüft, ob die Anforderungen und die Lösung tatsächlich die Wünsche und Bedürfnisse der Stakeholder erfüllen. Erreichen können Sie dies insbesondere durch Prototyping, Reviews, Szenarien oder Walkthroughs.

Das IREB geht sogar so weit zu behaupten, dass nicht-validierte Anforderungen nutzlos sind (Prinzip 6). Diese Validierung muss möglichst früh stattfinden. Hierbei prüfen Sie nicht nur, ob die Anforderungen die Wünsche und Bedürfnisse der Stakeholder erfüllen (Prinzip 2), sondern auch ein gemeinsames Verständnis vorliegt (Prinzip 3).

Ein Prinzip bezieht sich konkret auf die Verwaltung von Anforderungen:

Da der Kontext des Systems und die Bedürfnisse der Stakeholder sich ständig ändern, können wir sicher damit rechnen, dass sich auch die Anforderungen ändern (Prinzip 7). Aber auch das Beheben von Fehlern und Lücken in den Anforderungen führt zu Änderungen. Diese müssen Sie als Requirements Engineer verwalten und steuern. Dabei suchen Sie die richtige Balance zwischen “heiße Verbesserungen der Anforderungen willkommen” und “halte die Anforderungen möglichst stabil”. Die Validierung von Anforderungen führt sowohl zu Änderungen als auch zu einer höheren Stabilität, nachdem die Anforderungen derart qualitätsgesichert wurden.

Und damit sind wir wieder bei Prinzip 9: Systematische und disziplinierte Arbeit. Es ist die Basis für die Prinzipien zur Erhebung und zur Analyse der Anforderung. Es ist die Grundlage für erfolgreiches Requirements Engineering.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Unter http://www.herrmann-ehrlich.de/ bloggt Frau Dr. Andrea Herrmann regelmäßig über Requirements Engineering und Software Engineering.

Gerne empfehlen wir Ihnen auch das kostenlose Requirements Engineering Whitepaper, das viele Erläuterungen zum Thema enthält.

[1] IREB e.V.
[2] Lehrplan IREB CPRE Foundation Level

Im t2informatik Blog hat Dr. Andrea Herrmann weitere Beiträge veröffentlicht, u. a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.