Challenge
A Canadian satellite operator was building a new satellite, a programme governed by around twenty thousand engineering requirements. Its systems engineering teams all worked in one requirements management tool, and that tool had reached its limits.
The hard question in systems engineering is always the same: if this requirement changes, what else does it touch? The tool could store the requirements, but it could not answer that well. Impact analysis was slow, the ripple effect of a change was easy to miss, and the quality of the requirements themselves varied from team to team. Engineers spent a large part of their time cleaning, reconciling and chasing, instead of judging whether the system as a whole made sense.
And all of it sat under export-control rules. Nothing about the programme could leave the company's own network, which ruled out sending the requirements to any public AI service.
Solution
We built a platform that brings AI into the requirements work without anything leaving the building. It reads every requirement in context, understands what it means rather than just which words it uses, and links it to the requirements it depends on and affects. When something changes, the engineers see the ripple before it spreads.
On top of that, the platform checks the requirements for duplicates, conflicts and vague wording, and rewrites them at scale to the SMART standard: specific, measurable, achievable, relevant and testable. An engineer approves every change. The work that used to be janitorial is done by the system, and the engineers spend their time on the thing only they can do: keeping the whole system sane.
Execution
Working inside export control
The first design decision was where the platform could run at all. Export control meant no public AI services and no data leaving the company, so everything, including the language models, had to live in a private cloud on a closed network. We worked with the client's IT and security team from the start to set that environment up, agree what could run where, and prove that nothing could reach the outside world.
Building the platform
The platform runs on Azure inside the client's private environment. The language models are hosted there through Azure AI Foundry, so every call to a model stays in the network. Each service is packaged in Docker containers and deployed through Azure DevOps, which gave the IT team one controlled pipeline to review, test and release every change.
Designing the analysis
Three services do the work, each built to be checked by an engineer rather than trusted blindly:
- Semantic analysis reads every requirement with the context of the ones around it, so two requirements that say the same thing in different words are recognised as related.
- Impact analysis follows those links, so a proposed change shows everything it would touch before anyone commits to it.
- Rewriting takes requirements that fail the SMART test and proposes a clearer version, which the engineer accepts, edits or rejects.
Results
- Requirement errors, duplicates and conflicts are found by the system, not by chance.
- The ripple effect of a change is visible before the change is made.
- Requirements are rewritten to one standard, at scale, with an engineer approving each one.
- Systems engineers spend their time on the soundness of the system, not on cleaning the database.
