CC-REPRINT Das Problem der unzulänglichen Requirementsspezifikation Harry M. Sneed CC GmbH, Wiesbaden Published in: Gesellschaft für Informatik, achausschuß 5.1 Management der Anwendungsentwicklung und -wartung im achbereich 5 Wirtschaftsinformatik
Copyright No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of CC GmbH. Information in this document is subject to change without notice and does not represent a commitment on the part of CC GmbH. This document and the referenced software described in this document is furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the document or the software on any medium except as specifically allowed in the license or nondisclosure agreement. Copyright 2002 CC GmbH. All rights reserved
Harry M. Sneed CC GmbH, Wiesbaden Das Problem der unzulänglichen Requirementsspezifikation Aus Untersuchungen der Gartner und der Standish Gruppe 1 sowie aus Studien der IEEE 2 und des amerikanischen Rechnungshofes 3 geht hervor, daß mehr als die Hälfte aller Software-Entwicklungsprojekte scheitern. Die Statistik schwankt zwischen 50 und 60 %. Es ist ferner bekannt, das von denen, die erfolgreich beendet werden, mehr als die Hälfte ihr Budget um mehr als 50 % überschreiten. In Anbetracht dieser Zahlen darf es nicht wundern, wenn immer mehr Anwenderbetriebe auf fertige Lösungen bzw. Standard-Softwarepakete zurückgreifen. Die Risiken einer Neuentwicklung sind einfach zu hoch. Diese Risiken sind vielfältiger Natur. Es gibt Technologierisiken, Performancerisiken, Zuverlässigkeitsrisiken und Personalrisiken, aber eine Risikoart ragt besonders hervor und taucht immer wieder in den Studien als Hauptrisiko auf, und zwar das Requirementsrisiko. Nach Ed Yourdon's Bericht über die Litigation gescheiterter Softwareprojekte in den USA wird keine Ursache so häufig zitiert wie die Unzulänglichkeit der Requirementsspezifikation. Vor allem dann, wenn Entwicklungsprojekte außer Haus vergeben oder von externen Partnern zum estpreis im Haus abgewickelt werden, wird die Qualität des Requirements zum Hauptthema, erst recht wenn es zu einem Gerichtsprozeß kommt. Der Auftragnehmer kann sich fast immer darauf berufen, daß die Anforderungen unvollständig und widersprüchlich sind. Nicht umsonst wird in Verträgen immer wieder auf die Verpflichtung des Auftraggebers hingewiesen, vollständige, korrekte und widerspruchsfreie Anforderungen abzuliefern, denn damit hat der Auftragnehmer eine mächtige Waffe in der Hand, falls es zum Streit kommt. Die wenigsten Anwender sind in der Lage, dieser Verpflichtung nachzukommen. 1 2 3 Standish Group: Chaos - The Cost of IT Project ailures, PC-Week, Nr. 16, Jan. 1995 Karolak, D.: Software Engineering Risk Management, IEEE Computer Society Press, Los Alamitos, 1998 GAO: Technical Risk Assessment in the DOD, GAO Report 93-101, Washington D.C., 1993 Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 1
Die Schwierigkeiten, die damit verbunden sind, eine vollständige, korrekte und konsistente Requirementsspezifikation zu erstellen, sind ähnlich denen, die mit der Erstellung korrekter und konsistenter Programme verbunden sind. Im Grunde genommen ist eine Requirementsspezifikation bzw. ein achkonzept ein virtuelles Programm. Darin ist alles beschrieben - sowohl funktional wie auch nicht funktional -, was das System überhaupt leisten soll, und zwar bis ins kleinste Detail. Die Vorstellung, daß ein achkonzept nur grobe unktionen anzugeben hat und daß der Auftragnehmer verpflichtet ist, es zu verfeinern, ist eine ehlannahme, die vor einem Gericht keinen Bestand hat. Vom Auftragnehmer ist nicht zu erwarten, daß er Entscheidungen für den Kunden trifft, auch nicht die Entscheidung über die Gestaltung der Oberfläche, der Berechnung einer Zinsrate oder die Genauigkeit einer Messung. Er kann nur Vorschläge ausarbeiten, letztendlich muß der Kunde entscheiden, was er will. Außerdem muß jede Entscheidung, jede Verarbeitungsregel, jede Schnittstelle nach außen vollständig und präzise dokumentiert werden. Wie das zu machen ist, wird in der einschlägigen Literatur zum Thema "Requirements Engineering" vorgegeben. Besonders zu empfehlen sind die Bücher: Defining Software Requirements von Carolyn Shamlin in QED Information Science Pub. Software Requirements Analysis & Specification von Alan Davis in Prentice-Hall Pub. Object-Oriented Requirements Analysis and Logical Design von Donald iresmith in Wiley Verlag Mastering the Requirements Process von Susanne und James Robertson in Addison-Wesley Verlag Außerdem ist die ANSI/IEEE Norm 830 Guide to Requirement Specification zu empfehlen. Anwender, die aus Kapazitäts- oder Kenntnisgründen nicht in der Lage sind, adäquate Requirements zu liefern, sind gut beraten, Standardsoftware einzusetzen oder die Entwicklung in eigener Regie durchzuführen. Von einer externen Abwicklung ist dringend abzuraten. Sie wird mit Bestimmtheit daneben gehen. Da Requirements ständig im luß sind, hat es Konsequenzen für das Projektmanagement. Statt über Entwicklungsprojekte zu reden, muß von Evolutionsprojekte die Rede sein. Auch hier stiftet der Begriff Verwirrung. Auf jeden all ist der Begriff "Projekt" im Zusammenhang mit Software eigentlich ein ganz fataler Ausdruck. Denn ein Projekt impliziert einen Anfang und ein Ende mit einem kalkulierbaren Weg dazwischen. Das sind Voraussetzungen, die bei der Entwicklung neuer Softwaresysteme mit einer neuen Technologie oft Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 2
fehlen. Es gibt weder einen definierten Anfang noch ein definiertes Ende, geschweige denn einen kalkulierbaren Weg dazwischen. Das Problem liegt darin, daß Softwaresysteme in anderen Systemen eingebettet sind, wie Geräten, Prozessen und Organisationen, und nicht unabhängig von diesen Systemen definiert werden können. Zuerst muß das Trägersystem vollständig erfaßt und beschrieben sein, ehe an das Softwaresystem überhaupt gedacht wird. Leider läuft dies allzu oft anders ab. Man beginnt die Software zu definieren ohne Rücksicht auf die Umgebung, in der sie operieren soll. Es ist weder der Ist-Zustand noch der Soll-Zustand der organisatorischen Prozesse bekannt, dennoch wird ein "Projekt" gestartet, um diese Prozesse zu automatisieren. Man glaubt sogar, die Kosten und die Dauer solcher Expeditionen ins Ungewisse abschätzen zu können. Kein Wunder, wenn so viele Softwareprojekte - bis zu 57 % nach der Studie der Standish Gruppe - daneben gehen. Ehe ein Softwareprojekt kalkuliert werden kann, müssen alle Eigenschaften der Umgebung - funktionale und nicht-funktionale - sowie alle Anforderungen - funktionale und nicht-funktionale - und alle Einflussfaktoren bekannt sein. Die Anforderungen ergeben sich aus der Differenz zwischen den Ist-Eigenschaften und den Soll-Eigenschaften. Anforderung = Soll - Ist; Sie müssen nicht nur bekannt und definiert sein, sie müssen auch vollständig dokumentiert sein. Nur dann können sie als Ausgangsbasis für eine Softwareentwicklung dienen. Das bedeutet z. B. bei einer Gerätesteuerung, daß alle Schnittstellen zu dem Gerät bzw. die Signale exakt beschrieben sind, und zwar mit Wertebereich, Genauigkeit, Häufigkeit und Toleranz. Bei Informationssystemen bedeutet dies die Beschreibung aller Interaktionen mit den Menschen, die das System bedienen, und aller Schnittstellen zu fremden Systemen - die Use Cases. Darüber hinaus müssen die betroffenen Datenbestände und deren Mengengerüst bekannt sein. Schließlich sind auch die Geschäftsprozesse, in denen die unktionen der Software vorkommen, zu beschreiben. In einem Informations- und Kommunikationssystem kommt es also darauf an, die Abläufe, die Datenbestände, die Datenflüsse, die Anwendungsfälle, die Schnittstellen, die beteiligten Betriebsmittel, die Verarbeitungsregeln und die Qualitätsanforderungen zu ermitteln. Erst dann ist die Ausgangsbasis stark genug, um ein Softwareprojekt darauf aufzubauen und den Umfang es besagten Projektes zu kalkulieren. Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 3