Hoe schrijf je een goede software requirement?

Wat is een software requirement?

Een software requirement is een voorwaarde waar software aan moet voldoen. De gewenste functionaliteit van software wordt vastgesteld aan de hand van zgn. software requirements specificaties.

Wanneer heb je een software requirement nodig?

Voordat je een software-systeem of website gaat bouwen of updaten wordt in de vorm van requirements gedefinieerd waar de nieuwe software precies aan moet voldoen.

Je hebt requirements dus nodig vóór en tijdens het bouwen/updaten van software.

Wat is het belang van een goed geschreven requirement?

Een requirement is als het ware het contract tussen opdrachtgever en programmeur(s). Aan de hand van de requirement gaan de programmeurs aan de slag om te zorgen dat de software aan het gevraagde voldoet.

Als een requirement dus niet goed wordt opgesteld (bijvoorbeeld onduidelijk, ambigu, etc) dan zal de software die hieruit voortkomt hoogstwaarschijnlijk niet voldoen aan wat de opdrachtgever voor ogen had.

Software requirements zijn dus zeer belangrijk, en het slagen van een software project hangt mede af van het schrijven van goede requirements!

Hoe schrijf je dan een goede requirement?

Allereerst zijn er enkele voorwaarden waar een goede requirement aan moet voldoen.

Voorwaarden goede requirements

  • Eenduidig / niet-ambigu – Schrijf de requirement zó dat deze maar op één manier kan worden geïnterpreteerd. Taalgebruik en uitleg zijn dus zeer belangrijk.
  • Compleet / volledigheid – De requirements moeten het gehele systeem beschrijven, inclusief het gewenste gedrag en de benodigde features.
  • Consistent – Verschillende requirements mogen elkaar niet tegenspreken.
  • Prioriteit – Geef de requirements een prioriteit. Het is niet ongewoon dat software projecten langer duren dan vooraf ingeschat. Zorg er daarom voor dat de belangrijkste functionaliteit (en dus requirements) van het systeem als eerste worden geïmplementeerd. Een prioriteitenset van low-medium-high is voor de meeste projecten genoeg.
  • Testbaarheid – Het moet mogelijk zijn om na implementatie duidelijk te testen of de requirement is vervuld, zo niet, dan is de requirement normaal gesproken niet goed geschreven.
  • Tracking / Traceability – Dit geldt met name voor grotere projecten; Je kunt er voor kiezen om bij te houden waar in het design, waar in de code, en waar in de tests de requirement naar voren komt. Dit kun je bijvoorbeeld bijhouden in een traceability matrix. Dit is in sommige gevallen echter overkill voor kleinere projecten.

Voorbeelden slechte requirements

Om je een idee te geven van wat er fout kan gaan bij het schrijven van requirements, hieronder enkele voorbeelden van slechte requirements:

  • De website moet snel zijn.
  • Het systeem moet “Machine Learning” gebruiken.
  • Onze software moet alleen leden toelaten.

Bovenstaande voorbeelden zijn op meerdere manieren interpreteerbaar, en zijn onduidelijk over wat er precies moet gebeuren.

Voorbeelden goede requirements

Zorg ervoor dat je op een eenduidige manier beschrijft wat er moet gebeuren, en dat je naderhand de programmeur er ook op kan wijzen als iets niet voldoet:

  • 95% van alle aankopen in de webwinkel moeten binnen volledig verwerkt zijn binnen 4 seconden.
  • Om toegang tot de website te krijgen moet een gebruiker zich via een web-form registreren met zijn naam en e-mail adres, en via zijn inbox zijn inschrijving bevestigen door op een link te klikken. Pas dan krijgt de gebruiker toegang tot de content van de website.

Wat nu?

Eigenlijk heeft elk software project klein of groot requirements nodig.

Requirements voor grote projecten

Voor grote uitgebreide projecten is het gebruikelijk een heel document te maken. Zoek hiervoor op Google naar “Software Requirements Specification template” op Google, en je zult vele voorbeelden vinden van hoe je dit aan kunt pakken.

Requirements voor kleine projecten

Voor simpele websites kan je vaak al volstaan met een simpel lijstje met daarop de belangrijkste requirements.

Wat we voor kleinere projecten binnen Centillion graag doen is gebruik maken van een issue tracking systeem i.p.v. een document. Je hebt gewenste functionaliteit dan online staan en kan er met meerdere mensen tegelijk aan werken. Ook heeft iedereen altijd de meest up-to-date versie en kan je de status ook goed volgen.

Strikt genomen kan een issue tracking systeem een requirements document niet vervangen, maar in de praktijk is het voor kleine projecten vaak al meer dan genoeg, en kan het de kans van slagen van een project aanzienlijk vergroten, zonder al teveel overhead en tijdverspilling te introduceren.