Читать книгу Basiswissen Requirements Engineering - Klaus Pohl - Страница 14

Neben der Unterscheidung in funktionale Anforderungen, Qualitätsanforderungen und Randbedingungen wird eine Reihe anderer Klassifizierungen von Anforderungen in der Praxis verwendet. Diese können unternehmensspezifisch, projektspezifisch oder aufgrund anderer Vorgaben entstehen. Dies gilt beispielsweise für die in diversen Standards definierten Anforderungsklassen (z.B. CMMI [SEI 2006], SPICE [ISO/IEC 15504-5]) oder in Bezug auf die Klassifikation über Attributwerte von Anforderungen, etwa für den Detaillierungsgrad, die Priorität oder die rechtliche Verbindlichkeit von Anforderungen.

Klassifikation von Anforderungen

Häufig findet sich die Unterscheidung zwischen Systemanforderungen und Nutzeranforderungen. Daneben sind aber auch weitere Unterscheidungen gängig. Eine häufig verwendete Klassifikation von Anforderungen ist die Unterscheidung zwischen Systemanforderungen, Stakeholder-Anforderungen, Nutzeranforderungen, Domänenanforderungen und Geschäftsanforderungen [IREB-Lehrplan 2020].

 Systemanforderungen beschreiben, was das System leisten soll. Somit können Systemanforderungen als die »klassischen« Anforderungen aufgefasst werden, die dann in funktionale Anforderungen an das System, Anforderungen an die Qualität des Systems und Randbedingungen für Systemausführung und -entwicklung unterschieden werden.

 Stakeholder-Anforderungen beschreiben aus der Sicht eines Stakeholders, was dieser mit dem System erreichen will. Stakeholder-Anforderungen eignen sich, um Anforderungen aus unterschiedlichen Perspektiven zu erfassen und zu dokumentieren. Im Zuge der Definition von Systemanforderungen müssen basierend auf diesen Stakeholder-Anforderungen u.a. die Anforderungen der verschiedenen Stakeholder konsolidiert werden, Konflikte identifiziert und aufgelöst werden (siehe Abschnitt 4.3).

 Benutzeranforderungen beschreiben aus der Nutzerperspektive, was die Benutzer mit dem System erreichen wollen bzw. wie dieses genutzt werden soll. Nutzeranforderungen können als eine Unterkategorie der Stakeholder-Anforderungen aufgefasst werden, da die Nutzer eine spezifische Gruppe von Stakeholdern sind.

 Domänenanforderungen beschreiben Anforderungen (häufig Randbedingungen), die von dem jeweiligen Umfeld, in dem das System eingesetzt werden soll, vorgegeben werden.

 Geschäftsanforderungen beschreiben Anforderungen, die eng mit dem gewünschten Business Value verzahnt sind. Geschäftsanforderungen werden im Allgemeinen von der Organisation vorgegeben. Außerdem umfassen Geschäftsanforderungen wirtschaftliche Zielgrößen und Budgetbeschränkungen.

Exkurs: Ziele und Szenarien

Neben der Unterscheidung von Anforderungen entsprechend verschiedener Bereiche wird häufig zwischen weiteren Anforderungsarten unterschieden. Eine hilfreiche Unterscheidung ist hierbei die Unterteilung in:

 Ziele

 Szenarien

 Lösungsorientierte Anforderungen

Dies bringt die unterschiedliche Granularität von Anforderungen zum Ausdruck. Mit Zielen und Szenarien werden zwei Anforderungsarten in den Fokus gerückt, die im Gegensatz zu sehr detaillierten technischen Anforderungen auf das Verständnis des Problemraums hinwirken.

Unter einem Ziel versteht man die intentionale Beschreibung eines von Stakeholdern (z.B. Personen oder Organisationen) gewünschten charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprojekts. Ziele werden somit sehr nah an der ursprünglichen Intention der Stakeholder definiert. Damit eignen sich Ziele sehr gut, um in frühen Phasen erste Anforderungen zu erheben und diese bereits zu validieren und zwischen den verschiedenen Stakeholdern abzustimmen.

Szenarien werden genutzt, um beispielhafte Beschreibungen für Ziele oder Anforderungen zu definieren. Diese tauchen direkt in die Lebensrealität der Stakeholder ein und sind damit sehr gut geeignet, Detailwissen der Stakeholder zu erfragen und mit dem Verständnis des Requirements Engineer und den initialen Anforderungen abzugleichen. Eine bekannte Form von Szenarien sind User Stories. User Stories beschreiben ein aus Nutzerperspektive dargestelltes Bedürfnis und sind Ausdruck des Wertes/Nutzens, wenn dieses erfüllt ist.

Kernfakten 1–3: Requirements Engineering – Wo

www.cpre-buch.de/pk1w3

Hinweis: Requirements-Engineering-Prozess vs. Systementwicklungsprozess

Im weiteren Verlauf werden wir uns mit dem Requirements-Engineering-Prozess und den im Rahmen des Requirements Engineering anfallenden Aufgaben beschäftigen. Es ist jedoch zu berücksichtigen, dass Requirements Engineering kein Selbstzweck ist, sondern dass jeder Requirements-Engineering-Prozess immer auch in einen System- oder Softwareentwicklungsprozess eingebettet ist. Wie wir noch sehen werden, verfügen wir im Requirements Engineering über unterschiedliche Bausteine, die wir kombinieren können, um den jeweiligen System- oder Softwareentwicklungsprozess optimal unterstützen zu können. Eine immer wiederkehrende Unterscheidung, die Einfluss auf die Wahl des richtigen Requirements-Engineering-Vorgehens hat, ist die Unterscheidung zwischen traditionellen (eher wasserfallartigen) und agilen Vorgehensmodellen.

 Traditionelle EntwicklungIn schwergewichtigen Vorgehensmodellen (z.B. Wasserfallmodell [Royce 1987], V-Modell [V-Modell 2004]) wird versucht, alle Anforderungen in einer Projektphase vollständig zu erheben, bevor die ersten Entwurfs- oder Realisierungsentscheidungen getroffen werden. Das Ziel dieser Modelle ist es, bereits im Vorfeld der Umsetzung alle Anforderungen an das System zu ermitteln. Dies führt dazu, dass Requirements Engineering bei diesen Vorgehensmodellen als abgeschlossene, zeitlich befristete erste Phase der Systementwicklung durchgeführt wird.

 Agile EntwicklungLeichtgewichtige Vorgehensmodelle (z.B. eXtreme Programming [Beck 1999]) ermitteln die benötigten Anforderungen dagegen erst, wenn sie implementiert werden sollen, da »Hellsehen« bezüglich zukünftig gewünschter Funktionalität schwierig ist und Anforderungen sich auch im Laufe eines Projekts ändern. Hier wird Requirements Engineering als kontinuierlicher, phasenübergreifender Prozess in die Systementwicklung integriert.