Voor een professionele softwareontwikkelaar zijn specificaties het belangrijkst. Specificaties vertellen je namelijk wat de klant wil. Als je zonder specificaties aan de slag gaat is de kans groot dat je iets bouwt waar de klant helemaal niet op zit te wachten. In het ergste geval kun je dan al het gedane werk weggooien en opnieuw beginnen. Het is daarom belangrijk om met de klant in overleg te gaan over de precieze wensen die hij heeft.

Bij DSW brengen de business analisten deze gebruikerswensen in kaart. Zij overleggen met belanghebbenden en komen met een set aan specificaties die door de ontwikkelaars moeten worden gebouwd. Meestal worden specificaties opgebouwd uit drie stappen:

1. Precondities

Dit zijn de eisen waaraan voldaan moet worden voordat de functionaliteit uitgevoerd mag worden. Bijvoorbeeld: Je kunt een verzekering van een klant niet beëindigen als hij niet verzekerd is.

2. Acties

De acties zijn de gevraagde functionaliteit, maar dan tot in detail uitgewerkt. Wat moet er bijvoorbeeld gebeuren op het moment dat er een pasgeboren baby aan een polis wordt toegevoegd? Behalve dat we hem verzekeren, zullen we ook een kraampakket en een bevestiging opsturen.

3. Postcondities

De postcondities bevatten de uitkomst van de gevraagde acties. Een postconditie van het inschrijven van een baby is dat het kraampakket verzonden is, maar ook dat er een extra verzekerde op de polis staat. De postcondities zorgen er ook voor dat de werking van de functionaliteit kan worden gevalideerd.

Omdat de ontwikkelaars de specificaties gebruiken als basis waar zij het programma op bouwen is het belangrijk dat de ontwikkelaar er iets mee kan. Om deze reden zullen specificaties altijd eerst door ontwikkelaars worden gereviewd. Als er reviewpunten worden gevonden, dan zijn deze vaak op te delen in de volgende categorieën:

• Onjuist
• Onduidelijk
• Ambigu
• Oplossingsgericht
• Implementatiegericht

Onduidelijk

De specificaties zijn onbegrijpelijk voor de ontwikkelaar. Dit kan zijn doordat de specificaties slecht verwoord zijn of moeilijke domeinspecifieketermen niet worden uitgelegd. Ook kunnen specificaties onduidelijk zijn door slechte spelling of grammatica. Dit kan uiteraard eenvoudig worden opgelost door de specificaties te herschrijven of verduidelijken. Vervelender is het als de ontwikkelaar onvoldoende begrip heeft van het probleemdomein. Een oplossing hiervoor is dat je je als ontwikkelaar hier meer in verdiept. Bijvoorbeeld door vaker in gesprek te gaan met de analist of domeinexperts. Onthoud dan wel dat er altijd weer iemand nieuw op het project gaat komen die hetzelfde probleem gaat hebben. Alles wat onduidelijk is moet dus worden vastgelegd.

Onjuist

Het kan zijn dat de analist inhoudelijk fouten heeft gemaakt bij het opstellen van de specificaties. Deze fouten worden er over het algemeen al uitgehaald door reviews van andere belanghebbenden. Daarnaast kan het voorkomen dat de specificaties onvolledig zijn. Dit is bijvoorbeeld het geval als er een post- of preconditie wordt vergeten. Ook kunnen specificaties tegenstrijdig zijn met andere specificaties voor dezelfde applicatie.

Ambigu

De specificaties kunnen op een zodanige manier worden geïnterpreteerd dat er meer dan een oplossing 'goed' is. Dit is een groot probleem. Specificaties moeten namelijk zo geschreven worden dat deze maar op één manier kunnen worden uitgelegd. Zijn de specificaties ambigu, dan is het onduidelijk hoe de applicatie precies moet werken en kan de ontwikkelaar iets anders bouwen dan dat de analist bedoeld heeft. Bovendien levert dat later bij het oplossen van bugs problemen op, omdat er ruimte voor discussie is over wat de applicatie eigenlijk had moeten doen. Een voorbeeld hiervan is de volgende postconditie:

"De verzekerde komt niet op de controlepagina"

Het is leuk dat de verzekerde niet op de controlepagina komt, maar is het een bug als ik hem naar een willekeurige andere pagina stuur? Volgens de specificaties niet, maar waarschijnlijk wordt er wel een bug ingeschoten als de gebruiker aan het einde van de test op de homepage van DSW uitkomt.

Hier is de verzekerde wel op de controlepagina terechtgekomen.

Oplossingsgericht

In de specificaties staat niet een probleem beschreven, maar een oplossing. Het oplossen van problemen met behulp van software is juist de kracht van een software ontwikkelaar. De ontwikkelaar is op de hoogte van de beste technieken en lost dagelijks soortgelijke problemen op. Als hij hierin wordt beperkt doordat er een oplossing wordt aangedragen, dan worden zijn kwaliteiten niet ten volste benut.

Implementatiegericht

In de specificaties wordt een specifieke technische implementatie beschreven om een probleem op te lossen. Implementatiegericht en oplossingsgericht lijken erg op elkaar, maar er is een verschil:

"Het systeem slaat de gegevens in de database op"

Waar het bij oplossingsgericht gaat om een functionele, gaat het hier om een technische keuze. De keuze voor de implementatie is echter aan de ontwikkelaar. De ontwikkelaar weegt onder andere af of er een betere technologie voorhanden is voor dit specifieke probleem. In dit geval kan het handiger zijn om de gegevens in een simpel tekstbestand op te slaan. Specificaties zouden op een functionele manier beschreven moeten worden. Hier zou dat iets worden als:

"Het systeemslaat de gegevens op"

Op deze manier is het ook beter testbaar. De tester hoeft niet in de database op zoek te gaan naar de gegevens, maar hij kan eenvoudigweg controleren of hij de gegevens later nog terug kan vinden via de applicatie zelf. Merk ondanks deze reviewpunten op dat de specificaties eigendom zijn van de analisten, niet van de ontwikkelaars. Een ontwikkelaar zal specificaties niet wijzigen. Hij is er wel voor verantwoordelijk dat de specificaties niet af gaan wijken van de applicatie. Als dit gebeurt dan zal het gevoel van eigendom van de analist minder worden, waardoor hij zich minder betrokken voelt bij de applicatie. Daarnaast is er meer ruimte voor discussie over of iets wel of geen bug is. Het is daarom belangrijk om de applicatie alleen aan te passen nadat de specificaties zijn aangepast. Dit is de verantwoordelijkheid van de analist, maar in het bijzonder van de ontwikkelaar. Een ontwikkelaar heeft namelijk de mogelijkheid om de software aan te passen zonder dat daar specificaties voor zijn. Je zult dan net zien dat precies daarop een bug binnenkomt waar je het als ontwikkelaar niet mee eens bent. Dan kun je in een discussie belanden waar je niet uitkomt.

Zo bureaucratisch als hierboven beschreven gaat het in de praktijk natuurlijk niet. Je zult best wel eens een wijziging doorvoeren zonder dat de specificaties van tevoren worden aangepast. Ook zal de analist weleens vergeten om de specificaties achteraf aan te passen. Uiteraard zal hier dan precies die bug op worden gevonden en kom je in die discussie terecht. Door goede specificaties te hebben voor de rest van je applicatie zal dit niet te vaak voorkomen en is die enkele discussie ook wel weer op te lossen. Tot slot nog één keer de kenmerken van goede specificaties:

• Het probleem wordt beschreven, niet de oplossing en niet de implementatie.
• Ze zijn testbaar
• De applicatie doet precies wat de specificaties zeggen, niet meer en niet minder.
• Als er een bug wordt ingeschoten, dan is eenvoudig aan te wijzen waarom dit een bug is en wat de oplossing moet zijn.