Ontwikkelingen vakgebied

Requirements Engineering is een relatief jong vakgebied dat pas vanaf het einde van de twintigste eeuw op grote schaal werd toegepast. Sinds die tijd bevestigen onderzoeken keer op keer dat gedegen requirements een kritieke succesfactor zijn voor software ontwikkelprojecten. Het vakgebied heeft dan ook een sterke ontwikkeling doorgemaakt. Ik heb de belangrijkste ontwikkelingen op een rij gezet.

Systeemperspectief van requirements

In de jaren zeventig van de vorige eeuw was men tot het inzicht gekomen dat de gewenste acties van het systeem (de functionaliteit) en de implementatie daarvan (de technische oplossing) afzonderlijk bekeken moeten worden. Door het WAT van het HOE te scheiden, kwam er expliciet aandacht voor requirements.

In de eerste twee decennia werden de requirements uitsluitend vanuit het systeemperspectief benaderd. Hierbij stonden het systeem en de eisen die de business daaraan stelt centraal. Deze eisen worden softwarerequirements genoemd en zijn onder te verdelen in functionele en niet-functionele requirements.

Atomaire beweringen

Het was gebruikelijk om requirements als atomaire beweringen te beschrijven. Iedere bewering bevat dan precies één eenduidig geformuleerde requirement. Voor een gemiddeld systeem ging het al snel om honderden gedetailleerde softwarerequirements die in excel of in een requirements management tool beheerd werden. Ook het product Software Requirements Specificatie (SRS) stamt uit deze tijd.

Businessperspectief van requirements

Vanaf de jaren negentig is het accent verschoven van de functionaliteit van het systeem naar de omgeving waarin het systeem opereert. Het systeem ontleent haar bestaansrecht immers aan de toegevoegde waarden die het levert aan de business. Het is daarom beter om de requirements vanuit de te ondersteunen business processen te benaderen. Hierdoor blijft de aandacht van het softwareontwikkelteam gericht op de toegevoegde waarden die het systeem moet leveren. Het systeem is immers geen doel op zich.

Bij het businessperspectief staan de behoeften van de business aan geautomatiseerde ondersteuning centraal. Het businessperspectief voegt aan het systeemperspectief toe 'waarom' het systeem gewenst is en 'wat' voor proces of activiteit het systeem moet ondersteunen. Dit zijn achtereenvolgens de business- en de gebruikersrequirements.

Use cases

Use cases groeiden in de negentiger jaren uit tot de standaard techniek voor het specificeren van de requirements. Een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen dat waarde heeft voor de gebruiker. Alle acties van het systeem en van de gebruiker die nodig zijn om het doel van de gebruiker te halen zijn gegroepeerd tot een use case.

Just in time requirements

Sinds de eeuwwisseling is agile softwareontwikkeling sterk in opkomst. Dit heeft zijn weerslag op Requirements Engineering. Agilisten vinden immers dat het onmogelijk en onwenselijk is om aan het begin van het software ontwikkeltraject de requirements te specificeren. De gebruikers kunnen vooraf niet precies aangeven wat ze nodig hebben en wijzigingen in de requirements zijn onvermijdelijk vanwege voortschrijdend inzicht en veranderende omstandigheden.

Agile projecten werken incrementeel en iteratief. Ze beginnen met de meest basale variant van het systeem en breiden de software iedere iteratie uit op basis van feedback van gebruikers en op basis van just in time requirements. Het toevoegen en uitwerken van nieuwe requirements stellen agilisten zo lang mogelijk uit. Hierdoor ontstaat een continue stroom van just in time requirements, net voordat het ontwikkelteam die nieuwe informatie nodig heeft. Op dat latere moment is er meer informatie beschikbaar, hebben gebruikers eerdere versies van het systeem al gezien en is onderhouden van een requirements-'voorraad' niet nodig.

User stories

In agile omgevingen zijn user stories de meest gebruikte techniek voor het communiceren van requirements. Een user story luidt meestal als volgt:

Deze zin is geen exacte specificatie maar een 'reminder' voor de mondelinge afstemming over de requirement tussen de gebruiker (product owner) en de ontwikkelaars.

Hoe ervaar jij de ontwikkelingen in het vakgebied Requirements Engineering? Plaats hieronder je reactie.