1 Het programma van eisen

Iedere applicatie wordt ontworpen aan de hand van een aantal criteria, meestal bepaald door de opdrachtgever. Dit hoofdstuk geeft een overzicht van de informatie die de ontwerper nodig heeft om van start te kunnen gaan.

1.1 Doel en bereik

Voordat gestart wordt met het ontwerpen van een applicatie moeten het doel en het bereik (Engels: scope) van de applicatie zijn vastgelegd.

Voorbeeld

Het doel van een te bouwen webshop is om klanten via internet producten te laten bestellen.

Het bereik beschrijft kort en bondig wat de applicatie wel en niet doet.

Voorbeeld

Het bereik van een te bouwen webshop is het bestellen en betalen door klanten, het verschepen vanuit het magazijn en gebruikersbeheer.

Voorraadbeheer, retourzendingen, creditering, btw-berekeningen en het maken van facturen vallen buiten het bereik van deze applicatie.

Om de kosten en de doorlooptijd van het ontwerpen en bouwen van de applicatie zo laag mogelijk te maken, is het de kunst om het bereik zo klein mogelijk te maken.

1.2 Het programma van eisen

Meestal wordt het bereik nader uitgewerkt in een programma van eisen (Engels: requirements).

Voorbeeld

Het programma van eisen van bovengenoemde webshop bevat onder andere de volgende eisen:

Klanten kunnen zichzelf als klant registreren via internet.

Geregistreerde klanten kunnen producten bestellen.

Een bestelling wordt verscheept nadat de klant betaald heeft.

Een klant kan betalen via iDeal.

Een productbeheerder bepaalt welke producten er zijn en hun prijs.

Alle prijzen en bedragen zijn inclusief btw.

Het bereik en het programma van eisen beschrijven wat de applicatie doet, zonder in te gaan op hoe de applicatie dit doet. Het hoe wordt beschreven in het ontwerp.

1.3 Use cases

Vaak bevat het programma van eisen een aantal UML use case diagrammen. Deze tonen door middel van lijnen welke actoren (gebruikersrollen, aangeduid met een draadpoppetje) welke use cases (scenario’s, aangeduid met een ellips) kunnen uitvoeren.

Een use case beschrijft alleen de interactie, niet de interne werking van het systeem. Use cases kunnen goed met eindgebruikers besproken worden, omdat ze aansluiten bij hun belevingswereld.

De naam van een use case bestaat over het algemeen uit een zelfstandig naamwoord en een werkwoord.

Voorbeeld

In dit voorbeeld kunnen klanten en verkopers producten aan een winkelwagen toevoegen en bestellingen plaatsen. Een magazijnbediende kan de bestelling verzenden.

1.4 Onduidelijkheden in het programma van eisen

Het is een taak van de ontwerper om, als het programma van eisen onduidelijk of onvolledig is, deze onduidelijkheden en onvolledigheden weg te nemen door de juiste vragen hierover te stellen aan de opdrachtgever of een domeinspecialist.

Voor de traceerbaarheid is het verstandig om een logboek bij te houden van deze vragen en de antwoorden erop. Dit maakt het eenvoudig om later de juiste persoon te vinden als er nog meer detailvragen beantwoord moeten worden, of om te achterhalen waarom een bepaalde eis gesteld is. Dit laatste is vooral relevant wanneer in een later stadium het belang van verschillende eisen tegen elkaar moet worden afgewogen, bijvoorbeeld als er onvoldoende tijd of geld blijkt te zijn om aan alle eisen te voldoen.

1.5 Oefening voor een programma van eisen

Om de oefeningen in dit boek zo realistisch mogelijk te maken, kunt u de oefeningen het best toepassen op maatwerksoftware die de organisatie waar u werkt daadwerkelijk wil (laten) realiseren. Indien u (nog) niet bij een organisatie werkt waar dit mogelijk is, kies dan bijvoorbeeld een organisatie waar mensen werken die u kent, en met wie u hierover kunt praten.

Maak een keuze welke te realiseren maatwerksoftware u in alle oefeningen in dit boek gaat gebruiken.

Beschrijf vervolgens in deze eerste oefening kort en bondig:

Het doel van deze maatwerksoftware.

Het bereik ervan. Maak het bereik zo klein mogelijk, om de kosten en doorlooptijd van het realiseren ervan zo laag mogelijk te maken.

Het programma van eisen van deze maatwerksoftware, inclusief de use cases.