QIE: Quality Intelligence Engine

The problem

Many delivery issues begin before testing starts. Requirements often reach development with ambiguity, missing acceptance criteria, unclear dependencies, weak testability, incomplete accessibility considerations, unclear test data or hidden delivery risk, and traditional QA may only expose these issues once implementation is already underway.

Why we did it

We wanted to move quality thinking earlier, so teams could ask better questions about a requirement before implementation began rather than discovering the same problems once testing was underway.

Our approach

QIE takes a requirement, user story or functional description and analyses it through a structured quality framework, acting as a quality lens before development rather than a QA step after it. The aim was never to replace testers or human judgement, but to help teams surface the right questions earlier.

The solution

QIE is an internal UKHSA prototype that surfaces a requirement quality score, ambiguity, missing information, questions and gaps, BDD scenarios, test scenarios, test-data needs, delivery risks, accessibility considerations, testability concerns, automation skeletons and readiness signals, all from a single requirement or user story.

How we went about it

The core analysis was built to be deterministic rather than dependent on generative AI end to end, giving the product predictable outputs, clearer explainability, stronger repeatability and better control over how quality rules are applied. Optional AI capability can still be added where it genuinely improves the workflow, but the core quality logic does not depend on an LLM.

The decisions that mattered

• Quality analysis was moved to the requirements stage, surfacing ambiguity, missing acceptance criteria and testability concerns before development began rather than waiting for QA or UAT to find them.
• The core workflow was kept deterministic rather than built around generative AI, prioritising predictable, explainable and repeatable output over the flexibility an LLM-first design would offer.
• Optional AI capability was kept separate from the core quality logic, so the workflow's outputs don't depend on a model behaving consistently.
• The tool was scoped to surface better questions rather than to replace testers or human judgement, keeping people in control of the decisions the analysis informs.

Outcome

A working internal prototype, demonstrated to stakeholders, that shows how requirement quality, delivery risk, accessibility considerations and testability could be surfaced before implementation begins, turning quality into a lens applied earlier in delivery rather than a gate at the end of it.

What we learned

Keeping the core analysis deterministic made the tool easier to trust and explain to stakeholders than an AI-first design would have been. Quality thinking is most valuable while a requirement is still being shaped, not after it has already reached development.