Sinds het bestaan van it is de kwaliteit van it-toepassingen een issue. Er is veel energie gestoken in verbeteringen en behoorlijk wat bereikt op wat betreft methodieken voor ontwikkelen, testen en projectmanagement. Daarnaast ontwikkelt het aanbod zich naar een hoog niveau van volwassenheid. Paradoxaal genoeg draagt dit nog maar beperkt bij aan duurzame en dus kosteneffectieve it. “Wie een dramatische verbetering wil realiseren, moet investeren in de kwaliteit van de requirements”, stelt Tinus Vellekoop van Sogeti Software Control.
De cijfers liegen er niet om. 56 procent van bevindingen in projecten zijn terug te voeren op de requirements. Het oplossen van deze bevindingen beslaat 82 procent van alle tijd die wordt besteed aan bevindingenherstel. Als it-projecten worden stopgezet, ligt de oorzaak in 44 procent van de gevallen bij de requirements. Een ander opvallend fenomeen is dat slechts 54 procent van de oorspronkelijke requirements wordt gerealiseerd, en van dat deel wordt helaas maar 45 procent ook daadwerkelijk gebruikt door de eindgebruiker! Waar gaat het mis?
De zwakste schakel
Wanneer we deze problemen nader analyseren blijkt dat het probleem is terug te brengen tot, hoe kan het ook anders, onszelf. Ten eerste is het lastig om van tevoren precies uit te denken wat we willen. We maken ons over het algemeen meer druk om het oplossen van problemen dan om het voorkomen ervan. De dingen die we doen, doen we het liefst ook nog snel. Vaak wordt deze daadkracht ingegeven door druk uit de markt of de business. Daarnaast sluipen er gedurende het ontwikkelproces ook allerlei ‘afwijkingen’ in de software, omdat iedere discipline stand-alone werkt en zo haar eigen afwegingen maakt in de vrijheid die ontwikkeltrajecten bieden. Deze afwegingen zijn binnen de context van de disicipline vaak wel legitiem, maar geven niet altijd invulling aan de behoefte van de afnemers van de applicatie. Aan het eind van de rit blijkt de applicatie toch niet helemaal aan de eisen te voldoen. Achterhalen waar het precies mis is gegaan is dan heel lastig, maar de perceptie ontstaat dat het niet alleen om programmeerfouten gaat: een ongewenste situatie, zowel voor de continuïteit van de business als voor het imago van de it-afdeling. Dat laatste is op korte termijn niet zo’n probleem, maar aangezien het met grote regelmaat voorkomt, ondermijnt het uiteindelijk de positie en het bestaansrecht van de afdeling.
Requirements in soorten en maten
Toch is het mogelijk om een it-project tot een goed einde te brengen. Daarbij is de inrichting van een adequate requirements development en requirements management processen onontbeerlijk. Belangrijk daarbij is om een duidelijke definitie te hebben van wat requirements zijn. Karl E. Wiegers (auteur van het boek Software requirements) hanteert de volgende omschrijving: “A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide a value to a stakeholder.” Centraal in deze definitie staan de behoeften van de klant ten aanzien van een (it-)toepassing. In veel projecten is het inzicht in de behoeften van de klant ondergesneeuwd door de beschrijvingen van de oplossingen. Door het vervagen van de behoeften raken klanten het spoor bijster waar het gaat om grip te houden op it. Wil je bruikbare software implementeren, dan moet je bij het opstellen van requirements de klantwensen als vertrekpunt nemen. Daarnaast is het van belang om een samenhangende set requirements te definiëren waar zowel de opdrachtgever, de gebruikers, de engineers of pakketspecialisten, de beheerders én de testers mee uit de voeten kunnen. In de praktijk kom je een dergelijke set requirements nog maar weinig tegen. Besluitvorming, ontwikkeling en zelfs het testen gebeurt nog vaak op basis van verschillende, op zichzelf staande documenten die toch eigenlijk gemeenschappelijk moeten hebben dat ze de behoefte van de verschillende stakeholders weergeven.
Met alleen de introductie van het begrip requirements zijn we er nog niet. Er ligt ook een uitdaging in het hanteren van niveaus van requirements. We hebben het over requirements als een opdrachtgever een projectmanager duidelijk maakt wat hij verwacht van een project. Gebruikers en beheerders hebben het ook over requirements, maar dan in heel andere termen. Software engineers of pakketspecialisten vragen om nog weer andere en meer gedetailleerde informatie. Allemaal hebben ze het over requirements en allemaal hebben ze gelijk, maar toch praat men langs elkaar heen. Requirements zijn er van hoog naar laag, van globaal naar gedetailleerd, van generiek naar specifiek en dat voor veel verschillende aspecten. Het is daarom van belang om verschillende niveaus voor de requirements te hanteren.
De samenhang tussen niveaus van requirements is in de vorm van een piramide gevisualiseerd. De drie niveaus die we onderkennen zijn:
Business requirements
Deze geven antwoord op de ‘why‘-vraag: waarom is er behoefte aan een it-toepassing, welke doelen heeft de organisatie met het systeem?
User requirements
Deze geven antwoord op de ‘what‘-vraag: wat moet de gebruiker of in het algemeen de ‘stakeholder’ met het systeem kunnen doen?
System requirements
Deze geven antwoord op de ‘how‘-vraag: hoe een systeem ondersteuning bieden? (systeem is hierbij een ruim begrip)
Naast de verschillende niveaus wordt hier nog het onderscheid tussen functional en non-functional requirements benadrukt. In de praktijk blijkt nog steeds vaak dat er te weinig aandacht is voor vooral non-functional requirements. Deze blijken in 70 procent van de gevallen afwezig, te laat of onvoldoende concreet opgesteld te zijn. Voorbeelden van non-functional requirements zijn: performance, beveiligbaarheid, onderhoudsgemak en beschikbaarheid. Hierbij wordt vaak ten onrechte aangenomen dat dit ‘slechts’ de technische details betreft. Echter, non-functional requirements kennen we op alle niveaus; het zijn juist de non-functional requirements die op het niveau van business requirements het onderscheidend vermogen voor de business duidelijk maken.
De levensloop van requirements
De vaststelling van requirements op verschillende niveaus vergt een gestructureerde aanpak voor het verzamelen, analyseren, specificeren en valideren van de requirements. Daarbij moet rekening worden gehouden met het feit dat requirements niet statisch zijn, maar gedurende het proces kunnen wijzigen. Het is daarom van belang om, na het vaststellen van de verschillende requirements, het wijzigingen- en versiebeheer adequaat te verzorgen. De belangrijkste analyse in het kader van wijzigingenbeheer is de vaststelling van de impact op de samenhang tussen de requirements. Pas daarna volgt de vaststelling van de impact op het systeem en de consequenties van de wijzigingen op tijd en budget. Vanwege deze dynamiek van requirements spreken we over ‘requirements lifecycle management’.
Het ondersteunen van het requirements lifecycle management vraagt om inzet van een adequate requirements management tool. In een dergelijke tool leg je bijvoorbeeld per requirement de volgende gegevens vast: identificatie, versie, de beschrijving, prioriteit, status, bron, eigenaar en onderlinge relaties. Het bijhouden van deze requirementsattributen en vooral het onderhouden van relaties tussen requirements, waardoor bijvoorbeeld het bepalen van impact van wijzigingen mogelijk wordt, betekent dat het gebruik van Word of Excel voor requirements management geen serieuze optie is.
De meerwaarde van zo’n requirements management tool is ook gelegen in het feit dat het te koppelen is aan tools voor systeemontwikkeling, testmanagement en bevindingenbeheer. Dit maakt het beheer van het totale kwaliteitsproces een stuk efficiënter en eenvoudiger.
Door de requirements als fundament onder het ontwikkelproces te leggen en ze gedisciplineerd te managen wordt het grootste deel van de faalkosten in projecten voorkomen. Een ander voordeel is dat projecten realistischer kunnen worden begroot. Daarbij wordt het voor de it-afdeling mogelijk om zichtbaar te maken wat hun bijdrage is aan het realiseren van de businessdoelstellingen. Dit maakt bijvoorbeeld de discussie over outsourcen veel transparanter.
Uitbesteding
Offshoring en outsourcing zijn ‘hot’ op dit moment. Hoewel er een aantal overwegingen te noemen is waarom organisaties voor deze optie kiezen, gaat het toch vooral om kostenbeheersing en -besparing. De beoogde kostenbesparing gaat in de praktijk nog wel eens verloren omdat tijdens de ontwikkeling van de applicatie of het testen daarvan blijkt dat de requirements niet volledig of onvoldoende duidelijk zijn en vervolgens als wijziging of aanvulling worden behandeld. Het gevolg is dat er een omvangrijke kostenpost voor meerwerk ontstaat. Wie uitbesteding overweegt, doet er dan ook verstandig aan ter voorbereiding te investeren in het requirementsproces, temeer omdat outsourcen óók betekent dat de relatie tussen de business en it (klant en leverancier) verzakelijkt.
Voor wie zijn requirements gedisciplineerd opstelt en beheert, is de beloning groot. De perceptie is dat het in eerste instantie meer tijd kost, maar dat is niet altijd het geval. Belangrijker is dat steeds weer wordt bewezen dat de investering zich ruimschoots terugverdient, er minder faalkosten worden gemaakt, projecten beter stuurbaar zijn en de it-toepassing beter aansluit bij de behoefte van de klant.
Al met al ontstaat er een betere ondersteuning van de business door de it-afdeling. Door requirements te realiseren die daadwerkelijk bijdragen aan de doelstellingen van de business, wordt de business value hoger. Dat bepaalt tenslotte het rendement van it.
Tinus Vellekoop, manager Business Development bij Sogeti Software Control
