Een van de grootste faalfactoren in systeemontwikkeling is de onvolkomen manier waarop requirements worden vastgesteld. Zonder goede requirements geen goede oplossing. En zonder een goede definitie van de scope van het project en de rolverdeling en samenwerking tussen de betrokkenen geen goede requirements.
Requirements vallen uiteen in functionele en niet-functionele requirements. Functionele requirements zijn de eisen die de business aan de werking van het systeem stelt: wat moet het kunnen? Het gaat hier om functionaliteit die de organisatie in staat stelt haar werk te doen. De non-functional requirements beschrijven hoe het systeem moet werken en aan welke kwaliteitseisen het moet voldoen. Denk hierbij aan zaken zoals veiligheid, betrouwbaarheid, compliancy, compatibiliteit, beheerbaarheid en gebruikersvriendelijkheid.
Contract
Requirements zijn het contract tussen stakeholders en de realiserende partij. Missen er requirements, dan kan het eindresultaat wel eens niet het effect hebben wat beoogd was, en schiet het z'n doel voorbij. Dat een goede en complete set van requirements essentieel is blijkt wel uit nevenstaand staatje van The Standish Group.
Bij het achterhalen en verifiëren van de requirements is de rol van stakeholder cruciaal.
De stakeholder moet in een project goed weten waar hij aan toe is en wat zijn verantwoordelijkheden zijn. Bovendien moet hij al vanaf het beginstadium bij het project betrokken worden en doordrongen zijn van het belang van zijn input en zijn rol: hij heeft het ownership van zijn requirements en is daarmee mede verantwoordelijk voor het uiteindelijk eindresultaat. De stakeholder moet beseffen dat requirements expliciet, voor één uitleg vatbaar, moeten worden vastgelegd. Daarnaast moet de stakeholder inhoudelijk geëquipeerd zijn om de juiste input te leveren. Kortom: de stakeholder moet de juiste persoon zijn voor het proces.
Stakeholderanalyse
Om te toetsen of de stakeholder in staat is zijn taken uit te voeren moet een gedegen stakeholderanalyse uitgevoerd worden. Wie is de stakeholder en hoe verhoudt hij zich tot de organisatie? Vertegenwoordigt de stakeholder de business of alleen zichzelf? Is hij in staat goed te communiceren met zijn achterban en met de requirements-engineers? Heeft hij mandaat ?
Kan hij het alleen af? Beschikt hij over de juiste kennis en vaardigheden? Die analyse moet tijdig uitgevoerd worden. Stel dat het traject onderweg is en je komt erachter dat de stakeholder stelselmatig de verkeerde input op de verkeerde gronden heeft geleverd, of dat hij alleen namens zichzelf spreekt; dan is veel kostbare tijd verloren gegaan en kun je eigenlijk opnieuw beginnen.
De analyse zal soms een flinke knowledge/skills gap blootleggen ten aanzien van het functioneren van de stakeholder in het requirements-proces. Dat valt mede te verklaren door het feit dat organisaties meestal niet investeren in trainingen en opleidingen voor stakeholders; het budget gaat al op aan cursussen voor specialisten. En hoe goed de soft skills en hard skills van de requirements-engineers ook zijn, als de stakeholders niet hetzelfde niveau hebben wordt de vaststelling van de requirements een moeilijk verhaal. Dat is dan ook vaak de praktijk: stakeholders moeten meedoen in het requirements-proces, maar weten vaak niet wat er van hen wordt verwacht en wat ze van de requirements-engineers mogen verwachten. Opleiding kan stakeholders helpen hun verantwoordelijkheden duidelijk te maken, hun rol in te vullen en te voldoen aan de verwachtingen.
Samenwerking
Bij de vaststelling van requirements is het niet alleen van belang dat stakeholders en requirements engineers de juiste skills hebben, maar ook dat ze goed kunnen samenwerken. Immers: de stakeholders moeten samen met de engineers de requirements op papier zien te krijgen. De aanname van de stakeholder dat de requirements-engineer ‘de requirements wel begrijpt' en dat de betreffende requirements dus niet (of niet precies) hoeven worden vastgelegd leidt onherroepelijk tot een incomplete set requirements, een incompleet contract. Bovendien spreken requirements-engineers en stakeholders letterlijk een andere taal. Onder requirements-engineers zelf bestaat vaak al onenigheid over het gebruikte jargon, laat staan dat de stakeholders aan kunnen sluiten op die taal van de requirements-engineers.
Het resultaat: aan de ene kant heb je de requirements-engineers die op technisch niveau precies weten hoe de vork in de steel zit, maar eigenlijk geen idee hebben van wat de stakeholders precies verwachten en willen; aan de andere kant de stakeholders die het ontbreekt aan kennis van het proces waar ze inzitten en die niet in staat zijn hun wensen en eisen op het juiste detailniveau aan de requirements-engineers over te brengen.
Stakeholders en requirements-engineers moeten zich kunnen inleven in elkaars proces en moeten iets weten van wat de ander doet. De requirements-engineer moet in staat zijn de ‘vraag achter de wens' van de stakeholder bloot te leggen, de requirements achter de gevraagde oplossing; de stakeholder moet ervan doordrongen zijn dat ook de niet uitgesproken requirement cruciaal kan zijn.
Scope
Voordat je überhaupt kunt beginnen met requirements moet eerst de scope van het project duidelijk zijn. Wat beoogt de organisatie met de nieuwe oplossing? Aan de hand daarvan kun je bepalen welke requirements nodig zijn om dat doel te bereiken en welke niet. Het kan dan gebeuren dat stakeholders het moeten doen zonder allerlei nice to haves die misschien handig zijn, maar niet essentieel. Die scope ontbreekt vaak, laat staan dat het de stakeholders duidelijk is naar welk einddoel wordt toegewerkt. Stakeholders moeten met andere woorden de randvoorwaarden weten waarbinnen ze hun requirements kunnen formuleren. Dat verhoogt de kans op goede requirements.
Een kick-off aan het begin van het project is een uitgelezen middel om de scope en de verwachtingen aan beide kanten expliciet te maken. Zo'n sessie, waarin onder andere aan de orde komt waarom en hoe de requirements-engineers en stakeholders samen gaan optrekken, hoe de verantwoordelijkheden liggen en wat het gezamenlijke einddoel is, is cruciaal bij het behalen van een goed eindresultaat.
Ook in het verdere proces – van vaststelling van de requirements tot aan daadwerkelijke oplevering van het systeem – moet de voortgang doorlopend getoetst worden aan de vastgestelde scope. Voortschrijdend inzicht kan ervoor zorgen dat requirements alsnog worden geschrapt of toegevoegd, of zelfs dat de scope wordt bijgesteld. Hoe dan ook, er moet altijd een beeld bestaan van waar het proces heen moet.
Organisaties kunnen enorm besparen op tijd, geld en bemensing als het requirementsproces goed wordt ingericht. Het is daarbij van het grootste belang dat voldoende aandacht bestaat voor de rol van de stakeholders. Hun functioneren bepaalt of er in één keer een oplossing staat waarmee de organisatie uit de voeten kan.
Leo Kouwenhoven, product manager requirements-opleidingen Capgemini Academy
Joke Peek, trainer/senior consultant requirements-opleidingen Capgemini Academy
Een heel leuk verhaal over de business requirements die een belangrijk onderdeel voor een project voor Telepresence kunnen zijn. Ze passen prima in een van de deliverables van een project om tot implementatie van een wereldwijde oplossingen voor Telepresence te komen op basis van bij voorbeeld Polycom of Cisco (voorheen Tandberg).
Ik vind het wel opmerkelijk dat er over een requirements engineer wordt gesproken terwijl de eindverantwoordelijkheid voor het opleveren van requirements tot de taak van de senior user vanuit de stuurgroep (Prince2) behoort.
Aardige foto van een Cisco Telepresence ruimte!
Artikel is een kort uitreksel uit het boek ‘Mastering the Requirements Process’ van de Robertsons. Goed boek maar ik mis het stukje ‘opinie’ van de schrijvers.
Zelf werk ik via Agile, de rol van de stakeholder blijft cruciaal maar het ‘contract’ en ‘scope’ gedeelte van de Robertsons is bij agile weer minder toepasbaar.
Artikel geeft goed de pijnpunten aan tijdens veel requirementsprocessen. Maar volgens mij mist het 1 essentieel punt. Requirements worden veelal uitgeschreven in mooie documenten maar er is niemand die exact weet wat er gemaakt gaat worden, ook de requirements engineer niet. Laat staan dat hij hetzelfde beeld heeft als de stakeholder.
Iteratief werken kan dit pijnpunt gedeeltelijk oplossen maar volgens mij helpt maar 1 ding echt: visualiseren. Het zichtbaar maken van wat een (web)applicatie uiteindelijk gaat doen. Hierdoor ontstaat een eenduidig beeld en als positief effect is de stakeholder ook meer betrokken. Het is namelijk gemakkelijk en leuker om een simulatie door te kijken i.p.v. een dik document te scannen, reviewen, aan te vullen, etc.
Jammer dat in het stuk in de gedrukte Computable (29 juli 2011) de plaatjes ontbreken, terwijl er wel een verwijzing naar is.
Wat ik een beetje vreemd vind in het artikel is dat er regelmatig wordt gesproken over DE stakeholder. Juist omdat er zo veel belanghebbenden zijn en de besluitvorming in de vraagorganisatie vaak niet erg goed is geregeld, is het erachter komen wat de opdrachtgever wil en aan welke eisen van alle stakeholders samen uiteindelijk voldaan moet worden extra moeilijk.
Leuk stuk dus, met een grote kern van waarheid, maar de term en positionering van de stakeholder maken het voor mij toch wat mistig.