Aktionen

Kundenanforderungen dokumentieren

Aus PQWiki


Schnelligkeit
★★★
Einfachheit
★★☆
Agilität
★☆☆

Ziele

* Gesteigerte Kundenzufriedenheit
  • Dokumentation der genauen Erwartungen des Kunden*
  • Bessere Kommunikation mit dem Kunden

Motivation/Problemstellung

Eine der häufigsten Gründe dafür, dass fertige Produkte den Vorstellungen des Kunden nur teilweise oder gar nicht entsprechen, Funktionen fehlen oder aber die Zielgruppe verfehlt wird, liegt am mangelnden gegenseitigen Verständnis, an ungenügender Kommunikation oder fehlender Dokumentation von Kundenanforderungen. Mit dieser Best-Practice wird erläutert, wie konkrete Schritte aussehen könnten, um diesen oben genannten Problemen entgegenzuwirken.

Kurzbeschreibung

Anforderungsschablone.gif
Funktionale Anforderungen und Qualitätsanforderungen werden in Gesprächen mit dem Kunden strukturiert erfasst. Der Kunde ist jeder beliebige Anforderungssteller; er kann sowohl der Auftraggeber einer Software als auch der Endkunde (Anwender) selbst sein.

Input

Stakeholder des Kunden, Geschäftsprozess

Output

Kundennahe Dokumentation, Gesteigerte Kundenzufriedenheit

Rahmenbedingungen

Rolle (Ausführender)

Projektleiter,Vertrieb

Werkzeuge, Hilfsmittel

MS Word mit Templates zur Erfassung der Anforderungen, Notizblock und Stift zur Visualisie-rung, Anforderungsverwaltungswerk-zeug

Vorkenntnisse und Erfahrungen

Gute Produktkenntnisse, Kommunikationsfähigkeit, UML

Ort und Umgebung

Beim Kunden

Weitere Teilnehmer

Alle Stakeholder

Voraussichtliche Dauer

30min – 3h

Vorgehensweise

Vorbereitung

Projektansprechpartner Identifizieren

Zunächst müssen die konkreten Ansprechpartner(innen) ermittelt werden. Für den Auszuführenden bedeutet dies, seine Ansprechpartner grob in drei Kategorien zu unterteilen: 1. Fachexperten (Experten der Anwendungsdomäne, aber keine IT-Experte) 2. Systembetroffene (Mitarbeiter und konkrete Anwender) 3. Anforderungsverantwortliche (bspw. Führungskraft auf Kundenseite)

Je nach Einordnung in eine Kategorie, ist eine andere Form der Information zu erwarten: 1. Fachexperten geben Hintergrundwissen aus der Anforderungsdomäne 2. Systembetroffene kennen konkrete Arbeitsabläufe 3. Anforderungsverantwortliche treffen die Entscheidung

Für die Erhebung von Anforderungen sind 1 und 2 wichtiger.

Durchführung


Bei der Durchführung werden zusammen mit dem Ansprechpartner die Geschäftsprozesse und die mit ihnen in Verbindung stehenden System-Merkmale wie zum Beispiel Layout-Richtlinien oder die Benutzerführung identifiziert. Sie werden anhand von Beispielen behandelt und letztlich abstrakt in einem Dokument beschrieben.

Zusätzlich zu den Geschäftsprozessen werden Qualitätsmerkmale berücksichtigt. Hierbei wird der Kunde aktiv und gezielt auf die unterschiedlichen Gruppen von Qualitätsmerkmalen aufmerksam gemacht, um sie später in der Konzeptionierungsphase möglichst frühzeitig berücksichtigen zu können. Es müssen gemeinsame nicht funktionale Akzeptanzkriterien gefunden werden, die auch überprüfbar sind. Ziel sollte es sein, von Anfang an neben den offenkundigen auch die besonderen Belange des Kunden zu berücksichtigen und diese durch gezieltes Fragen zu ermitteln.

Hinweis: Hintergrundwissen über Begriffe und Objekte der Anwendungsdomäne und abstrakte Abläufe gibt am ehesten der Fachexperte; Informationen über konkrete Vorfälle, konkrete Arbeitsschritte oder die Häufigkeiten gibt eher der Systembetroffene.

Wichtig: Es sollen möglichst alle Anwendungsfälle mit den Kundenansprechpartnern be-sprochen und dokumentiert werden. Dabei sollte stets darauf geachtet werden, dass sich die Gesprächspartner auf demselben Abstraktionsniveau befinden, damit es nicht zu unterschiedlichen Interpretationen von Vorgängen kommt.

Nachbereitung

In der Nachbearbeitung ist es wichtig, dass der Erfasser die gemeinsam ermittelten Anforderungen und den Gesprächsverlauf in einem zentralen Dokument niederschreibt. Dieses Dokument sollte sowohl alle wichtigen Informationen und Spezifikationen, die für die Anforderungen relevant sind, enthalten als auch die Merkmale festhalten, die nicht in Anforderungen Berücksichtigung finden. Beim Verfassen sollte auf offene Fragen geachtet werden. Dieses Dokument, so wie die Fragen hierzu, werden im Anschluss mit dem Kunden nochmals besprochen, um Missverständnisse zu erkennen und zu beheben.

Gütekriterien/Empfehlungen

Die Dokumente sollten in einem entsprechenden Ordner hinterlegt und mit Datum, Kunde und Betreff versehen werden. Im Dokument sollte eine Versionshistorie mit Datum und Bearbeiter hinterlegt sein. Alternativ bieten sich Systeme mit integrierter Versionskontrolle, bspw. ein Wiki-System, oder das Dokumentenmanagement einer CRM-Software an. Für die Erfassung der eigentlichen Anforderungen sollte eine Vorlage verwendet werden, die mindestens das Ziel der Anforderung, den Bereich und die Priorität umfasst. Sie helfen bei der Prüfung auf Vollständigkeit, sorgen für eine bessere Übersicht und (in der Wiederholung) für eine schnellere und gezieltere Bearbeitung der Anforderungsdokumentation.

Risiken

Die Anforderungsdokumentation hat großen Einfluss auf das gesamte Projekt. Fehler können daher die Kosten steigern und den Projekterfolg gefährden.

Einordnung in das PQ4Agile-Qualitätsmodell

Schlagworte

Funktionale Anforderung, Qualitätsanforderung (nicht-funktionale Anforderung), Anforderungssteller, Stakeholder, Akzeptanzkriterium, Überprüfbarkeit, Messbarkeit, Kundenzufriedenheit, UML

Weiterführende Informationen

Literatur

*A. Herrmann, E. Knauss, R. Weißbach: Requirements Engineering und Projektma-nagement, Springer, Berlin 2013
  • B. Oestereich: Objektorientierte Softwareentwicklung Analyse und Design mit der Unified Modeling Language, Oldenburger, Wien 2001
  • C. Rupp: Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis, Carl Hanser, München 2009
  • C. Kühl: Formalisierung von Requirements durch Nutzung von Templates, Freie Uni-versität Berlin 2010