Grundsätze des Requirements Engineering

RE unterliegt einer Reihe von grundlegenden Prinzipien, die für alle Aufgaben, Aktivitäten und
Praktiken im RE gelten. Die folgenden neun Prinzipien bilden die Grundlage für die in den
folgenden Kapiteln dieses Lehrplans vorgestellten Praktiken.

1. Wertorientierung: Anforderungen sind Mittel zum Zweck, kein Selbstzweck

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

3. Gemeinsames Verständnis: Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht
   möglich

4. Kontext: Systeme können nicht isoliert verstanden werden

5. Problem–Anforderung–Lösung: Ein unausweichlich ineinandergreifendes Tripel

6. Validierung: Nicht-validierte Anforderungen sind nutzlos

7. Evolution: Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall

8. Innovation: Mehr vom Gleichen ist nicht genug

9. Systematische und disziplinierte Arbeit: Wir können im RE nicht darauf verzichten

Prinzip 1 - Wertorientierung: Anforderungen sind ein Mittel zum Zweck, kein
Selbstzweck

Der Wert einer Anforderung ist gleich ihrem Nutzen abzüglich der Kosten für das Ermitteln,
Dokumentieren, Validieren und Verwalten der Anforderung. Der Nutzen einer Anforderung ist
der Grad, den sie dazu beiträgt:

• Ein System zu bauen, das die Wünsche und Bedürfnisse der Stakeholder erfüllt.

• Das Risiko von Fehlschlägen und kostspieligen Nacharbeiten bei der Entwicklung des
  Systems zu verringern.

Prinzip 2 – Stakeholder: Im RE geht es darum, die Wünsche und Bedürfnisse der
Stakeholder zu befriedigen

Da es beim RE darum geht, die Wünsche und Bedürfnisse der Stakeholder zu verstehen, ist der
richtige Umgang mit Stakeholdern eine Kernaufgabe des RE. Jeder Stakeholder hat eine Rolle im
Kontext des zu errichtenden Systems, z.B. Benutzer, Kunde, Auftraggeber, Betreiber oder
Regulierungsbehörde. Ein Stakeholder kann auch mehrere Rollen gleichzeitig ausüben. Für
Stakeholder-Rollen mit zu vielen Einzelpersonen oder wenn Einzelpersonen unbekannt sind,
können fiktive archetypische Beschreibungen, sogenannte Personas, als Ersatz definiert werden.
Es reicht nicht aus, nur die Anforderungen der Endbenutzer oder Kunden zu berücksichtigen.
Dies würde bedeuten, dass wir kritische Anforderungen anderer Stakeholder übersehen
könnten. Benutzer, die Feedback zu einem in Gebrauch befindlichen System geben, sollten
ebenfalls als Stakeholder betrachtet werden.
Stakeholder können unterschiedliche Bedürfnisse und Standpunkte haben, was zu konträren
Anforderungen führen kann. Es ist eine Aufgabe des RE, solche Konflikte zu identifizieren und zu
lösen.
Die Einbeziehung der richtigen Personen in die entsprechenden Stakeholder-Rollen ist für
erfolgreiches RE von entscheidender Bedeutung. Praktiken zur Identifizierung, Priorisierung
und zur Zusammenarbeit mit Stakeholdern werden in LE 3.5 beschrieben.

Prinzip 3 – Gemeinsames Verständnis: Erfolgreiche Systementwicklung ist ohne eine
gemeinsame Basis nicht möglich

RE schafft, fördert und sichert ein gemeinsames Verständnis zwischen den und innerhalb der
beteiligten Parteien: Stakeholder, Requirements Engineers und Entwickler. Es gibt zwei Formen
des gemeinsamen Verständnisses:

• Explizites gemeinsames Verständnis (erreicht durch dokumentierte und vereinbarte
  Anforderungen)

• Implizites gemeinsames Verständnis (basierend auf gemeinsamem Wissen über
  Bedürfnisse, Visionen, Kontext usw.)

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.
Bewährte Praktiken zur Erzielung eines gemeinsamen Verständnisses umfassen die Erstellung
von Glossaren (LE 3.5), das Erstellen von Prototypen (LE 3.7) oder die Verwendung eines
bestehenden Systems als Bezugspunkt. Zu den Praktiken zur Bewertung des gemeinsamen
Verständnisses gehören unter anderem Beispiele für erwartete Ergebnisse, die Untersuchung
von Prototypen oder die Schätzung der Kosten für die Umsetzung einer Anforderung.

Die wichtigste Praxis zur Verringerung der Auswirkungen von Missverständnissen ist die
Anwendung eines Verfahrens mit kurzen Rückkopplungsschleifen (LE 5).

Prinzip 4 – Kontext: Systeme können nicht isoliert verstanden werden

Systeme sind in einen Kontext eingebettet. Ohne diesen Kontext zu verstehen, ist es unmöglich,
ein System richtig zu spezifizieren. Im RE ist der Kontext eines Systems der Teil der
Systemumgebung, der für das Verständnis des Systems und seiner Anforderungen relevant ist.
Die Systemgrenze ist die Grenze zwischen einem System und seinem umgebenden Kontext.
Anfangs ist die Systemgrenze oft nicht klar, und sie kann sich im Laufe der Zeit sogar ändern.
Die Klärung der Systemgrenze und die Definition der externen Schnittstellen zwischen dem
System und den Kontextelementen, mit denen es interagiert, sind echte RE-Aufgaben.
Gleichzeitig muss der Umfang des Systems - d.h. die Reichweite der gestaltbaren Dinge bei der
Entwicklung des Systems - bestimmt werden. Wir müssen auch die sogenannte Kontextgrenze
berücksichtigen, die den RE-relevanten Teil der Umgebung eines Systems vom Rest der Welt
trennt.
Bei der Spezifizierung eines Systems reicht es nicht aus, nur die Anforderungen innerhalb der
Systemgrenze zu berücksichtigen. RE muss auch in Betracht ziehen:

• Änderungen im Kontext, die sich auf die Systemanforderungen auswirken können.

• Anforderungen der realen Welt, die für das System relevant sind (und wie sie den
  Systemanforderungen zugeordnet werden können).

• Annahmen über den Kontext, die für das Funktionieren des Systems und die Erfüllung
  der Anforderungen der realen Welt gelten müssen.

Prinzip 5 - Problem - Anforderung - Lösung: Ein unausweichlich
ineinandergreifendes Tripel

Ein Problem tritt auf, wenn die Stakeholder mit der Situation, wie sie ist, nicht zufrieden sind. Die
Anforderungen erfassen, was die Stakeholder brauchen, um das Problem zu lösen oder zu
vereinfachen. Ein sozio-technisches System, das diesen Anforderungen gerecht wird, stellt eine
Lösung dar.
Probleme, Anforderungen und Lösungen treten nicht unbedingt in dieser Reihenfolge auf.
Lösungsideen können Nutzerbedürfnisse erzeugen, die als Anforderungen ausgearbeitet und in
eine konkrete Lösung umgesetzt werden müssen. Dies ist typischerweise bei Innovationen der
Fall.

• Probleme, Anforderungen und Lösungen sind eng miteinander verflochten: Sie können
  nicht isoliert angegangen werden.

• Dennoch sind Requirements Engineers bestrebt, Probleme, Anforderungen und
  Lösungen beim Denken, Kommunizieren und Dokumentieren so weit wie möglich
  voneinander zu trennen. Diese Trennung der Belange erleichtert die Abwicklung der RE-
  Aufgaben.

Prinzip 7 – Evolution: Sich ändernde Anforderungen sind kein Unfall, sondern der
Normalfall

Systeme und ihre Anforderungen unterliegen der Entwicklung. Das bedeutet, dass sie sich
ständig ändern. Anfragen zur Änderung einer Anforderung oder einer Menge von
Anforderungen an ein System können z.B. verursacht werden 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

Feedback von Systembenutzern, die nach einer neuen oder geänderten Funktion fragen
Darüber hinaus können sich die Anforderungen aufgrund von Rückmeldungen der Stakeholder
bei der Validierung von Anforderungen, durch die Entdeckung von Fehlern in zuvor erhobenen
Anforderungen oder durch geänderte Bedürfnisse ändern.
Folglich müssen Requirements Engineers zwei scheinbar widersprüchliche Ziele verfolgen:

• Zulassen, dass sich Anforderungen ändern

• Anforderungen stabil halten

Wie dies erreicht werden kann, wird in LE 6.7 beschrieben.

Prinzip 8 – Innovation: Mehr vom Gleichen ist nicht genug

Wenn man den Stakeholdern nur genau das gibt, was sie äußern, verpasst man die Gelegenheit,
Systeme aufzubauen, die ihre Bedürfnisse besser erfüllen, als sie es erwarten. Gutes RE strebt
nicht nur danach, die Stakeholder zufrieden zu stellen, sondern auch danach, dass sie glücklich
und begeistert sind oder sich sicher fühlen. Darum geht es schließlich bei Innovation.
RE gestaltet innovative Systeme:

• Im Kleinen durch das Streben nach aufregenden neuen Funktionen und
  Benutzerfreundlichkeit.

• Im Großen durch das Streben nach verändernden (disruptiven) neuen Ideen.

LE 4.2 erörtert verschiedene Techniken zur Förderung von Innovationen im RE.

Prinzip 9 – Systematische und disziplinierte Arbeit: Wir können im RE nicht darauf
verzichten

Wir müssen geeignete Prozesse und Praktiken zur systematischen Ermittlung, Dokumentation,
Validierung und Verwaltung von Anforderungen anwenden, unabhängig vom tatsächlich
genutzten Entwicklungsprozess. Selbst wenn ein System ad hoc entwickelt wird, verbessert ein
systematischer und disziplinierter Ansatz für das RE die Qualität des daraus resultierenden
Systems.
Es gibt nicht den einen Prozess oder das eine Verfahren im RE, welches in jeder gegebenen
Situation oder zumindest in den meisten Situationen gut funktioniert. Systematisches und
diszipliniertes Arbeiten bedeutet, dass Requirements Engineers:

• Die von ihnen angewendeten Prozesse und Praktiken an das jeweilige Problem, den
  Kontext und die Arbeitsumgebung anpassen.

• Nicht immer das gleiche Verfahren und die gleichen Praktiken verwenden.

• Prozesse und Praktiken aus früheren erfolgreichen RE-Arbeiten nicht unreflektiert
  wiederverwenden.

Für jedes RE-Vorhaben müssen Prozesse, Praktiken und Arbeitsprodukte gewählt werden, die
der jeweiligen Situation am besten entsprechen. Die Einzelheiten werden in LE 3, LE 4, LE 5 und
LE 6 ausgearbeitet.