Systematisches Requirements-Engineering (Teil 2)
Mit System zum Erfolg
Fortsetzung des Artikels von Teil 1
Mit System zum Erfolg
| Arbeitsergebnisse | Ermittlung | Analyse | Prüfung | Abstimmung | Verwaltung |
|---|---|---|---|---|---|
| Vision |
x |
Taktgeber abgeschaltet - RAM aktiviert |
externen Interrupt, Pin-Änderung oder Watchdog-Timer |
5 µA | |
| Use-Case/Szenario | x | Sämtliche Peripherie läuft normal - Code kann nicht ausgeführt werden | Jede Peripherie kann die CPU aktivieren | 0,7 mA | |
| Bewertung | x | x | x | x | |
| Lastenheft, SLA | x | x | x | x | x |
| Projektplan | x | x | x | x | |
| Teststrategie | x | x | x | ||
| Lösungsmodell | x | x | x | ||
| Pflichtenheft | x | x | x | x | |
| Release-Planung | x | x | x | ||
| Produktkatalog | x | x | |||
| Vertrag | x | x | x | ||
| Abnahme |
x | x |
Tabelle 1: Arbeitsergebnisse und Dokumente im Requirements-Engineering
Studien bei Vector Consulting zeigen, dass sich in der Medizintechnik die Kosten für Nacharbeiten über den Produktlebenszyklus hinweg durch eine Verbesserung des Requirements-Engineering um 30 bis 50 Prozent senken lassen. Die Einführung und systematische Umsetzung von Requirements-Engineering braucht Aufwand sowohl in der Entwicklung als auch an ihren Schnittstellen, also Produktmanagement, Produktmarketing und Vertrieb.
Häufig wird dieser Aufwand als zu hoch und zu zeitraubend gesehen, sodass die Anforderungen weiterhin ad-hoc in das Projekt hineinpurzeln und dort bruchstückhaft und mit vielen Nacharbeiten umgesetzt werden, bis einmal mehr das Projekt seine Ziele verfehlt oder abgebrochen werden muss.
Nutzen des Requirements-Engineerings
Aus der Beratungspraxis sowie den Industrieerfahrungen in der Medizintechnik bei Vector ist dieses Dilemma bekannt: Verbesserungen in Methodik, Prozessen, Ausbildung und Werkzeugen werden nicht angegangen, da der Kunde den Anfangsaufwand, um diese Verbesserungen anzustoßen, als zu hoch betrachtet. Daher soll im Folgenden der Nutzen eines systematischen Requirements-Engineering qualitativ und quantitativ unterstrichen werden.
Vor allem aber sollen konkrete Hinweise gegeben werden, wie man in der eigenen Umgebung den Nachweis führen kann, dass sich der Aufwand für das Requirements-Engineering lohnt. Eine weitaus umfangreichere Darstellung der ROI-Konzepte (Return on Invest) und zugrunde liegenden Projektaufwandsdaten findet sich in [2,3,4].
| Literatur |
|
|---|---|
| [1] |
C. Ebert: "Software-Projekten zum Erfolg verhelfen"; MEDIZIN+elektronik 5/2012; www.medzin-und-elektronik.de/it-in-der-klinik/article/92791 |
| [2] | C. Ebert: "Systematisches Requirements Engineering"; Dpunkt-Verlag, Heidelbert, Germany, vierte überarbeitete Auflage 2012 |
| [3] | C. Ebert, R. Dumke: "Software Mearusement"; Springer, Heidelbert, New York, 2007 |
| [4] |
B. Berenbach, D. Paulish, J. Kazmeier, A. Rudorfer: "Software Systems Requirements Engineering", McGraw Hill, 2009 |
- Produktivitätsverbesserung: Typischerweise werden 30 bis 50 Prozent des Entwicklungsaufwands für
- Fehlerbehebung und nicht entwicklungsbezogene Aktivitäten eingesetzt. Die Hälfte der Fehler kommt direkt aus unzureichenden Anforderungen und unkontrollierten Änderungen. Im Systemtest sind es 80 Prozent der Fehler, die aus unvollständigen (31 Prozent) oder falschen Anforderungen (49 Prozent) resultieren.
- Verbesserte Projektplanung und Ressourceneinteilung, weniger Verzögerungen vor Projektstart, eine schnellere Anlaufphase sowie Termintreue aufgrund von bekannten Anforderungen und klaren Verantwortungen im Projektteam und im Vertrieb: Mehr Aufwand für Entwicklung und konsequente Umsetzung und Test der Anforderungen verbessert die Termintreue und reduziert Verzögerungen auf unter 20 Prozent.
- Kürzere Durchlaufzeiten durch Fokus auf jene Aktivitäten und Inhalte, die Wert schaffen: Knapp die Hälfte aller Funktionen eines Softwaresystems werden nicht genutzt. Das gilt sowohl in der IT wie auch in medizintechnischen Produkten. Weniger Anforderungen reduzieren die Komplexität und machen damit die Projekte verlässlicher und verbessern die Qualität.
- Weniger Nacharbeiten von inkonsistenten Anforderungen durch Einflussanalyse bei sich ändernden Anforderungen und Nachverfolgbarkeit zu den betroffenen Arbeitsergebnissen: Werden die Anforderungen so umgesetzt, wie sie vom Kunden oder Benutzer beschrieben werden, führt das leider zu Nacharbeiten, die im Schnitt 45 Prozent des Projektaufwands ausmachen.
- Wiederverwendung von Anforderungen und davon abgeleiteten Arbeitsergebnissen (z.B. Mechanismen zur Systemsicherheit).
- Höhere Kundenzufriedenheit durch konsistentes Verständnis der wirklichen Anforderungen.
Einige dieser Faktoren, wie Termintreue oder weniger Nacharbeiten, schaffen einen unmittelbar greifbaren Nutzen. Andere, beispielsweise die Kundenzufriedenheit, sind eher »opportunistisch« und werden in Form nachhaltig guter Kundenbeziehungen und weiterer Projekte greifbar.
Insgesamt zeigen die Erfahrungen bei Vector Consulting, dass eine Verdoppelung des Aufwands für Requirements-Engineering hin zu zehn Prozent des Projektaufwands in den Bereichen Methodik, Prozesse, Training und Werkzeugunterstützung konkret realisierbaren Projektnutzen von über 20 Prozent schafft. Das ist ein ROI von mehr als 4, und damit sind nur die direkt messbaren Vorteile berücksichtigt. Genügend Gründe, das eigene Requirements-Engineering zu hinterfragen.
Über den Autor:
Dr. Christof Ebert ist Geschäftsführer und Partner der Vector Consulting Services.
| Tipps für die Praxis |
|
|---|---|
| → | Trennen Sie bei der Anforderungsentwicklung zwischen der externen Sicht (Marktanforderungen, Bedürfnisse, Problembeschreibung) und der internen Sicht (Produktanforderungen, Lösungskonzeption, Komponentenanforderungen). |
| → | Bilden Sie in der Spezifikation der Anforderungen drei Typen von Anforderungen, nämlich Marktanforderungen, Produktanforderungen und Komponentenanforderungen. |
| → | Vermischen Sie niemals das Was und das Wie. Beginnen Sie nicht zu früh mit der Lösung, solange noch nicht klar ist, was die wesentlichen Bedürfnisse sind. |
| → | Modellieren Sie beim Übergang von der Problembeschreibung (z.B. Lastenheft) zur Lösungskonzeption (z.B. Pflichtenheft) sowohl die Systemumgebung als auch die zu entwickelnde Systemarchitektur. Beim Übergang zu den Komponentenanforderungen muss die Systemarchitektur bereits hinreichend detalliert sin, um Auswirkungen von Entwurfsentscheidungen (z.B. Partitionierungen) bewerten zu können. |
| → | Antworten Sie immer auf der Basis der Konsequenzen auf den Projektplan, falls es zu Änderungsvorschlägen kommt. Begeben Sie sich nie in eine Situation, in der Änderungswünsche isoliert von den Auswirkungen im Projekt und der Rückwirkung auf andere Funktionen behandelt werden. |
| → | Berücksichtigen Sie alle Anforderungen. Fragen Sie relevante Interessenvertreter, ob etwas übersehen worden ist. Machen Sie dabei klar, dass die Ermittlung von Anforderungen noch keine Garantie für deren Lieferung ist. Geliefert wird nur, was vereinbart und bezahlt wird. |
| → | Betrachten Sie Requirements-Engineering als projektbegleitend. Requirements-Engineering ist nicht mit dem Erfassen von Anforderungen abgeschlossen. Als Prozess begleitet es die weitere Entwicklung bis zum Projektabschluss und darüber hinaus in die Betriebs- und Wartungsphase bis zum Lebensende. |
| → | Setzen Sie Methodik und Werkzeuge im Requirements-Engineering situativ ein. Ein Werkzeug allein bringt keine Verbesserung. Die Basis für gute Ergebnisse ist Systematik und Disziplin. |
| → | Überlegen Sie sich gut, was Sie mit einem Werkzeug erreichen wollen. Grundsätzlich gilt heute, dass kein Unternehmen mehr solche Werkzeuge selbst machen sollte - außer Sie wollen es anschließend verkaufen oder aber im Bereich von kundenspezifischen Dienstleistungen einsetzen. |
| → |
Optimieren Sie das Requirements-Engineering, und Sie werden in den Projekten beträchtlichen Aufwand sparen. Systematisches Requirements-Engineering reduziert Nacharbeiten, Zusatzaufwände durch Inkonsistenzen und vor allem Fehler, die erst spät entdeckt werden. |
- Mit System zum Erfolg
- Mit System zum Erfolg
Lesen Sie mehr zum Thema
