Anforderungen müssen konkret formuliert werden

Heute ist mir mal wieder klargeworden, wie wichtig klar formulierte Anforderungen sind, um eine passende Software entwickeln zu können. Was war passiert?  Jemand hat versucht mich zu kontaktieren, und hat meine private Mailadresse verwendet, die im Impressum einer meiner Websites aufgeführt ist. Da ich einige Tage im Urlaub war, hat dies dazu geführt, dass ich diese Mail erst heute beantworten konnte. Für solche Fälle hatte ich aber extra einen generischen Mailuser eingerichtet. Die Mails, die dort ankommen, können von meinen Urlaubsvertretern gelesen werden. Meine Site war jedoch missverständlich aufgebaut.

Formulierungshinweise für griffige Anforderungen

Software Requirements Specifications sind im IEEE Standard 830 erstmalig definiert worden. In dieser Norm kann man die Anforderungen nachlesen, die an Anforderungen, bzw Spezifikationen generell zu stellen sind (siehe z.B. in Wikipedia → Software Requirements Specification). Dort werden Requirements, bzw Anforderungen wie folgt definiert:

„Mit Requirements (deutsch: Anforderungen) ist sowohl die qualitative als auch die quantitative Definition eines benötigten Programms aus der Sicht des Auftraggebers gemeint. Im Idealfall umfasst eine solche Spezifikation ausführliche Beschreibung von Zweck, geplantem Einsatz in der Praxis sowie dem geforderten Funktionsumfang einer Software. Hierbei sollte fachlichen – „Was soll die Software können?“ – wie auch technischen Aspekten – „In welchem Umfang und unter welchen Bedingungen wird die Software eingesetzt werden?“ – Rechnung getragen werden.“ – siehe Wikipedia

Generell ist es wichtig, dass man die Anforderungen eindeutig und nachprüfbar formuliert. Eine zu vage Formulierung erkennt man oft daran, dass man bereits Schwierigkeiten damit hat, Testfälle zu formulieren.

Hier ein Beispiel für eine zu vage Formulierung und den passenden Testfall: „Der Geldautomat soll nach Eingabe von Karte und Daten unverzüglich Geld ausgeben“ (Anforderung) „Der Kunde führt eine Gesundheitskarte ein, und tippt 4 Ziffern. Geld wird ausgeworfen.“ (Testfall).

An diesem Beispiel erkennt man, wie wichtig es ist, den Betriff „Karte“ und „Daten“ genauer zu spezifizieren. Anderenfalls besteht die Gefahr, daß nicht einmal ein Test, diese Fehler findet.

Beispiele

Die folgenden Beispiel zeigen sinnvollere Formulierungen:

• Grundanforderungen an das Produkt formuliert man konkret wie „Bei clicken des Buttons „Hilfe“ wird die Software ein Hilfefenster mit Informationen anzeigen“
• Funktionale Anforderungen mit Schnittstelle als beispielsweise „Die Software stellt synchron die Eingabedaten für den Folgeprozess zur Verfügung.“
• Funktionale Anforderungen mit Schnittstelle/Einschränkungals zum Beispiel „Die Software stellt synchron die Eingabedaten für den Folgeprozess zur Verfügung, nachdem der Nutzer „Ok“ gedrückt hat“
• Nichtfunktionale Anforderungen mit Schnittstelle/Einschränkung: „Die Software soll innerhalb von 10 Sekunden auf die Eingabe des Nutzers reagieren“
• Nichtfunktionale Prozessanforderungen mit Einschränkung: „Der Administrator soll die fehlerfreie Datei innerhalb der nächsten Stunde transportieren“
• Nichtfunktionale Prozessanforderungen: „Die Dokumentation soll zum Projektende in Deutsch und Englisch vorliegen“
• Nichtfunktionale Prozessanforderungen mit Projektrandbedingungen: Das verantwortliche Scrum Team wird aus einem Produktowner, einem Scrum Owner, 7 Entwicklern, und einem Qualityexperten bestehen“

Weitere Aktivitäten

Nachdem Anforderungen formuliert sind kann man weitere Techniken anwenden, um sie zu verarbeiten.

Darauf gehe ich dann in späteren Artikeln genauer ein. Hier nur ein kurzer Überblick:

Verstehen und Bewerten

In diesem Schritt geht es darum, Anforderungen zu konzentrieren und diese dann zu bewerten. Hierfür klärt man mindestens die folgenden Punkte:

• Anforderungen klassifizieren nach Art der Anforderung (Bug, legale Änderungen, nice-to-have-Erweiterungen, etc), um herauszufinden, was wie wichtig ist.
• Kundenimpact (warum sollte die Anforderung aus Kundensicht implementiert werden?), etc

Dabei ist es wichtig, Ihre Bewertung zu dokumentieren, und in einer kurzen Empfehlung direkt bei der Anforderung zu erfassen. Das erlaubt dann spätere Umplanungen.

Zusammenfassen

Die Clustern von Anforderungen ist aus mindestens zwei Gründen wichtig:

• Wenn Sie Anforderungen nach Priorität bewerten, kommen kleine Anforderungen oft nicht zum Zug. Wenn Sie diese Anforderungen im Gesamtkontext bewerten, kann die Wichtigkeit ganz anders ausehen.
• Mit dem Gruppieren der Anforderung reduzieren sie die Menge.

Teams, die im Scrum-Modus arbeiten kennen sicher den Unterschied zwischen der User Story und dem Backlog Item. Beide Elemente sind Teile einer solchen Verdichtung.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Dienstag, April 13th, 2010 at 7:59 pm. It is filed under PM-Themen, Thema des Tages and tagged with Anforderungen, Beispiele, Kommunikation. You can follow any responses to this entry through the RSS 2.0 feed.