Author: Marcel van den Bosch Date: 04-nov-2013
Wanneer duidelijk is welke richting de gekozen oplossing op gaat, kan worden gekeken wat de oplossing precies moet kunnen. Het proces om dit boven water te halen en dit te beschrijven noemt men Requirements Analyse. Dit is een belangrijke activiteit voor de informatieanalist en de business-analist.
Eisen en wensen zijn niet beperkt tot alleen IT-oplossingen. Zo zal in de bouwwereld een architect ook heel zorgvuldig naar de behoefte van zijn opdrachtgever moeten kijken, voordat hij kan beginnen met het ontwerpen van een nieuw te bouwen gebouw. De gedachte erachter is hetzelfde, maar in deze blogreeks richten we ons echter hoofdzakelijk op IT en bedrijfskundige oplossingen.
Wat zijn requirements?
Requirements vervullen een brugfunctie tussen de stakeholders uit de business en het ontwikkelteam. Ze beschrijven de eisen en wensen, die elke stakeholder aan het systeem stelt.
IEEE geeft de volgende formele definitie van een requirement: 1) a condition or capability needed by a user to solve a problem or achieve an objective. 2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or other formally imposed document. 3) a documented representation of a condition or capability as in (1) or (2)
Over het algemeen schept de IEEE definitie vaak wat onduidelijkheid, bij het uitleggen wat requirements nu zijn. Ik denk dat het handig is om in gedachte te houden dat requirements de eisen/wensen van een belanghebbende zijn.
Het belang van Requirements Analysis
Uit verschillende onderzoeken blijkt dat de oorzaak van een softwarefout in 60% van de gevallen te herleiden is tot een probleem met de requirements. Ook zijn de kosten voor het herstellen hoger wanneer we verder in het traject zijn.
Er is immers niets zo vervelend als tijdens de acceptatietest (of erger: wanneer het systeem al in productie is) te ontdekken dat bepaalde onderdelen verkeerd geïmplementeerd zijn of zelfs compleet over het hoofd zijn gezien. Het is dan hopen dat het allemaal wel mee valt, zodat je niet helemaal terug naar de tekentafel (ontwerpfase) moet. Dat zijn dan van die nare ‘oeps-momenten’.
Daarnaast is het in sommige bedrijfstakken ook van belang om een goede traceerbaarheid van requirements te hebben. De aerospace en de automotive (ISO 26262) industrie hebben bijvoorbeeld allerlei verplichte veiligheidsstandaarden, die meegenomen dienen te worden in het programma van eisen en wensen. Het zou immers bijzonder vervelend zijn wanneer bij een vliegtuigcrash, niet meer herleid kan worden of bepaalde veiligheidsstandaarden wel of niet zijn meegenomen.
Uit de praktijk: Hoort dit niet gewoon bij het offertetraject?
In het verleden heb ik regelmatig bij MKB bedrijven te horen gekregen dat er alleen voor softwareontwikkeling betaald kan worden. Het uitvoeren van een gedegen requirements analyse schaart men dan onder de offerte werkzaamheden, waarvoor men niet bereid is te betalen. Overigens, niets ten nadeel van MKB bedrijven, grote organisaties zijn natuurlijk ook dol op ‘free consultancy’.
Het is daarom van essentieel belang om de meerwaarde van een complete requirements analyse te onderstrepen en alle noeste arbeid die eraan verbonden is, niet zomaar gratis weg te geven. Het uitvoeren van een ‘quick-scan’ of ‘opportunity-scan’ - die globaal aangeeft wat de omvang van het vraagstuk is – zou passender zijn om tijdens een salestraject toe te passen
Afbakening
Om gericht de requirements van een nieuw te ontwikkelen systeem boven water te krijgen, moet eerst een afbakening gemaakt worden. Op die manier kan gericht worden gekeken naar onderdelen van de omgeving die invloed uitoefenen op het systeem. Bij de afbakening moet worden aangegeven wat de systeemgrens is en wat de grens van de context is.
De systeem grens bepaald welke delen tot het te ontwikkelen systeem behoren en welke tot de omgeving behoren. De delen binnen de systeemgrens kunnen worden veranderd tijdens het ontwikkelproces. De contextgrens geeft aan welke delen van de omgeving relevant zijn en welke niet van belang zijn. Immers, een systeem staat niet op zichzelf en moet vaak met de buitenwereld communiceren.
Elicitatie
Elicitatie is het boven water halen van de eisen en wensen van het te ontwikkelen systeem. Wanneer we weten wat de context is, kunnen we daarbinnen kijken naar bronnen voor requirements. Requirements kunnen afkomstig zijn van de volgende drie bronnen: 1) Stakeholders, 2 Documenten, 3) Systemen die al in gebruik zijn.
Er zijn verschillende technieken voor het in kaart brengen van de requirements. Het wel of niet toepassen van deze technieken hangt af van de specifieke situatie van de organisatie en de kenmerken van het project. Hieronder heb ik een lijst met de meest belangrijke soorten elicitatie-technieken gemaakt en met voorbeelden.
• Survey technieken
Deze technieken zijn met name geschikt voor het in kaart brengen van expliciete kennis. Voorbeelden zijn: Interviews, Enquêtes
• Creatieve technieken
Om tot innovatieve eisen en wensen te komen, kunnen creatieve technieken worden gebruikt. Voorbeelden zijn: Brainstorming, brainstorming paradox, verandering van perspectief, analogieën.
• Document-gerichte technieken
Dit soort technieken maakt gebruik van de kennis en ervaring van reeds bestaande systemen. Voorbeelden zijn: Systeem archeologie, perspectief-gebaseerd lezen, hergebruik
• Observatie technieken
Hiermee kunnen de requirements voor een niet gedocumenteerd bedrijfsproces worden achterhaald. Voorbeelden zijn: Veldobservatie, het meester/gezel principe (apprenticing)
Documenteren van requirements
Wanneer de requirements boven water zijn gehaald, is het van belang om deze zo zorgvuldig mogelijk te specificeren. Dit is belangrijk omdat ze de basis vormen voor de ontwikkeling van het systeem, maar ook om het systeem later in beheer te kunnen nemen. Verder kunnen er ook juridische situaties te bedenken zijn, waardoor het belangrijk kan zijn om de requirements goed gedocumenteerd te hebben.
Het documenteren van requirements kan op verschillende manieren worden bekeken. Soms is het nuttig om de structuur van gegevens vast te leggen. De relatie tussen klant en order is hier een voorbeeld van. Dit is informatie die erg belangrijk is bij de ontwikkelen van het systeem. Een ander voorbeeld is de order afhandelingsfunctionaliteit van een systeem, waarbij de verwerking van in/uitgaande informatie beschreven is.
Deze manier van het kijken naar requirements documentatie, geeft ons een drietal perspectieven. Vanuit het data perspectief, worden alleen de statische structurele aspecten van een systeem beschreven. Daarnaast hebben we ook het functionele perspectief, waarin de gegevens worden beschreven die door functies van het systeem worden gemanipuleerd. Tenslotte, hebben we ook het behaviorele perspectief. Hierin wordt gekeken naar de verandering van de toestand van het systeem. Dit naar aanleiding van verschillende gebeurtenissen (event).
Het daadwerkelijk vastleggen van requirements kan op de volgende manieren gebeuren:
• Op basis van de natuurlijke taal;
• Met behulp van conceptuele modellen;
• Een combinatie van beide;
Het meest eenvoudigst is het gebruik van de natuurlijke taal. Immers, iedereen kan in gewoon Nederlands zijn eisen en wensen beschrijven. Een groot nadeel hiervan is dat dit meestal niet altijd ondubbelzinnig is en er kan verwarring ontstaan.
Een oplossing hiervoor is het gebruik van conceptuele modellen. Een veel gebruikte modelmatige taal is Unified Modeling Language (UML). UML biedt een verzameling van structuur- en gedragsdiagrammen, die erg nuttig zijn voor het eenduidig vastleggen van requirements.
Validatie en onderhandelen
Tijdens het uitvoeren van een requirements analyse is het noodzakelijk om de kwaliteit van de opgestelde requirements te controleren. Daarnaast dient de stakeholder ook zijn goedkeuring te geven aan de opgestelde requirements, zodat zijn eisen en wensen juist zijn geformuleerd.
Enkele voorbeeldtechnieken voor het valideren van requirements zijn:
• Commentaar;
• Inspecties;
• ‘Walk-throughs’;
• Perspectief-gebaseerd lezen;
• Validatie met behulp van prototypes;
• Validatie checklists;
Het kan voorkomen dat verschillende stakeholders het niet eens kunnen worden over bepaalde requirements. De business-analist of informatieanalist moet dan zorgen dat er een consensus ontstaat over de manier waarop de betreffende requirement gedefinieerd dient te worden.
Requirements Management
Wanneer er een grote verzameling aan requirements aanwezig is, moet deze ook worden beheerd. Bij het managen van requirements, zorgt men ervoor dat de gedocumenteerde requirements (en relevante informatie hierover) beschikbaar zijn gedurende de gehele levensduur van een systeem.
Daarnaast valt onder requirements management ook de taak van het toewijzen van attributen aan requirements, het aanbrengen van prioriteit, en het zorgen voor traceerbaarheid. Tenslotte dient er ook versie- en wijzing beheer plaats te vinden.
Requirements – En nu?
Wanneer we kwalitatief goede requirements hebben opgesteld voor onze gekozen oplossingsrichting kunnen we verder. Voor een maatwerkoplossing, zal meestal een functioneel ontwerp worden opgesteld. Wanneer er voor een softwarepakket gekozen is, zal op basis van deze requirements een pakketselectietraject worden opgestart.