und Gestik oder Sprache und Tonfall) sowie auf Rückkopplung. Bei schriftlicher Kommunikation wird redundanzarm und ohne (oder mit wenig direkter) Rückkopplung kommuniziert.
Zusätzlich zu den Problemen der unterschiedlichen Begriffswelten und Kommunikationsmedien ist meist zu beobachten, dass Informationen gar nicht oder nicht adäquat weitergegeben werden. Dies lässt sich oftmals auf natürliche Vorgänge zurückführen, die bei der Wahrnehmung des Menschen und der Kommunikation des Wahrgenommenen immer mehr oder weniger ausgeprägt auftreten: die Fokussierung und die Vereinfachung.
Die Fokussierung geschieht primär unter zwei Gesichtspunkten. Zum einen wird man immer auf das fokussieren, was einem wichtig ist. Zum anderen kann man nur auf das fokussieren, was einem bewusst ist. Das heißt, unbewusste Informationen gehen verloren.
Kommunikation, die auf dem Ausdruck von Wissen basiert, ist notwendigerweise vereinfachend. Ein Autor setzt beim Leser ein gewisses Vorwissen voraus. Diese Vereinfachungen im Ausdruck sind es, die im Zusammenhang mit Anforderungen problematisch werden, da sie Anforderungen unterschiedlich interpretierbar machen. In Kapitel 3 wird näher auf die Darstellung von Anforderungen in natürlicher Sprache und mit Modellen eingegangen.
Die Bedeutsamkeit von gutem Requirements Engineering
Die steigende Bedeutung von Systemen mit einem signifikanten Softwareanteil in industriellen Projekten sowie die Notwendigkeit, innovativere, individuellere und umfangreichere Systeme schneller, besser und mit höchster Qualität auf den Markt zu bringen, setzen ein leistungsfähiges Requirements Engineering voraus. Fehlerfreie und ausreichend vollständige Anforderungen sind die Basis für eine erfolgreiche Systementwicklung. Bereits im Requirements Engineering müssen potenzielle Risiken aufgedeckt, und, wenn es geht, behoben werden, um einen erfolgreichen Projektablauf zu ermöglichen. Fehler und Lücken in Anforderungsdokumenten müssen frühzeitig erkannt werden, um langwierige Änderungsprozesse zu vermeiden.
Kernfakten 1–2: Requirements Engineering – Warum
1.3 Requirements Engineering – Wo?
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
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