Phantomanforderungen
Jede Software hat einen eigentlichen Anwendungszweck – den Nutzen, den sie erfüllen soll.
Darüber hinaus ist es üblich, diesem Nutzen zahlreiche weitere Anforderungen hinzuzufügen, wie Wiederverwendbarkeit, Wartbarkeit, Änderbarkeit, Erweiterbarkeit, Testbarkeit, Code-Verständlichkeit, etc.
Diese nicht unmittelbar den Zweck betreffen¬den Anforderungen
- fügen einem Projekt zusätzliche Komplexität hinzu
- machen den eigentlichen Nutzen schwerer erreichbar und führen deshalb zu einem Verlust an Freude und Begeisterung
- beruhen nicht auf tatsächlichen sondern auf angenommenen oder befürchteten Szenarien; müssen alle möglichen Fälle abdecken, da der konkrete spätere Fall, falls er überhaupt eintritt, noch nicht bekannt ist.
Kennzeichnend für diese Art von Anforderungen ist, dass sie einen gewissen Stress auslösen. Man weiß eigentlich nicht, was genau man denn nun tun soll, um es zu erfüllen:
Wann ist etwas erweiterbar? Wieviel Erweiterbarkeit ist genug? usw.
Da – wie schon ausgiebig dargelegt – die Energie für die Entwicklung einer Software durch ihren Zweck bzw. Nutzen bzw. das WAS erzeugt wird, steht für diese Zusatzanforderungen keine Energie zur Verfügung, denn sie dienen nicht dem eigentlichen Zweck.
Umgekehrt werden spätere Zwecke, die mit anderen Versionen oder Varianten zu erreichen sind (und die im Moment noch reine Fiktion sind), sehr wohl Energie dafür zur Verfügung stellen, dass vorhandene Komponenten – falls geeignet – genutzt werden (durch Erweiterung, Änderung, Wiederverwendung). Der Aufwand verlagert sich dann von dem Projekt, das es nicht betrifft zu dem Projekt, das es tatsächlich betrifft. Und in diesem ist es auch kein Mehraufwand, sondern eine Abkürzung.
