Door stakeholders wordt al snel gezegd dat een systeem aan de wet moet voldoen. Toch is dat niet vanzelfsprekend. Niet systemen maar mensen en organisaties moeten zich aan de wet houden.

Hoe belangrijker en ingrijpender een specifieke wettelijke regeling voor een organisatie is, hoe belangrijker het is expliciet onderscheid te maken tussen:

  • Wettelijke verplichtingen
  • Requirements
  • Bewijzen

Om hier aandacht op te vestigen hebben we een infographic gemaakt. Klik op de afbeelding om de infographic (pdf) te openen. Meer toelichting lees je hieronder.

Wettelijke verplichtingen

In de eerste plaats moet je weten wat de betreffende wetten en regels exact inhouden. Het valt lang niet altijd mee die regels helemaal te doorgronden en te bepalen wat in een concrete situatie van toepassing is. Al helemaal niet als er ook jurisprudentie meegenomen moet worden.

Wiens taak het is om uit te zoeken wat de wettelijke verplichtingen precies zijn, hangt van diverse factoren af:

  • Welke wet het is en hoe moeilijk alle nuances te begrijpen zijn?
  • Of de organisatie de betreffende wet moet naleven, uitvoeren of handhaven?
  • Wat de consequenties van een onjuiste interpretatie zijn?
  • Hoe goed de lijnorganisatie van de wettelijke details op de hoogte is?

Stem op tijd af wie verantwoordelijk is voor het interpreteren, concretiseren en vertalen van de betreffende regelgeving naar specifieke situaties.

Is dat de lijnorganisatie, de afdeling juridische zaken, een business analist en/of het agile team?

Requirements

Organisaties mogen zelf bepalen hoe ze aan haar wettelijke verplichtingen voldoen. En overheidsorganen bepalen zelf hoe ze te werk gaan bij het uitvoeren of controleren op naleving van wettelijke verplichtingen.

De vraag is hier hoe willen de stakeholders hun processen inrichten en in hoeverre willen ze die automatiseren?

Soms is het verstandiger om dingen procedureel op te lossen, al dan niet tijdelijk. Bijvoorbeeld als het gaat om uitzonderingen, om te voorkomen dat de software erg ingewikkeld wordt of om de software eerder en/of gefaseerd uit te rollen.

In tegenstelling tot wettelijke verplichtingen bepalen de stakeholders zelf hun requirements.

Bij agile softwareontwikkeling is de product owner hiervoor verantwoordelijk. Hij bepaalt in samenspraak met de teamleden en business stakeholders welke requirements gerealiseerd worden.

Bewijzen

Het keurig naleven van de wettelijke verplichtingen is in sommige branches niet genoeg. Toezichthouders zoals DNB en AFM vragen gedetailleerd bewijsmateriaal. Vraag je daarom bij het inrichten van het proces en het ontwikkelen van de software al af welke bewijslast je hebt:

  • Hoe toon je aan dat je aan de wettelijke verplichtingen voldoet?
  • Wie is de toezichthouder en waar controleert die op?
  • Moet daar bewijsmateriaal voor gemaakt worden of bepaalde controles in de software ingebouwd, bijvoorbeeld?

Het is aan de product owner om tijdens de ontwikkeling rekening te houden met de bewijslast. Als daarvoor bepaalde systeemfunctionaliteit nodig is, neemt hij dat op in de requirements en de product backlog. Overkoepelende zaken zoals documentatie en specifieke kwaliteitsstandaarden toepassen, komen bij voorkeur in de Definition of Done.

Hier is de link naar de infographic nogmaals. Het is een beknopte weergave van dit artikel.

Hoe gaat men in jouw organisatie met requirements voor wet- en regelgeving om? Zijn de verantwoordelijkheden duidelijk belegd? Welke rol speel jij daar als analist of product owner in? Laat het ons weten in een reactie onder dit artikel.

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

0 reacties

Geef een reactie