Management Skill - Anforderungsmanagement

Diese Managementaufgabe umfasst somit sowohl die Begleitung einer Anforderungserhebung als auch Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen; deckt also in Bezug auf Anforderungen auch ein Risikomanagement, ein Änderungsmanagement und ein Umsetzungsmanagement ab.

Das vorrangige strategische Ziel im Bereich des Anforderungsmanagements ist es, ein gemeinsames Verständnis über ein zu entwickelndes System zwischen Auftragnehmer und Auftraggeber zu erreichen.

Prinzipiell werden beim Anforderungsmanagement die Wünsche bzw. Bedarfe eines internen oder externen Kunden dokumentiert und die daraus resultierenden Anforderungen – die Requirements – an ein System abgeleitet. Dieser Prozess wird so lange fortführend spezifiziert, bis abzuarbeitende Arbeitspakete entstanden sind.

Eine wesentliche Aufgabe des Anforderungsmanagements ist es geeignete Zustände und Zustandsübergänge von Anforderungen zu definieren und jedem Anforderungsstadium entsprechend verantwortliche Rollen zuzuordnen.

Use Cases sind Anwendungsfälle, die über eine definierte Modellierungssprache ein sichtbares interaktionales Verhalten (Funktionalität) eines geplanten oder existierenden Softwaresystems aus Sicht des Anwenders grafisch beschreiben und somit Anwenderanforderungen grob dokumentieren.

Eine Anwendungsfallbeschreibung bedarf prinzipiell lediglich folgender Informationen:

• Bezeichnung Anwendungsfall
• Kurzbeschreibung Anwendungsfall (inkl. Beziehungen zwischen Akteuren und Use Case)
• Vorbedingungen für Anwendungsfall
• Beschreibung des Ablaufs sowie der Auswirkungen

Von der Grundidee her werden bei einer methodischen Beschreibung via Use Cases die betroffen Funktionalität in logisch zusammengehörige und zusammenhängend abgeschlossene Einheiten gegliedert und in standardisierter Form z.B. via Aktivitäts- oder Datenflussdiagramme (Bestandteile: Akteur, Kommunikationsbeziehung zwischen Akteur und Anwendungsfälle, Beziehung zwischen Anwendungsfällen) dokumentiert.

Die Beschreibung von Anforderungen für technische Anwendungen ist sehr komplex, weil die zu verwendende Begriffswelt für die Anforderungsformulierung von Fachbereich und gleichzeitig auch vom IT Bereich gleichgerichtet verstanden werden muss.

Oftmals haben jedoch der Anwender und der Softwareentwickler einen unterschiedlichen natürlichen Sprachgebrauch, deren gegenseitige Verständnislücke durch eine gemeinsame formale Spezifikationssprache geschlossen werden muss.

Anforderungen lassen sich also alternativ zu Use Cases durch umgangssprachliche Formulierungen jederzeit präzise ausdrücken, sofern entsprechende Standards vereinbart sind und bei der Anforderungsbeschreibung konsequent eingehalten werden.

Um bei der Beschreibung von Anforderungen sprachliche Effekte so weit wie möglich zu vermeiden, müssen für das Schreiben von Anforderungen grundlegende Regeln vereinbart und das Regelwerk in einer generischen Anforderungsschablone dokumentiert werden.

Eine Anforderungsschablone legt somit als Grundlage für einen angestrebten Entwicklungsprozess die syntaktische (= Rahmen gebende) Aufbaustruktur eines einzelnen Anforderungssatzes einheitlich fest.

Eine Anforderung setzt sich beschreibend mit der zu erfüllenden oder einzuschränkenden Eigenschaft bzw. mit der zu erbringenden oder einzuschränkenden Leistung eines Produktes bzw. eines Erzeugnisses durch das Treffen einer klaren Aussage auseinander.

Funktionale und nicht-funktionale Systemanforderungen sollen daher als eine qualitative Bedingung je Prozesswort stets im Aktiv als genau ein vollständiger Anforderungssatz so eindeutig strukturiert aufgebaut geschrieben werden, dass damit inhaltlich der gewünschte Teil des Geschäftsprozesses ohne Interpretationsspielräume verständlich abgebildet wird.

Dieses setzt voraus, dass unterschiedliche Leser stets das gleiche verstehen und die spezifizierte Anforderung konsistent, also widerspruchsfrei ist.

Anforderungen, die anhand einer Satzschablone formuliert werden, sind für den Kunden (Auftraggeber) oft verständlicher als eine grafische Darstellung, so dass dieser folglich stärker in den Anforderungsprozess eingebunden werden kann.

Im Allgemeinen bringt der Einsatz von Anforderungsschablonen Möglichkeiten zur Minimierung bekannter Fehlerquellen und weitere Vorteile (Reduzierung von Mehrdeutigkeiten und Ungenauigkeit etc.) mit sich, so dass später in der Anforderungsanalyse Zeit und Kosten gespart werden.

Die Detailbeschreibung einer Anforderung setzt zumindest eine vorherige Identifizierung der einzelnen Geschäftsprozessschritte sowie eine Klärung voraus, ob der zu beschreibende Prozess aktiv durch eine selbständige Systemaktivität (d.h. ohne Einwirkung des Benutzers), passiv durch eine Benutzerinteraktion (z.B. via Eingabemaske) oder durch ein Drittsystem ausgelöst wird. Wenn das System einen Prozess in Abhängigkeit eines anderen Systems ausführt, spricht man von einer Schnittstellenanforderung.

Die Anforderungstypen lassen sich grundsätzlich wie folgt unterscheiden:

• Ziel (Vision)
  Ein Ziel beschreibt kurz und prägnant auf einer High Level Basis anhand von charakteristischen Merkmalen eine realitätsnahe Vorstellung von Stakeholdern über die gewünschte Zukunft eines (weiter) zu entwickelnden Softwaresystems (oder Komponente), jedoch nicht wie das überprüfbare Ziel im dazugehörigen Entwicklungsprojekts erreicht werden soll. Der Mehrwert des Leitgedankens wird lediglich begründet.

• Bedarf (Kundenanforderung)
  Ein Bedarf ist ein in Verbindung mit dem Streben nach Ausgleich empfundener Mangel an einem Produkt oder Erzeugnis mit einer aus der Perspektive von Stakeholdern (Interessenvertreter) an ein Endergebnis formulierten konkrete Aussage, was fachlich grundsätzlich erreicht bzw. entwickelt werden soll. Bekannte Ziele bzw. Visionen bilden die Grundlage für die Definition von funktionalen und nicht-funktionalen Anforderungen.

• Funktionale Anforderung (Systemanforderung)
  Fachlich motivierte Beschreibung von gewünschten fachlichen Funktionalitäten (z. B. Funktionen, Daten, Verhalten, Interaktion, Geschäftsobjekte) mit Adressierung an ein konkretes Softwaresystem oder einer seiner Komponenten, welches die bereitzustellenden Funktionalitäten implementieren soll.
  
  Mit den Begriffen „muss“ (Pflicht), „soll“ (Wunsch) oder „kann“ (Vorschlag) wird die juristische Verbindlichkeit einer Anforderung festgelegt. Anhand des sogenannten Prozesswortes ist zu erkennen, was getan oder auch nicht getan werden soll.
  
  Muster: Anforderungssatzschablone

• Nicht-funktionale Anforderung (Systemanforderung)
  Fachlich motivierte Beschreibung von gewünschten nicht-funktionalen Eigenschaften wie z.B. Last- und Performanceverhalten, Zuverlässigkeit, Verfügbarkeit, Nutzbarkeit (Usability), Sicherheit, Robustheit, Installierbarkeit, Portabilität, Änderbarkeit, Wartbarkeit, Mengengerüste, Antwortverhalten, Reaktionszeiten) mit Adressierung an ein konkretes Softwaresystem oder einer seiner Komponenten, welches die bereitzustellenden Leistungsanforderungen implementieren soll.
  
  Anmerkung: Folglich beschreiben Nicht-funktionale Anforderungen typischerweise Aspekte, die mehrere funktionale Anforderungen betreffen.
  
  Mit den Begriffen „muss“ (Pflicht), „soll“ (Wunsch) oder „kann“ (Vorschlag) wird die juristische Verbindlichkeit einer Anforderung festgelegt. Anhand des sogenannten Prozesswortes ist zu erkennen, was getan oder auch nicht getan werden soll.
  
  Muster: Anforderungssatzschablone

• Randbedingung
  Randbedingungen schränken die für die Umsetzung von funktionalen und nicht-funktionalen Anforderungen zur Verfügung stehenden Realisierungsmöglichkeiten beispielsweise aus technischen, organisatorischen oder kulturellen Gründen ein.
  
  Es handelt sich hierbei um allgemeine, i.d.R. aus fachlicher Sicht nicht beeinflussbare bzw. nicht veränderbare restriktiv wirkende unternehmensexterne oder –interne Umstände oder Vorgaben (z.B. Gesetze, verbindliche Richtlinien, Revisionssicherheit des Systems, Einhaltung der Bestimmungen des Bundesdatenschutzgesetzes, gesetzliche und/oder unternehmensinterne Aufbewahrungsfristen).
  
  Die formulierten Anforderungen werden durch Rahmenbedingungen hingegen nicht eingeschränkt.

Allgemein legen funktionale Anforderungen fest, WAS ein Softwaresystem leisten oder nicht tun soll, während nicht-funktionale Anforderungen hingegen beschreiben, WIE das Softwaresystem arbeiten soll.

Alle an einen Anforderungsprozess Beteiligte (Auftraggeber, Auftragnehmer, Projektleiter, Qualitätssicherer, Tester etc.) haben ein großes Interesse, dass eine Anforderung qualitativ hochwertig beschriebenen wird. Diese Beschreibung muss insbesondere auch die unterschiedlichen Perspektiven dieser Interessengruppen berücksichtigen.

Eine Validierung von Anforderungen ist wichtig, um festzustellen, ob die beschriebenen Anforderungen formal und inhaltlich die folgenden Kriterien angemessen erfüllen:

Für die systematische Ermittlung von Anforderungen aus den verfügbaren Anforderungsquellen (suchen, erfassen und konsolidieren) können verschiedene Techniken genutzt werden, um die Bedürfnisse der Stakeholder und anderer Quellen zu erheben.

Die für eine Umsetzung ermittelten einzelnen Anforderungen mit sind allen beteiligen Interessengruppen (Stakeholder) abzustimmen. Zum Schutz vor späteren Änderungsanträgen sollte auch final geklärt werden, was nicht gemacht werden soll (Abgrenzungskriterien).

Eine systematische Vorgehensweise ermittelte Anforderungen in einem Anforderungsprozess zu klassifizieren, zu prüfen, zu bewerten, zu vergleichen und zu priorisieren bezeichnet man als Anforderungsanalyse. Umgangssprachlich ist die Anforderungsanalyse auch als Anforderungsspezifikation oder Requirements Engineering bekannt.

Mittels einer Klassifikation von Anforderungen lässt sich die Vollständigkeit, Zusammengehörigkeit und Überlappungen von Anforderungen in einer großen Menge erkennen.

Die typischerweise für ein Softwaresystem oder für eine Komponente erhobenen Anforderungen können adäquat in natürlicher Sprache oder in konzeptionellen Modellen (oder auch als Mischform) nach vorgegebenen Kriterien dokumentiert werden. Dieses Vorgehen wird auch als systematische Anforderungsspezifikation bezeichnet.

Eine Anforderungsvalidierung hat den Anspruch, nach einer Anforderungsspezifikation durch Prüfungen und Abstimmungen frühzeitig zu richtigen und widerspruchsfrei formulierten Anforderungen zu gelangen, die allen geforderten Qualitätskriterien genügen.

Die Durchführung der Prüfungen beschäftigt sich vorrangig mit der Frage, ob die Anforderungen den Wünschen und Bedürfnissen der Stakeholder entsprechen.

Die Anforderungsverwaltung flankiert alle anderen Aktivitäten des Anforderungsmanagement indem die Anforderungen strukturiert, für unterschiedlichsten Zwecke aufbereitet und im Falle einer erforderlichen Modifizierung konsistent geändert werden.

Die nachfolgende Grafik veranschaulicht beispielhaft anhand eines Musterprozessvorgehens zur Software Entwicklung je Entwicklungsstufe die jeweils zuordenbare Managementaufgabe.

Aus der obigen Grafik ist ersichtlich, dass Requirements Engineering - also das Erheben von der Anforderungen des Auftraggebers an das zu entwickelnde System - im Entwicklungsprozess lediglich ein Teil vom Anforderungsmanagement (Requirements Management) ist und als Basis für die Erstellung eines Pflichtenhefts dient.

Die nachfolgende Grafik veranschaulicht am Beispiel eines Phasenmodells, die Anordnung und Zuständigkeit des Teilbereichs Requirements Engineering im Rahmen des Requirements Management.