Vortrag von Adrian Zwingli, SwissQ
Nur 35% der Projekte gelten als on-time, on-budget und mit guter Funktionalität abgeschlossen.
Die Probleme liegen in der Aufwandschätzung (moving target), in der Planung, in der Anforderungs-Definition und in realistischen Erwartungen.
Requirements Engineering wird in Firmen zwar als wichtig erachtet, die nötigen Ressourcen werden aber oft nicht gesprochen. Man beginnt schnell mal mit der Software-Entwicklung, erst dann „beginnt“ das Projekt für viele Stakeholder. Der Vorlauf für Requirements Engineering ist oft zu kurz.
Viele versuchen, in den Anforderungen „weniger spezifisch“ zu sein, um Abkürzungen zu nehmen. In Unternehmen hat das Testing oft einen höheren Stellenwert als Requirements Engineering. Wahrscheinlich weil die Maturität in den Prozessen weiter fortgeschritten ist.
Requirements Engineering gleicht manchmal einer Forschungsarbeit: Was ist gefragt, wie kann man es anbieten? Entsprechend läuft manchmal auch etwas falsch…
Nur 1/4 beurteilt ihre Requirements Prozesse als gut oder ausgezeichnet, 44% beurteilen sie als mittelmässig. Das Berufsbild ist nicht gut definiert und bietet nur eine weiche Abgrenzung zum Product Management.
Das Resultat ist eines, der soziale Prozess, der ein Resultat trägt, ist etwas anderes: Welche Stakeholder sind für was zuständig, haben welchen Einfluss? Welche kulturellen oder historischen Widerstände müssen überwunden werden?
Bei der Verwaltung von Requirements wird meist der grösste Verbesserungsbedarf identifiziert.
In über 50% der Fälle wird der Business Value nicht genügend abgeklärt. In 75% der Projekte sind sprachliche Fehler in Anforderungen ein Problem. Entscheidungstabellen können hier Abhilfe schaffen, da sie weniger sprachabhängig sind als Prosatexte.
Missverständnisse in der kommunikation und ändernde Anforderungen führen mit 77% und 69% am öftesten zu Problemen.
50% der Firmen verwenden weniger als 15% des Gesamtprojektaufwandes für Requirements Engineering. Dabei wäre aber noch klar zu definieren, welche Arbeiten zu Requirements Engineering zählen, z.B. das Erstellen von Detailanforderungen durch Software-Ingenieure?
Der Aufwand für die Stakeholderanalyse wird in ca. 50% der Projekte sehr stiefmütterlich behandelt. Die wenigsten kennen eine strukturiertes Stakeholdermanagement mit Zuständigkeiten, Stärken/Schwächen, Ansichten, Wünschen, etc.
Als grösster Erfolgsfaktor wird das Modellieren von Anforderungen bezeichnet. Anstelle des „was“… Auch das Erstellen von Abnahmekriterien wird als erfolgskritisch beurteilt.
Die Traceability wird als grosse Herausforderung betrachtet. Diese ist ja auch nicht einfach zu erreichen über Anforderungen, Code und entsprechende Testcases.
An Tools setzen die Meisten die Microsoft Office Suite ein. Microsoft wird entsprechend PowerPoint um Prozesstools aufbohren und nicht Visio. Zusammen mit dem Team Foundation Server ist Microsoft stark verbreitet, danach folgt IBM mit Rational Requisite Pro, Rational Doors und Enterprise Architect HP Quality Center / ALM ist das meistgenutzte spezialisierte Tool.
@swissq Trends und Benchmarks im Requirements Engineering http://t.co/kfDH5CBE Update vom Executive Summit #Requirements #BusinessAnalyst
— Walter Schärer (@WalterSchaerer) June 19, 2012
Requirements Engineering Trends & Benchmarks: Adrian Zwingli http://t.co/wqkLiX7d
— SwissQ (@swissq) June 19, 2012
