Wir haben bereits die 4 Hauptaktivitäten des Requirements Engineering besprochen.

Requirements Engineering ist ein Prozess der Erfassung und Definition der Dienste, die das System bereitstellen soll.

Es konzentriert sich auf die Beurteilung, ob das System für das Unternehmen nützlich ist (Machbarkeitsstudie), auf die Entdeckung von Anforderungen (Erhebung und Analyse), auf die Umwandlung dieser Anforderungen in ein Standardformat (Spezifikation) und auf die Überprüfung, ob die Anforderungen das System definieren, das der Kunde wünscht (Validierung).

In der Praxis ist das Requirements Engineering kein sequentieller Prozess, sondern ein iterativer Prozess, bei dem die Aktivitäten ineinander übergehen.

Zum Beispiel iteriert man zuerst die Benutzeranforderungen; Erhebung, Spezifikation und Validierung und wiederholt die gleichen Schritte für die Systemanforderungen.

Am Anfang des Prozesses wird der meiste Aufwand auf das Verständnis der übergeordneten Geschäfts- und Benutzeranforderungen verwendet. Später im Prozess wird mehr Aufwand auf die Erhebung und das Verständnis der detaillierten Systemanforderungen verwendet.

Einige Leute betrachten das Requirements Engineering als den Prozess der Anwendung strukturierter Analysemethoden, wie z.B. der objektorientierten Analyse. Dies beinhaltet die Analyse des Systems und die Entwicklung einer Reihe von grafischen Systemmodellen, wie z.B. Use-Case-Modelle, die dann als Systemspezifikation dienen.

Obwohl strukturierte Methoden eine Rolle im Requirements-Engineering-Prozess spielen, umfasst das Requirements-Engineering weit mehr als das, was durch diese Methoden abgedeckt wird.

Die objektorientierte Analyse und der objektorientierte Entwurf werden in einer anderen Reihe von Tutorien behandelt.

Benutzer- und Systemanforderungen

Typischerweise werden Anforderungen in zwei Detaillierungsebenen dargestellt; Benutzer- und Systemanforderungen, wobei Benutzer eine High-Level-Aussage der Anforderungen benötigen, während Systementwickler eine detailliertere Systemspezifikation benötigen. Benutzer- und Systemanforderungen beziehen sich also auf unterschiedliche Detailebenen.

Eine unterschiedliche Detailebene ist nützlich, weil sie Informationen über das zu entwickelnde System für unterschiedliche Lesertypen vermittelt.

Die Endbenutzer werden sich also nicht mit den Details befassen, sie brauchen eine generische, abstrahierte schriftliche Anforderung.

Während die Leute, die an der Entwicklung beteiligt sind, genau wissen müssen, was das System tun soll.

Sie werden wahrscheinlich eine Menge Probleme und Missverständnisse haben, wenn sie keine klare Trennung zwischen den verschiedenen Detailstufen haben.

Benutzeranforderungen

Sie beschreiben die Dienste, die das System bereitstellen soll und die Einschränkungen, unter denen es arbeiten muss. Es handelt sich eher um allgemeine Anforderungen.

Sie werden normalerweise in einer natürlichen Sprache geschrieben und mit Diagrammen versehen.

Wir werden später in dieser Serie verschiedene Arten der Spezifikation von Anforderungen diskutieren.

Systemanforderungen

Die Systemanforderungen sind eine detailliertere Beschreibung der Systemdienste und der betrieblichen Einschränkungen, wie z.B. die Art und Weise, wie das System verwendet wird, und der Entwicklungseinschränkungen, wie z.B. die Programmiersprachen.

Dieser Detaillierungsgrad wird von denjenigen benötigt, die an der Systementwicklung beteiligt sind, wie z.B. Ingenieure, Systemarchitekten, Tester usw.

Funktionale &Nicht-funktionale Anforderungen

Die Softwareanforderungen werden in funktionale Anforderungen und nicht-funktionale Anforderungen unterteilt.

Funktionale Anforderungen

Sie umfassen die Hauptfunktionen, die vom System bereitgestellt werden sollen. Wenn sie als Benutzeranforderungen ausgedrückt werden, werden sie in der Regel auf abstrakte Weise beschrieben.

Die spezifischeren funktionalen Systemanforderungen beschreiben jedoch die Funktionen des Systems, seine Eingaben, seine Verarbeitung, wie es auf eine bestimmte Eingabe reagieren wird und was die erwartete Ausgabe ist.

Nicht-funktionale Anforderungen

Dies sind die Einschränkungen der vom System bereitgestellten Funktionen.

Die Einschränkungen, wie z.B. wie viele Prozesse das System verarbeiten kann (Leistung), welche (Sicherheits-) Probleme das System lösen muss, wie z.B. SQL-Injections …

Die Ausfallrate (Zuverlässigkeit), welche Sprachen und Werkzeuge werden verwendet (Entwicklung), welche Regeln müssen befolgt werden, um sicherzustellen, dass das System innerhalb der Gesetze der Organisation funktioniert (Gesetzgebung).

Nicht-funktionale Anforderungen sind oft kritischer als einzelne funktionale Anforderungen. Benutzer können in der Regel Wege finden, um eine Systemfunktion zu umgehen, die ihre Bedürfnisse nicht wirklich erfüllt. Wird jedoch eine nichtfunktionale Anforderung nicht erfüllt, kann dies bedeuten, dass das gesamte System unbrauchbar ist.

Wenn beispielsweise ein Flugzeug die Zuverlässigkeitsanforderungen nicht erfüllt, ist es nicht betriebssicher, oder wenn ein eingebettetes Steuerungssystem die Leistungsanforderungen nicht erfüllt, funktionieren die Steuerfunktionen nicht korrekt.

Nicht-funktionale Anforderungen sollten messbar sein

Wann immer möglich, sollten wir nicht-funktionale Anforderungen quantitativ schreiben, so dass sie getestet werden können. Man kann sie messen, wenn das System getestet wird, um zu überprüfen, ob das System die nicht-funktionalen Anforderungen erfüllt.

In der Praxis fällt es den Kunden eines Systems oft schwer, ihre Ziele in messbare Anforderungen zu übersetzen. Sie verstehen nicht, welche Zahl die erforderliche Geschwindigkeit oder Zuverlässigkeit definiert. Für einige Ziele, wie z.B. die Wartbarkeit, gibt es keine Metriken, die verwendet werden können.

Die Kosten für die Verifizierung messbarer nicht-funktionaler Anforderungen können sehr hoch sein, und die Kunden sind vielleicht nicht der Meinung, dass diese Kosten gerechtfertigt sind.

Nicht-funktionale und funktionale Anforderungen sind voneinander abhängig

Nicht-funktionale Anforderungen stehen oft in Konflikt, interagieren oder erzeugen sogar andere funktionale oder nicht-funktionale Anforderungen.

Eine Benutzeranforderung, die sich auf die Sicherheit bezieht, wie z.B. die Beschränkung des Zugriffs auf autorisierte Benutzer, kann andere funktionale Anforderungen erzeugen, wie z.B. die Notwendigkeit, Benutzerauthentifizierungsmöglichkeiten in das System einzubauen.

Die Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen

In der Praxis ist es schwierig, funktionale und nicht-funktionale Anforderungen zu trennen. Die Unterscheidung ist nicht so klar, wie es ihre Definitionen vermuten lassen.

Trennung zwischen funktionalen und nicht-funktionalen Anforderungen

Wenn die nicht-funktionalen Anforderungen getrennt von den funktionalen Anforderungen angegeben werden, kann die Beziehung zwischen ihnen schwer zu verstehen sein.

Anforderungen, die sich eindeutig auf emergente Systemeigenschaften wie Leistung oder Zuverlässigkeit beziehen, sollten jedoch explizit hervorgehoben werden.

Emergente Eigenschaften sind Eigenschaften des Systems als Ganzes und nicht Eigenschaften, die sich aus den Eigenschaften der einzelnen Systemkomponenten ableiten lassen.