Konzept: Abgeleitete Anforderungen
Eine abgeleitete Anforderung ist eine Anforderung, die einer Benutzeranforderung entnommen oder aus dieser abgeleitet wird. Die Ableitung dieser Anforderungen erfolgt durch eingehende Beschäftigung mit den Details der Benutzeranforderung.
Beziehungen
Hauptbeschreibung

Einführung

Es gibt unweigerlich eine Hierarchie von Anforderungen an die Systementwicklung. Die Anforderungen können von globalen Anforderungen, die den Auftrag des Systems oder die Benutzerziele und -zielsetzungen für das System zusammenfassend definieren, über mehrere Zwischenstufen bis hin zu detaillierten Anforderungen reichen. Auf der detailliertesten Stufe können die Anforderungen mit dem Vokabular der vom System verwendeten Technologie ausgedrückt werden. Auf der höchsten Stufe werden Anforderungen in der Regel eher abstrakt in der Sprache der jeweiligen vom System zu bedienenden Domäne formuliert, z. B. in Form von Fähigkeiten, Services, Verhalten, Funktionen, Features usw. Die Wortwahl ist hier häufig willkürlich. Es ist sicherlich möglich, diesen Wörtern unterschiedliche Bedeutung zuzuschreiben, um präziser darin zu sein, was ausgedrückt werden soll (beispielsweise ist es möglich, dass die Beschreibung eines bestimmten Verhaltens des Systems nicht viel über das Ziel oder die Absicht aussagt und irgendein anderer Beschreibungstyp erforderlich ist), aber dies ist hier nicht die Zielsetzung.

Die Präzisierung von Anforderungen (von der höchsten Stufe ausgehend immer mehr Details hinzufügen) kann auf rein funktionale Weise vorgenommen werden, indem Funktionen in Unterfunktionen oder Unteraufgaben aufgeteilt werden, die die Funktionen unterstützen, ohne irgendwelche realisierenden Architekturen zu berücksichtigen. Dies kann bis zu einer Stufe fortgesetzt werden, auf der das, was beschrieben wird, (sofern das System auf diese Weise erstellt wird) tief im Inneren des Systems stattfindet und möglicherweise keine direkte Verbindung zur Systemumgebung hat. Dies wäre beispielsweise in einem strukturierten Analyseansatz der Fall, der bis zu einer Basisberechnung ginge.

Mit diesem Ansatz wären Sie schlecht beraten, weil er zur Identifizierung von Dingen wie Anforderungen führt, die gar keine Anforderungen sind, sondern einfache Arbeitsergebnisse der Dekomposition. Außerdem kann ein solcher Ansatz minderwertige Architekturen hervorbringen (z. B. Architekturen, die andere, nicht funktionale Anforderungen nicht oder nur mangelhaft erfüllen), wenn der Designer die Realisierung sehr nah an die Dekomposition anlehnt. Eine gewisse funktionale Dekomposition lässt sich jedoch rechtfertigen, wenn die Visionsziele auf hoher Ebene beschrieben sind und der Grad der Dekomposition auf erkennbare Fähigkeiten oder Funktionen beschränkt wird, d. h. wenn genügend Details verfügbar sind, um alle (für die Stakeholder) relevanten Verhalten, Features usw. zu erfassen, so dass der Designer sie korrekt realisieren kann. Anforderungen, die (mehr oder weniger direkt) auf der Basis von Anforderungen der höheren Ebene präzisiert werden, sind eine Form abgeleiteter Anforderung.

Abgeleitete Anforderungen

Im Folgenden sehen Sie ein einfaches Beispiel:

Angenommen, eine Benutzeranforderung lautet "das System muss das ganze Jahr in Alaska im Freien funktionieren".

Verschiedene abgeleitete Anforderungen sind:

  1. Das System muss bei Temperaturen unter 0 Grad Celsius funktionieren.
  2. Das System muss im Schnee funktionieren.

Es gibt einen weiteren Typ abgeleiteter Anforderung. Wenn die Anforderungen auf Systemebene mit dem entsprechenden Detailgrad für die Realisierung beschrieben wurden, tun Sie Folgendes:

  • Sie partitionieren das System (Modell) in Elemente (z. B. OOAD-Methoden).
  • Sie bestimmen, wie diese Elemente kollaborieren, um das gewünschte Systemverhalten zu erbringen.
  • Sie fassen Verhalten der unteren Ebene aus der Kollaboration zu Anforderungen auf Elementebene zusammen.

Solche Anforderungen auf unterer Ebene sind abgeleitete Anforderungen, die sich bei der Dekomposition des Systems ergeben. Dies steht einem funktionsbasierten Ansatz gegenüber, bei dem die Partitionierung ohne Berücksichtigung der Architekturdekomposition und der Präzisierung der Anforderungen auf Systemebene (siehe Einleitung) durchgeführt wird.

Zugewiesene Anforderungen

Zugewiesene Anforderungen sind Anforderungen, die (basierend auf funktionalen Überlegungen) Komponenten eines Systems, z. B. Hardware- oder Softwaresubsystemen, zugeordnet wurden. Wenn Sie beispielsweise auf sehr hoher Ebene (Auftragsebene) über Anforderungen für ein System von Systemen diskutieren, kann es trotzdem angemessen sein, solche Anforderungen funktional auszuarbeiten, danach die daraus abgeleiteten Anforderungen aufzuteilen und die Gruppen bestimmten Systemen zuzuordnen, die vor der Realisierung dann unter Umständen weiter präzisiert werden. Darüber hinaus sollte wie unter "Abgeleitete Anforderungen" beschrieben verfahren werden. Selbst auf der Ebene "System von Systemen" können Sie diese Vorgehensweise unter Verwendung eines Geschäftsmodellierungansatzes in Betracht ziehen.

Bei einem Ansatz mit abgeleiteten Anforderungen zerlegen Sie das System in Entitäten und bestimmen die Anforderungen der Entitäten, indem Sie untersuchen, wie diese Entitäten kollaborieren, um die Anforderungen der höheren Ebene zu erfüllen. Bei einem Ansatz mit funktionalen, zugewiesenen Anforderungen zerlegen Sie die Anforderungen und geben Entitäten an, die die Anforderungen der unteren Ebene erfüllen.

Welcher Ansatz verwendet wird, richtet sich nach dem Kontext und den kulturellen und vertraglichen Erwartungen. Die National Aeronautics and Space Agency (NASA) fordert [in der Veröffentlichung Software Assurance Guidebook, NASA Goddard Space Flight Center Office of Safety, Reliability, Maintainability and Quality Assurance, 9/89] beispielsweise, dass Anforderungen auf vier Detailebenen definiert werden:

  • Ebene 1, Auftragsebene: Die Anforderungen auf dieser Ebene sind sehr abstrakt und stehen zu einem sehr frühen Zeitpunkt fest.
  • Ebene 2, Systemebene (zugewiesen): Diese Anforderungen stehen ebenfalls bereits zu einem sehr frühen Zeitpunkt fest. Sie werden von der Auftragsebene abgeleitet und Segmenten zugewiesen.
  • Ebene 3, Subsystem- oder Segmentebene (abgeleitet): Die Anforderungen auf dieser Ebene werden von den Anforderungen auf Systemebene abgeleitet, die dem Segment zugewiesen sind.
  • Ebene 4, Konfigurationselementebene (Hardwarekonfigurationselement [HWCI], Softwarekonfigurationselement [CSCI]) (detailliert): Auch hier werden die Anforderungen auf der Basis der übergeordneten Ebene zugewiesen und anschließend präzisiert.

Anforderungsebenen und Zuordnung zu

Anforderungsebenen und Zuordnung zu RUP.

Normalerweise werden Aufträge auf der Basis der Ebene 3 geschlossen. Die NASA ist daran gewöhnt, Anforderungen auf diese Weise zu behandeln, und es wäre nur selbstverständlich, wenn eine Organisation, die mit der NASA zu tun hat, eine ähnliche Taxonomie anwendet. Trotzdem hätten die Entwickler noch genügend Flexibilität zu entscheiden, wie Anforderungen der unteren Ebene abgleitet werden, aber angesichts der sehr hohen Abstraktionsebene von Anforderungen auf Auftragsebene (es handelt sich häufig eher um Anforderungen auf Programmebene) kann die Ableitung der Anforderungen auf Systemebene (und ihrer Zuordnung zu Segmenten) selbstverständlich funktionalen Aspekten folgen. Mit zunehmendem Interesse an Unternehmensarchitekturen wird es sogar immer gebräuchlicher, dass selbst Systemanforderungen aufgrund architektonischer Überlegungen abgeleitet werden. Die vorherige Abbildung veranschaulicht dies und zeigt die Zuordnung der NASA-Ebenen zu den RUP-Arbeitsergebnissen (einschließlich Geschäftsmodellierung). Beachten Sie, wie im RUP-Prozess die Zuordnung im traditionellen Ablauf im Prozess der Anwendungsfallrealisierung und der nachfolgenden Verhaltensaggregation umgesetzt wird. Die blaue gestrichelte Linie verbindet Arbeitsergebnisse auf ähnlicher Ebene.