Wie beurteilt man die Qualität von Anforderungen?

    Zu Beginn eines Projekts werden die Anforderungen je nach Auftraggeber in unterschiedlicher Qualität und Tiefe an das Projektteam übergeben. Das hängt in der Praxis ganz maßgeblich vom Wissensstand der Mitarbeiter des beauftragenden Unternehmens ab. Der Mangel an Systematik beim Briefing und in der Konzeption hat schwerwiegende Auswirkungen auf den Projekterfolg.

    Formen von Anforderungen

    Die tatsächliche Qualität der dokumentierten Anforderungen schwankt ganz erheblich. In der Praxis werden Anforderungen in Form

    • eines freien Briefings,
    • eines Lastenhefts/ Grobkonzepts,
    • von Wireframes oder Layouts/Entwürfen,
    • von User Stories (wenn der Auftraggeber agile Methoden mag) oder
    • eines ausführlichen technischen Feinkonzept

    übermittelt.
     

    Mangelhafte Anforderungsdokumente sind die Regel

    Die Folgen dieses Kuddelmuddels liegen auf der Hand. Oft wird mit einem mangelhaften Briefing schon einer der ersten schwerwiegenden Fehler im Projektablauf gemacht. Und oft kommt es bereits an dieser Stelle zu den ersten Mißverständnissen zwischen Product Owner und Team.
    Das sieht dann oft so aus, dass der Auftraggeber schlicht und einfach behauptet “es sei ja alles ganz einwandfrei beschrieben” oder “Fragen seien überflüssig, dafür würde die Zeit fehlen” und überhaupt “solle man sich an die Arbeit machen, die Zeit würde drängen”.
    Bei dieser schlechten Ausgangslage verwundert es mich nicht, dass schätzungsweise 80% der IT-Projekte scheitern. Die Qualität des Briefings ist ganz erheblich für den Projekterfolg mitverantwortlich. Handelt es sich bei dem Briefing nur um eine grobe, mit ein paar Details gewürzte, Ideenskizze, so sind die Anforderungen nicht vollständig beschrieben und dem Requirements Engineering sollte mehr Zeit gegeben werden.
     

    Wozu der Aufwand?

    In der Praxis lassen sich  Anforderungen sehr systematisch beschreiben. Die Dokumentation von Anforderungen hat den Zweck, für alle Projektbeteiligten einwandfrei klarzustellen, was gewünscht wird. Ich selbst beschreibe Anforderungen gern zunächst in Form von User Stories und leite dann dazu die passenden Use Cases ab.
    Ganz wichtig ist, dass alle Anforderungen objektivierbar sind und von allen Stakeholdern im Projekt verstanden werden können.
    Anforderungen sollen

    • die Effizienz innerhalb des Teams erhöhen,
    • die Effizienz mit externen Dienstleistern und anderen internen Teams erhöhen,
    • das Projekt rechtfertigen und den Bezug zu übergeordneten Zielen darstellen,
    • und letztendlich natürlich die konkrete Nachfrage an Funktionen beschreiben.

     

    Kriterien für gute Anforderungen

    Aus der Praxis haben sich einige Kriterien bewährt, anhand derer man einzelne Anforderungen überprüfen kann. Es ist dabei unerheblich, ob die Anforderung in Form eines Use Cases (bei Prozessen/ Abläufen) oder in Form von Wireframes (bei statischen Anforderungen) beschrieben wird. Es ist übrigens auch ganz unerheblich, ob eine agile Methode oder ein systematisches Vorgehen angewendet wird.
    Hier sind übergreifende Qualitätskriterien für Anforderungen:

    • Einzigartigkeit: jede einzelne Anforderung soll sich bloß mit einer einzigen Sache befassen (z.B. der Selectbox für die Sprachauswahl)
    • Vollständigkeit: eine Anforderung sollte ihre Sache möglichst vollständig an diesem Ort abbilden. Auf Referenzen zu anderen Anforderungen sollte hingewiesen werden.
    • Konsistenz: die Anforderung sollte nicht einer anderen Anforderung widersprechen und sollte im Einklang mit der maßgeblichen externen Dokumentation oder anderen Vorgaben stehen.
    • Kleinteiligkeit: die Anforderung sollte so kleinteilig wie möglich sein, es sollten keine Bedingungen mit ihr verknüpft sein. Eine Bedingung ist eine weitere Anforderung.
    • Verfolgbarkeit: die Anforderung erfüllt alle oder ein Teil eines Unternehmens müssen wie von den Beteiligten angegeben.
    • Aktualität: die Anforderung sollte nicht im Laufe der obsolet werden, sondern Bestand haben. Ansonsten liegt eine Bedingung vor, die wieder in einer eigenen Anforderung zu definieren wäre.
    • Realisierbarkeit: die Anforderung sollte innerhalb der finanziellen und zeitlichen Grenzen des Projekts umgesetzt werden können. Kurz: sie sollte realistisch sein.
    • Eindeutigkeit: die Anforderung sollte prägnant formuliert sein – ohne Rückgriff auf Fachjargon oder Abkürzungen. Oft können Wortschablonen helfen. Das ist zwar nicht so schön, aber effektiv.
    • Obligatorisch: es sollten keine Wunschlisten, sondern nur konkret geplante Anforderungen dokumentiert werden. Ansonsten sind es keine Anforderungen und das Ergebnis wäre Feature-Creep.
    • Überprüfbarkeit:. die Anforderungen sollten durch Inspektion, Demonstration, Test oder Analyse überpüft werden können.

     

    Metriken

    Was sind denn nun die KPIs für gute Anforderungen? Ganz allgemein könnte man sicher sagen, dass eine Anforderung um so besser beschrieben ist, je weniger sie zwischen den Teammitgliedern hin und hergeschoben werden muss. Um so weniger Abstimmungsaufwand also nötig ist. Hier zeigt sich, dass gerade in den Projekten mit mangelhaften Anforderungen der Abstimmungsaufwand besonders groß ist. (Nebenbei: ist das einer der Gründe, warum in vielen Agenturen so lange gearbeitet wird?).
     

    • Requirement churn (Link)
    • Requirement Coverage
    • Requirement to Defect Ratio

    Foto: “Kitty Joyner – Electrical Engineer – GPN-2000-001933” by NACA – Great Images in NASA Description. Licensed under Public domain via Wikimedia Commons.

    Was machen wir daraus? Was sind Ihre Gedanken dazu?

    Ihr

    unterschrift_180-180x100
    Posted in

    Thomas Vehmeier

    Thomas Vehmeier ist Diplom-Volkswirt, Digital-Stratege und Plattformökonom. Online bereits seit 1993, berät er heute Konzerne und mittelständische Unternehmen bei ihrer Internet-Strategie und unterstützt im Interim-Management – zuletzt im ThinkTank des Telekom-CEO, zuvor vor allem für Franchise-Zentralen und Handelsunternehmen.
    Nach oben scrollen