💻 computer science

From Requirements to Production: Governing AI-Assisted Software Delivery through a Canonical Requirements Model

Dit artikel presenteert een design science-studie die een governance-framework introduceert voor AI-ondersteunde softwarelevering, dat gebruikmaakt van een canoniek vereistenmodel, een dual-vendor build-and-review-lus en uitvoerbare documentatie om een hoge traceerbaarheid en naleving te bereiken over twee onafhankelijke productiesystemen heen, terwijl de rol van de business analyst wordt geherdefinieerd.

Oorspronkelijke auteurs: Mohamed Zahran

Gepubliceerd 2026-07-21

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Mohamed Zahran

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

De Nieuwe Regels van de Weg voor Robotbouwers

Stel je voor dat je een meesterarchitect bent die jarenlang blauwdrukken heeft getekend voor menselijke bouwploegen. Je weet dat als je een klein gaatje in de plannen laat — zoals het vergeten te specificeren van de kleur van de voordeur — een bekwame menselijke bouwer gewoon aan je zal vragen: "Hé, welke kleur wil je?" of de kleur zal raden op basis van de stijl van de buurt. Zij vullen de gaten in met hun eigen gezond verstand en ervaring. Zo heeft softwareontwikkeling decennialang gewerkt: een mens schrijft de eisen en een menselijk team bouwt de software, waarbij zij de ontbrekende details gaandeweg invullen.

Maar stel je nu voor dat je een vloot supersnelle, superslimme robotbouwers inhuurt. Deze robots zijn geweldig; ze kunnen stenen leggen en bedrading aanleggen in seconden. Echter, ze hebben één groot gebrek: ze zijn letterlijke wezens. Ze hebben geen gezond verstand, ze raden niet en ze stellen zeker geen vragen. Als je een robot de opdracht geeft om "een deur te bouwen" maar niet de kleur specificeert, kan hij de deur neongroen schilderen omdat dat de meest logische kleur is in zijn database, of hij kan stoppen en vastlopen omdat hij niet weet wat hij moet doen. In de wereld van software is dit de uitdaging van AI-ondersteunde ontwikkeling. De "vereisten" (de instructies) die perfect werkten voor mensen, zijn nu gevaarlijk voor robots, omdat robots de gaten niet kunnen invullen. Als de instructies niet perfect zijn, bouwen de robots het verkeerde, en dat gebeurt zo snel dat de fout al in het eindproduct zit voordat iemand het merkt. Dit artikel onderzoekt hoe we de regels van de weg kunnen herschrijven, zodat deze robotbouwers vertrouwd kunnen worden om veilige, werkende software te construeren zonder dat een mens elke seconde hun hand vast hoeft te houden.

Van "Misschien" naar "Moet": Een Nieuwe Manier om met AI te Bouwen

Het artikel, geschreven door Mohamed Zahran, pakt een groot probleem aan: AI-coderingsagenten zijn snel, maar ze zijn gevaarlijk als de instructies niet perfect zijn. De auteur betoogt dat de oude manier van het schrijven van eisen — documenten ontworpen voor menselijke teams die "tussen de regels door kunnen lezen" — kapot is wanneer de bouwer een machine is. Als een mens een onvolledige instructie leest, gebruikt hij zijn brein om het te corrigeren. Als een robot een onvolledige instructie leest, raadt hij het gewoon in, en die gok verandert vaak in een bug of een beveiligingslek.

Om dit op te lossen, heeft de auteur niet alleen een nieuwe theorie geschreven; hij heeft ook twee echte, werkende softwaresystemen gebouwd met een nieuwe methode die hij zelf heeft ontworpen. Denk aan een chefkok die, in plaats van alleen een kookboek te schrijven, daadwerkelijk twee verschillende complexe maaltijden heeft gekookt in een stressvolle keuken om te bewijzen dat zijn nieuwe recept werkt.

Het Kernidee: De "Single Source of Truth"
De oplossing van de auteur is een "Governed AI-Ready Delivery Framework". De grootste verandering is de verschuiving weg van losse documenten (zoals Word-bestanden) die rommelig kunnen worden en verschillende versies van hetzelfde kunnen bevatten. In plaats daarvan creëerde hij een Canonical Requirements Model.

De Analogie: Stel je een meester digitale blauwdruk voor die in een beveiligde kluis leeft. Deze blauwdruk is de enige ware versie van het plan.
De Magie: Vanuit deze ene meesterblauwdruk genereert het systeem automatisch twee verschillende "weergaven":
1. De Menselijke Weergave: Een prettig leesbaar document voor de Business Analyst en managers om goedkeuring op te geven.
2. De Robot Weergave: Een strikt, machineleesbaar instructiepakket voor de AI-coderingsagenten.
Waarom het belangrijk is: Omdat beide weergaven van dezelfde meesterblauwdruk afkomen, kunnen ze nooit uit elkaar lopen. De mens kan geen plan goedkeuren waar de robot niet daadwerkelijk het gevolg van is. Het is alsoast het hebben van een enkele bron van waarheid die iedereen direct bijwerkt.

De "Vier-ogen-regel" voor Robots
Het artikel introduceert een slimme veiligheidscontrole genaamd Separation of Duties, maar dan voor robots.

De Opstelling: De auteur gebruikte twee verschillende AI-coderingsinstrumenten van twee verschillende bedrijven (vendors).
Het Proces: Eén AI (Vendor A) was de "Bouwer". Het schreef de code op basis van de instructies. Een totaal andere AI (Vendor B) was de "Inspecteur". Het bekeek de code om te controleren op fouten, beveiligingslekken en of het overeenkwam met het plan.
Het Resultaat: Dit voorkwam dat de AI een huis bouwde en zichzelf vervolgens een voldoende gaf. De "Inspecteur"-AI ving dingen op die de "Bouwer"-AI had gemist, net zoals een menselijk team dat zou doen.

De Bevindingen: Snelheid Zonder Chaos
De auteur testte dit framework op twee zeer verschillende projecten:

Geval 1: Een platform voor bescherming (safeguarding) voor 170 nationale organisaties (een groot, complex, traag bewegend project).
Geval 2: Een multi-tenant analysewerkruimte voor business analisten (een sneller, kleiner project met extra beveiligingsregels voor creditcards).

De resultaten waren indrukwekkend. Het framework liet de AI ongelooflijk snel werken terwijl alles onder controle bleef:

Traceerbaarheid: Het systeem hield bij waar elk stukje code vandaan kwam. In Geval 1 was 94,9% van de eisen perfect gekoppeld aan de code en de tests; in Geval 2 was dit 97,8%.
Geen Onbevoegde Wijzigingen: In beide gevallen was het percentage onbevoegde wijzigingen 0,00%. Het systeem was zo strikt dat niemand (of geen enkele robot) stiekem de code kon veranderen zonder dat het systeem het wist.
Minder Fouten: De "defect escape rate" (bugs die het eindproduct bereikten) was 9,1% in het eerste geval en 4,7% in het tweede geval. Het tweede geval was zelfs beter dan het "best-in-class" industrie gemiddelde.
Snelheid: Het framework vertraagde de boel niet. Sterker nog, het tweede project werd in slechts 31 kalenderdagen opgeleverd (met slechts 12 actieve bouwdagen), wat ongelooflijk snel is voor dat niveau van complexiteit.

Wat de Auteur Ziet als Niet de Oplossing
Het artikel is heel duidelijk over wat niet werkt. Het spreekt zich uit tegen het idee dat je simpelweg een vage prompt aan een AI kunt geven en de rest laat uitzoeken. Het waarschuwt ook dat het toevoegen van AI aan een project alleen omdat het "modieus" is, een slecht idee is; soms is een eenvoudige proceswijziging beter dan het gebruiken van AI. De auteur benadrukt dat AI het menselijk oordeel, zakelijke helderheid of de noodzaak voor een mens om het eindresultaat te keuren, niet kan vervangen.

Hoe Zeker Zijn We?
De auteur is voorzichtig met de claim dat dit een wondermiddel is dat alles voor altijd oplost. De studie is gebaseerd op twee specifieke gevallen die werden opgeleverd door dezelfde persoon (de auteur). Hoewel de resultaten zeer sterk en consistent zijn over twee zeer verschillende soorten projecten, geeft de auteur toe dat, omdat zij de enige persoon waren die het werk uitvoerde, we niet 100% zeker kunnen weten of dit exact hetzelfde zou werken voor een heel team van verschillende mensen zonder meer testen. Ze ontdekten ook dat hoewel het systeem geweldig was in het opvangen van duidelijke fouten, het soms "stille fouten" (bugs die niet direct zichtbaar zijn) miste, wat betekent dat mensen nog steeds af en toe een diepe controle moeten uitvoeren.

De Belangrijkste Conclusie
Het artikel concludeert dat de rol van de Business Analyst verandert. Ze zijn niet langer alleen schrijvers van documenten voor andere mensen. Ze worden de architecten van controlesystemen. Hun taak is het ontwerpen van het "governed delivery framework"—de regels, de controles en de meesterblauwdruk—die AI in staat stellen om veilig software te bouwen. De toekomst gaat niet over mens versus AI; het gaat over mensen die de perfecte instructies ontwerpen, zodat AI het zware werk kan doen zonder iets kapot te maken. Zoals de auteur het verwoordt: "In het AI-tijdperk wordt de Business Analyst niet langer alleen gedefinieerd door wat hij schrijft, maar door wat hij anderen — zowel mens als AI — in staat stelt te leveren."

Technische Samenvatting: Het besturen van AI-ondersteunde softwarelevering door middel van een canoniek vereistenmodel

1. Probleemstelling

Het artikel identificeert een fundamentele breuk tussen traditioneel requirements engineering en AI-ondersteunde softwarelevering. Business Analysts (BA's) hebben historisch gezien artefacten geproduceerd (bijv. Business Requirements Documents, user stories) die ontworpen zijn voor menselijke leveringsteams. Deze documenten vertrouwen op "tacit knowledge" (stilzwijgende kennis), domeinoordeel en gesprek om hiaten in de specificatie op te vullen. Wanneer de uitvoerder verschuift van een deskundige menselijke ontwikkelaar naar een autonome AI-coderingsagent, verbreekt dit impliciete contract. AI-agenten concluderen geen ontbrekende details; zij gaan uit van de "meest plausibele interpretatie", waardoor onvolledige specificaties veranderen in bronnen van defecten.

Verder betoogt het artikel dat de huidige industriële focus op snelheid vaak leidt tot de gevaarlijke aanname dat gestructureerde business analyse onnodig is. Bewijs suggereert dat zonder rigoureuze probleemdefinitie en governance, AI-projecten kampen met hoge faalpercentages door een slechte workflow-fit, onvoldoende data en zwak eigenaarschap. Het kernprobleem is het gebrek aan een governance-framework dat AI-agenten in staat stelt om vereisten betrouwbaar uit te voeren, terwijl menselijke verantwoording, traceerbaarheid en functiescheiding behouden blijven.

2. Methodologie

De studie maakt gebruik van een Design Science Research (DSR) benadering. De bijdrage is een doelgericht operationeel artefact — een beheerd leveringsframework — dat is geconstrueerd, toegepast en verfijnd tijdens de levering van twee onafhankelijke, live productiesystemen.

Onderzoekssetting: Twee verschillende casussen geleverd door een enkele solo-operator (de auteur):
- Casus 1: Een meertalig platform voor veiligheidsbeoordeling voor 170 nationale organisaties (GDPR/OWASP-compliance). Geleverd over 17 weken (~320 uur).
- Casus 2: Een multi-tenant analyse-workspace SaaS-product voor business analysts (GDPR + PCI DSS SAQ A compliance). Geleverd in 31 kalenderdagen (~165 uur).
Databronnen: De studie analyseerde de volledige versiebeheergeschiedenis, governance-artefacten (module packs, agent prompts, review checklists) en de broncode van beide systemen.
Evaluatiestrategie: Het framework werd geëvalueerd tegen zes operationele maten berekend uit de leveringsgegevens. De studie erkent methodologische beperkingen, waaronder het gebrek aan gematchte controles voorafgaand aan het framework en de bias van de enkele operator, waarbij de resultaten worden geframed als haalbaarheidsdemonstraties in plaats van statistisch generaliseerbare causale claims.

3. Het Ontworpen Artefact: Een Beheerd AI-Klaar Leveringsframework

De kernbijdrage is een framework dat vereisten herontwerpt van communicatiemiddelen naar uitvoerbare controle-instrumenten. Het rust op drie ontworpen elementen:

A. Het Canonieke Vereistenmodel

Het framework vervangt uiteenlopende documenten door een enkel, versioneerd canoniek model, $M(m, v)$ , voor elke module $m$ op baseline $v$ . Dit model bevat:

R: Vereisten en acceptatiecriteria.
D: Architectuur en ontwerpbeslissingen.
C: Constraints (bedrijfsvoering, technisch, beveiliging, toegankelijkheid).
T: Testgevallen en validatiebewijs.
P: Provenance (herkomst) en traceerbaarheidsrelaties.
A: Goedkeuringsstatus en verantwoordelijke besluitvormers.
H: Versie en wijzigingsgeschiedenis.

Gecontroleerde Projecties: Menselijk leesbare documenten (Assurance Packs) en machineleesbare repository-bestanden (Agent Packs) zijn geen aparte bronnen van waarheid. Ze zijn gegenereerd als gecontroleerde projecties, $O(i, m, v)$ , vanuit het enkele canonieke model met behulp van specifieke exportprofielen. Dit zorgt ervoor dat het document dat een stakeholder ondertekent en de code die een agent uitvoert, aantoonbaar consistent zijn.

B. Functiescheiding via de Dual-Vendor Loop

Om het "vier-ogen-principe" toe te passen op autonome agenten, dwingt het framework een dual-vendor build-and-review loop af:

Build Agent: Eén AI-vendor (bijv. Vendor A) krijgt de taak om code en implementatie-artefacten te genereren.
Review Agent: Een tweede, onafhankelijke AI-vendor (bijv. Vendor B) voert onafhankelijke review, beveiligingsvalidatie en defectdetectie uit.
Human Gate: Verantwoordelijke mensen geven bij elke poort goedkeuring. De review-agent keurt niet de productie goed; zij levert bewijslast voor menselijke besluitvormers.

C. Documentatie als een Uitvoerbaar Controleoppervlak

Vereisten worden geherstructureerd om expliciet, testbaar en traceerbaar te zijn. Het framework bevat specifieke artefacten zoals:

AI Build Governance Pack: Definieert grenzen, verboden acties en validatieregels voor de build-agent.
Independent Reviewer Prompt/Contract: Een beheerd contract voor de review-agent om te valideren tegen de goedgekeurde baseline.
Pack Manifest: Een machineleesbaar record dat gegenereerde bestanden bindt aan hun oorspronkelijke baseline, wat herkomst garandeert en drift detecteert.

Change Control: Als een vereiste verandert, keert het voorstel terug naar het canonieke model. Na goedkeuring wordt een nieuwe baseline ( $v+1$ ) aangemaakt, en alle beïnvloede outputs (menselijk en machine) worden gelijktijdig geregenereerd. Dit voorkomt "specification drift", waarbij menselijke documenten en instructies voor agenten uiteenlopen.

4. Resultaten

Het framework werd geëvalueerd over de twee casussen aan de hand van zes operationele maten. De resultaten tonen consistentie aan over verschillende domeinen, schalen en leveringssnelheden:

Maatstaf	Casus 1 (Safeguarding Platform)	Casus 2 (Analysis Workspace SaaS)
Traceability Coverage	94,9% (185/195 vereisten)	97,8% (496/507 vereisten)
Output Divergence	0,5 substantiële divergenties per baseline	0,0 substantiële divergenties per baseline
Baseline Compliance	99,2% van activiteiten tegen huidige baseline	99,7% van activiteiten tegen huidige baseline
Unauthorised-Edit Rate	0,00% (0/924 outputs)	0,00% (0/343 outputs)
Defect Escape Rate	9,1% (31/341 defecten)	4,7% (8/169 defecten)
Change Propagation	Mediaan 16 min	Mediaan 0 min (single commit)

Traceerbaarheid: Een hoge dekking werd bereikt, waarbij de enige systematische kloof de automatische testkoppelingen voor minder belangrijke UI-functies waren.
Consistentie: De "gecontroleerde projectie"-aanpak resulteerde in bijna nul divergentie tussen menselijke en agent-artefacten.
Governance: De structurele handhaving van de pipeline (bijv. het verwerpen van niet-gecommitteerde lokale wijzigingen) bereikte een "unauthorised edit rate" van 0,00%.
Defecten: De defect escape rates lagen binnen of net boven de industrie-standaard. De studie merkte echter op dat de langstlevende defecten "silent failures" waren (controles afwezig zonder zichtbare fouten), die de snelle inner loop miste en pas naar voren kwam tijdens bewuste volledige repository-reviews.

5. Betekenis en Claims

Het artikel claimt een governance-architectuur voor AI-ondersteunde levering te bieden en een bijbehorende herdefinitie van de rol van de Business Analyst.

Herdefinitie van de BA: De BA wordt niet langer uitsluitend gedefinieerd door wat zij schrijven, maar door wat zij anderen (mens en AI) in staat stellen te leveren. De rol verschuift van het schrijven van specificaties voor collega's naar het schrijven van controle-instrumenten voor machine-executeurs en het besturen van de AI-leveringspipeline.
Haalbaarheid van Snelheid + Controle: De studie demonstreert dat het toevoegen van rigoureuze governance (functiescheiding, traceerbaarheid, baseline-controle) het snelheidsvoordeel van AI niet tenietdoet. In Casus 2 leverde het framework tweemaal zoveel modules in een kwart van de tijd van Casus 1, terwijl een hogere compliance en nul ongeautoriseerde wijzigingen werden behouden.
Single Source of Truth: Het artikel valideert dat een enkel canoniek model zowel menselijke assurance als machine-executie kan dienen zonder dat er uiteenlopende bronnen van waarheid ontstaan, mits de outputs worden gegenereerd als gecontroleerde projecties.

Bescheidenheid van Claims:
Het artikel stelt expliciet dat deze resultaten haalbaarheidsdemonstraties zijn uit een casestudy met twee gevallen door een enkele operator. Het claimt geen statistische generaliseerbaarheid. De auteurs erkennen dat de evaluatie geen gematchte controles voorafgaand aan het framework heeft en dat de metriek "defect escape" berust op het oordeel van de auteur. De primaire bijdrage is het ontwerp van een methode die AI-ondersteunde levering bestuurbaar, veilig en traceerbaar maakt, waarbij de last van duidelijkheid verschuift van de menselijke interpreet naar het gestructureerde vereisten-artefact.