Eisenanalyse, formuleren en begrijpen

Eisen zijn een wezenlijk onderdeel van het specificeren. Hier wordt veel aandacht aan besteed. Eisen vormen de schakel tussen behoefte en oplossing, of vraag en activiteit. Actie, reactie dus. Hoe duidelijker de eis, hoe groter de slaagkans van uitvoering. Hoe beter de formulering was, hoe minder gedaan hoeft te worden om de vraag/eisen te begrijpen, interpreteren.

Vandaar dat de formulering en het lezen, begrijpen van de eisen in 1 hoofdstuk zijn geplaatst. Waar bijvoorbeeld de eisen niet duidelijk geformuleerd zijn, dient de ontvanger, de lezer dit nog te doen. De aanpak is wel zodanig geformuleerd dat de opsteller de verantwoordelijkheid draagt voor het stellen van een begrijpelijke en haalbare vraag.

Eisen komen voort uit diverse bronnen. Voorbeelden zijn de stakeholders, wet- en regelgeving, normen, standaarden en overige kennisbronnen. De klanteisenspecificatie (KES) is de eerste vorm van een verzameling van eisen voor een project. Om de KES te ontwikkelen, wordt de conceptfase doorlopen met diverse planprocedures en (doel)analyses. Nadien worden eisen meer afgeleid van ontwerpkeuzes en de daarboven liggende eisen tijdens de systeemontwikkeling.
De eisen zijn te typeren als:

• functie-eisen betreffende het gewenst gedrag, de basisfunctionaliteit;
• aspecteisen betreffende de op de basisfunctie-eis aanvullende kwaliteiten, de ondersteunende functies;
• proceseisen betreffende kwaliteitverwachtingen aan (deelnemers van) het proces;
• raakvlakeisen (intern en extern), betreffende eisen tussen rakende functies, activiteiten of objecten.

Specifieke objectgerelateerde kwaliteiten, zoals de maatvoering, komen voort uit de functies of aspecten en worden objecteigenschappen genoemd.
Het verzamelen van eisen en deze typeren en structureren, is een eerste stap.

Bij het verzamelen en formuleren van eisen is het essentieel goed in de gaten te houden waar het om gaat en waar een eis vandaan komt. Waarom stel je een eis? Kun je hem weglaten? En zo niet: geeft hij precies aan wat nodig is om de doelen van de belanghebbenden te vervullen? Bij de aanpak wordt onderscheid gemaakt tussen het formuleren en het interpreteren, begrijpen van de eis en mogelijke herformulering. In hoofdzaak worden deze stappen onderscheiden. Hierbij is een volgorde aangegeven, maar is het vaak nuttig een iteratieve aanpak toe te passen. Zo kan het zijn dat je eisen eerst moet groeperen, voordat je ze expliciet kunt maken.

We onderkennen de volgende zes stappen, verdeeld over twee hoofdgroepen:

1. Eisen formuleren

   1	Bronnen verzamelen en eisen verzamelen.
   2	Eisen expliciet maken, SMART, eisen aan eisen.
   3	Eisen structureren, groepen herkennen, alloceren en typeren.
   4	Compleetheid en haalbaarheid eisen toetsen. Aanvullend: verificatie- en validatieplan opstellen per (groep) eis(en) (zie hoofstuk 11).

2. Eisen ontvangen, lezen, interpreteren en mogelijk herformuleren

   5	Eisen begrijpen.
   6	De kwaliteit en actualiteit van eisen en V&V-plan controleren.

Stap 1 Bronnen verzamelen en eisen verzamelen
Naast het afleiden van eisen vanuit de gedefinieerde doelen van de stakeholders en de gevraagde waarde voor de oplossing, kunnen eisen ook verborgen zitten in allerlei documenten. Voor het opstellen van een goed afgewogen KES en vervolgspecificatie, is het van belang al deze verborgeneisenbovenwatertehalen.

Een voor de hand liggende methode om aan de juiste eisen te komen, is het overnemen van eisen uit soortgelijkeprojecten.Belanghebbendenmoetendanalwel voldoende duidelijk hebben gemaakt wat hun vraag is. Ook moet bij deze werkwijze elke over te nemen eis nadrukkelijk tegen het licht worden gehouden. Controleer daarom steeds of de eis goed en passend is geformuleerd en stel zo nodig de formulering bij.

Vanzelfsprekend worden ook documenten, rapporten en dergelijke gebruikt die voorafgaand aan of in een eerdere fase van het lopende project zijn verschenen. Daarnaast kunnen eisen worden ontleend aan documenten uit andere projecten en zelfs aan documenten die buiten enig projectverband zijn ontstaan, zoals een artikel in een vaktijdschrift. Overige documenten waar voorwaarden aan kunnen worden ontleend, zijn bijvoorbeeld documenten met een eisend karakter. Denk aan de Tracéwet, ontwerpvoorschriften, nationale en internationale normen; hier worden de relevante randvoorwaarden uit gehaald. Voor een infrastructureel bouwproject loopt het aantal vaak in de tientallen.

Aandachtspunten bij de methode zijn:

• Neem eisen niet zonder meer over. Zo kan het noodzakelijk zijn om een goed geformuleerde eis uit een eerder project toch opnieuw te formuleren, bijvoorbeeld omdat de (project)context verschilt.
• Verwijzingen naar documenten moeten specifiek zijn. Verwijs daarom niet naar documenten als geheel! Zo’n eis wordt namelijk geïmporteerd in de specificatie. Hiermee wordt de specificatie op zichzelf staand.
• Als de tekst uit het brondocument wordt aangepast om te kunnen worden opgenomen in de specificatie, bestaat het gevaar van interpretatieverschillen. De relatie met het brondocument wordt dan onduidelijk.
• Als de tekst van het brondocument niet voor slechts één uitleg vatbaar is (ofwel niet ‘eisrobuust’ is), moet de eis alsnog opnieuw geformuleerd worden. Dit is de overgang naar stap 2, eisen expliciet maken.

Belangrijk is om steeds goed te weten waar een eis vandaan komt. Ook moet een eis zo worden geformuleerd dat hij precies aangeeft wat onmisbaar is. Hierbij geldt dat een volgende discipline zoveel mogelijk vrijheid moet krijgen om optimale oplossingen (ontwerp, constructie, materiaal) te bedenken. In principe geldt: hoe meer eisen, des te minder vrijheid om optimale oplossingen te bedenken.

Stap 2 Eisen expliciet maken, SMART, eisen aan eisen
Goede eisen moeten voldoen aan bepaalde uitgangspunten, de eisen aan eisen genaamd (zie bijlage I). Het betreft dan niet alleen de inhoud, maar tevens de stijl, de formuleringswijze. Hierbij is het SMART-principe een eerste stap, de volledige set eisen aan eisen is groter.

Zoek een goede balans, pas minimaal het SMART-principe toe en wees nauwkeuriger indien dit van belang is, bijvoorbeeld voor risicovolle of doelstellingsgerelateerde eisen. Inleidend noemen we een drietal randvoorwaarden aan eisen, die door middel van het SMART-principe kunnen worden gewaarborgd.

Een heel belangrijke eis aan een eis is dat deze zo geformuleerd is dat deze niet voor meer dan één uitleg vatbaar is of zelfs onbepaald is. Wie de ontvanger ook is, de vraag moet niet multi-interpretabel zijn. Dit is makkelijker gezegd dan gedaan, maar hieraan aandacht geven vergroot de kans van slagen. Vooral bij aanbestedingen is dit van belang vanwege het gelijkheidsbeginsel, het geven van gelijke kansen aan inschrijvers.
Deze interpretatierobuustheid moet zoveel mogelijk contextvrij zijn. Daarmee wordt bedoeld dat de betekenis van de eis niet staat of valt met de betekenis van andere eisen. Eisen moeten als het ware gezien worden als bouwstenen (variabelen) met een zo groot mogelijke vrijheid van plaatsing. Zulke vrijheid bestaat bijvoorbeeld niet bij zinnen die je uit een lopende tekst haalt.

Om niet vooruit te lopen op het ontwerp, moet de eis zoveel mogelijk oplossingsruimte bezitten. Dit is moeilijk, want vaak bestaat al een idee of zelfs (vermeende) zekerheid over de oplossing voor het ontwerp. Dan is het heel verleidelijk om die oplossing alvast te vangen in de eis.

Als derde randvoorwaarde moeten eisen traceerbaar zijn. Hanteer hiertoe de volgende uitgangspunten:

• Leg relaties vast. Dit dient om verwarring te voorkomen bij het ontstaan van specificaties (dus bij het afleiden en toewijzen van eisen).
• Rechtvaardig de eisen waarop de eerste ontwerpslag is gebaseerd (geschiedenis, achtergrond, verantwoording en besluitvorming).
• Rechtvaardig de eerste ontwerpslag door te valideren dat de oplossing binnen de oplossingsruimte valt.

Wijs een team aan dat de eisen categoriseert en toewijst aan verschillende disciplines. Deze groep van mensen (dit kan een relatief kleine groep zijn) wijst de eisen toe aan een of meerdere disciplines. Hiervoor wordt het RACI-principe (Responsible, Accountable, Consulted, Informed) toegepast. Hierbij geldt dat als een eis aan meerdere disciplines wordt toegekend, de disciplines de volgende rol kunnen hebben: Het doel van de rollen is het voorkomen van conflicterende interpretaties of de uitwerking van verschillende oplossingen. De disciplines hebben zo ook een duidelijk beeld van de eisen die aan hen zijn toebedeeld; daarnaast hebben ze een gestructureerde en traceerbare methode voor het escaleren van aandachtspunten en risico’s.

Bij het formuleren van eisen wordt vaak de term SMART gebruikt. Deze letters staan voor:

• Specifiek: is de eis eenduidig omschreven?
• Meetbaar: bij welke kwaliteit wordt aan de eis voldaan?
• Acceptabel: gaan de actoren de eis accepteren?
• Realistisch: is de eis (in combinatie met andere eisen) haalbaar?
• Tijdgebonden: op welk(e) moment(en) moet de eis bereikt zijn?

Het ‘SMART-principe’ wordt veel gebruikt bij projectmanagement in zowel de private als de publieke sector. Wanneer mensen praten over eisen ‘SMART maken’ of ‘SMART formuleren’, bedoelen ze dat de eisen specifiek, meetbaar, acceptabel, realistisch en tijdgebonden moeten worden geformuleerd. Hierna wordt elk kenmerk nader toegelicht.

Een eis mag niet vaag en algemeen geformuleerd zijn, maar moet juist heel nauwkeurig en concreet zijn benoemd. Hij moet een waarneembare actie, een gedrag of resultaat beschrijven waaraan een getal, bedrag, percentage of ander kwantitatief gegeven verbonden is. Kortweg, het moet iedereen duidelijk zijn waar het om gaat.

Om te kunnen nagaan of eisen bereikt worden, moeten ze meetbaar zijn. Er dienen dus normen te worden vastgelegd. Het is immers belangrijk om bij verificatie- en validatiemomenten objectief te kunnen vaststellen of aan de eisen is voldaan. De toetsbaarheid kan betrekking hebben op kwantiteit, kwaliteit, tijd, geld, enzovoort. Meetbaar betekent ook dat eventuele toleranties worden aangegeven. Deze zijn vaak afhankelijk van de beschikbare meetmethoden of mogelijkheden tijdens de realisatie. Het kan dus zijn dat ook de meetmethode moet worden beschreven.

Eisen moeten geaccepteerd worden door de belanghebbenden in het project. Daarnaast is het belangrijk dat ze passen binnen beleids- en organisatiedoelstellingen.

Bij het bepalen van eisen is het nuttig ook stil te staan bij de haalbaarheid en realiseerbaarheid ervan. Als eisen te hoog zijn, is het niet mogelijk ze te halen. De lat van eisen mag best wat hoger liggen dan normaal, een prikkel is gezond, maar het moet wel een realistische prikkel zijn. Kijken naar de haalbaarheid van unieke eisen is dan niet voldoende. De eigenlijke beoordeling vindt plaats door haalbaarheidscontrole van de integrale set eisen in een (productie)keten. “Kan de markt dit aan?”. Deze vraag beantwoord je dan.

Er wordt een bepaald tijdstip vastgelegd waarop aan een eis moet zijn voldaan. Bijvoorbeeld bij een tussentijdse verificatie, een oplevering of aan het einde van het meerjarig onderhoud. Bij voorkeur wordt een tijdlijn opgesteld waarop wordt aangegeven wanneer aan (tussentijdse) eisen moet zijn voldaan. Er worden dan scenario’s bedacht op een bepaalde waarde, waar ‘pijlstokken’ in worden gehangen op relevante momenten. Dit zijn dan de tijdstippen, in combinatie met de gewenste waarde, waarop de eis wordt beoordeeld. Dit is input voor je verificatie-envalidatieplan.InUAV-GC-projecten komt daarbij dat dit input is voor de annex Toetsing en Acceptatie (zie deel C).

Door het SMART-principe te hanteren, kom je bij een eerste formulering al dicht bij een juiste formulering. De simpele vaststelling dat de eisen SMART moeten zijn, is echter niet voldoende. Wanneer is een eis optimaal geformuleerd? Welke eisen worden gesteld aan eisen? De criteria ‘eisen aan eisen’ waarborgen de eigenschappen waaraan een eis moet voldoen. Het opvolgen van de criteria is slechts een hulpmiddel om eisen te formuleren. De criteria zijn ingedeeld in vier rubrieken, te weten inhoud, vorm, context en traceerbaarheid. Deze criteria zijn opgenomen in de bijlage ‘eisen aan eisen’.

Stap 3 Eisen structureren, groepen herkennen, alloceren en typeren
Overzicht bewaren en wijzigingen kunnen beheersen, dat is het doel van deze stap. Het is gericht op eisenmanagement. Het structureren en alloceren helpt daarbij om overzicht te creëren. Het typeren helpt om nuttig onderscheid te maken tussen eisen. Hoe doe je dit nu in een iteratief specificatieproces? Voordeel van het iteratieve proces is dat eisen niet uit de lucht komen vallen, maar dat ze ontwikkeld worden op basis van een behoefte, analyse. Je kent dus de reden, de achtergrond van de eis. Je weet dus ook waarmee een eis samenhangt, zowel met betrekking tot het onderwerp waarop de eis zich richt (object, activiteit, functionaliteit...) als de hiërarchie. Welke eis is bovenliggend aan, of voorganger, initiator van? Welke eis volgt uit deze eis, ofwel welke eis is onderliggend?

Moeilijker is het als er een lijst is van eisen die nadien gestructureerd moet worden. Dan worden vragen gesteld als:

• waarom? (het vinden van de functie);
• waartoe? (het vinden van het object, activiteit);
• naar aanleiding van wat? (het vinden van de bovenliggende eis, doel).

Om te groeperen en te structureren, moet onderscheid worden gemaakt en samenhang worden gezien. Onderscheidende zaken worden uiteengerafeld en getypeerd. Het typeren van eisen heeft als idee dat elk type eis vraagt om een omgangsvorm, namelijk:

• Functie-eisen zijn hard, gekoppeld aan het primaire bestaansrecht van het systeem.
• Aspecteisen zijn zachter, de ene meer dan de andere. Er wordt waarde aan gehecht door een of meerdere stakeholders. Het is dus stakeholdersafhankelijk.
  Bij bijvoorbeeld een onhaalbare set aspecteisen dient ergens de lat lager te worden gelegd. Typeren van aspecteisen heeft als aanvullend doel de aspectsysteemanalyse te kunnen doen.
• Proceseisen zijn gericht op beheersing van de integrale aanpak die hier wordt aangeboden. Bij slechte procesbeheersing zijn ze schadelijk voor het project, maar wellicht ook voor het organisatorische imago en het imago van de sector als geheel.
• Externe raakvlakeisen zijn belangrijk voor de afstemming met de omgeving; dit is waar de ‘buurt’ op let. Ze zijn dus belangrijk in het kader van omgevingsmanagement en communicatie.
• Interne raakvlakeisen zijn belangrijk voor de afstemming tussen disciplines. Ze worden geborgd in werkafspraken of leverantiespecificaties. De kritische raakvlakeisen kunnen worden gevonden met behulp van de N² chart analyse, die hier niet verder is beschreven.
• Objecteisen zijn eisen die betrekking hebben op unieke eigenschappen van een gekozen oplossing. Bij wijziging van die keuze kunnen deze eisen, mits goed getypeerd, komen te vervallen.

Het structureren van eisen kan door middel van structuren; veelvoorkomende zijn hiërarchische ‘boom’structuren, in dit geval de eisenboom (RBS, Requirements Breakdown Structure). Van belang is de relatie met de aanleiding vast te houden, bijvoorbeeld een functie en ook hetgeen waar de eis zich op richt, bijvoorbeeld een activiteit. Er wordt dus samenhang, relaties aangegaan met andere structuren, bijvoorbeeld de objectenboom (SBS, System Breakdown Structure) of de activiteitenboom (WBS, Work Breakdown Structure). Let wel, het structureren dient om overzicht te creëren, samenhang en omissies in eisensets te vinden. Het is geen doel op zich. En: als je het doet, doe het dan goed. Ga geen combinatiebomen maken van bijvoorbeeld de objecten en activiteitenboom. Gebruik van ICT-ondersteuning is een vrijwel zekere voorwaarde. De ICT-ondersteuning is gericht op onderscheidende informatie scheiden en relaties aangaan. Bij kwalitatief goede structuren kunnen, afhankelijk van de behoefte, door middel van queries doorsnedes worden gemaakt zonder de datastructuur te hoeven aanpassen. De dataset kan in de faseovergangen meegaan; zo heeft de beheerder steeds inzicht in uitgangspunten. Hierbij kan gewerkt worden met ‘bevroren’ informatie, de baselines (zie deel A).

Stap 4 Compleetheid en haalbaarheid eisen toetsen
Is de eisenset (bijvoorbeeld de KES of vraagspecificatie UAV-GC) compleet? Is er ook een antwoord mogelijk, ofwel is het geheel haalbaar? Geen eenvoudige, maar wel zeer legitieme vragen. Er zijn hulpmiddelen voor deze toets; de eerste is gezond verstand en deskundigheid. Daarnaast zijn er meer analytische methodieken, gebaseerd op de typering van eisen. Een korte uitleg:

• Ga na welke doelstelling(en) er worden nagestreefd. Zoek in de hiërarchie de eisen die rechtstreeks gekoppeld zijn aan dit doel. Beschouw de kwaliteit daarvan door je af te vragen “Wordt het (klant)doel hierdoor behaald?”.
• Ga na welke processen je verwacht/wilt. En beschouw de groep (selectie, door middel van bijvoorbeeld een query in een database) proceseisen. Stel je per proces nog eens de vraag of de eisen voldoende waarborg geven aan beheersing van deze processen.
• Ga na welke basisfunctionaliteit(en) het systeem moet leveren. Selecteer de functie-eisen en stel jezelf de vraag “Wordt hierdoor aan de functie voldaan?”.
• Ga na op welke aspecten er wordt gestuurd (bijvoorbeeld beschikbaarheid). Selecteer de aspecteisen van het betreffende type (beschikbaarheid) en stel jezelf de vraag “Wordt hiermee voldoende waarborg gegeven aan de doelstellingen waarop wordt gestuurd?”.
• Controleer de overige aspecten. Maak een lijst met aspecten die van belang worden geacht en zoek naar de selectie van aspecteisen die hierop betrekking hebben. Stel jezelf vervolgens de vraag “Is aan elk aspect voldoende aandacht gegeven, wordt niet ergens een ondergrens overschreden?”.
• Selecteer de externe raakvlakeisen. Beschouw of elke externe stakeholder minstens één ingaande en één uitgaande eis kent. Controleer daarnaast aan de hand van de stakeholdersanalyse of elke stakeholder voldoende waarborg heeft gekregen. Stem dit bij twijfel nog af met de stakeholder.
• Beschouw de interne raakvlakeisen per abstractieniveau. Dus eerst op deelsysteemniveau, daarna dieper liggend. Beschouw per niveau of de interactie tussen onderdelen van het systeem voldoende is geborgd. Hiervoor geldt de vraag ‘Functioneert dit onderdeel in zijn context?’. Eventueel kan een aanvullende functie-analyse nog uitkomst bieden.

Stap 5 Eisen begrijpen
Begrijpen we de eis? Relevant als je antwoord moet geven op de eis. Deze basisvraag kunnen beantwoorden, is de proof of the pudding van de kwaliteit van eisen. Uiteraard gaan we ervan uit dat als we stap 1 t/m 4 goed doorlopen, deze kwaliteit geborgd is. Toch kan het een assumptie zijn die niet waar is. De vraagsteller kan bijvoorbeeld geen rekening hebben gehouden met de perceptie van de lezer. Voor een vraagsteller is het dus van belang zich te verplaatsen in de lezer. Dit is nog niet eenvoudig als er heel veel lezers zijn met diverse achtergronden (geldt ook voor de schrijver van dit boek...). Toch kan worden gezegd dat de SMART- en formuleringsprincipes de kans vergroten dat de vraag wordt begrepen, ongeacht de lezer. Het is uiteindelijk aan de lezer om dit te beoordelen (net als u voor dit boek..., laat het ons weten).

Welke vragen moeten we ons stellen om de begripsvraag te kunnen beantwoorden?

• Weten we om welk (deel)systeem het gaat?
• Kennen we het probleem dat opgelost moet worden?
• Kennen we de doelstellingen?
• Sluiten de eisen aan op de doelstellingen?
• Is de vraag compleet (zie ook stap 3) vanuit het lezersperspectief?
• Begrijp ik het nu?

Dit laatste kun je borgen door je interpretatie van de eis te toetsen bij de vraagsteller.

Stap 6 De kwaliteit en actualiteit van eisen en V&V-plan controleren
Wanneer eisen niet worden begrepen, kan dit een gevolg zijn van slecht geformuleerde eisen. Het is dan zaak de kwaliteit van deze eisen te verbeteren door ze te herformuleren. Hiervoor kunnen stap 2 t/m 4 worden ingezet voor de betreffende eisen. Naast de kwaliteit van eisen is voor de lezer ook van belang om te weten hoe de eis wordt getoetst. Immers, de lezer is veelal actiehouder van antwoord geven op de vraag, door bijvoorbeeld een ontwerp te maken. Er wordt begrip gevormd hoe de kwaliteit die je levert wordt beoordeeld en of dit valide is. Hierbij is het zaak niet alleen naar de eisen te kijken die er zijn, maar tevens uit te gaan van eigen kwaliteit. Het is mogelijk dat naar de mening van de lezer, uitgaande van de kwaliteitszorg die hij levert, de V&V-plannen onvoldoende zijn. Er kunnen dan ook aanvullingen worden voorgesteld. Niet reactief, maar pro-actief gedrag is de juiste houding.

Waar nodig stap 1 t/m 4 herhalen
Indien de eis niet goed wordt begrepen, niet meer actueel is, het geheel niet compleet is of er iets schort aan de toetsing, is het van belang stap 1 t/m 4 te herhalen. Uiteraard selectief, alleen op de punten waar een probleem is.

De output van de eisenanalyse is een duidelijke vraag inclusief de controle op begrijpelijkheid, actualiteit en compleetheid. De duidelijkheid zit in de kwaliteit van de eisformulering, de aangeboden structuur, de relaties met bronnen. De output wordt gebruikt om te kunnen ontwerpen. Het is de input voor velerlei analyses. Neem bijvoorbeeld de trade-off matrix. De vorm van de output kan zeer verschillend zijn. De structuren zijn gevarieerd, de eisen kunnen in een informatiemodel zitten, maar ook op papier staan. Het kan een vraagspecificatie van een contract zijn, maar ook een bestuurlijke opdracht of intern dossier. Welke vorm dan ook, als de vraag maar duidelijk is!