Anforderungs­management Summary

Ein gutes Produkt soll die Lösung für ein bestehendes Problem sein. Die Lösung soll dabei einfach bedienbar sein, denn was nutzt einem ein hochkomplexes, funktionsüberladenes Produkt, das kein Nutzer bedienen kann und möchte. Um eine gute Lösung zu entwickeln, muss man die Bedürfnisse und Anforderungen seiner Nutzer kennen.

Anforderungsmanagement oder auch genannt „Requirements Engineering“ befasst sich mit der Behandlung von Anforderungen, von der Erfassung und Spezifizierung, über die korrekte Implementierung bis hin zur Verwaltung und dem Versionsmanagement.

Diese Summary richtet sich an Projektmanager und Produktmanager von IT- und Softwareprojekten und soll eine kurze Zusammenfassung über das Requirements Engineering sein. Sie orientiert sich am International Requirements Engineering Board (IREB). Bitte informieren Sie sich zum vollen Verständnis des Themas gern noch intensiver, z.B. durch die unten genannten Literaturempfehlungen.

Die Anforderung

Es gibt 3 Sichtweisen auf Anforderungen:

Marktanforderungen sind Anforderungen bzw. Bedürfnisse des Kunden bzw. Benutzers. Es sind die Ziele, die der Nutzer mit den Produkt erreichen will. Es ist das „Warum“ ein Produkt überhaupt entwickelt wird. Dabei ist zu beachten: Die Anforderungen sind in der Sprache des

  • Marktanforderungen sind Anforderungen bzw. Bedürfnisse des Kunden bzw. Benutzers. Es sind die Ziele, die der Nutzer mit den Produkt erreichen will. Es ist das „Warum“ ein Produkt überhaupt entwickelt wird („Lastenheft“). Dabei ist zu beachten: Die Anforderungen sind in der Sprache des Kunden formuliert, es können Widersprüche oder Inkonsistenzen auftreten. Wichtig ist hier, zu ermitteln, was sind wirkliche geschäftlich relevante Bedürfnisse des Kunden und was nur eine unerfüllbare Wunschsammlung.
  • Produktanforderungen sind die funktionalen und nichtfunktionalen Anforderungen, an ein Produkt (Produkteigenschaften). Es ist das „Was“ der Benutzer mit dem Produkt machen kann und wie die Marktanforderungen letztlich in ein konkretes Produkt umgesetzt werden. Sie werden im Pflichtenheft dokumentiert.
  • Komponentenanforderungen sind konkrete (Software-)Anforderungen, die dem Programmierer beschreibt, was genau er umsetzen soll, z.B. Komponenten, Technologien oder Algorithmen. Komponentenanforderungen sind die Verfeinerung der Produktanforderungen, also „Wie“ der Programmierer das Produkt entwickeln soll.

Während Marktanforderungen noch zum Problem gehören, sind Produkt- und Komponentenanforderungen etwas genauer spezifiziert und damit bereits Teil der Lösung.

Es gibt 3 Arten von Anforderungen, Innerhalb dieser existieren natürlich wieder verschiedene Sichtweisen, die des Kunden und die des Programmierers.

  • Funktionale Anforderungen
    • Aus Nutzersicht, z.B. Dienstleistungen, Anwendungsfälle
    • Aus Programmierersicht, z.B. Softwarearchitektur, Stromversorgung
  • Qualitätsanforderungen
    • Aus Nutzersicht, z.B. Usability, Performance
    • Aus Programmierersicht, z.B. Wartbarkeit, Plattformunabhängigkeit
  • Randbedingungen
    • z.B. Kosten, Organisation, Gesetze

Tipps

  • Bilden Sie immer sauber die 3 Anforderungssichtweisen Markt-, Produkt- und Komponentenanforderungen, vermischen Sie sie nicht, so gelingt es Ihnen später leichter eine Produktlösung zu entwickeln und auch mögliche spätere Änderungen korrekt in diesen 3 Ebenen abzuhandeln.
  • Unterscheiden Sie bei Ihrer Anforderungsentwicklung zwischen externer Sicht (Marktanforderung, Bedürfnis, Problembeschreibung) und interner Sicht (Produktanforderung, Komponentenanforderung, Lösungskonzept)
  • Beginnen Sie erst mit der Lösung, wenn die Bedürfnisse klar sind.
  • Weisen Sie den Kunden daraufhin, dass die Ermittlung der Anforderungen noch nicht die Vereinbarung zu deren tatsächlicher Lieferung ist.

Der Anforderungsmanagement-Prozess

Nachfolgend finden Sie in kompakter Form die 7. Schritte auf dem Weg zur gelungenen Anforderung. Per Klick auf die einzelnen Schritte der nachfolgenden Liste gelangen Sie zu den dazugehörigen Erläuterungen.

Weiter unten finden Sie zudem Empfehlungen für weiterführende Links und Literatur, die für dieses normalerweise doch recht komplexe und umfangreiche Thema sehr zu empfehlen sind.

  1. Zielgruppen und Interessengruppen identifizieren
  2. Anforderungen ermitteln
  3. Anforderungen spezifizieren
  4. Anforderungen analysieren
  5. Anforderungen validieren
  6. Anforderungen vereinbaren
  7. Anforderungen verwalten

1. Zielgruppen und Interessengruppen identifizieren

  • Notieren Sie alle Interessengruppen, z.B. Nutzer, Geschäftsführer, Controller, Projektmanager, Programmierer. Welche Zielgruppen werden das Produkt wie nutzen, z.B. erfahrener Nutzer, Einsteiger, Produktion, Wartung, Installation, etc..
  • Tragen Sie die Interessengruppen in einer sogenannten Beteiligungsmatrix oder einer Cross-Impact-Matrix ein, Hieraus können Sie ablesen, wie die Bedürfnisse und Ziele der Interessengruppen sind, in Bezug auf das Produkt, aber auch untereinander.
    Oft kristallisieren sich dabei zwei Hauptgruppen heraus, die beide wichtig sind: Solche die sehr detailverliebt und anwendungsorientiert beschreiben und solche die eher mit Blick aufs geschäftliche Ganze, die Lösung für ein Geschäftsziel suchen.
  • Ermitteln Sie zu den erfassten Interessengruppen und Zielgruppen deren jeweilige Nutzungsszenarien:
    • Wie soll das Produkt genutzt werden, was soll es leisten?
    • Was sind dabei Haupt-, was Nebennutzen?
    • Gibt es Schnittstellen zwischen diesen Szenarien? Gibt es dafür bereits Umsetzungsstandards? Nutzen Sie dafür ein ein Kontextdiagramm.
  • Gibt es weitere Interessengruppen, die Sie möglicherweise vergessen haben, wie z.B. Hacker?

Tipps

  • Neben Sie die Kundenperspektive ein und beteiligen Sie ihn in geeignetem Maße am Projekt. Ihr Kunde ist letztlich derjenige, der über den Erfolg des Produktes entscheidet und die Ihre Rechnung bezahlt.
  • Identifizieren Sie die Hauptinteressensgruppen und schaffen Sie „win-win-Situationen“.
  • Jede Interessengruppen sieht meist nur ihre eigenen Anwendungsfälle und Anforderungen. Diese können sich aber miteinander überschneiden. Achten Sie dabei auf ein konsistentes Verständnis für die Anforderungen unter allen Interessengruppen.

2. Anforderungen ermitteln

  • Erfassen Sie die Anforderungen, z.B. durch Kundeninterviews, Marktforschungsstudien, Strategieberater, Marketingabteilungen.
  • Klären Sie daraufhin mit dem Kunden, was er wirklich benötigt und was Sie benötigen (z.B. anfallender Kostenaufwand, technische Einschränkungen). Ggf. können hier einige Anforderungen bereich gestrichen werden.
  • Hinterfragen Sie, ob es wohlmöglich auch noch unbekannte Anforderungen oder wichtige Randbedingungen gibt, die Sie und Ihr Kunde noch nicht kennen. Dies kann z.B. mittels Durchspielen eines Demoszenarios geschehen.
  • Überprüfen Sie welche Anforderungen wie einander beeinflussen bzw. behindern. Gibt es wohlmöglich technische Einschränkungen/Abhängigkeiten?
  • Priorisieren Sie die Anforderungen. Inwieweit zahlt welche Anforderung auf die Wertschöpfung des Produktes ein?
  • Definieren Sie für die Anforderung relevante Qualitätskriterien (z.B. ISO-Standards, Gesetze, KPIs) oder Einschränkungen (z.B. Kosten, Zeit)

Tipps

  • Achten Sie darauf dem Kunden nicht alles zugeben was er will (Wunsch), sondern das was er braucht (Bedürfnis). Vermeiden Sie dabei aber auch, die Bedürfnisse des Kunden erahnen zu wollen.
  • Folgende Methoden helfen bei der lückenlosen Erfassung von Anforderungen:
    • Workshops, Rollenspiele, Brainstorming, Interviews
    • Prototypen, Modelle, Experimente
    • Szenarien, Fallbeispiele, Use Cases, Personas
    • Marktstudien, Marketingumfragen

3. Anforderungen spezifizieren

  • Die bislang noch „lose“ ermittelten Anforderungen werden nun detaillierter betrachtet und strukturiert. Es gibt zwei Perspektiven von Spezifikationen:
    • Anforderungsspezifikationen sind das „Lastenheft“. Sie sind detaillierter umschrieben, im Hinblick darauf, was und wofür sie gemacht sind.
    • Lösungsspezifikation sind das „Pflichtenheft“. Sie sind detaillierter umschrieben im Hinblick darauf, wie sie gemacht werden. Hierzu gehören Produktanforderungen und teilweise Komponentenanforderungen.
  • Jede Anforderung bekommt eine Referenznummer, anhand derer auch spätere Änderungen verfolgt werden.
  • Nutzen Sie dafür User Stories „Als <Nutzer/Wer> möchte ich <Funktion/Was> um / weil <Wert/Warum>“ bzw. Use Cases.
  • Typische Attribute, um eine Anforderung näher zu spezifizieren sind:
    • Referenznummer
    • Version
    • Autor
    • Schnittstelle / Workflow
    • Realisierungsstatus
    • Priorität
    • Aufwand
    • Akzeptanzkriterien

4. Anforderungen analysieren

  • Die Anforderungsanalyse ist die nähere Spezifikation eines Lösungsmodells und damit der erste Schritt zur Lösung. Überprüfen Sie dabei…
  • …Vollständigkeit
    • Sie die Anforderungen komplett?
    • Wurden alle Benutzungsszenarien berücksichtigt?
    • Hat jede Anforderung ihr Qualitäts- und Akzeptanzkriterium?
    • Sind die Anforderungen im vertraglich vereinbarten Rahmen machbar?
  • …Schätzungen
    • Sind die Schätzungen nachvollziehbar und realistisch?
    • Liegen evtl. Unsicherheiten vor?
    • Was wurde nicht geschätzt? Wo traten bei früheren Projekten Probleme auf?
  • …Projekt
    • Gab es bereits ähnliche Projekte?
    • Welche Fähigkeiten und Mitarbeiter werden für das aktuelle Projekt benötigt?
  • …Technologie
    • Sind alle Schnittstellen zu anderen System definiert?
    • Welche neuen Technologien können ggf. eingesetzt werden?
    • Stimmt die Systemqualität?
  • …Lieferanten
    • Sind alle benötigten Lieferanten bekannt? Gibt es ggf. Unteraufträge / Outsourcing oder Ersatzlieferanten?
    • Können alle Liefertermine gehalten werden?
    • Wer kontrolliert die Lieferanten? Wie sind die Haftungsrisiken?

5. Anforderungen verifizieren und validieren

  • Bevor mit der Implementierung der Anforderungen begonnen wird, werden die Spezifikationen auf mögliche Fehler überprüft.
  • Validierung („doing the right things“) überprüft dabei, ob das geplante Produkt auch das gewünschte Bedürfnis adressiert (den gewünschten Nutzen bringt), z.B. in Hinblick auf Geschäftnutzen, Eindeutigkeit, Vollständigkeit, Korrektheit.
  • Verifikation („doing things right“) stellt dabei das Qualitätslevel der Anforderung sicher, z.B. durch Standards und Vorlagen, Reviews, Fehlerlimit, Verständlichkeit.

6. Anforderungen vereinbaren

  • In diesem Schritt geht es um die förmliche, vertragliche Vereinbarung der Anforderungen für das Produkt. Sie wird getroffen, bevor das Produkt umgesetzt wird.
  • Hier werden die Anforderungen als ein konkretes Projekt definiert, mit den dazu benötigten Ressourcen, Meilensteinen, Arbeitspakten, Qualiätszielen, Lizenzen usw.

7. Anforderungen verwalten

  • Folgende Umstände können zu Änderung der Anforderung führen:
    • Geänderte Markt- oder Kundenanforderungen
    • Unsicherheiten, falsche Annahmen
    • Anfangs unklare Anforderungen
  • Das Änderungsmanagement durchläuft dabei meist folgende Schritte:
    • Änderung erfassen per Änderungsantrag
    • Auswirkungsanalyse im Hinblick auf Umfang, Kosten, Risiken, etc.
    • Freigabe der Entscheidung, z.B. durch PMO oder Entwicklungsleitung etc.
    • Priorisierung, Planung und Beauftragung der Umsetzung & Festlegen von Verantwortlichkeiten
    • Umsetzung der Änderung
    • Test, Abnahme und Freigabe der Änderung
    • Änderungsdokumentation Changelog Produktes

Tools für Anforderungsmanagement

  • OpenSource
    • rmToo
    • OSRMT
  • Kostenpflichtig
    • ReQtest
    • IRqA
    • Visure

Quellen

https://www.medical-design.news/sonstige/software-projekten-zum-erfolg-verhelfen.92791.html
Buch „Systematisches Requirements Engineering“ von Christof Ebert