For systems engineers in aerospace and defense
Find the requirements you can't verify, before your test plan does.
VerifyPlan reads your requirements, flags the ones that can't be proven as written, suggests how to verify each one, and drafts the verification matrix your team builds by hand today.
In development with a small group of design partners. Email us at partners@verifyplan.com.
Invented requirements for a fictional satellite. The findings, methods and counts are VerifyPlan's actual output for them; the animation is simplified.
The problem
Requirements that can't be tested
"Shall be robust." "Shall respond quickly." A number with no unit. A value still marked TBD. Each one turns into a verification argument late in the program.
A matrix built by hand
Someone reads every requirement, picks test, analysis, inspection or demonstration, and types it into a spreadsheet. It takes days and goes stale with the next change.
Tools that don't check content
DOORS, Jama and Polarion store and trace requirements well. They don't tell you which ones are ambiguous, compound, duplicated or in conflict.
How it works
- 1
Import or connect
Use a ReqIF export, spreadsheet or Word file. For live reads, connect to DOORS Next or Polarion through the command line. See the tested integration scope.
- 2
Audit
Every requirement is checked against clear rules: vague terms, missing units or bounds, TBDs, compound statements, escape clauses, duplicates and conflicting values. Each gets a suggested verification method (test, analysis, inspection or demonstration) with the reason, or is marked not verifiable as written.
- 3
Review and fix
You get a draft verification matrix, a report, and a fix list for the authors with a suggested fix for each finding. Engineers mark findings that don't apply, and those decisions carry over. Audits are read only by default. You edit requirement text in your own tool; optional result fields require explicit application.
- 4
Re-run
Audit a fresh export or read the source again through its API. VerifyPlan shows what was fixed, what's new and what changed. In a build pipeline it can fail a revision that adds problems.
How it runs
Runs on your machines
File audits run offline with the AI pass off, which is the default. Live connectors contact your selected requirements server. If you choose a cloud AI provider, flagged requirement text is sent to that provider.
Works with your tools
Keep your existing requirements tool. Audit exported files in the desktop app or command line, or use an optional live connector. VerifyPlan does not rewrite your source requirements.
Engineers stay in control
Findings come from rules you can read, not a model. The AI pass is off by default; when on, its rewrites are labeled, checked against the same rules and never replace your text.
Works with your requirements tools
Read requirements from DOORS Next and Polarion, or audit exported files locally.
- IBM
DOORS Next
- Siemens
Polarion
How you buy it
An annual subscription
Licensed per engineer, per team or per program. You install VerifyPlan on your own machines, servers or air-gapped network. Nothing is sent to us: no telemetry, no license server.
Start free, then pilot
Evaluate free for 30 days on sample requirements. Then run a fixed-fee pilot on one program's real requirements, credited in full toward your first year.
Ready for defense buyers
Licensed as commercial software under standard government terms, with source code escrow available. Open interfaces so you are never locked in.
Pricing on request: partners@verifyplan.com
Become a design partner
We're working with a small number of engineering teams to shape VerifyPlan on real requirements sets. Design partners get an offline install kit, run it on a sample of their own requirements on their own machines, and compare the result with their current verification matrix. What comes back to us is a counts-only summary, with no requirement text, IDs or file names.
Talk to usOr email partners@verifyplan.com