Blog

SMART requirements

Het acroniem SMART staat voor Specifiek, Meetbaar, Acceptabel, Realiseerbaar en Tijdsgebonden. Hoewel deze kwaliteitscriteria oorspronkelijk bedoeld waren voor het formuleren van persoonlijke doelen, worden ze ook veelvuldig gebruikt voor individuele requirements. Vaak ligt daarbij de nadruk op het criterium meetbaar. Deze keer geef ik vijf concrete tips voor het specifiek en eenduidig formuleren van gedetailleerde requirements.

Tips voor het SMART maken van requirements

De volgende tips helpen je om softwarerequirements SMART te formuleren:

  1. Formuleer vage woorden specifieker
  2. Herformuleer dubbele ontkenningen
  3. Splits meervoudige condities waarin zowel 'en' als 'of' voorkomt op
  4. Vervang meervoudige condities met geneste 'als dan' door opsommingen van de condities
  5. Herformuleer negatieve requirements

Voorbeelden en een korte toelichting vind je hieronder.

1. Formuleer vage woorden specifieker

Woorden die ruimte geven voor een eigen invulling noemen we vaag.

Voorbeelden van vage woorden:

  • Behandelen, afhandelen, verwerken, koppelen
  • Eventueel, misschien, soms, zelden, meestal, ongeveer, indien nodig
  • Zoals, bijvoorbeeld, verschillende, meerdere, etc.
  • In het algemeen, in principe, zoveel mogelijk, normaliter, bijna altijd


De specificaties van de requirements moeten specifiek en eenduidig zijn. De aanwezigheid van vage woorden in de gedetailleerde specificaties is een teken dat niet alle informatie boven tafel is gehaald.

Voorbeelden van vage requirements:

  • Het systeem moet de aanvraag koppelen aan de klant
  • Het systeem moet de ontvangen aanvraag verwerken


Deze requirements kunnen specifieker geformuleerd worden:

  • Het systeem moet de aanvraag toevoegen aan het dossier van de klant
  • Het systeem moet op basis van de ontvangen aanvraag een nieuwe verzekering voor de klant aanmaken

2. Herformuleer dubbele ontkenningen

Een requirement met een dubbele ontkenning leest niet prettig en is vaak onduidelijk. Het is daarom de moeite waard om deze zinnen te herformuleren.

Voorbeeld van een dubbele ontkenning:

  • Het hotelovernachtingssysteem mag geen reservering toestaan voor een kamer die niet beschikbaar is


Deze requirement kan beter vervangen worden door twee andere requirements:

  • Het systeem moet verifiëren dat de kamer beschikbaar is voordat het de reservering bevestigt
  • Het systeem moet aangeven dat er geen kamer beschikbaar is (als dat uit de verificatie blijkt)

3. Splits meervoudige conditie waarin zowel 'en' als 'of' voorkomt op

Dit soort condities geeft vaak aanleiding tot interpretatieverschillen. Ze kunnen het beste opgesplitst worden in afzonderlijke requirements.

Voorbeeld van een requirement met een meervoudige conditie:

  • Het systeem moet de order aan een beoordelaar voorleggen als de klant een betalingsachterstand heeft en de order groter of gelijk is aan vijfhonderd euro of als de klant met acceptgiro wil betalen

Deze requirement is op verschillende manieren te lezen:

  • Het systeem moet de order aan een beoordelaar voorleggen als (de klant een betalingsachterstand heeft en de order groter of gelijk is aan vijfhonderd euro) OF (als de klant met acceptgiro wil betalen)
  • Het systeem moet de order aan een beoordelaar voorleggen als (de klant een betalingsachterstand heeft) EN ( de order groter of gelijk is aan vijfhonderd euro of als de klant met acceptgiro wil betalen)


Wel eenduidig zijn de volgende formuleringen:

  • Het systeem moet de order aan een beoordelaar voorleggen als de klant een betalingsachterstand heeft en de order groter of gelijk is aan vijfhonderd euro
  • Het systeem moet de order aan een beoordelaar voorleggen als de klant met acceptgiro wil betalen

4. Vervang meervoudige condities met geneste 'als dan' door opsommingen van de condities

Een zin met daarin een 'als dan' binnen een andere 'als dan' is moeilijk leesbaar. De zin is beter leesbaar te maken door de geneste 'als dan' te vervangen door een opsomming van de condities.

Voorbeeld van een requirement met een geneste 'als dan':

  • Als een bepaald product wordt verkocht en de voorraad daalt onder het minimum bestelniveau, dan moet het systeem dat signaleren aan de inkoper als er geen vaste afspraken met de betreffende leveranciers bestaan


De volgende formulering is duidelijker:

  • Het systeem moet een signaal geven aan de inkoper als door de verkoop van een bepaald product het minimum bestelniveau wordt bereikt en als er bovendien geen vaste afspraken bestaan met de betreffende leverancier

5. Herformuleer negatieve requirements

Dit zijn requirements die aangeven wat het systeem niet mag doen of waaraan de gebruiker geen behoefte heeft. Om een negatief requirement te implementeren hoeft het systeem dus helemaal niets te doen. Een systeem dat alleen negatieve requirements hoeft te implementeren is snel gebouwd. Het zegt daarom meer als het requirement aangeeft onder welke voorwaarde het systeem wel een actie moet uitvoeren.

Voorbeeld van een negatief requirement:

  • De vacaturesite hoeft de ingevoerde gegevens niet te bewaren als de sollicitant op geen enkele vacature reageert


Deze requirements kan beter positief geformuleerd worden:

  • De vacaturesite moet de ingevoerde gegevens opslaan als de sollicitant op één of meer vacatures reageert.
Deze blog is geschreven door Nicole de Swart. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van reaco
Nicole de Swart
Reaco Academy - Requirements expert

Nicole de Swart is auteur van Handboek Requirements en oprichtster van het Requirements Kenniscentrum. Via de Reaco Academy helpt Nicole requirementsanalisten de overstap naar agile te maken. Daarnaast geeft ze les aan studenten Business Information & Management op de Hogeschool van Amsterdam.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.