De afgelopen jaren is er een behoorlijke verandering gaande geweest hoe we omgaan met met de eisen voor software oftewel de software requirements. 

Deze verandering is mede tot stand gekomen door de ontwikkelmethodiek Agile. Software requirements beschrijven wat een bepaalde applicatiesoftware moet kunnen, zoals webapplicatie ontwikkeling. Drie pijlers spelen een belangrijke rol hierbij: betrek de betrokkenen bij het ontwikkelproces, review de prototypes en testreleases. Voor mij als Product Manager vormt dit een belangrijk onderdeel van diverse SaaS oplossingen die wij ontwikkelen. In deze blog vertel ik jullie iets meer op welke wijze software requirements worden toegepast.

De basis

Ongeacht de methodiek, zijn er bepaalde basis stappen die doorlopen dienen te worden om te komen tot de applicatiesoftware en daarmee de requirements. We hebben het dan over het verzamelen van de vereisten, ontwerpen van een oplossing en de ontwikkeling van het software product. Als productmanager is het belangrijk de markt te verstaan, beslissingen te nemen die strategisch zijn en financieel een bijdrage leveren voor de klant. Wanneer er commitment is vanuit de klant, dan starten we met het verzamelen van de requirements, het prioriteren en de communicatie naar de personen die het softwareproduct gaan ontwerpen en ontwikkelen.

Continu proces

Het opstellen van software requirements is een continu proces. We hebben het dan over veranderingen en updates die gemanaged moeten worden tijdens de ontwikkeling en doorontwikkeling van de software. Tijdens de ontwikkeling wordt continu gekeken of een requirement in de aankomende release moet of de resources beschikbaar zijn en/of de geplande datum gehaald gaat worden. Indien we te maken krijgen met aanvullende requirements, dan zal bepaald worden of deze op de roadmap dienen te komen voor de toekomst en/of ze aansluiting vinden bij de wensen van de klant.

Hoe stel je requirements op?

Er is geen goede of foute manier. Wanneer de requirements zeer gedetailleerd beschreven zijn en er wordt zeer formeel mee omgegaan, dan geeft dit weinig ruimte tot creativiteit. Te weinig beschreven requirements geven het risico dat de ontwikkelde software geen aansluiting vindt bij de behoefte van de klant. Wat de beste manier is, is afhankelijk van hetgeen dat ontwikkeld dient te worden. Denk hierbij aan een mogelijke applicatie integratie, de bedrijfscultuur van de klant, het ontwikkelproces en de planning. Afhankelijk hiervan moet er besloten worden wat de juiste werkwijze is voor de software ontwikkeling.

Requirements komen het best tot zijn recht wanneer er een nauwe samenwerking is tussen de verschillende disciplines die te maken hebben met de proces automatisering zoals Product Management, de projectleider, de ontwikkelaar en de klant. Dat betekent dat er continu een wisselwerking is met betrekking tot de mogelijkheden, wat er nodig is en wat de wensen zijn. Requirements zijn namelijk gebaseerd op verschillende gebruikers van de applicatiesoftware en beschreven vanuit de gebruiker. Kortom er zijn diverse afhankelijkheden en dat maakt het werk zo interessant!