SWEM

Anforderungen ändern sich regelmässig während eines Projekts und müssen entsprechend angepasst werden.

Die Systemgrenze trennt das System vom Kontext; die Kontextgrenze trennt den Kontext von der irrelevanten Umgebung.

Randbedingungen

z. B. Antwortzeit < 4 Sekunden

Eine Anforderung ist ein notwendiges Bedürfnis eines Stakeholders, eine Fähigkeit oder Eigenschaft, die ein System erfüllen muss, und die dokumentierte Repräsentation eines solchen Bedürfnisse

Basiswissen Requirements Engineering (Pohl), Kapitel 1.1 (Definition 1–1).

Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit dem Ziel, die Wünsche und Bedürfnisse der Stakeholder zu verstehen und das Risiko zu minimieren, ein System zu liefern, das diese nicht erfüllt.

Basiswissen Requirements Engineering (Pohl), Kapitel 1.1 (Definition 1–3).

Gutes Requirements Engineering sorgt dafür, dass das zu lösende Problem frühzeitig besser verstanden wird. Das verringert das Risiko, am Bedarf vorbei zu entwickeln, und hilft, Fehler früh zu entdecken, was teure Korrekturen spät in der Entwicklung vermeidet. Zudem legt RE die Grundlage für realistische Aufwandsschätzungen und schafft die Voraussetzung, um das System anhand der Anforderungen zu testen.

Basiswissen Requirements Engineering (Pohl), Kapitel 1.2.

(a) Das Risiko, ein falsches System zu entwickeln, wird verringert, und 
(b) es entsteht ein besseres Verständnis des zugrundeliegenden Problems.

Darüber hinaus schafft RE eine Basis für die Schätzung von Entwicklungsaufwänden und ermöglicht das Ableiten von Testfällen aus Anforderungen

Basiswissen Requirements Engineering (Pohl), Kapitel 1.2.

Die falsche Annahme der Stakeholder, dass vieles selbstverständlich ist und nicht explizit genannt werden muss. Dieses Übersehen von eigentlich notwendigen Anforderungen führt oft zu Lücken oder Missverständnissen.

Basiswissen Requirements Engineering (Pohl), Kapitel 1.2 (Gründe für fehlerhafte Anforderungen).

Ein Stakeholder (Interesseneigner) ist eine Person oder Organisation, die Einfluss auf die Anforderungen des Systems hat oder auf die das System Auswirkungen hat. Stakeholder sind also alle, die Anforderungen stellen oder von der Systemnutzung betroffen sind.

Basiswissen Requirements Engineering (Pohl), Kapitel 1.1 (Definition 1–2).

Weil Stakeholder die Hauptquelle für Anforderungen sind. Werden bestimmte Stakeholder übersehen, bleiben deren Bedürfnisse unerfasst, was zu einem lückenhaften Anforderungskatalog führt. Fehlende Stakeholder bedeuten meist fehlende oder unvollständige Anforderungen.

Basiswissen Requirements Engineering (Pohl), Kapitel 1.1.

zukünftige Endnutzer (z. B. Kunden, Anwender), betriebliche Auftraggeber oder Manager, Administratoren, regulatorische Behörden oder Gesetzgeber, und sogar externe Personen wie Hacker (vor denen das System geschützt werden muss) gelten als Stakeholder, da sie Anforderungen beeinflussen.

Die Aufgaben des Requirements Engineering bestehen darin, Anforderungen zu ermitteln, zweckmäßig zu dokumentieren, sie zu prüfen und mit den Stakeholdern abzustimmen sowie die dokumentierten Anforderungen über den gesamten Systemlebenszyklus hinweg zu verwalten.

Man unterscheidet funktionale Anforderungen, Qualitätsanforderungen (als Oberbegriff für nicht-funktionale Anforderungen) und Randbedingungen (Constraints). Funktionale Anforderungen beschreiben Funktionen des Systems, Qualitätsanforderungen gewünschte Qualitätseigenschaften und Randbedingungen schränken den Lösungsraum ein.

Eine Randbedingung ist eine Anforderung, die den Lösungsraum einschränkt, über das hinaus, was zur Erfüllung der fachlichen Anforderungen nötig ist. Meist handelt es sich um organisatorische oder technologische Vorgaben, z. B. rechtliche Rahmenbedingungen oder technologische Einschränkungen, die die Art der Lösungsumsetzung limitieren.

(1) Die Etablierung einer gemeinsamen Sprache – z. B. durch ein für alle zugängliches Glossar, in dem wichtige Begriffe eindeutig definiert sind. 
(2) Falls nötig, die Verwendung formalerer Beschreibungsmittel wie einer Modellierungssprache (z. B. UML), auf die sich alle Beteiligten einigen. Diese Maßnahmen stellen sicher, dass Sender und Empfänger dieselben Begriffe verstehe

Basiswissen Requirements Engineering (Pohl), Kapitel 1.2 (Exkurs Kommunikationsprobleme).

Anforderungen sind Mittel zum Zweck, nicht Selbstzweck. Es sollen nur solche Anforderungen erhoben und spezifiziert werden, die tatsächlich benötigt werden, um die Wünsche und Ziele der Stakeholder zu erreichen. Unnötige Anforderungen gilt es zu vermeiden. Außerdem ist der Nutzen einer Anforderung stets gegen die Kosten ihrer Ermittlung, Dokumentation, Abstimmung usw. abzuwägen.

CPRE FL Lehrplan 3.1.1, LE 2 (Prinzip 1: Wertorientierung).

Der Wert einer Anforderung entspricht ihrem Nutzen abzüglich der Kosten für das Ermitteln, Dokumentieren, Validieren, Abstimmen und Verwalten dieser Anforderung. Der Nutzen bemisst sich daran, inwieweit die Anforderung zur Erfüllung der Stakeholder-Bedürfnisse beiträgt und das Risiko von Fehlentwicklungen reduziert.

CPRE FL Lehrplan 3.1.1, LE 2.2 (Prinzip Wertorientierung).

Es bedeutet, dass alle Beteiligten ein gemeinsames, abgestimmtes Verständnis der Anforderungen und des zu entwickelnden Systems haben müssen. RE soll ein solches gemeinsames Verständnis schaffen, fördern und absichern – sowohl explizit (durch dokumentierte und vereinbarte Anforderungen) als auch implizit (durch gemeinsames Wissen, Vertrauen, gemeinsame Kultur etc.). Ohne diese gemeinsame Basis ist eine erfolgreiche Systementwicklung nicht möglich.

Dieses Prinzip (Prinzip 4) lautet: Systeme können nicht isoliert verstanden werden. Das heißt, man muss stets den Systemkontext, also den relevanten Teil der Systemumgebung, betrachten. Ohne Berücksichtigung des Umfelds (anderen Systeme, Prozesse, Organisation, Gesetze etc.) lassen sich Anforderungen nicht richtig definieren – ohne Kontext keine Anforderung.

CPRE FL Lehrplan 3.1.1, LE 2.1 (Prinzip 4) / Basiswissen RE (Pohl), Kapitel 2.2.

Dieses Prinzip (Prinzip 5) betont, dass Problem, Anforderungen und Lösung untrennbar zusammenhängen. Aus einem gegebenen Problem leiten die Stakeholder Anforderungen ab, und anhand der Anforderungen wird eine Lösung entwickelt. Diese drei Elemente greifen ineinander: Eine Änderung am Problem, an den Zielen oder Rahmenbedingungen beeinflusst die Anforderungen, und geänderte Anforderungen beeinflussen die Lösungsfindung. Problem, Anforderung und Lösung bilden also ein ineinandergreifendes Tripel

CPRE FL Lehrplan 3.1.1, LE 2.1 (Prinzip 5).

Weil Fehler in Anforderungen umso kostengünstiger behoben werden können, je früher sie entdeckt werden. Werden Anforderungen ernsthaft betrieben, testet und prüft man sie wie jedes andere Artefakt, da statistisch belegt ist, dass frühe Fehlererkennung wesentlich billiger ist als späte. Frühe Validierung stellt sicher, dass die richtigen und vollständigigen Anforderungen umgesetzt werden.

9