We schreven eerder over hoe je succesvol credit management software implementeert. We noemen daar het opstellen van requirements en de uitwerking tijdens de implementatie. In dit artikel richten we ons op het specificeren van requirements. Waarom het belangrijk is en hoe je dat in de praktijk doet.

Het verschil tussen requirements en specificaties

Wanneer je software aanschaft of nieuwe functionaliteiten toevoegt dan heb je eisen — requirements — waar het aan moet voldoen. Bijvoorbeeld dat het een goedkeuringsproces moet ondersteunen. Een onderdeel van het inkoopproces is daarom dat leveranciers beantwoorden aan welke requirements ze kunnen voldoen. Op die manier verken je of een product een passende oplossing is.

Een requirement beschrijft abstract wat je wilt doen. In ons voorbeeld wil je dat de software een proces ondersteunt voor het goedkeuren van “iets”. Dit is voldoende voor de eerste fase. Voor de implementatie heb je meer informatie nodig en daar komen specificaties om de hoek kijken. Specificaties zoomen in op de details. Wat moet er goedgekeurd worden, welke data is er nodig, wat is de autorisatiematrix en meer.

Specificaties beschrijven wat je als opdrachtgever verwacht dat een functionaliteit — requirement — doet binnen de software. Dit onderscheid wordt regelmatig onderschat. Terwijl er weinig mensen zijn die op basis van enkel het woord goedkeuringsproces weten wat en hoe ze iets moet ontwikkelen. Je hebt daarom specificaties nodig.

Vormen van specificeren

Specificaties zijn het uitgangspunt zijn voor het ontwikkelen en configureren van software. De manier van specificeren hangt af van hoe je software implementeert.

Je kunt elk onderdeel tot in detail beschrijven — de watervalmethode —, maar dat heeft niet onze voorkeur. Je gaat tenslotte naar een nieuwe situatie, waarbij je onderweg tot nieuwe inzichten komt. Wanneer je vooraf elk detail vastlegt, dan kun je niet meer inspelen op die nieuwe inzichten.

Bij CE-iT hanteren we geen strikte methodologie, maar kijken we naar wat we in de praktijk zien werken. Je kunt onze aanpak Agile noemen — lees ook onze blog over hoe wij Agile werken — en hierbij specificeren we requirements tot een niveau dat voldoende is voor de ontwikkelaar. Wat je niet doet, is ieder punt tot in detail beschrijven. Je beschrijft dus niet hoe breed een button moet zijn en op welke plek deze staat. Dat werk je tijdens de implementatie uit.

Het voordeel van de Agile aanpak is dat er ruimte blijft voor voortschrijdend inzicht. Bij de Watervalmethode weet je — in theorie — vooraf precies wat je krijgt, alleen ontbreekt de ruimte voor het verwerken van nieuwe inzichten. Terwijl dat laatste in praktijk het product van voldoende naar goed of zelfs geweldig kan tillen.

Wat het nadenken over en het uitschrijven van specificaties oplevert

Specificeren heeft veel voordelen. We noemen de vier belangrijkste.

1) Schrijven dwingt tot helder formuleren

Waar je met mensen samenwerkt, ontkom je niet aan communicatie. Specificeren is ook een vorm van communicatie, want je legt uit wat de wensen zijn. Het dwingt je daarmee om na te denken over wat je daadwerkelijk wilt. Wat heb je nodig? Welke uitkomst verwacht je bij een proces?

Maar nadenken alleen is onvoldoende. Je moet de specificaties ook uitschrijven. Eventueel voorzien van diagrammen of andere vormen die het verduidelijken. Waar specificeren je dwingt tot nadenken, dwingt schrijven je tot helder formuleren. En helder formuleren verkleint de kans op verschillende interpretaties.

Nog een opmerking bij dit onderdeel. Afbeeldingen kunnen zorgen dat je iets sneller begrijpt, maar de tekst is leidend. Je beschrijft daarom wat er functioneel op de afbeelding gebeurt. Op die manier zorg je dat de inhoud duidelijk is en dat de focus ligt op het specificeren en niet op het ontwerp. Want ontwerpen komt pas in een latere fase.

2) De ontwikkelaar weet wat er verwacht wordt

Met heldere specificaties weet de ontwikkelaar wat het verwachte eindproduct moet kunnen. Dat betekent dat de ontwikkelaar niet bedenkt hoe iets moet werken, maar zich richt op de ontwikkeling. En dat is wat je wilt, want bij vrije interpretatie is de kans groot dat je niet krijgt wat je wilt.

3) Testen is makkelijker

Voor testen geldt hetzelfde als bij ontwikkelen. Testen wordt makkelijker, omdat vooraf bekend is wat de de software moet kunnen. Als tester doorloop je op basis van de specificaties een proces in de software.

Wanneer je test zonder specificaties dan kan het gebeuren dat een functie wordt afgekeurd, omdat het niet voldoet aan de verwachting. Een verwachting die onvoldoende is gecommuniceerd of is bijgesteld door voortschrijdend inzicht. Als je test aan de hand van gespecificeerde requirements, filter je dat. Hiermee voorkom je dat een functie onterecht wordt afgewezen. Je krijgt daarmee een beter beeld van de kwaliteit van het opgeleverde werk.

Met specificeren baken je dus het werk af, omdat je weet wat er verwacht wordt. Specificeren is daarmee ook een middel voor het sturen op een planning. Wijzigingen die zijn ontstaan door voortschrijdend inzicht neem je dan eventueel mee in een volgende iteratie. Zo voorkom je vertraging in de ontwikkeling.

4) Het bespaart geld en levert een beter product op

Specificeren levert dus duidelijkheid op. Daarmee krijg je een beter product, in minder tijd en tegen lagere kosten. Software implementeren zonder specificaties is werken met een op einde, waarbij je niet weet wanneer iets af is. Het lijkt op het bouwen van een huis. Als de bouwer vooraf niet weet wat de eisen zijn, dan voldoet de woning waarschijnlijk niet aan de verwachting. Daarom specificeer je vooraf. Dan zijn de verwachtingen vanaf het begin duidelijk en voorkom je onnodige kosten.

Hoe specificeer je?

De manier waarop je specificaties schrijft, hangt af van de uitgangssituatie. Implementeer je nieuwe software of is het een wijziging binnen bestaande software? In het laatste geval start je met de beschrijving van de huidige situatie en vervolgens de wijzigingen. Op die manier maak je inzichtelijk wat de verschillen zijn, wat er verandert en wat de invloed is op bestaande functies.

1) Breek processen in stukken

Iedere requirement bestaat uit een of meerdere onderdelen en specificeren begint met het identificeren van de verschillende onderdelen. Het opbreken van een proces zorgt voor mini-processen en die begrijpen mensen —die onbekend zijn met het proces— sneller. En wanneer je iets begrijpt, dan ontwerp, ontwikkel en test je beter.

Je doorloopt elke stap chronologisch, waardoor je de kans verkleint dat je iets vergeet. Het kan zijn dat je soms terug moet naar een eerdere stap, maar dat is niet erg.

Afhankelijk van het proces, kan het zinvol zijn dat je de stappen uittekent. Zowel voor het eigen begrip, als voor de andere mensen in het projectteam.

2) Gebruik scenario’s

Als aanvulling op het uitschrijven van processen, werken we ook met scenario’s. Deze bieden een beter inzicht in de verschillende variabelen. Een proces gaat in theorie uit van een standaard, maar in de praktijk zie je afwijkingen.

Neem als voorbeeld een aflossingsregeling op een lening. De afspraak met een individuele klant is dat deze elke maand € 100 betaalt en dat dit op de eerste dag van de maand ontvangen moet zijn. Dit is duidelijk, maar in de praktijk zie je dat het minder zwart-wit is. Voor de praktische uitvoering gelden dan aanvullende regels en bijvoorbeeld de volgende scenario’s waarin een termijn wordt gekenmerkt als nagekomen:

  • Het volledige bedrag is ontvangen op de eerste dag van de maand.
  • Het bedrag is met een marge van maximaal € 3 minder ontvangen op de eerste dag van de maand.
  • Het volledige bedrag is uiterlijk drie werkdagen na de eerste dag van de maand ontvangen.
  • Het bedrag is met een marge van maximaal € 3 minder uiterlijk drie werkdagen na de eerste dag van de maand ontvangen.

Scenario’s zijn de praktische toelichting op een proces die het plaatje compleet maken. Het plaatst de regels in context, zodat het meer gaat leven.

3) Werk niet alleen

In de meeste gevallen gebruikt meer dan een persoon de software. Dat leidt tot meerdere meningen en invalshoeken. Bijvoorbeeld door een andere manier van werken of andere verantwoordelijkheden. Voor een goed inzicht moet je daarom samenwerken met de verschillende belanghebbenden. Goede vormen zijn hierbij zijn workshops en interviews.

Een voordeel van een workshop is de mogelijkheid tot discussie. Interviews zijn persoonlijker waardoor mensen soms vrijer spreken.

Samenwerking voorkomt dat er een tunnelvisie ontstaat van één persoon.

4) Review specificaties

Reviews mogen niet ontbreken in het specificatieproces. Dit is ter controle of de uitwerking compleet en correct is, en het biedt ruimte voor nieuwe inzichten. Mensen kunnen iets vergeten tijdens een workshop of komen tot een idee wanneer ze het als geheel lezen.

Prioriteren

Een bijkomend voordeel van specificeren is dat je inzicht krijgt in welke onderdelen van een requirement vereist zijn en welke optioneel. Dit stelt je instaat tot prioriteren, waarmee je zowel op kosten als op planning stuurt. Iets wat met alleen een requirement vrijwel onmogelijk is.

Valkuilen

Het specificeren van requirements kent verschillende valkuilen waarvan we er twee uitlichten.

  1. Niet elk detail, zoals namen van personen die iets moeten goedkeuren, is belangrijk. Wel belangrijk is dat je alle stappen van een proces benoemd, inclusief en de randvoorwaarden.
  2. Specificeren is niet hetzelfde als ontwerpen. Uiterlijke kenmerken zoals het gebruik van kleur en de plaatsing van buttons zijn in deze fase niet relevant. Daar zijn standaarden voor en bovendien pas je dit eenvoudig aan.

Conclusie

Wanneer je controle wilt over het op te leveren product, dan kun je niet om specificeren heen. Het is een middel waarmee je stuurt op het eindresultaat en zorgt dat de verwachtingen duidelijk zijn. Tegelijkertijd helpt het bij het beheersen van kosten.

Downloads: via deze link download je een voorbeeld van een specificatie zoals wij die vaak gebruiken.