AnalystEngine — AI Business Analyst - Requirements Capture POC

Sheet AE-01 · Rev A · Status: Proof of Concept · 2026-07-31

A conversational AI business analyst. The proof of concept includes some outline suggestions to run requirements elicitation at the scale of an entire portfolio, not one interview at a time.

01 — The problem we're solving

Requirements gathering doesn't scale with headcount. A senior BA can run maybe two or three deep stakeholder interviews a day, then spend the afternoon turning notes into a Business Requirement Document.

AnalystEngine is a working prototype that puts an AI analyst on the other end of that conversation — one that asks the follow-up questions a senior BA would ask, tracks what's actually been covered against a structured model of the domain, and turns approved conversation into BRDs, SRS documents, Gherkin user stories, and Mermaid diagrams without a human drafting a single paragraph from scratch.

02 — What's actually running

Underneath the chat window sits a three-layer ontology — Aspect → Dimension → Slot — that models what a complete requirement set for a project looks like. Every turn of conversation is read twice: once by an Interviewer agent that replies and asks the next gap-filling question, and in parallel by a Slot Extractor that fills in ontology slots from what was just said. The coverage bar the stakeholder sees updating live isn't cosmetic — it's the actual state a downstream pipeline reads from.

The artifact pipeline:

Documenter ──> Checker ──(score ≥ 7)──> draft, awaiting review
                  │
             (score < 7)
                  ▼
   Security ∥ UX debate ──> Reviser ──> Checker ──> draft, awaiting review

Every draft is scored against the 6Cs / INCOSE heuristics before a human ever sees it. When a draft scores low, it isn't quietly patched — a Security Auditor and a UX Advocate critique it in parallel, a Reviser synthesises their objections into a revision, and the whole thing is re-checked. Either way, what lands in front of a human is a draft, not a final document: the full checker report and debate transcript ride along with it, and nothing ships without explicit approval.

03 — What ships from one session

BRD	Business requirements, generated from the covered ontology slots plus conversation context.
SRS	IEEE-830-style software requirements specification.
Stories	User stories with Gherkin acceptance criteria, ready to paste into a backlog.
Diagrams	Use-case, flow, and sequence diagrams in Mermaid, rendered in-browser.
Voice	Same pipeline, spoken — barge-in turn-taking, local STT/TTS, no cloud speech API.

04 — Where "at scale" actually comes from

One AI-run interview is a demo. The interesting question is what changes when a hundred stakeholders across a dozen projects go through it in the same week.

01 — Interviews run in parallel, not in a calendar. Every session is its own agent conversation — there's no reason two, twenty, or two hundred stakeholders can't be mid-interview simultaneously. The constraint stops being "how many interviews can one BA fit this week" and becomes "how many stakeholders are available to talk."

02 — The ontology is a shared schema, not a personal notebook. Because every session fills the same Aspect → Dimension → Slot structure, coverage isn't just visible per-session — it's comparable across sessions. Gaps in one interview show up as gaps in the same schema everywhere else, which is what makes portfolio-level gap analysis possible instead of forty inconsistent Word documents.

03 — Humans move from authoring to reviewing. The Checker/debate gate holds every session to the same quality bar automatically, before a person is involved. That shifts the senior BA's job from writing every BRD to approving or rejecting one — the actual scaling bottleneck moves from drafting time to review time, which is a much smaller number.

04 — Scopes partition context the way teams already are organised. Sessions can be grouped into scopes — a domain, a department, a workstream — so context injection and coverage tracking naturally partition along the lines an organisation already uses, instead of one undifferentiated backlog.

The honest bottleneck. Scaling elicitation isn't really about generating more text faster — a single BA could already out-type this. It's about running the same quality gate across many more conversations than one person could personally sit through, and only asking a human to spend time where the gate says the draft is uncertain.

05 — What this is not, yet

It's a prototype, and not yet production ready:

Deferred	Why it's fine for a PoC
RBAC / multi-tenancy	No owner model on sessions yet — needed before any bot integration, not before proving the pipeline.
pgvector RAG	Uploaded docs are truncated into the prompt; fine until corpora outgrow the context window.
Jira / DOORS sync, custom templates	Export targets, not core to whether the elicitation loop works.
Impact analysis (FR-04)	Traceability sections exist in artifacts; full change-impact tracing is future work.

None of these are architectural blockers — the multi-agent pipeline, the ontology, and the human-in-the-loop gate require careful design and integration into a production environment.

---

AnalystEngine · PoC — Backend :8010 · Frontend :3001 · Voice :8011 — Sheet AE-01, Rev A