KMO’s, vooral dan de relatief weinig gesofistikeerde KMO’s of de KMO’s met relatief weinig resources, hebben nogal de neiging om amateuristisch te werk te gaan.

Zo blijkt uit de praktijk bijvoorbeeld dat zij geen gedocumenteerd proces hebben voor de uittekening, de ontwikkeling, het testen en de deployment van software; laat staan dat hun software gedocumenteerd is.

Dit kan trouwens ook het geval zijn wanneer een organisatie de ontwikkeling, de deployment en het latere beheer van de software outsourcen aan een extern informatica bedrijf.

Dit heeft tot gevolg dat wanneer bijvoorbeeld de software ontwikkelaars na enige tijd de organisatie verlaten de kennis van de software verloren gaat.

In het beste geval kan men misschien nog een gebruikershandleiding hebben, maar de technische documentatie van de software ontbreekt doorgaans.

Requirements

Om te kunnen voldoen aan de GDPR verplichtingen van de verwerkte persoonsgegevens, zoals bijvoorbeeld de verplichting inzake gegevensbescherming door ontwerp en door standaardinstellingen, indien nodig het opstellen van een DPIA, etc. is het belangrijk dat men beschikt over gedocumenteerde requirements van de software.

Met gedocumenteerde requirements kan men achteraf gemakkelijker nagaan en eventueel aantonen dat de software aan de nodige vereisten voldoet; hetgeen veel moeilijker is wanneer men niet over documentatie beschikt.

Voor wat software development betreft wordt er doorgaans een onderscheid gemaakt tussen business -, functionele en niet-functionele requirements.

Hieronder zullen we enkel kort de business – en de functionele requirements bespreken.

De tekst is immers niet bedoeld als uitgebreide informatiebron inzake business – en functionele requirements, noch hoe men deze het best opstelt. Daarvoor zijn er andere bronnen beschikbaar.

Business requirements

De basis wordt gevormd door de business requirements.

Business requirements kunnen soms ook deel uitmaken van de business case.

Deze requirments bevatten de achtergrond, het doel, de reden, de noden, de stakeholders, de veronderstellingen, de risico’s, het minimum aanvaardbaar te leveren product, de criteria waarop men de testen zal uitvoeren om de oplevering te aanvaarden, etc.

Een organisatie dat software ontwikkelt of laat ontwikkelen zou dergelijke requirements moeten documenteren, zodat nadien erop een beroep kan worden gedaan naar de reden, de omstandigheden, de assumpties en de risico’s van het software project.

Business requirements kunnen nadien, indien nodig, ook de uitvoering van een DPIA vergemakkelijken; doordat men sommige gegevens reeds op papier heeft staan, w.o. het doel, de reden en de risico’s die reeds in de business requirements zijn opgenomen.

Functionele requirements

In tegenstelling tot het waarom, zoals voorzien in de business requirements, definieert men via de functionele requirments wat het te ontwikkelen software systeem precies moet kunnen doen; m.a.w. het gedrag en de werking van het te ontwikkelen software systeem.

Zo moet het software systeem bijvoorbeeld aan de gebruiker enkel die velden van een webformulier tonen waarvoor die gebruiker toegangsrechten heeft, enkel invulformulieren tonen wanneer de gebruiker is ingelogd, dat er een mogelijk aanwezig moet zijn om een gebruiker te identificeren en te authentificeren, etc.

Dergelijke requirements worden doorgaans gedefinieert onder de vorm van stories en epics. Dit laatste is gewoon een grote story.

Stories en epics kunnen dan worden opgedeeld naar de verschillende betrokken actors, bijvoorbeeld de applicatie zelf of een sub-systeem van de applicatie, de user, …

In sommige gevallen gebeurt het definiëren van functionele requirements ook via use-cases, zoals in UML.

M.a.w. het gaat hier om een exhaustieve opsomming van alle gevallen waarmee het te ontwikkelen software systeem zal worden geconfronteerd, en hoe het software systeem daarop zal reageren.

De documentatie van deze uitgeschreven functionele requirements kunnen toelaten om na te gaan welke hiaten op het vlak van gegevensbescherming, de juistheid van de gegevens etc. de software applicatie heeft. Ze kan, net zoals de business requirements, ook dienen ter ondersteuning van het maken van een DPIA en om aan te tonen dat de te ontwikkelen of ontwikkelde software applicatie de beginselen van de GDPR respecteert.

Helaas, in een KMO-omgeving ontbreekt dergelijke documentatie vaker dan men denkt. Dit kan problemen geven o.a. wanneer men bijwerkingen (updates) van de software voorziet, wanneer ontwikkelaars de organisatie verlaten, etc.

Het is daarom ten zeerste aan te bevelen om de aanwezige software volledig te documenteren.

Bloep, 22 oktober 2025.