💻 computer science

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

This paper presents a design science study introducing a governance framework for AI-assisted software delivery that utilizes a canonical requirements model, a dual-vendor build-and-review loop, and executable documentation to achieve high traceability and compliance across two independent production systems while redefining the business analyst's role.

Original authors: Mohamed Zahran

Published 2026-07-21

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Mohamed Zahran

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The New Rules of the Road for Robot Builders

Imagine you are a master architect who has spent years drawing blueprints for human construction crews. You know that if you leave a tiny gap in the plans—like forgetting to specify the color of the front door—a skilled human builder will just ask you, "Hey, what color do you want?" or guess based on the style of the neighborhood. They fill in the blanks with their own common sense and experience. This is how software development has worked for decades: a human writes the requirements, and a human team builds the software, filling in the missing details as they go.

But now, imagine you hire a fleet of super-fast, super-smart robot builders. These robots are incredible; they can lay bricks and wire circuits in seconds. However, they have one major flaw: they are literalists. They don't have common sense, they don't guess, and they certainly don't ask questions. If you tell a robot to "build a door" but don't specify the color, it might paint it neon green because that's the most logical color in its database, or it might stop and crash because it doesn't know what to do. In the world of software, this is the challenge of AI-assisted development. The "requirements" (the instructions) that worked perfectly for humans are now dangerous for robots because robots can't fill in the gaps. If the instructions aren't perfect, the robots build the wrong thing, and it happens so fast that the mistake is already in the final product before anyone notices. This paper explores how to rewrite the rules of the road so that these robot builders can be trusted to construct safe, working software without needing a human to hold their hand every single second.

From "Maybe" to "Must": A New Way to Build with AI

The paper, written by Mohamed Zahran, tackles a big problem: AI coding agents are fast, but they are dangerous if the instructions aren't perfect. The author argues that the old way of writing requirements—documents designed for human teams who can "read between the lines"—is broken when the builder is a machine. If a human reads an incomplete instruction, they use their brain to fix it. If a robot reads an incomplete instruction, it just guesses, and that guess often turns into a bug or a security hole.

To fix this, the author didn't just write a new theory; they actually built two real, working software systems using a new method they designed. Think of it like a chef who, instead of just writing a cookbook, actually cooked two different complex meals in a high-stress kitchen to prove their new recipe works.

The Core Idea: The "Single Source of Truth"
The author's solution is a "Governed AI-Ready Delivery Framework." The biggest change is moving away from loose documents (like Word files) that can get messy and different versions of the same thing. Instead, they created a Canonical Requirements Model.

The Analogy: Imagine a master digital blueprint that lives in a secure vault. This blueprint is the only true version of the plan.
The Magic: From this one master blueprint, the system automatically generates two different "views":
1. The Human View: A nice, readable document for the Business Analyst and managers to sign off on.
2. The Robot View: A strict, machine-readable instruction pack for the AI coding agents.
Why it matters: Because both views come from the same master blueprint, they can never drift apart. The human can't sign off on a plan that the robot isn't actually following. It's like having a single source of truth that updates everyone instantly.

The "Four-Eyes" Rule for Robots
The paper introduces a clever safety check called Separation of Duties, but for robots.

The Setup: The author used two different AI coding tools from two different companies (vendors).
The Process: One AI (Vendor A) was the "Builder." It wrote the code based on the instructions. A completely different AI (Vendor B) was the "Inspector." It looked at the code to check for mistakes, security holes, and whether it matched the plan.
The Result: This prevented the AI from building a house and then giving itself a passing grade. The "Inspector" AI caught things the "Builder" AI missed, just like a human team would.

The Findings: Speed Without Chaos
The author tested this framework on two very different projects:

Case 1: A safeguarding platform for 170 national organizations (a big, complex, slow-moving project).
Case 2: A multi-tenant analysis workspace for business analysts (a faster, smaller project with extra security rules for credit cards).

The results were impressive. The framework allowed the AI to work incredibly fast while keeping things under control:

Traceability: The system tracked where every single piece of code came from. In Case 1, 94.9% of requirements were perfectly linked to the code and tests; in Case 2, it was 97.8%.
No Unauthorized Edits: In both cases, the rate of unauthorized changes was 0.00%. The system was so strict that no one (or no robot) could sneakily change the code without the system knowing.
Fewer Mistakes: The "defect escape rate" (bugs that made it to the final product) was 9.1% in the first case and 4.7% in the second. The second case was actually better than the "best-in-class" industry average.
Speed: The framework didn't slow things down. In fact, the second project was delivered in just 31 calendar days (with only 12 active build days), which is incredibly fast for that level of complexity.

What the Author Says is Not the Answer
The paper is very clear about what doesn't work. It argues against the idea that you can just give an AI a vague prompt and let it figure out the rest. It also warns that adding AI to a project just because it's "fashionable" is a bad idea; sometimes, a simple process change is better than using AI at all. The author emphasizes that AI cannot replace human judgment, business clarity, or the need for a human to approve the final result.

How Sure Are We?
The author is careful not to claim this is a magic bullet that solves everything forever. The study is based on two specific cases delivered by the same person (the author). While the results are very strong and consistent across two very different types of projects, the author admits that because they were the only one doing the work, we can't be 100% sure this would work exactly the same way for a whole team of different people without more testing. They also found that while the system was great at catching obvious errors, it sometimes missed "silent failures" (bugs that don't show up immediately), which means humans still need to do a deep check occasionally.

The Big Takeaway
The paper concludes that the role of the Business Analyst is changing. They are no longer just writers of documents for other humans. They are becoming the architects of control systems. Their job is to design the "governed delivery framework"—the rules, the checks, and the master blueprint—that allows AI to build software safely. The future isn't about humans vs. AI; it's about humans designing the perfect instructions so that AI can do the heavy lifting without breaking anything. As the author puts it, "In the AI age, the Business Analyst is no longer defined only by what they write, but by what they enable others — human and AI — to deliver."

Technical Summary: Governing AI-Assisted Software Delivery through a Canonical Requirements Model

1. Problem Statement

The paper identifies a fundamental disconnect between traditional requirements engineering and AI-assisted software delivery. Business Analysts (BAs) have historically produced artifacts (e.g., Business Requirements Documents, user stories) designed for human delivery teams. These documents rely on "tacit knowledge," domain judgment, and conversation to fill specification gaps. When the executor shifts from a skilled human developer to an autonomous AI coding agent, this implicit contract breaks. AI agents do not infer missing details; they proceed on the "most plausible interpretation," turning incomplete specifications into sources of defects.

Furthermore, the paper argues that the current industry focus on speed often leads to the dangerous assumption that structured business analysis is unnecessary. Evidence suggests that without rigorous problem definition and governance, AI projects suffer high failure rates due to poor workflow fit, insufficient data, and weak ownership. The core problem is the lack of a governance framework that allows AI agents to execute requirements reliably while preserving human accountability, traceability, and separation of duties.

2. Methodology

The study employs a Design Science Research (DSR) approach. The contribution is a purposeful operational artifact—a governed delivery framework—constructed, applied, and refined during the delivery of two independent, live production systems.

Research Setting: Two distinct cases delivered by a single solo operator (the author):
- Case 1: A multilingual safeguarding-assessment platform for 170 national organizations (GDPR/OWASP compliance). Delivered over 17 weeks (~320 hours).
- Case 2: A multi-tenant analysis-workspace SaaS product for business analysts (GDPR + PCI DSS SAQ A compliance). Delivered in 31 calendar days (~165 hours).
Data Sources: The study analyzed the complete version-control history, governance artifacts (module packs, agent prompts, review checklists), and source code of both systems.
Evaluation Strategy: The framework was evaluated against six operational measures computed from the delivery records. The study acknowledges methodological limitations, including the lack of matched pre-framework controls and the single-operator bias, framing the results as feasibility demonstrations rather than statistically generalizable causal claims.

3. The Designed Artifact: A Governed AI-Ready Delivery Framework

The core contribution is a framework that re-engineers requirements from communication aids into executable control instruments. It rests on three designed elements:

A. The Canonical Requirements Model

The framework replaces disparate documents with a single, versioned canonical model, $M(m, v)$ , for any module $m$ at baseline $v$ . This model contains:

R: Requirements and acceptance criteria.
D: Architecture and design decisions.
C: Constraints (business, technical, security, accessibility).
T: Test cases and validation evidence.
P: Provenance and traceability relationships.
A: Approval state and accountable decision-makers.
H: Version and change history.

Controlled Projections: Human-readable documents (Assurance Packs) and machine-readable repository files (Agent Packs) are not separate sources of truth. They are generated as controlled projections, $O(i, m, v)$ , from the single canonical model using specific export profiles. This ensures that the document a stakeholder signs and the code an agent executes are provably consistent.

B. Separation of Duties via Dual-Vendor Loop

To apply the "four-eyes" principle to autonomous agents, the framework enforces a dual-vendor build-and-review loop:

Build Agent: One AI vendor (e.g., Vendor A) is assigned to generate code and implementation artifacts.
Review Agent: A second, independent AI vendor (e.g., Vendor B) performs independent review, security validation, and defect detection.
Human Gate: Accountable humans sign off at every gate. The review agent does not approve production; it provides evidence for human decision-makers.

C. Documentation as an Executable Control Surface

Requirements are re-engineered to be explicit, testable, and traceable. The framework includes specific artifacts such as:

AI Build Governance Pack: Defines boundaries, prohibited actions, and validation rules for the build agent.
Independent Reviewer Prompt/Contract: A governed contract for the review agent to validate against the approved baseline.
Pack Manifest: A machine-readable record binding generated files to their originating baseline, ensuring provenance and detecting drift.

Change Control: If a requirement changes, the proposal returns to the canonical model. Upon approval, a new baseline ( $v+1$ ) is created, and all affected outputs (human and machine) are regenerated simultaneously. This prevents "specification drift" where human documents and agent instructions diverge.

4. Results

The framework was evaluated across the two cases using six operational measures. The results demonstrate consistency across different domains, scales, and delivery paces:

Measure	Case 1 (Safeguarding Platform)	Case 2 (Analysis Workspace SaaS)
Trace Coverage	94.9% (185/195 requirements)	97.8% (496/507 requirements)
Output Divergence	0.5 substantive divergences per baseline	0.0 substantive divergences per baseline
Baseline Compliance	99.2% of activities against current baseline	99.7% of activities against current baseline
Unauthorised-Edit Rate	0.00% (0/924 outputs)	0.00% (0/343 outputs)
Defect Escape Rate	9.1% (31/341 defects)	4.7% (8/169 defects)
Change Propagation	Median 16 min	Median 0 min (single commit)

Traceability: High coverage was achieved, with the only systematic gap being automated-test links for minor UI features.
Consistency: The "controlled projection" approach resulted in near-zero divergence between human and agent artifacts.
Governance: The structural enforcement of the pipeline (e.g., discarding uncommitted local changes) achieved a 0.00% unauthorized edit rate.
Defects: Defect escape rates were within or just above industry best-in-class bands. However, the study noted that the longest-lived defects were "silent failures" (controls absent without visible errors) that the fast inner loop missed, surfacing only during deliberate full-repository reviews.

5. Significance and Claims

The paper claims to provide a governance architecture for AI-assisted delivery and a corresponding redefinition of the Business Analyst role.

Redefinition of the BA: The BA is no longer defined solely by what they write, but by what they enable others (human and AI) to deliver. The role shifts from authoring specifications for colleagues to authoring control instruments for machine executors and governing the AI delivery pipeline.
Feasibility of Speed + Control: The study demonstrates that adding rigorous governance (separation of duties, traceability, baseline control) does not negate the speed advantage of AI. In Case 2, the framework delivered twice the module count in a quarter of the time of Case 1 while maintaining higher compliance and zero unauthorized edits.
Single Source of Truth: The paper validates that a single canonical model can serve both human assurance and machine execution without creating divergent sources of truth, provided the outputs are generated as controlled projections.

Modesty of Claims:
The paper explicitly states that these results are feasibility demonstrations from a two-case study by a single operator. It does not claim statistical generalizability. The authors acknowledge that the evaluation lacks matched pre-framework controls and that the "defect escape" metric relies on the author's judgment. The primary contribution is the design of a method that makes AI-assisted delivery governable, safe, and traceable, shifting the burden of clarity from the human interpreter to the structured requirement artifact.