Zo’n vijf jaar geleden mislukte maar liefst 75% van alle ICT-projecten. Nu is dat nog steeds 50%. Best pijnlijke cijfers. De oorzaak? Vaak: een niet al te beste business analyse, en system requirements die het échte probleem niet oplossen. Terwijl juist de analyse en requirements de ‘backbone’ zijn van het systeem dat gebouwd moet worden. Neem daarom de tijd om een goede basis te leggen. De rest van het ontwikkelproces loopt dan stukken soepeler!

In deze blog geef ik 10 tips die je kunt gebruiken om betere requirements te schrijven. Zodat ze geen verwarring meer veroorzaken, en het probleem van kop tot staart oplossen.

Regel 1: er bestaat niet zoiets als ‘het perfecte format’. Requirements stel je op voor een bepaalde doelgroep, en die is niet altijd hetzelfde. De ene keer spreek je developers aan, de andere keer zijn het designers. Een format is dus altijd maatwerk. Bespreek met je doelgroep waar hun behoeften liggen. Welke info zien ze graag terug, en wat kun je achterwege laten? Stel samen een format op, en zorg dat iedereen zich eraan houdt.

Wil je doelgroep de API-calls terugzien in de tickets? Prima! Hebben ze behoefte aan een design bij elke feature? Ook goed! Wees flexibel, blijf communiceren en optimaliseer het format constant. Er is tenslotte altijd ruimte voor verbetering.

Begin altijd met een oude vertrouwde user story. Daarmee schep je in een paar zinnen duidelijkheid over het achterliggende doel, en snapt je doelgroep sneller hoe ze de requirements moeten lezen. Een goede user story beschrijft:

  1. de actor (gebruiker) die de actie uitvoert;

  2. de actie die genomen moet worden;

  3. het doel dat met de actie bereikt moet worden.

Bijvoorbeeld:
Als webshopgebruiker
wil ik mijn order kunnen traceren
zodat ik op het juiste moment thuis kan zijn om mijn order te kunnen ontvangen.

Houd de user story zo basic mogelijk. Kaart niet de oplossing aan, maar alleen de actor, actie en het achterliggende doel. Probeer woorden als ‘en’, ‘maar’ en ‘behalve’ te vermijden; die zorgen alleen maar voor verwarring en maken de user story veel te lang.

Houd de user story zo basic mogelijk. Kaart niet de oplossing aan, maar alleen de actor, actie en het achterliggende doel. Probeer woorden als ‘en’, ‘maar’ en ‘behalve’ te vermijden; die zorgen alleen maar voor verwarring en maken de user story veel te lang.

Stel je requirements op zonder vage woorden te gebruiken. ‘Een beetje’, ‘soms’ en ‘snel’ zijn bijvoorbeeld niet meet- of tastbaar en kunnen voor verwarring zorgen. Probeer zo meetbaar mogelijk te formuleren en zorg dat er geen ruimte is voor interpretatie.

heldere-taal-system-requirements

Het heeft weinig zin om lastige animaties of bewegende objecten in het design te documenteren. Ga liever met een developer en/of designer aan tafel om de animaties te bespreken. Dat gaat veel sneller en makkelijker dan eerst alles documenteren, en daarna nog eens overdragen.

Probeer consistent te zijn in je woordgebruik. Gebruik bijvoorbeeld niet ‘shopping cart’, ‘cart’ en ‘basket’ door elkaar als je steeds hetzelfde bedoelt, want ook dit kan voor verwarring zorgen.

Requirements moeten autonoom zijn: volledig, onafhankelijk af te handelen en makkelijk leesbaar. Verwijs dus niet naar tickets met requirements die nog niet zijn uitgewerkt, want dat kan ervoor zorgen dat iemand vastloopt. Bovendien vinden veel mensen het irritant om steeds doorverwezen te worden.

Werk niet alleen de happy flow uit, maar denk alle scenario’s en uitzonderingen uit die van belang zijn. Wat als actie X niet lukt? Sla hier ook weer niet te ver in door; voorkom dat je edge case-scenario’s eindeloos blijft uitdenken.

Leg je requirements in een vroeg stadium voor aan je stakeholders. Kijk of jullie met z’n allen op één lijn zitten en verbeter waar nodig. Kloppen de business requirements en worden er geen aannames gedaan? Wordt het achterliggende probleem écht opgelost met de techniek? Probeer fouten zo vroeg mogelijk op te sporen. Want het laatste wat je wilt, is dat er iets wordt gebouwd dat niet het probleem aanpakt.

In de jaren 70 kwam Barry Boehm met ‘de wet van Boehm’. Deze laat duidelijk zien dat de herstelkosten exponentieel toenemen naarmate een fout later opduikt in het ontwikkelproces. Hoe eerder je een fout dus opspoort, hoe goedkoper het is om ‘m te corrigeren.

wet-van-boehm

Het kan handig zijn om – naast de functional requirements – ook de non-functional requirements in je tickets te noemen.

  1. Functional requirements beschrijven wat het systeem moet doen

  2. Non-functional requirements beschrijven hoe het systeem dat moet doen

Je kunt de non-functional requirements in verschillende categorieën onderverdelen:

  • Onderhoudbaarheid: een maat voor het gemak waarmee het systee onderhouden kan worden

  • Bruikbaarheid: mate waarin het systeem geschikt is voor gebruik

  • Betrouwbaarheid: mate waarin het systeem blijft functioneren, ook tijdens storingen

  • Efficiëntie: mate waarin het systeem met beschikbaar gestelde middelen presteert

De non-functional requirements worden nog weleens overgeslagen. Het is natuurlijk ook vanzelfsprekend dat een website op z’n minst op de bekendste browsers moet functioneren, en het liefst op alle browsers en alle versies. Toch is het belangrijk om aan te geven op welke browserversies de website moet kunnen draaien, en welke versies je achterwege kunt laten. Het is namelijk niet realistisch om aan alle browserversies te voldoen. Ook hier geldt: hou je doelgroep goed voor ogen.

Wil je meer weten over business analyse of het opstellen of uitdenken van requirements? Deniz, die op dit moment bij Rituals Cosmetics werkt als Business Analyst, vertelt je er graag meer over. Hij denkt én werkt dagelijks business requirements uit en vertaalt die vervolgens naar de techniek, zodat development met een vliegende start kan beginnen.