Leo Kouwenhouven en Joke Peek beschrijven in het Computable-artikel "Requirements: bezint eer ge begint" de belangrijkste basics van requirements en gaan vooral in op de rol van stakeholder(s). Het artikel blijft wat mij betreft een beetje steken in algemeenheden, maar geeft wel goed inzicht in de complexiteit van het requirementsproces.
Het belang van requirements wordt ondersteund met een verwijzing naar het klassieke Chaos Report van de Standish Group en de stelling dat zonder goede requirements eigenlijk geen goede oplossing mogelijk is.
Requirements worden onderverdeeld 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."
Binnen het requirementsproces is het volgens Kouwenhoven en Peek belangrijk voldoende aandacht te besteden aan de rol van de stakeholders. De rol van de stakeholders is cruciaal bij het achterhalen en verifiëren van de requirements. Belangrijke aandachtspunten zijn verder dat de relevante stakeholders al vanaf het beginstadium bij een project worden betrokken en zich bewust is van zijn verantwoordelijkheden ('ownership' van de requirements en daarmee verantwoordelijk voor het uiteindelijke eindresultaat!).
Bij het achterhalen van de stakeholders via een zgn. stakeholderanalyse moet ook worden gekeken of de getraceerde stakeholders ook daadwerkelijk een goede vertegenwoordiging zijn van hun achterban (incl. mandaat) en of hij of zij beschikt over de juiste kennis en (communicatie)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."
Kouwenhoven en Peek stellen dat bij de vaststelling van requirements stakeholders en requirements-engineers goed moeten (kunnen) samenwerken en beide partijen beschikken over de juiste vaardigheden. "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."
Volgens Kouwenhoven en Peek 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. (..) 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."
Kouwenhoven en Peek wijzen ook op het belang van een duidelijke scope van het project: "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."
Bron: Leo Kouwenhoven/Joke Peek, artikel "Requirements: bezint eer ge begint", Computable 29-07-2011
