Doeltreffend programma van eisen en wensen

In een programma van eisen en wensen staan de requirements voor het te ontwikkelen systeem. Bij uitbesteding aan een interen of externe leverancier moet je immers duidelijk maken aan welke eisen het systeem moet voldoen. Opstellen van een programma van eisen en wensen is daarvoor al decennia lang gebruikelijk.

De problemen die opdrachtgever ondervinden met het uitbesteden van software ontwikkeling zijn ook al tientallen jaren onveranderd. In de bekende karikatuur met de schommel wordt dat treffend geïllustreerd.

schommelkarikatuur

Hier lees je waarom het mijns inziens niet lukt om de schommelkarikatuur te verslaan.

Programma van eisen en wensen opstellen

Het opstellen van een programma van eisen en wensen is niet eenvoudig. Tenminste als je het over een traditioneel programma van eisen hebt.

Maar het kan ook anders. Er zijn tegenwoordig andere, effectievere manieren om een softwareontwikkeltraject in goede banen te leiden. Voor een doeltreffend programma van eisen moet je slimme manieren vinden om:

  1. De business te helpen hun eisen en wensen helder te krijgen
  2. De eisen en wensen duidelijk over te brengen aan het ontwikkelteam
  3. Op tijd te controleren of de ontwikkelde software aan de gebruikersbehoeften voldoet

Het recept hiervoor bestaat uit drie basisingrediënten. Ze versterken elkaar en vormen gezamenlijk een ijzersterk recept waarmee je de schommelkarikatuur de baas wordt.

1. Concreet beeld gewenste situatie

Om de business te helpen bij het expliciet maken van hun eisen en wensen hebben ze een concreet beeld van het gewenste systeem nodig. Dat beeld moeten ze geleidelijk opbouwen.

Het is niet mogelijk om alles op voorhand te overzien. Daarom is het niet reëel om van de business stakeholders te verlangen dat ze hun complete set van eisen en wensen in een traditioneel programma van eisen opnemen.

Mini programma van eisen en wensen

Het Programma van Eisen kun je beter in delen laten opstellen. Of beter gezegd je gaat in kleine deelprojecten werken. Voor ieder deelproject laat je dan een mini-PvE opstellen. Dat doe je kort van tevoren, namelijk tijdens het voorafgaande deelproject.

In het eerste deelproject laat je een basale versie van het systeem ontwikkelen. Die initiële versie laat je steeds verder uitbreiden in de opeenvolgende deelprojecten. Dit worden incrementen genoemd. En daarvoor stel je steeds een mini-PvE op. 

De business stakeholders hoeven zo niet meteen het complete plaatje te overzien. Ze kunnen zich op basis van de reeds opgeleverde software een steeds concreter beeld vormen. En ze kunnen voortborduren op de in de voorgaande deelprojecten opgeleverde functionaliteit. 

2. Tweerichtingsverkeer

Om de eisen duidelijk over te brengen aan het ontwikkelteam is tweerichtingsverkeer noodzakelijk. Dat is namelijk de makkelijkste manier om erachter te komen of de eisen duidelijk zijn en goed geïnterpreteerd worden door de ontvanger.

Voor het Programma van Eisen betekent dit dat je als opdrachtgever (vertegenwoordigd door business stakeholders en/of een business analist) een groot deel mondeling overbrengt. Niet alle details hoeven dan schriftelijk vastgelegd te worden. Alleen de informatie waarop je later terug wilt kunnen grijpen.

Hoe vaker er mondeling contact is met het ontwikkelteam, hoe minder details je hoeft vast te leggen. Ook is het een stuk eenvoudiger om mondeling uit te leggen wat je van het systeem wilt. En je krijgt meteen terugkoppeling of je boodschap correct overkomt.

3. Ruimte voor herstelacties

Controleren of de software aan de gestelde eisen voldoet is geen overbodige luxe. Maar dat is alleen zinvol als er ruimte is om bij te sturen. Je wilt immers een systeem opgeleverd krijgen dat aan je behoeften voldoet. Maar dat komt alleen in zicht als er ruimte is voor herstelacties.

Voor de acceptatietesten die je op basis van een programma van eisen uitvoert, betekent dit dat ze vroegtijdig moeten plaatsvinden. Hoe eerder en hoe vaker je test, hoe eenvoudiger en minder kostbaar het is om de software aan te passen.

Alleen acceptatietesten aan het eind van ieder deelproject uitvoeren, is niet voldoende. Organiseer ook tussentijds feedback op schermprototypen. Of beter nog op in ontwikkeling zijnde onderdelen van het systeem.

Bottom line

Participatie tijdens de ontwikkeling van de software is vele malen effectiever dan een gedetailleerd programma van eisen.

Besteed je kostbare tijd en die van de stakeholders daarom niet aan het opstellen van een allesomvattend programma van eisen, maar aan actieve deelname aan het project. Dan creëer je de mogelijkheid om de eisen en wensen gaandeweg scherp te stellen, te communiceren en feedback te geven op de ontwikkelde software.

In het online programma Meester in agile requirements ontdek je op welke andere punten agile practices indruisen tegen traditionele werkwijzes. Aanrader voor traditioneel opgeleide vakmensen die werk van hoge kwaliteit willen blijven leveren.

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

Nicole de Swart

Nicole de Swart

Auteur Handboek Requirements

Volg Nicole op:

Priya Soekhai

Priya Soekhai

Expert agile samenwerken

Volg Priya op:

Tips over agile requirements

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.000 collega abonnees.
Je kunt je op elk moment weer uitschrijven

Copy link