Find it in the files, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
Find it in the files, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
For quality assurance & test teams
Nothing ships until your tests pass, so every failure you cannot explain holds up the release. The cause sits somewhere in a specification of thousands of requirements, and finding it means walking back through the V, team by team, with hours of reading and asking around. Wyzer Detective matches the defect description against the specification and returns the few requirements the case is about: the neighbourhood of the needle, not the haystack. Export the specification, paste the description, and your team starts on the right requirements today.
The same defect, two ways through the process. The first is the one most QA teams know by heart.
An integration test fails now and then. When the CPU and RAM run hot, a module boots a little late, a timer expires before it answers, and the system falls back. You cannot reproduce it on demand, so you have a log and a build but no reliable steps. The cause could be in any of roughly 30,000 requirements.
Take the text you wrote for the ticket and give it to Wyzer Detective with the ReqIF export of the specification. Detective matches the description against every requirement and links the defect to the ones it concerns.
What comes back is a short list: the requirements that govern the same signal, from every module, laid out in the relationship graph. Several of them define the timeout for the same signal with different values. Each reads fine alone, but they cannot all be met. The finding carries the requirement IDs and a severity.
The ticket no longer says "behaves inconsistently". It names the requirements that conflict, and notes which of them the software met. Engineering gets a precise pointer, product gets a question about the specification, and nobody has to defend a decision they did not make.
A body-control and powertrain integration build: roughly 30,000 requirements across twelve supplier-facing modules. A regression test fails sporadically, and nobody can reproduce it on demand: it may be nothing more than a boot delay, caused by CPU and RAM temperature, that times out a timer. The defect travels from the software team to the supplier to the system architect, and every hand-off costs a retest, because nobody can say quickly which requirements it touches. With the defect description matched to the specification, the first reviewer gets about ten requirements, two of them in conflict, and sees at once that it is a question about the specification.
This example illustrates the class of defect Wyzer Detective helps trace. It is not a specific customer engagement. Detective works on your specification, not on your defect tracker or test logs. You paste the description of the defect, and there is no integration to set up.
These are the release criteria QA is measured on and holds everyone else to. The bar stays where it is. With the relevant requirements attached to the defect, each one gets quicker to meet.
Indicator
Without a traced origin
With Wyzer Detective
Time to root cause
Days of reading the specification and asking around, while teams argue whether it is code, hardware or specification.
The few relevant requirements are found from the defect description, and any conflict between them is marked on the ticket.
Reopen rate
Fixed against one requirement, reopened because a second one still conflicts.
Every requirement in the same conflict is visible before anyone scopes the fix.
Defect leakage
Specification-origin defects are found last, at the most expensive point.
The same finding shows up when the specification is checked, before tests run against it.
Retest cycles
Retests spent confirming a fix for a requirement nobody had settled.
Ambiguous acceptance criteria are flagged, so the test has something definite to check.
Audit trail
A defect is closed with a note. The link to the specification, and to the standards the project says it follows, lives in people's heads.
The defect is tied to the requirements it concerns, so the standards you claim to follow can be checked against them.
QA teams see what the specification costs before anyone else does, which puts them in the best position to push for an earlier check, together with product and engineering. Each step below starts from a finding QA already holds, and the team on that side of the V can act on it without changing how it works.
Detective provides QA withThe requirements behind a failed test, with the conflicts between them marked and their IDs.
So that QA canask requirements engineers to run the same check before the next release of the specification, so this kind of defect never reaches a test.
Detective provides QA withThe signals and interfaces where requirements from different modules disagree.
So that QA canshow architects where a boundary is under-specified while it is still cheap to move.
Detective provides QA withThe neighbourhood of every requirement a fix touches, before the fix is scoped.
So that QA canhave developers close the whole conflict in one change instead of one requirement at a time, so the ticket stays closed.
Detective provides QA withA finding that names requirements and where they sit.
So that QA canopen the supplier conversation with a question about the specification instead of a dispute about fault.
Export the specification your failing test touches, add the defect description, and get the relevant requirements back within minutes, with contradictions, ambiguity and gaps marked by requirement ID.
← See the full product