Slechte requirements kosten ‘zakken met geld’. Denk alleen maar eens aan herstelkosten, extra inhuur van medewerkers, uitloop of stopzetten van projecten en juridische procedures.
En hoe later in de ontwikkeling van een product een fout wordt ontdekt, des te duurder is het om deze te herstellen. Tot wel duizend maal meer wanneer een fout pas wordt gevonden in productie. Deze wetmatigheid werd al in 1978 aangetoond door Barry W. Boehm.
Maar zonder harde cijfers zijn managers vaak moeilijk te overtuigen om meer aandacht en prioriteit te geven aan het opstellen en toetsen van requirements. Zeker in tijden van crisis. Probleem is echter dat er vaak geen harde cijfers bijgehouden worden voor projecten in de eigen organisatie.
Om de kosten van slechte requirements toch snel inzichtelijk te maken hebben Tom King en Joe Marasco, op basis van heel veel data en statistieken uit de praktijk, een formule ontwikkeld voor software projecten (in een traditionele ontwikkelomgeving). Deze formule berekent wat het gemiddeld kost om één fout in de requirements te herstellen, die pas wordt ontdekt tijdens de systeemtest en/of acceptatietest.
Deze formule bestaat uit de volgende 6 stappen:
A.
Schat de hoeveelheid zuivere ontwikkeltijd- en kosten in, dus zonder herstelwerkzaamheden, projectmanagement en/of analyse tijd. Een vuistregel die je hiervoor kunt gebruiken is: Vermenigvuldig het totaal aantal verwachte schermen en rapportages in het eindproduct met vier werkweken (= ontwikkeltijd in weken) en vermenigvuldig dit met de gemiddelde weekkosten van één lid van het ontwikkelteam (= ontwikkelkosten).
B.
Schat het aantal verwachte gebreken in tijdens de testfase. Uit onderzoeken blijkt dat je gemiddeld voor elke week ontwikkeltijd één gebrek kunt verwachten. Kortom, het aantal te verwachten gebreken is gelijk aan de ontwikkeltijd in weken (= A).
C.
Schat het aantal gebreken in dat zijn oorsprong heeft in de requirements. Ga daarbij uit van tenminste de helft van al je verwachte gebreken (= 0,5 x B), want uit onderzoek van James Martin blijkt dat 56 procent van alle gebreken in software zijn oorsprong heeft in de requirements.
D.
Schat de kosten in voor herstelwerkzaamheden. Een vuistregel is dat projecten 30 procent van hun zuivere ontwikkelkosten (=A) nodig hebben voor herstelwerkzaamheden, ongeacht de oorsprong van de gebreken.
E.
Schat de herstelkosten in voor fouten in de requirements. Het herstellen van gebreken die hun oorsprong hebben in de requirements kost vaak meer dan andere gebreken. Uit onderzoek van o.a. het Chaos Report blijkt namelijk dat zij ergens tussen de 70 en 85 procent van de totale herstelkosten (=D) voor hun rekening nemen. Reken dus tenminste met 75 procent..
F.
Bereken nu de kosten voor één foutieve requirement, door de herstelkosten voor foutieve requirements (= E) te delen door het aantal foutieve requirements (=C ).
Een rekenvoorbeeld: Voor een project dat een applicatie ontwikkelt dat bestaat uit 25 schermen en rapportages en waarvan de gemiddelde weekkosten van een ontwikkelaar 2500 euro bedragen, zullen de totale herstelkosten voor vijftig fouten in de requirements zo’n 56.250 euro bedragen (op een bedrag van circa 250.000 euro aan zuivere ontwikkelkosten). Oftewel, in dit rekenvoorbeeld zal elke fout in de requirements die je pas ontdekt tijdens de testfase 1125 euro kosten (en later zelfs nog meer!).
Met deze formule kun je voor managers per project uiteindelijk heel concreet maken wat bij benadering de kosten zullen zijn van fouten in de requirements die je pas tijdens de testfase ontdekt. En dat dit dertig tot zeventig keer meer is dan wanneer je ze ontdekt voordat je begint met het bouwen van de applicatie.
Investeren in goede trainingen, processen en extra tijd voor het opstellen en vroegtijdig toetsen van requirements kost geld. Maar deze kosten zijn een fractie van de kosten voor het herstellen van slechte requirements die pas laat ontdekt worden.
Of met andere woorden,
“If you think good requirements are expensive, try bad requirements!”
(Analoog aan Joseph Yoder over architectuur)
Reacties zijn welkom!
@ Mirjam,
ik ben altijd gek op het kwantificeren van kwalificerende zaken, dat is zo iets als nauwkeurig willen rekenen met onnauwkeurige zaken……In die zin spreekt je verhaal me zeer aan, maar,
Wat je aan geeft in de stappen is denk ik iets voor de IT omgeving, maar niet voor een communicatie-infrastructuur omgeving. Heb je daar iets over, dan ben ik zeer geïnteresseerd.
Punt C roept een vraag bij me op:
– zijn de requirements slecht, of worden ze verkeerd geïnterpreteerd door degene die het moet implementeren?
Waarom ik het me afvraag: ik kan requirements opstellen, en deze laten reviewen door mijn collega’s waarna we na afloop er van overtuigd zijn dat we goede requirements hebben …. althans, als we het zelf zouden moeten implementeren.
Onze collega’s van de software afdeling, die de context kennen waarbinnen wij ons werk doen, zijn prima in staat op basis van deze requirements het juiste te maken.
Maar besluit de organisatie de implementatie uit te besteden naar een goedkope partij in verweggistan, dan kan ik je op een briefje geven dat we niet krijgen waarom we gevraagd hadden.
Ligt dit nu aan de requirements???
Mirjam,
Zoals Maarten al zegt wordt hier geprobeerd te rekenen met aannames waardoor dit eigenlijk niet meer dan een Monte-Carlosimulatie is. Niet meer dan ‘guesstimating’ dus, of zoals je zelf al zegt een formule die een benadering van de kosten geeft. Een formule die wel makkelijk te vangen is in Excel om zo meerdere simulaties te maken en de mediaan te bepalen.
Leuk verhaal maar het gaat een beetje voorbij aan het feit dat de meeste onder ons (zo niet iedereen) sowieso veel moeite hebben om precies te bedenken wat ze willen (zeker in complexere projecten). En ik denk dat het nog meer geld en tijd steken in het maken van betere specs alleen maar zal leiden tot nog uitgebreidere en gedetailleerdere beschrijvingen van dingen waar men eigenlijk helemaal niet op zit te wachten.
En dat brengt me ook gelijk bij punt C. Wordt zo’n “gebrek” inderdaad veroorzaakt doordat de developer de specs niet goed heeft geïnterpreteerd of heeft hij alles keurig volgens de specs gebouwd en was dit achteraf niet wat de klant wilde. In dat laatste geval is het natuurlijk geen bug maar een feature.
Als tijdens een project inderdaad veelvuldig interpretatiefouten worden gemaakt door de developers is, investeren in betere specificaties een prima idee. Maar als dit niet het geval is, zou het toch zeker de moeite lonen om een naar een meer agile aanpak te kijken waarbij er een snelle terugkoppeling is van fouten, zij het in de specs of in de uitvoering.
Daarnaast heb ik mijn vraagtekens bij de getallen die genoemd worden. Vier weken ontwikkeltijd (desnoods inclusief testen) vind ik erg veel. Ik heb succesvolle projecten in anderhalve maand gedaan en gelukkig waren we flink veel verder gekomen dan anderhalf scherm per ontwikkelaar. En als ik terug kijk naar alle projecten die ik gedaan heb, is die 4 weken erg hoog. Eén gebrek per week ontwikkeltijd vind ik daarentegen weer extreem laag maar misschien komt het ene wel voort uit het ander. Maar 4 weken voor een scherm inclusief debug tijd, is nog steeds erg riant.
uit de categorie goede requirements:
Ik ken veel bedrijven die blij zouden zijn als er “maar” 4 weken ontwikkeltijd nodig is voor een scherm. (LG, samsung, philips etc….)
Waarmee het artikel deels tegen haar eigen stellingname zondigt: de getallen en formule die genoemd worden is sector specifiek. Dit wordt echter nergens vermeld.
Een gemiddeld motor management systeem bijvoorbeeld zal weinig schermen laten zien….. Of zijn mensen die aan beeldverwerking doen waarbij beeldstromen van 50 fps gewoon zijn heel efficiënt; immers, zij kunnen in korte tijd héél veel schermen laten zien
Prima artikel, maar wel te kort om echt uit te leggen waar het om gaat.
Als een organisatie echt wil weten wat het kost als specificaties vaag blijven moeten ze maanden, zo niet jaren, meetgegevens verzamelen. Als ontwikkelaars in staat zijn om zelf de fouten in een ontwerp te herkennen dan helpt dat ook zeker. Ik heb projecten meegemaakt waar de ontwikkelaars feitelijk het ontwerp maakten omdat de Business Analisten en functioneel ontwerpers dat niet konden! Feit is en blijft dat een fout in productie herstellen minstens tien keer zo veel kost als meteen goed specificeren. Scrum en “Extreme Programming” zijn methoden waarmee de ontwerpkosten laag gehouden kunnen worden, maar de methode moet wel bij het team passen.
Dat sommige mensen hier aangegeven het artikel flauwekul te vinden geeft weinig hoop voor de toekomst. Sinds 1978 is er weinig geleerd en zo lang bedrijven ICT blijven bestempelen als bijzaak en vanuit de Business onvoldoende meewerken om correcte specificaties aan te leveren moet men niet zeuren dat ICT duur is!
In een tijd waar agile development key is kan de vraag worden gesteld waarom je moet gaan rekenen met verkeerde of foute requirements. Met Agile start je op basis van enkele requirements, werkt een maand en kijkt dan waar je bent om vervolgens te besluiten om wel of niet door te gaan.
Het voorspellen van de toekomst is tot nu toe niemand gelukt. Verder vraag ik mij nog af waarom bedrijven zelf software gaan ontwikkelen. Je moet heel goed naar principes kijken en op basis van je business architectuur besluiten of je wel of niet zelf gaat ontwikkelen. Ik kan mij eigenlijk weinig projecten herinneren die binnen tijd en budget de requirements opleveren.
@Willem
Interessante gedachtengang om telkens na een maand te kijken of je wel of niet verder gaat.
Hoe vaak krijg je dat “verkocht” aan je opdrachtgever?
Immers, die maand werk die verzet is zal toch ook betaald moeten worden neem ik aan?
@Pavake en Willem
Eerst denken dan doen is al een oud en wellicht vergeten gezegde, maar wel met een kern van waarheid.
Noch steeds gaat er in aanbestedingen het meeste mis door het negeren van dit al oude gezegde.
Mirjam, mooi artikel dat volstaat met vuistregels voor het maken van inschattingen. Een heel aantal herken ik ook wel en ook de uiteindelijke kosten per bug klinken me niet vreemd in de oren.
Ik vind helaas de conclusie dat dit aan foute requirements ligt iets tekort door de bocht. PaVeKa geeft ook al aan dat context en cultuur erg belangrijk zijn voor het goed begrijpen van requirements. De vraag is dan altijd of de requirements dan fout zijn. In mijn optiek kun je de requirements nooit goed opschrijven omdat ze altijd op meerdere manieren te lezen zijn. Meer tekst maakt het probleem dan alleen maar erger. Ik maak dan ook graag gebruik van een communicatiemethode die bevestiging en controlevragen mogelijk maken. Oftewel gewoon mondeling toelichten of uitleggen in plaats van een document op de mail zetten. De requirements analyst had namelijk niet verwacht dat iemand het op een andere manier zou lezen en de ontwikkelaar had nou eenmaal een andere context of cultuur.