Trend 2: Goede kwaliteitseisen

Kunnen we objectief zeggen dat een vereiste van goede kwaliteit is? Wat zou de maatstaf voor goed zijn? Bestaat er zoiets als ‘goed genoeg’? De meeste antwoorden op deze vragen zijn 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.

Aangezien requirements het resultaat zijn van een requirements engineering proces, lijkt het logisch om te controleren of een requirement voldoet aan de doelen van het proces. Ten eerste zijn de behoeften van de belanghebbenden vastgesteld en ten tweede is een correcte en volledige overgang van de behoeften van de belanghebbenden gewaarborgd tot het decompositieniveau waarop de eisen kunnen worden geïmplementeerd in hardware- of softwarecomponenten. Ik zal me hier richten op het tweede doel.

Er wordt onderscheid gemaakt tussen intrinsieke en extrinsieke requirementskwaliteit. Intrinsiek betekent dat de kwaliteit van een requirement wordt bepaald door de manier waarop het is gedocumenteerd of gepresenteerd aan de lezer – de syntax van de requirement. Dit kan puur tekstueel zijn of verfraaid met afbeeldingen, tabellen en meer. De controle kan in theorie worden uitgevoerd door personen of applicaties zonder kennis van het onderwerp. Ze hoeven niet te begrijpen waar de eis over gaat, maar ze moeten eerder kijken of het in strijd is met de regels voor het schrijven van eisen. Deming spreekt van “trots op vakmanschap” en “goed opgestelde eisen”. In de loop van de laatste 10-15 jaar zijn softwaretools om deze kwaliteitscontroles te ondersteunen steeds geavanceerder geworden. In tools zoals QVScribe zijn checklists zoals de Writing Requirements richtlijn van de International Council on Systems Engineering (Incose) volledig ingebed en intrinsieke kwaliteitscontroles zijn volledig geautomatiseerd (inclusief diverse requirements templates zoals EARS en IREB).

Merk op dat de intrinsieke kwaliteit slechts een derde van de totale kwaliteit van de vereisten dekt. Maar de intrinsieke kwaliteitscontroles hebben wel degelijk waarde. Als ze worden uitgevoerd en correcties worden aangebracht voordat de requirement wordt beoordeeld door materiedeskundigen en relevante belanghebbenden, kunnen deze tools tijd besparen en inderdaad nuttig zijn om de kwaliteit van requirements te verbeteren.

Maar tools helpen je 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. Het is van toepassing in twee richtingen: terug naar de belanghebbenden die vroegen om een specifieke eigenschap van het te ontwikkelen product of een productkenmerk of gedrag (het bronpubliek), en vooruit naar de ontvangers van de vereiste (het doelpubliek).

Laten we eens kijken naar de volgende eis: “De reactiesnelheid van het systeem mag niet groter zijn dan 0,5 ms.” Deze eis zal waarschijnlijk met vlag en wimpel door de geautomatiseerde kwaliteitscontroles komen. In de praktijk wordt deze eis vaak geformuleerd als: “Systeemresponsiviteit: ≤ 0,5 ms.” Zou je zeggen dat deze eisen van gelijke kwaliteit zijn? Vanuit een syntactisch perspectief zal de eerste een hogere score opleveren omdat deze een richtlijn bevat, maar pas als we het de relevante belanghebbenden vragen, hebben we enig idee of de bedoelde betekenis correct is vertaald.

[Courseinstructor heading=”‘equirements engineers moeten hun eisen laten controleren en beoordelen.'”

Kwaliteit is conformiteit aan de vereisten, zegt Crosby. Hebben wij, als requirements engineers of business analisten, de behoefte van de stakeholder correct vertaald naar een systeemvereiste? Dit kan alleen worden beantwoord door de belanghebbenden die de oorspronkelijke behoefte hebben geformuleerd. Dus requirements engineers moeten hun requirements laten controleren en beoordelen – een activiteit die als moeilijk wordt ervaren.

Stel dat de klant zegt dat de ingenieur het verzoek niet heeft begrepen? Of dat hij het punt volledig heeft gemist? Zulke feedback is niet altijd prettig en dat zorgt ervoor dat een requirements engineer deze confrontaties uit de weg gaat. Hij neemt vaak de veilige weg door contact op te nemen met iemand van het project om de klant of stakeholder te vertegenwoordigen.

Dat is geen slimme houding. We willen er zeker van zijn dat we de behoeften van de belanghebbenden hebben begrepen en dat we ze correct en volledig hebben vertaald in vereisten. Daarom is er geen andere manier dan deze moeilijke vragen direct te stellen.

Kwaliteit is geschiktheid voor het doel, zegt Juran. Requirements moeten voldoende informatie en details bevatten voor ontwerpers om oplossingen te bedenken. Van de requirements wordt verwacht dat ze gekwantificeerd zijn zodat testers de succesvolle implementatie ervan kunnen verifiëren en valideren. Kortom, ze moeten duidelijk, ondubbelzinnig en zinvol zijn en voldoende gedetailleerd voor degenen die de vereisten ontvangen als input voor hun werk.

Ik heb gevallen gezien waarin er geen documentatie over vereisten 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 doelen van het requirements engineering proces gehaald. De leverancier levert het onderdeel nu al meer dan twaalf jaar met constante kwaliteit tot tevredenheid van de klant.

Wat zou jij doen in dit soort situaties? Hoe kijk je aan tegen de kwaliteit van requirements in jouw bedrijf? Hoe zou jij omgaan met behoeften van stakeholders zoals “ik wil dat de volgende versie van de auto energiezuiniger is”? Ik hoor graag van je, om te leren en door te geven.