Aktionen

Kundenanforderungen in technische Anforderungen übertragen

Aus PQWiki


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

Ziele

* Aufbereitung von Kundenanforderungen
  • Grobaufteilung in technische Anforderungen
  • Erkennen von Umsetzungsproblemen

Motivation/Problemstellung

Aus der Kundendiskussion ergeben sich überwiegend fachliche Anforderungen der An-wendungsdomäne des Kunden. Entwickler sind in der Regel Technologiespezialisten und keine Fachexperten der Domäne. Für die Umsetzung benötigen sie technische Anforde-rungen. Daher müssen Kundenanforderungen vor der Umsetzung in technische Anforderungen übertragen werden.

Kurzbeschreibung

Situation Motivation Outcome.gif
Der Anforderungskatalog wird in Anwendungsfälle (Use Cases) mit klarem Anfangs- und Endzustand unterteilt und mit funktionalen Merkmalen, Qualitätsmerkmalen und Randbe-dingungen versehen.

Input

Dokumentierte Kunden-Anforderungen

Output

Technische Anforderungen (Entwickler-Anforderungen)

Rahmenbedingungen

Rolle (Ausführender)

Technischer Projektleiter

Werkzeuge, Hilfsmittel

UML und unterstützende Tools, Tool zur Anforderungserstellung, Ticketsystem

Vorkenntnisse und Erfahrungen

Gute UML-Kenntnisse

Ort und Umgebung

Arbeitsplatz, Besprechungsraum

Weitere Teilnehmer

Entwickler der betroffenen Bereiche (Oberfläche, Datenbank, Backend-entwickler, Administratoren)

Voraussichtliche Dauer

1h - 4h pro Sprint

Vorgehensweise

Vorbereitung

-

Durchführung


Die Anforderungen werden als Anwendungsfälle zum Beispiel in einem Ticketsystem er-fasst. Eine technische Anforderung zeichnet sich hierbei im Vergleich zu einer Kundenanforderung dadurch aus, dass sie neben der offenkundigen menschlichen Interaktion mit dem System auch die hintergründigen technischen Belange eines Anwendungsfalls berücksichtigt. Zum Beispiel könnte es erforderlich sein, den Anwendungsfall „Der Benutzer loggt sich ein“ technisch dahingehend zu erweitern, dass für Passwörter Vergaberichtlinien festgelegt sein müssen und dass ein Login-Formular nach dreimaliger falscher Eingabe des Passworts für eine Minute gesperrt und die Falscheingabe zudem protokolliert wird.

Die Übertragung jeder Kundenanforderung in eine technische Anforderung sollte hierbei jeden der folgenden fünf Aspekte berücksichtigen: die Anforderungsart, den Verbindlichkeitsgrad, den Detaillierungsgrad, die Priorität und den Termin. Insbesondere die Verbindlichkeit und die Anforderungsart helfen dabei, den Anwendungsfall auf Vollständigkeit hin zu überprüfen. Die Anforderungsart bespricht die Probleme, Ziele, die funktionalen genauso wie die nicht-funktionalen Anforderungen, die Randbedingungen und die Testanforderungen. Die Verbindlichkeit legt fest, welche Anforderungen geschäftskritisch sind, welche optional sind oder welche Anforderungen auf bloße Absichten (eventuell aber zukünftige Anforderungen) hinauslaufen. Aspekte der Verbindlichkeit, die lediglich Vorschlags- oder Kommentarcharakter haben, sollten nichtsdestoweniger vermerkt werden, da sich ihr Verbesserungspotential im Laufe der Umsetzung als integrierbar und realisierbar erweisen könnte.

Bemerkung: Bei der Identifizierung von Anwendungsfälle sollten insbesondere auch die Anwendungsfälle berücksichtigt werden, für die keine menschlichen Akteure gegeben sind. Es sind häufig genau diese Anwendungsfälle, die Qualitätsmerkmale wie zum Beispiel Effizienz und Zuverlässigkeit des Systems, die Erweiterbarkeit, Wartbarkeit, Administrierbarkeit usw. berücksichtigen.

Nachbereitung

In der Nachbearbeitung werden die erstellten Anwendungsfälle (Use Cases) mit den Kundenanforderungen verglichen.

Gütekriterien/Empfehlungen

Es hat sich als günstig erwiesen, bei den Besprechungen diejenigen Entwickler einzubeziehen, die danach für die Umsetzung der Anforderungen verantwortlich sind. Sie können sich besser mit den besonderen Herausforderungen identifizieren und bei Bedarf Verbesserungsvorschläge einbringen. Der Anfangs- und Endzustand eines Anwendungsfalls sollte bekannt sein und dokumentiert werden.

Risiken

Der Projektleiter sollte stets darauf achten, während dieser Phase mit dem Vertrieb in engem Kontakt zu stehen, um Lücken der Spezifikation aufzudecken und Missverständnissen vorzubeugen.

Einordnung in das PQ4Agile-Qualitätsmodell

Schlagworte

Kunden-Anforderungen, technische Anforderung, Enwickler-Anforderung, Anwendungsfall, Use Case, Akteur, UML

Weiterführende Informationen

Literatur

*A. Herrmann, E. Knauss, R. Weißbach: Requirements Engineering und Projektma-nagement, Springer, Berlin 2013
  • B. Oestereich: Die UML 2.0 Kurzreferenz für die Praxis, Oldenburger, München Wien 2004
  • B. Oestereich: Objektorientierte Softwareentwicklung Analyse und Design mit der Unified Modeling Language, Oldenburger, Wien 2001