Zo schrijf je betere system requirements

-

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.

1. het perfecte format bestaat niet

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.

2. begin altijd met een user story

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:

  • de actor (gebruiker) die de actie uitvoert;
  • de actie die genomen moet worden;
  • 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.

3. vermijd vage woorden

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.

4. vermijd beschrijvingen van lastige animaties

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.

5. consistency is key

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.

6. verwijs niet naar requirements die nog gespecificeerd moeten worden

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.

7. documenteer niet alleen de happy flow

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.

8. laat je system requirements controleren door je stakeholders

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.

de wet van boehm

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.

10. non-functional requirements, ain’t nobody got time for that

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

  • Functional requirements beschrijven wat het systeem moet doen
  • Non-functional requirements beschrijven hoe het systeem dat moet doen

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

1. onderhoudbaarheid

Een maat voor het gemak waarmee het systeem onderhouden kan worden

2. bruikbaarheid

Mate waarin het systeem geschikt is voor gebruik

3. betrouwbaarheid

Mate waarin het systeem blijft functioneren, ook tijdens storingen

4. 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.

voorbeeld

meer weten?

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.