Wat is een softwarespecificatie en waarom wordt die niet gebruikt?

De softwarespecificatie is een van de belangrijkste documenten bij softwareontwikkeling. Toch is het een term die door bedrijven vaak verschillend wordt geïnterpreteerd - soms simplistisch als een "lijst van eisen", soms als een "klantopdracht". Maar de werkelijkheid is veel breder en dieper. Een goed opgestelde softwarespecificatie kan beide kanten van een samenwerking beschermen en het risico dat een project vertraging oploopt, op budget of op een misverstand stuit, aanzienlijk verkleinen.

In dit artikel leggen we in detail uit wat een software specificatie is en wat het niet is, wat het bevat, waarom het belangrijk is en wie het helpt, en hoe we ermee werken bij TRITON IT.

Wat is een software specificatie?

Een softwarespecificatie is een gedetailleerd document dat beschrijft wat er moet worden gemaakt, hoe het moet werken, onder welke voorwaarden het resultaat als af wordt beschouwd en met welke risico's rekening moet worden gehouden. Het is niet zomaar een "verlanglijstje" of een opdracht op papier. Het is een formele overeenkomst tussen de klant en de leverancier, waarin specifieke eisen en verwachtingen worden vastgelegd - wederzijds overeengekomen.

Het opstellen van een specificatie is meestal het onderwerp van een aparte prijsbepaling, omdat alleen op basis hiervan de prijs van het project betrouwbaar kan worden bepaald - ervan uitgaande dat deze vooraf wordt bepaald en definitief is. In het geval van agile ontwikkelingsmethodologieën kan de totale prijs variëren afhankelijk van de ontwikkelingsfasen. Daarom bevat de specificatie vaak een gedetailleerde beschrijving van het werk en de architectuur in de vorm van tekst of bijvoorbeeld UML-diagrammen.

Wat is UML?

UML (Unified Modeling Language) is een gestandaardiseerde taal voor het visueel modelleren van softwaresystemen. Het wordt gebruikt om de structuur, het gedrag en de architectuur van een systeem vast te leggen met behulp van diagrammen die het ontwerp, de analyse en de communicatie tussen ontwikkelaars vergemakkelijken. UML helpt om ideeën te vertalen naar begrijpelijke modellen.

Wat is PlantUML?

PlantUML is een beschrijvende taal waarmee UML-diagrammen op een tekstuele en gestandaardiseerde manier kunnen worden gedefinieerd. Terwijl UML zelf slechts een grafische notatie is, biedt PlantUML een manier om deze diagrammen te maken met behulp van eenvoudige code. Dit zorgt voor eenvoudige integratie in versiebeheersystemen, automatisering van documentatie en ook het genereren van diagrammen met behulp van AI, zoals grote taalmodellen (LLM's). Hierdoor kunnen software-architecten efficiënter AI-gebaseerde systeemarchitecturen ontwerpen.

De specificatie heeft als doel ambiguïteit weg te nemen. Op het moment dat de ontwikkeling begint zonder een precieze specificatie, ontstaan er veronderstellingen, interpretaties en ruimte voor fouten. Een goede specificatie bepaalt de spelregels - voor ontwikkeling, testen en overdracht.

Wat houdt een software specificatie in?

Een softwarespecificatie is een precieze en gedetailleerde leidraad voor hoe het resultaat eruit moet zien. Zie het als een gedetailleerde bouwtekening voor een huis - als u een huis wilt, is het niet genoeg om te zeggen "ik wil een huis met drie slaapkamers en een badkamer". De architect moet je een plan geven dat precies laat zien wat waar moet komen, welke materialen er worden gebruikt, waar de lichten komen, elektriciteit, waar de deuren zijn, hoe dik de muren zijn, enz.

1. Beschrijving van het werk

Hier beschrijf je eenvoudig wat er gemaakt gaat worden. Of het nu gaat om een webapp, een intern bedrijfssysteem, een mobiele app of misschien een archiveringstool. Het doel is om ervoor te zorgen dat beide partijen hetzelfde idee hebben van wat het resultaat van het project is.

Voorbeeld

2. Functionele eisen

Functionele vereisten zijn een lijst met specifieke functies die de software moet kunnen uitvoeren. Wat de gebruiker moet kunnen doen - bijvoorbeeld inloggen, een item zoeken, een profiel bewerken, een factuur downloaden. En het belangrijkste - een deel van de specificatie bevat dingen die de applicatie niet kan, ook al lijken ze voor de hand liggend.

Voorbeeld:

• Een gebruiker kan inloggen met een e-mail en wachtwoord.
  
• De app staat geen registratie toe met een Facebook- of Google-account.
  
• De beheerder kan gebruikersaccounts verwijderen.

3. Niet-functionele verzoeken

Dit zijn geen functie-eisen, maar eerder voorwaarden en beperkingen waaronder het systeem moet werken. Dit zijn bijvoorbeeld hoe snel het systeem moet reageren, op welk apparaat het moet draaien, wat de verwachte belasting van het systeem is, welke technologieën gebruikt moeten worden of welke gegevens het moet verwerken.

Voorbeeld:

• Het systeem wordt geoptimaliseerd voor mobiele telefoons.
  
• Het zal draaien op een client-server die op Linux draait.
  
• Het moet compatibel zijn met de browsers Chrome en Firefox.
  
• Het moet 500 gelijktijdig verbonden gebruikers aankunnen.
  

4. Procedures die naar het doel leiden

Dit beschrijft hoe de ontwikkeling zal verlopen. Welke stappen worden achter elkaar gevolgd, welke mijlpalen worden gesteld, hoe vaak wordt er gerapporteerd, wanneer wordt wat getest, wanneer wordt wat overgedragen.

Voorbeeld:

• Fase één: ontwerp gebruikersinterface.
  
• Fase twee: ontwikkeling van kernfunctionaliteit.
  
• Fase drie: testen en debuggen.
  
• Fase vier: acceptatie en implementatie.
  

5. Systeemstructuur

De sectie systeemstructuur laat zien uit welke onderdelen (modules) het hele systeem bestaat en wie erbij betrokken is (actoren). Modules zoals "bestelformulier", "productcatalogus", "beheerinterface". Actoren zijn verschillende typische gebruikers - bijvoorbeeld een regelmatige bezoeker, een geregistreerde gebruiker, een beheerder..

Voorbeeld:

• Module
  
• Module
  
• Actoren:
  
  • Gebruiker (maakt een reservering)
    
  • Beheerder (beheert capaciteit, bevestigt bestellingen)
    

6. Geschetste architectuur

Dit is geen diepgaand technisch ontwerp (dat komt later), maar een schets van hoe het systeem intern zal werken - hoe de verschillende onderdelen met elkaar zullen communiceren, waar de database zal worden opgeslagen, of het systeem zal worden opgedeeld in frontend en backend, wat de logica daartussen zal zijn.

Dit geeft de klant een idee van de complexiteit van de oplossing en of het past bij hun behoeften en mogelijkheden.

7. Wijze van acceptatie

Een van de belangrijkste onderdelen! Hier beschrijf je precies hoe de overdracht van het werk zal plaatsvinden. Wat er allemaal getest moet worden, hoe de checklist eruit zal zien om te controleren of het werk af is. Als de checklist is afgevinkt, is er geen ruimte voor giswerk over de vraag of alles klaar is voor de oplevering en wordt het werk zonder voorbehoud geaccepteerd.

Voorbeeld:

• Inloggen en uitloggen van de gebruiker werkt
  
• De gebruiker kan een nieuwe boeking maken
  
• Binnen 5 minuten komt er een bevestiging per e-mail binnen

8. Risico's

In dit gedeelte wordt beoordeeld wat voor complicaties zou kunnen zorgen - bijv. afhankelijkheid van derden, trage besluitvorming door de klant, integratie met externe systemen, enz. Dit onderdeel is voor iedereen belangrijk, want zelfs een goed gepland project kan tegen obstakels aanlopen die je maar beter van tevoren kunt benoemen.

Voorbeeld:

• Integratie met een mailservice van derden kan mislukken als zij de API veranderen.
  
• Te late aanlevering van documenten van de klant kan een vertraging in de opleverdatum veroorzaken.

Wat is geen software specificatie?

Een softwarespecificatie is niet zomaar een specificatie van de klant. Als een klant een e-mail stuurt waarin hij zegt dat hij een "reserveringssysteem voor capaciteitsbeheer" wil, is dat geen specificatie. Hetzelfde geldt voor een lijst met functies geschreven in Excel of een mindmap of wireframe, hoewel deze dingen deel kunnen uitmaken van de specificatie.

Een echte specificatie is een compleet document dat niet alleen de functies beschrijft, maar ook hun grenzen, omgevingen, testscenario's en acceptatievoorwaarden. Het belangrijkste is dat het ondertekend moet zijn of op zijn minst goedgekeurd door beide partijen. Anders heeft het geen gewicht.

Wat heb je eraan?

Voor de klant heeft de specificatie grote voordelen:

• Ze weten precies wat ze kopen.
  Geen verwarring over wat wel en niet geleverd wordt.
  
• Geeft een gelijk speelveld in het aanbestedingsproces.
  Als de klant besluit om meerdere bedrijven te benaderen, kunnen ze de specificatie nemen en deze ter prijs aanbieden. Ze concurreren dan allemaal voor hetzelfde - niet voor hun interpretatie.
  
• Het voorkomt het opblazen van de prijs tijdens de ontwikkeling.
  Als iets niet in de specificatie staat, kan het redelijkerwijs worden gekwantificeerd als meervoudige kosten. Maar als wat in de specificatie staat er eenmaal in staat, moet de leverancier het ontwikkelen en leveren.
  
• Dit zorgt voor een soepele overdracht.
  Bij acceptatievoorwaarden wordt duidelijk aangegeven wat er getest moet worden en onder welke voorwaarden het werk zonder voorbehoud wordt geaccepteerd.

Hoe we het bij TRITON IT doen

Voor grotere contracten of aanbestedingen maken we een softwarespecificatie als een betaalde dienst. De klant kan deze dan meenemen en aan iemand anders geven - laat meerdere bedrijven de oplossing prijzen. Als we de aanbesteding winnen, trekken we de prijs voor de specificatie af van de totale prijs. In de praktijk maakt dit de specificatie gratis voor de klant.

Tegelijkertijd staan we er niet op dat we de specificatie moeten maken. Als de klant het zelf of met een andere leverancier opstelt, is dat prima - maar wij willen het altijd zien. Zonder specificatie gaan we niet in ontwikkeling.