Ideeën en concepten concreet en verifieerbaar maken
Om het productidee communiceerbaar en begrijpelijk te maken, zal dit zo concreet mogelijk moeten worden uitgewerkt. Alleen als dit goed gebeurt, zullen engineers in staat zijn te ontwerpen wat er verwacht wordt. Deze uitwerking bestaat minimaal uit de context, de requirements en use cases.
Context
De context beschrijft het verhaal van het product en het bredere concept, waarom het een goed product is en wat voor waarde het biedt voor de gebruikers. Daarnaast is een uitleg van het business model waardevol om te begrijpen hoe er geld verdient gaat worden met het product. Ten slotte is het van belang om de grotere omgeving, waarbinnen het product moet werken, te omschrijven.
Use cases
Use cases zijn beschrijvingen van scenario's hoe een gebruiker interacteert met het product. Het definiëren van use cases is een goed middel om vroegtijdig na te denken over de verschillende scenario’s die mogelijk zijn en hoe daarmee om te gaan. Het forceert de product owner om in detail de interactie met de gebruikers te beschrijven. Use cases geven heel veel context waarin en hoe een product gebruikt wordt. Dit is onmisbaar bij het ontwerpen van het systeemgedrag, met name als er menselijke interactie is (denk aan human machine interface (HMI)).
Requirements
Vervolgens worden de functionele en niet-functionele eisen vastgelegd (requirements). Functionele eisen zeggen iets over wat het product moet kunnen en niet-functionele eisen zeggen waar het product aan moet voldoen. Het goed vastleggen van requirements is absoluut noodzakelijk. Ook is het belangrijk dat de requirements van goede kwaliteit zijn. Het is een valkuil om ‘alles’ te willen specificeren: dat is een een onhaalbaar doel. De kwaliteit van de requirements is belangrijker. Met goede requirements zullen engineers een ontwerp maken wat voldoet aan de verwachtingen. Op basis van goede requirements is het ook mogelijk om aan te tonen dat het ontwerp aan de eisen voldoet (verificatie).
Goede requirements voldoen in ieder geval aan de volgende punten:
- Er staat in een requirement nooit een oplossing. Er staat wat het product moet doen of waar het aan moet voldoen, nooit hoe het dat moet doen.
- Requirements zijn niet ambigue. Oftewel, concreet. Voorkom dat er mogelijkheden voor interpretatie en aannames in de requirement zitten. Impliciete aannames zijn de bron van falen!
- Per requirement wordt ook vastgelegd hoe deze requirement getest (geverifieerd) gaat worden. Een bijkomend voordeel van het vastleggen van een test per requirement, is dat het mogelijke aannames over de requirement voorkomt. De requirement wordt dus nog concreter.
- Een requirement is één requirement. Staan er twee in één zin, maak er dan twee requirements van.
Het vastleggen van goede requirements is geen gemakkelijke taak en het vergt de aandacht van zowel product owners als engineers. Er zijn een aantal valkuilen en misvattingen als het om requirements gaat, zoals:
- Product owners denken soms te veel in termen van oplossingen, in plaats van eisen. Dit levert geen goede requirements op en beperkt de creativiteit van engineers. Hier geldt: schoenmaker, blijf bij je leest!
- Requirements worden soms benaderd als statisch en onwijzigbaar. Door deze benadering wordt het vastleggen van requirements nog moeilijker, zo niet onmogelijk. Datzelfde geldt als requirements de basis zijn voor commerciële afspraken. Requirements kunnen wijzigen gedurende het project, zolang dat maar volgens een goede procedure gaat.