Im Zusammenhang mit Anforderungen sind die Funktionen eines Systems zentral. Auch blosse Eigenschaften können Funktionen sein. In Zertifiziert für das Unmögliche: Anforderungen formulieren habe ich gesagt, dass in Migrations- und Integrationsprojekten meistens Standardsysteme zum Einsatz kommen, die allenfalls customized werden. Solche Projekte können nicht vollständig spezifiziert werden, weil niemand in der Lage ist, alle Funktionen eines (Standard-)systems zu kennen. Denken Sie z.B. an ein Automobil, genauer gesagt, einen Personenwagen (PW). Glauben Sie, sie könnten die Funktionen eines PW aufzählen? Wahrscheinlich sind Sie nicht einmal in der Lage, auch nur 10% aller Funktionen eines PW aufzuzählen, und dies nicht nur wegen des Problems unterspezifizierter Initialkonditionen, von dem Fischhoff et al. berichten1. Es gibt immer auch hidden functions. Klaus Pohl berichtet, dass allein die Steuerung einer PW-Elektronik 2’500 Funktionen umfasst2. Jede dieser Funktion ist auch eine Funktion des PW. Natürlich interessieren Sie sich allenfalls für ein halbes Dutzend dieser Elektronikfunktionen, der Rest sind eben hidden functions, mit denen Sie sich gar nicht erst auseinandersetzen wollen. Aber können Sie sicher sein, dass sich nicht eine dieser 2’500 Funktionen für Sie negativ manifestieren wird? Es könnte doch sein, dass sich eine dieser unzähligen Funktionen mit der Zeit für Sie als lästig bemerkbar machen wird. In vollständigen Anforderungen an das System PW hätten Sie diese Funktion ausdrücklich untersagt, wenn Sie sie im Voraus gekannt hätten. Hidden Functions von IT-Systemen, die in komplexe Umgebungen eines informationsintensiven Unternehmens integriert werden müssen, stören oft andere Systeme, weil die Entwickler nicht alle Umgebungen kennen konnten, in welchen ihr System jemals in Einsatz gelangt.
Im übrigen gibt es Funktionen, die eigentlich Funktionenkomplexe sind. Beispielsweise ist doch die wichtigste Funktion eines PW, dass er fahren möge. Meinen Sie „fahren“ oder „transportieren“? In jedem Fall verbirgen sich hinter beiden Funktionenkomplexen viele Einzelfunktionen, wie z.B. vorwärts fahren, rückwärts fahren, im Schritttempo vorwärts fahren, sehr schnell vorwärts fahren. Meinten Sie „transportieren“, so sind Einzelfunktionen eine Person transportieren, mehr als eine Person transportieren, im Rahmen des Strassenverkehrsgesetz transportieren, Waren transportieren, mehr als einen Kubikmeter Waren transportieren, usw. Die Unterteilung eines Funktionenkomplexes ist sehr willkürlich. Wann haben Sie hinreichend unterteilt? Wann haben Sie zu sehr fragmentiert? Was ist überhaupt noch eine Funktion? Schliesslich gibt es Sekundärfunktionen. Z.B. kann ein PW auch die Funktion haben, Ihnen gesellschaftliches Ansehen zu verleihen, oder zumindest Ihnen den Eindruck zu geben, dass Sie wegen Ihres PW zu mehr gesellschaftlichem Ansehen gelangen.
Ein System kann auch implizite Funktionen haben. Das sind solche, die niemand spezifiziert und entwickelt hat. Alle die 2500 Funktionen der Elektroniksteuerung mussten einzeln spezifiziert und implementiert werden. Auch die Funktion, gesellschaftliches Ansehen zu verleihen, wurde zumindest teilweise explizit spezifiziert, z.B. durch ein schnittiges Design oder durch entsprechendes Marketing. Ein Porsche kostet nicht nur so viel, weil er wirklich so gut ist, sondern auch, um eben den Namen Porsche als Nobelmarke zu platzieren. Aber ein PW kann auch Funktionen haben, die nicht spezifiziert worden sind.
Wie wir sehen ist es nie möglich, abschliessend zu sagen, wieviele Funktionen ein System hat oder haben kann. Bye, bye Requirements Engineering!
1B. Fischhoff, P. Slovic & S. Lichtenstein. Fault Trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of experimental psychology: Human Perceptions and Perfomance. 4/1978, 330-334
2Klaus Pohl. Leitfaden für modellbasiertes Requirements Engineering und Requirements Management softwareintensiver Eingebetteter Systeme
gefördert durch das BMBF im Rahmen der Forschungsoffensive „Software Engineering 2006“