Requirements Engineering in der Softwareentwicklung

In der Softwareentwicklung ist Requirements Engineering immer wieder ein grosses Thema. Deshalb sollte jeder Software Ingenieur wissen, was Anforderungen (Requirements) sind, welche Rolle sie in der Softwareentwicklung und anderen Prozessen haben, woher sie kommen und wie man damit arbeitet. Unsere Partnerfirma KnowGravity insbesondere der KnowBody Christian Bühler ist Experte im Bereich Requirements Engineering und lieferte uns folgende Inputs zum Thema:

Was sind Anforderungen?

Anforderungen sind gewünschte Eigenschaften oder Verhaltensweisen eines Systems. Diese können verschiedene Formen haben: es können funktionale Anforderungen sein (was muss das System können, wie muss es sich in einer gegebenen Situation verhalten) oder nicht-funktionale Anforderungen (wie sieht es aus, welche Belastbarkeit hat es in Stresstests, Anforderungen zur Wartbarkeit etc.).

Es gibt viele verschiedene Arten, Anforderungen zu formulieren. Einige Beispiele sind Zustandsmaschinen, User Stories oder Skizzen. Die Struktur einer Anforderungen sollte aber jeweils ähnlich aufgebaut sein. Eine Anforderung besteht aus folgenden Teilen:

• einer Id zur eindeutigen Identifikation
• der Beschreibung der gewünschten Eigenschaft
• dem Typ der Anforderung (funktional oder nicht-funktional, es können auch weitere Typen verwendet werden)
• der Priorität/Modalität
• der Motivation (warum soll das System diese Anforderung erfüllen)
• einem Verantwortlichen, der die Anforderung aufgestellt hat
• dem Status oder Bearbeitungsstand der Anforderung
• dem Thema zur Kategorisierung
• der Machbarkeit
• Verweisen auf zusätzliche Quellen.

Die Anforderungssprache kann verschieden gewählt werden. Das wichtigste ist dabei, dass die Beteiligten die Sprache und die Anforderung verstehen. Hier sind graphische Anforderungssprachen oft von Vorteil, weil sie übersichtlicher sind als reine Texte. Auch ist es besser, eine Anforderung möglichst formal zu schreiben, solange sie verständlich bleibt. Präzision ist auch wichtig, um Fehler durch falsch verstandene und falsch umgesetzte Anforderungen zu verhindern. Dazu wird ein Glossar verwendet, wo Begriffe definiert werden.

Eine gute Anforderung beschreibt, was gewünscht wird, nicht, wie es umgesetzt werden soll. Oft lohnt es sich, atomare Anforderungen zu stellen und nicht mehrere Anforderungen zusammenzufassen.

Was ist das System?

Dies ist eine zentrale Frage im Requirements Engineering. Um Anforderungen an ein System zu stellen, muss dieses zunächst genau definiert werden, indem die Grenzen des Systemkontexts und des Systems selbst klar bestimmt werden. Der Systemkontext umfasst alle Faktoren, die das System beeinflussen, und die Systemgrenze trennt das System von seinem Kontext. Um die Systemgrenze zu dokumentieren, kann man z.B. Anwendungsfall-, Kontext-, Datenfluss- oder Prozessdiagramme verwenden.

Was ist ein Glossar?

Im Glossar werden Begriffe definiert, um Anforderungen klar formulieren zu können. Dabei sind gute Definitionen präzise und minimal. Es gibt verschiedene Arten von Definitionen wie z.B. die intensionale und die extensionale Definition.

• Die intensionale Definition schränkt ein allgemeineres Konzept ein, wie zum Beispiel "ein Mann ist eine Person männlichen Geschlechts". Intensionale Definitionen helfen dabei, ähnliche Begriffe zu unterscheiden.
• Die extensionale Definition fasst verschiedene, engere Konzepte zusammen, wie "eine Person ist ein Mann oder eine Frau".

Woher kommen Anforderungen?

Die wichtigste Quelle für Anforderungen sind beteiligte Personen, die Stakeholder. Im Umgang mit den Stakeholdern ist es wichtig, dass diese sich untereinander absprechen, um Konflikte und widersprüchliche Anforderungen von verschiedenen Stakeholdern zu vermeiden. Eine zweite wichtige Quelle sind die zu unterstützenden Geschäftsprozesse. Dazu kommen noch weitere Quellen wie Dokumente und bereits bestehende Systeme.

Grundsätzlich können Anforderungen jederzeit in einem Projekt dazukommen oder ändern. Um damit umzugehen, braucht es ein gutes Change Management. Dabei ist wichtig, dass die Situation während dem Projekt ändert. Zu Beginn ist das Finden von Anforderungen kreativ und chaotisch. Anforderungen müssen ohne grosse Probleme erstellt, geändert oder entfernt werden können. Gegen Ende eines Projekts ist Kontrolle wichtiger, da dann schon viele Anforderungen umgesetzt wurden und neue Anforderungen grossen Einfluss haben. Jetzt muss vor allem auch die Konsistenz der neuen Anforderungen geprüft werden.

Konsistenz von Anforderungen

Konsistenz bedeutet, dass Anforderungen sich nicht gegenseitig widersprechen dürfen. Dies ist einfacher zu überprüfen, je formaler die Anforderungen formuliert sind. Hier haben Modelle als Anforderungen einen Vorteil, da sie meist von selbst konsistent sind.

Wie arbeitet man mit Anforderungen?

Es ist wichtig, dass Anforderungen sinnvoll sind. Es kann geschehen, dass ein schlechtes Produkt entsteht, das jedoch alle Anforderungen erfüllt. Deshalb müssen zuerst die Pain Points identifiziert werden. Pain Points sind die grundsätzlichen Ziele und Probleme, die mit dem neuen System gelöst bzw. erreicht werden sollen. Mit diesen Pain Points und äusseren Bedingungen kann man nun eine Lösung identifizieren und dazu "gute" Anforderungen erarbeiten. Während dem Realisieren des Systems können neue Pain Points entstehen oder ans Licht kommen. Deshalb müssen diese auch berücksichtigt werden.

Wenn Anforderungen umgesetzt wurden, können diese verifiziert werden. Dabei wird geprüft, ob das System die gewünschten Eigenschaften tatsächlich erfüllt. Dies muss jedoch nicht die Pain Points lösen, dafür braucht es die Validierung. Beim Validieren wird überprüft, ob die Anforderungen, wenn sie erfüllt sind, die Pain Points lösen.

Beim Verifizieren stellt man also die Frage "Wurde alles richtig gemacht?". Bei der Validierung ist die Frage "Wurde das Richtige gemacht?".

Validieren von Anforderungen

Das Validieren von Anforderungen ist sehr wichtig, da nur so bestimmt wird, ob die Anforderungen tatsächlich sinnvoll sind oder ob damit nur Zeit für Unwichtiges verbraucht wird. Um Anforderungen zu validieren, gibt es verschiedene Möglichkeiten. Einige Techniken, die gute Aufschlüsse zur Validierung geben, sind der Einsatz von Prototypen und die Simulation mit Modellen. Im Fall von externen Kunden kann auch der Abschluss eines Vertrags eine Validierung sein: damit werden die "entscheidenden" Anforderungen festgelegt, nämlich die, welche im Vertrag stehen.

Verifizieren von Anforderungen

Wenn Anforderungen realisiert wurden, können sie verifiziert werden. Das heisst man kann prüfen, ob das System sich verhält wie gewünscht und die gewünschten Eigenschaften hat.

Wenn das System fertig erstellt wurde, gibt es eine spezielle Verifikation: die Verifikation des Systems gegenüber der Spezifikation. Dabei wird geprüft, wie gut das System die Gesamtheit der Anforderungen erfüllt. Bei einem Vertragsverhältnis wird diese abschliessende Verifikation auch Abnahme genannt.