Er zit niets anders op: leg je requirements voor aan je stakeholders

Kunnen we objectief over een requirement zeggen dat hij van goede kwaliteit is? Wat is dan de maatstaf voor ‘goed’? Bestaat er zoiets als ‘goed genoeg’? Een antwoord hierop is voor een groot deel te vinden in het werk van Philip Crosby, William Edwards Deming en Joseph Juran. Deze drie kwaliteitsgoeroes zijn niet meer onder ons, maar hun ideeën blijven een grote bron van inspiratie.

Omdat requirements het resultaat zijn van een requirementsengineeringproces, lijkt het logisch om na te gaan of een requirement voldoet aan de doelstellingen van dat proces. Ten eerste, zijn de behoeftes van de stakeholders vastgesteld? Ten tweede, is een correcte en volledige vertaling van deze behoeftes vastgelegd tot op het decompositieniveau waar de eisen kunnen worden geïmplementeerd in hardware- of softwarecomponenten? Hier zal ik mij richten op dit tweede doel.

Intrinsieke kwaliteit

We maken voor requirements onderscheid tussen intrinsieke en extrinsieke kwaliteit. Intrinsiek betekent dat de kwaliteit van de requirement wordt bepaald door de manier waarop deze is gedocumenteerd of gepresenteerd aan de lezer – de syntax van de requirement. Dit kan met tekst, afbeeldingen, tabellen, enzovoorts. De controle kan, in theorie, worden uitgevoerd door personen of toepassingen die geen materiekennis hebben. Zij hoeven niet te begrijpen waar de requirement over gaat maar moeten eerder zien of de beschrijving in strijd is met regels voor het opstellen ervan. Deming spreekt over ‘pride of workmanship’ en ‘well-crafted requirements’.

In de loop van de laatste tien tot vijftien jaar werd de softwaretooling voor kwaliteitscontrole steeds geavanceerder. Tools als QVScribe doen automatisch checks volgens de writing requirements-richtlijn van de internationale raad voor systeemengineering Incose. De intrinsieke kwaliteitscontrole is daar volledig geautomatiseerd (inclusief diverse requirementstemplates als EARS en IREB).

Let wel, de intrinsieke kwaliteit dekt slechts een derde van de totale requirementskwaliteit. Maar deze intrinsieke kwaliteitscontroles hebben hun waarde. Als ze worden uitgevoerd en correcties worden aangebracht voordat de requirement wordt gereviewd door domeinexperts en relevante stakeholders, dan kunnen deze tools tijd besparen en de kwaliteit van requirements fors verbeteren.

Terug- en vooruitkijken

Maar tools helpen niet om te bepalen of je requirement zinvol is voor het beoogde publiek. Dit is waar de extrinsieke kwaliteit van requirements om de hoek komt kijken. Daar is een aanpak in twee richtingen nodig: terug naar de stakeholders die vroegen om een specifieke functionaliteit van het te ontwikkelen product, productkenmerk of gedrag (het bronpubliek), en daarnaast vooruit naar de ontvangers van de eis (het doelpubliek).

Laten wij de volgende eis beschouwen: ‘het reactievermogen van het systeem zal kleiner of gelijk zijn aan 5 ms’ (R1). R1 zal hoogstwaarschijnlijk met vlag en wimpel de geautomatiseerde kwaliteitscontroles doorstaan. In de praktijk wordt deze eis vaak geformuleerd als: ‘reactievermogen van het systeem ≤ 5 ms’.

Zijn deze eisen van gelijke kwaliteit? Vanuit syntactisch oogpunt zal de eerste een hogere score geven, omdat het als een instructie geschreven is (‘het systeem zal iets doen’). Maar we weten het pas echt als we het aan de relevante stakeholders vragen. Pas dan horen we of hun wensen correct zijn vertaald.

Check bij de bron

Kwaliteit is conformiteit aan requirements, stelt Crosby: hebben wij, als requirementsengineers of businessanalisten, de behoeftes van de stakeholders correct vertaald in een systeemeis? Deze vraag kan alleen worden beantwoord door de stakeholders die de oorspronkelijke eisen hebben geformuleerd. Dit betekent dat requirementsengineers hun requirements moeten laten controleren en beoordelen, iets dat meestal als moeilijk wordt ervaren.

Stel dat de klant je vertelt dat je niet hebt begrepen waar hij om vroeg. Of dat je zijn punt totaal hebt gemist? Dergelijke feedback is niet altijd aangenaam en dat zorgt ervoor dat je dit soort confrontaties liever uit de weg gaat. Vaak pak je de veilige weg door iemand in het project te vragen om de rol van klant of stakeholder te spelen.

Dat is echter niet verstandig. Je wilt er zeker van zijn dat je de behoeftes van de stakeholder hebt begrepen en dat je alles correct en volledig hebt vertaald in requirements. Er zit dus niets anders op dan je requirements weer voor te leggen aan je oorspronkelijke bronnen.

Ondubbelzinnig

Kwaliteit is fitness for purpose, zegt Juran: requirements moeten voldoende informatie en detail bevatten voor ontwerpers om er oplossingen voor te bedenken. De requirements moeten gekwantificeerd zijn om testers in staat te stellen de succesvolle implementatie ervan te verifiëren en te valideren. Kortom: ze moeten duidelijk, ondubbelzinnig, zinvol en voldoende gedetailleerd zijn voor degenen die de eis als input voor hun werk ontvangen.

Ik heb gevallen gezien waarin er geen documentatie van eisen bestond tussen een oem en een van zijn leveranciers van onderdelen. Alleen een mondelinge overeenkomst. Hoewel dit in sommige culturen een onaanvaardbare situatie lijkt, werden de doelstellingen van het requirementsengineeringproces wel bereikt. De leverancier levert het onderdeel nu al meer dan twaalf jaar met een constante kwaliteit tot tevredenheid van de klant.

Wat zou jij doen in situaties als deze? Hoe zie je de kwaliteit van requirements in jouw bedrijf? Hoe zou je omgaan met behoeftes van klanten zoals ‘ik wil dat de volgende versie van de auto energiezuiniger is’? Ik hoor het graag, om ervan te leren en het door te geven.