We weten het allemaal maar verzuimen in de praktijk regelmatig om onze requirements 'smart' te maken. Zijn jou requirements altijd Specifiek, Meetbaar, Acceptabel, Realiseerbaar en Tijdgebonden? Met name 'specifiek' en 'meetbaar' blijken lastig. Dit komt enerzijds omdat de benodigde informatie soms moeilijk te achterhalen is (wanneer werkt een systeem snel en gemakkelijk?) en anderzijds omdat we niet gewend zijn om zorgvuldig te formuleren.
Zou jij onderstaande requirements geschreven kunnen hebben?
1. Om een gebruiker toegang te geven zijn loginnaam en wachtwoord nodig.
2. Het systeem controleert bestellingen van nieuwe klanten.
3. Het systeem ondersteunt de verkopers bij het managen van hun klantenbestand en het samenstellen van rapporten.
4. Als de klant een kortingskaart heeft, jonger is dan 26 jaar en een internationaal retourticket koopt dat alleen in het weekend geldig is, moet het systeem 50 procent korting geven.
5. Het kassasysteem geeft geen korting als de scanner geen valide kortingskaart detecteert.
6. De klant wordt geïnformeerd wanneer de afgesproken leveringsdatum niet haalbaar blijkt.
7. De binnendienstmedewerker koppelt het verstrekte productmonster aan de klant.
8. De klant moet de software kunnen downloaden en eenvoudig zelf kunnen installeren.
9. Hypotheekadviseurs moeten na een training met het nieuwe systeem probleemloos hypotheekoffertes kunnen maken.
10. De noodprocedures moeten toegankelijk zijn voor zowel helpdeskmedewerkers als applicatiebeheerders.
Deze requirements zijn niet allemaal fout maar ze zijn zeker voor verbetering vatbaar. Requirements moeten voor zowel gebruiker(vertegenwoordiger)s als ontwikkelaars en testers begrijpelijk, verifieerbaar en voor één uitleg vatbaar zijn. Dat valt niet altijd mee.
De volgende regels helpen je bij het specificeren van requirements.
– Maak actieve zinnen. Het is dan expliciet wie de actie uitvoert.
– Vermijd vage woorden. Deze woorden geven onvoldoende informatie.
– Maak requirements atomair. Ze kunnen dan niet verder opgesplitst worden.
– Zet het kernpunt aan het begin van de zin. De zin is dan duidelijker en makkelijker leesbaar.
– Formuleer requirements positief. Negatieve zinnen met ontkenningen geven niet expliciet aan wat wel gewenst is.
– Kwantificeer waar mogelijk. Dat maakt requirements meetbaar.
– Gebruik geen homoniemen. Die leiden tot ambiguïteit.
Laten we bovenstaande regels eens toepassen op de tien voorbeelden hierboven.
1. Het systeem geeft gebruikers toegang op basis van hun loginnaam en wachtwoord (actief).
2. Het systeem controleert bij bestellingen van nieuwe klanten of de klantgegevens volledig zijn ingevuld (vaag woord).
3. Het systeem ondersteunt de verkopers bij het managen van hun klantenbestand en het systeem ondersteunt de verkopers bij het samenstellen van rapporten (atomair).
4. Het systeem moet 50 procent korting geven als de klant een kortingskaart heeft, jonger is dan 26 jaar en een internationaal retourticket koopt dat alleen in het weekend geldig is (kernpunt vooraan).
5. Het kassasysteem geeft 10 procent korting als de scanner een valide kortingskaart detecteert (positief).
6. Het systeem moet de klant per email informeren wanneer de afgesproken leveringsdatum niet haalbaar blijkt (actief).
7. De binnendienstmedewerker legt de verstrekking van het productmonster vast in het klantdossier (vaag woord).
8. De klant moet de software kunnen downloaden en daarna in hooguit drie klikken kunnen installeren (kwantificeren).
9. 90 procent van de hypotheekadviseurs moeten de standaard hypotheekoffertes na een één-daagse training probleemloos kunnen maken (kwantificeren).
10. De noodprocedures moeten begrijpelijk zijn voor zowel helpdeskmedewerkers als applicatiebeheerders of zowel helpdeskmedewerkers als applicatiebeheerders moeten toegang hebben tot de noodprocedures (homoniem).
Welk voorbeeld spreekt je aan of juist niet? Hoe zorg jij dat je requirements helder geformuleerd zijn? Plaats je opmerkingen in het reactieveld hieronder.
Nicole,
De zin ‘Requirements moeten voor zowel gebruiker, ontwikkelaar als tester begrijpelijk, verifieerbaar en één uitleg vatbaar zijn’ lijkt me een onmogelijke opgave. Zo’n regel is nu eenmaal vatbaar voor meerdere interpretaties, in bijvoorbeeld een uitleg naar de letter of de geest van het geschrevene.
Naar letter van geschrevene voldoet dus één account voor iedereen en een makkelijk te onthouden wachtwoord aan requirement ‘Om een gebruiker toegang te geven zijn loginnaam en wachtwoord nodig’ Maar in de geest van het geschrevene zal iedereen vast wel begrijpen dat dit geen vorm van beveiling biedt. De vraag die dan bij mij opkomt is in hoeverre requirements waarvan iedereen het nut en doel begrijpt uitgeschreven moeten worden.
Zulke theoretische beschrijvingen maken bestekken, plannen en offertes zo dik als wetboeken. Vooral leuk voor iemand die betaald wordt per woord, met misschien een bonus voor moeilijke woorden maar ik betwijfel of de kwaliteit van het systeem er beter van wordt. En uiteindelijk worden alle woorden waarschijnlijk toch weer vertaald in een ontwerp, een plaatje dat vaak refereert aan een standaard. Een plaatje dat trouwens precies beschrijft wat ik bedoel:
http://3.bp.blogspot.com/-5xxIU8wf91Q/TdAi1RCi1WI/AAAAAAAAAMA/dCYVfPK7DJE/s1600/project1.jpg
Dit heeft ook alles te maken met zaken als perceptie en referentiekader.
Ik gebruik zelf de slogan “Bouwen is Vertrouwen”.
Als je op voorhand alles ondubbelzinning probeert te beschrijven, maar het blijkt toch voor een andere inetpretatie vatbaar, krijg je andere uitkomst.
Zorg dat je samen op één lijn zit en besteed hier aandacht aan, om met name de onderlinge relatie te onderhouden en het zelfde referentiekader te hanteren.
@Nicole,
elk antwoord op een vraag dat meer tekst bevat is vrijwel altijd een ja of nee en daarna een inperking van die eerste 2 of 3 letters. Dat maakt dat het antwoord ook voor meer uitlegmogelijkheden te interpreteren is. Het SMART maken helpt wel iets om die ruimte in te perken, maar is niet de oplossing voor een goed PvE. SMART is namelijk niet echt slim.
In navolging van Suzanne en James Robertson van Volere kan ik adviseren om bij een requirement altijd een rationale (motivering) toe te voegen. Google eens op Volere Snow Card en je leest hier meer over.
Een motivering bij je requirement zorgt voor meer achtergrond begrip van de requirement. Dat zorgt er weer voor dat alternatieven beter afgewisseld moeten worden.
Denk aan de boven eerst genoemde voorbeeld “Het systeem geeft gebruikers toegang op basis van hun loginnaam en wachtwoord.”.
In deze requirement zit al een oplossing opgenomen. Zoals Ewout Dekkinga al in zijn reactie aangeeft, mag er dan één userid en een makkelijk wachtwoord uitgedeeld worden?
Dat zal niet de bedoeling zijn.
Door over een motivering na te denken, maak je beter duidelijk wat de requirement inhoud.
De motivering kan zijn: we willen doen alsof dit systeem beveiligd is, maar echt gevaar voor inbrekers lopen we niet.
Dan kan dus inderdaad de door Ewout gestelde suggestie een goede oplossing worden.
Is de motivering echter: we willen een streng beveiligd systeem waarbij een gebruiker alleen bij de eigen gegevens kan en niet bij andermans gegevens.”
Door dat te bedenken en op te schrijven ga je je afvragen of de requirement dan wel goed opgeschreven staat. Moet er een loginnaam en wachtwoord in de requirement? Of moet daar “authenticatie” staan? Het meer algemene authenticatie en streng beveiligd, brengt je in ieder geval aan het denken: login/wachtwoord kan, maar een verificatie met vingerafdruk of token via een GSM kan ook.
Kortom: naast SMART maken ook een Motivering toevoegen.