Het belang van de juiste voorwaarden
Björn | 25 maart 2020
Björn | 25 maart 2020
Het succes van een project bij ByYoursite, is afhankelijk van de start van het project, zoals dat voor ongeveer ieder ICT-gerelateerd project geldt. Helemaal aan het begin van het traject worden namelijk de voorwaarden bepaald waar het project aan moet voldoen, of dit nu om een website gaat of een complete (cloud-)applicatie. In de ICT worden dit ook wel de ‘requirements’ genoemd.
Deze requirements moeten zo volledig en gedetailleerd mogelijk zijn ingevuld om goed te kunnen bepalen hoe het eindproduct van een project eruit moet komen te zien en wat de functionaliteiten zijn. Wanneer de requirements niet volledig zijn, zal een ontwikkelaar, op basis van zijn eigen ervaringen, aannames doen over wat de juiste functionaliteit of look moet worden. Deze kan afwijken van wat de opdrachtgever of klant wil, wat tot gevolg heeft dat het betreffende onderdeel opnieuw uitgevoerd moet worden, de klant een ontevreden gevoel heeft en het budget voor een project wordt overschreden. Met andere woorden, volledige requirements zorgen ervoor dat er minder aannames worden gemaakt en een project sneller kan worden gerealiseerd met de voor de opdrachtgever gewenste uitkomst.
Om tot volledige requirements te komen is het zaak dat alle stakeholders (alle partijen die belang hebben bij het project zoals opdrachtgever, ontwikkelaars, ontwerper en projectmanager) bij elkaar komen om gezamenlijk voor aanvang van het project tot in detail door te spreken hoe het eindproject eruit moet komen te zien en dit op te splitsen in onderdelen die tot in detail worden vastgelegd qua ontwerp en functionaliteit. Op die manier kan een ontwikkelaar de benodigde datamodellen en de benodigde functionaliteit per model bepalen.
Het analyseren, documenteren en valideren van deze voorwaarden wordt, omdat het een constructief proces betreft, ook wel ‘requirements engineering’ genoemd. Het doorlopen van dit proces behoort toe aan een rol, die van de requirements analist. Deze rol kan door de projectmanager worden vervuld, maar kan ook worden ingevuld door een ontwikkelaar.
Requirements engineering bestaat uit drie deelprocessen: elicitatie, specificatie en validatie.
Elicitatie: in het algemeen is de requirements analist geen expert in het domein dat hij moet analyseren. Door interactie met bijvoorbeeld een medewerker van de klant moet hij/zij zich een beeld vormen van wat daar speelt. Requirements elicitatie gaat dus over het begrijpen van het probleem.
Specificatie: Nadat het probleem is begrepen, moet het beschreven worden. Er zijn nogal wat technieken voor het vastleggen van requirements, variërend van informeel (door middel van taal en plaatjes) tot zeer formeel (wiskundig).
Validatie: Nadat het probleem is beschreven, moeten de verschillende stakeholders het eens worden. We moeten vaststellen dat de juiste voorwaarden zijn vastgelegd en dat deze voorwaarden juist zijn vastgelegd.
Omdat gedurende de looptijd van het project een ontwikkelaar of opdrachtgever tot een ander inzicht kan komen, is het vaststellen en documenteren van voorwaarden een iteratief traject.
Binnen ByYourSite maken we geregeld gebruik van de Scrum of Agile methode van ontwikkelen, wat betekent dat het gehele project in stukjes wordt gehakt en er in een korte periode van ongeveer 1 á 2 weken een stukje wordt opgeleverd. Na de oplevering van ieder stukje, een release, kan dus gekeken worden naar de requirements van de volgende release alvorens daar aan wordt begonnen.
Requirements engineering kent verschillende technieken om de voorwaarden te kunnen bepalen voordat deze vastgelegd worden. De technieken die wij bij ByYourSite het meest toepassen zijn een interview (met de opdrachtgever), een brainstorm met opdrachtgever en ontwikkelaar(s), user stories, wireframes en prototypes.
In een interview vragen we de opdrachtgever wat de huidige situatie is en wat de opdrachtgever wil. Het probleem is dat hieruit modellen ontstaan van impliciete aard die gewoontes, vooroordelen en inconsistenties kunnen bevatten. In een brainstorm of groepsdiscussie tussen opdrachtgever en ontwikkelaars kan het juist voorkomen dat enkele deelnemers de boventoon voeren, wat tot inconsistenties leidt. User stories beschrijven stapsgewijs en in detail de stappen die worden genomen om tot een specifiek eindresultaat te komen of taak uit te voeren. Wireframes zijn (enigszins) grafisch uitgetekende voorbeelden of ontwerpen van een deel van het te bouwen systeem of scherm.
Wanneer de opdrachtgever of ontwikkelaars onzeker zijn over de requirements kan worden besloten om prototypes te ontwikkelen. Beginnend met de aanwezige requirements wordt een uitgeklede maar functionele versie van het systeem ontwikkeld waarna met de ervaringen uit het prototype verder wordt gebouwd naar de volgende versies tot het systeem is uitgegroeid tot het volwaardige product waar de opdrachtgever naar zoekt.
Al het bovenstaande moet leiden tot een levend document waarmee de ontwikkelaars kunnen hanteren om te bepalen wat er exact gebouwd moet worden en waar het systeem aan moet voldoen om exact overeen te komen met de wensen van de opdrachtgever.
Nog voordat een project echt begonnen is, is een van de belangrijkste onderdelen van het project al gestart. Wanneer de requirements correct zijn vastgelegd en de juiste requirements helder zijn heb je een grotere kans dat aan het eind van het traject aan alle gewenste voorwaarden van het project kan worden voldaan.
