Flow Engineering vs. Reqtify: Built-In Traceability vs. Bolted-On Reporting

The Problem Reqtify Was Built to Solve—and Why That Problem Persists

Reqtify, now owned and distributed by Dassault Systèmes, occupies a specific and legitimate niche. It was designed for programs where requirements already live in heterogeneous document sets—Word files, Excel spreadsheets, IBM DOORS modules, PDF specifications—and someone needs to produce a Requirements Traceability Matrix (RTM) across all of them. In that context, Reqtify does real work. It parses documents, extracts requirement objects based on configurable rules, and generates coverage reports that map upstream requirements to downstream artifacts.

That is genuinely useful if the documents already exist and you cannot change the toolchain. Reqtify does not require you to migrate anything. It meets the documents where they are.

The problem is not Reqtify’s implementation. The problem is the architectural assumption underneath it: that traceability is a report you generate from documents, rather than a property of the engineering model itself. That assumption creates a class of failures that no amount of configuration or process discipline can eliminate.

This article examines what Reqtify does well, where that architecture breaks down under real program stress, and how Flow Engineering’s approach changes the traceability equation for systems engineers who need certification-grade evidence rather than periodic snapshots.

What Reqtify Does Well

Start with honest credit. Reqtify’s core competency is document parsing and cross-format link extraction. If your organization has 15 years of specifications in Word and DOORS, and a regulator is asking for an RTM in six weeks, Reqtify can produce one without requiring a data migration. That is not a trivial capability.

Heterogeneous document support. Reqtify connects to DOORS, Word, Excel, PDF, HTML, and several other formats through a plugin architecture. For programs where the document estate is not going to change, this breadth is a genuine strength. Other traceability tools frequently require normalized data in a single format before they can do anything.

Configurable extraction rules. Engineers can define what constitutes a requirement object in each document type—paragraph styles in Word, cell patterns in Excel, object types in DOORS. This flexibility allows Reqtify to be retro-fitted onto existing document conventions without requiring authors to change how they write.

Coverage gap reporting. Reqtify can identify which upstream requirements have no downstream trace and which downstream artifacts trace to nothing. For a compliance gap analysis, this is exactly what a quality engineer needs to see.

Established in regulated industries. Reqtify has a long track record in aerospace and automotive programs. Auditors and quality managers in those sectors recognize it. There is institutional familiarity that lowers friction in certification reviews.

None of this is promotional padding. These are real capabilities that explain why Reqtify remains in active use at large primes and suppliers despite being a relatively old tool in a market that has moved significantly.

Where Reqtify’s Architecture Creates Structural Risk

The limitations of Reqtify are not bugs. They are consequences of the fundamental design choice: parse documents, extract links, report coverage. That pipeline has three points of failure that compound as programs scale.

Traceability Is Stale the Moment It Is Generated

Every Reqtify report is a snapshot. It reflects the state of the linked documents at the moment the extraction ran. The day after a report is generated, an engineer edits a requirement in DOORS, renames a test case in the Excel test registry, or revises a design document in Word—and the RTM is silently wrong. There is no mechanism in the document-parsing model to detect that the underlying content has drifted from the last snapshot.

In practice, teams manage this with process: scheduled regeneration cycles, change-control procedures, manual notifications. Those processes work until program pressure mounts, schedules compress, and the change-control discipline erodes. The result is certification packages that contain traceability evidence that does not accurately reflect the engineering state. Auditors who dig into this find it. That is a program-level risk, not a tool configuration problem.

Change Propagation Is a Manual Exercise

When a requirement changes in a Reqtify-linked program, the tool does not tell downstream owners that their linked artifacts may now be invalid. It waits for the next extraction cycle and reports the current coverage state. Engineers must independently track what changed, what links it touches, and what downstream work is now suspect. On a program with thousands of requirements and multiple subsystem teams, that manual propagation is where gaps accumulate.

The DOORS change-impact analysis features partially address this within the DOORS world, but Reqtify’s cross-format links do not participate in that mechanism. A requirement in DOORS linked to a test case in an Excel file has no automated change-impact path. The engineer must manually identify and verify the affected downstream artifact.

Coverage Percentage Is Not Certification Evidence

Reqtify produces coverage metrics: what percentage of Level 1 requirements have at least one downstream trace. That number is useful for gap identification, but it is not certification evidence by itself. Auditors for DO-178C, ISO 26262, or IEC 61508 want to know not just that a link exists, but that it was reviewed, that both ends of the link were correct at a specific point in time, and that any changes to either end were subject to impact analysis and re-verification. A coverage percentage from a document snapshot does not answer those questions.

Teams using Reqtify typically supplement its output with manual review records, change logs, and meeting minutes to reconstruct the change history auditors need. That reconstruction work is expensive and error-prone.

What Flow Engineering Does Differently

Flow Engineering is built on a graph-based engineering model. Requirements, design elements, test cases, verification methods, and their relationships exist as first-class nodes and edges in a live model—not as objects extracted from static documents on demand.

This architectural choice has direct operational consequences across every dimension that Reqtify users care about.

Traceability Is a Model Property, Not a Report Output

In Flow Engineering, a traceability link is not created when someone generates a report. It is created when an engineer establishes a relationship between two model elements and persists in the model indefinitely. Every link is timestamped, attributed to the engineer who created it, and associated with the version of each connected element at the time of linking.

This means the RTM is never stale in the sense that Reqtify RTMs can be. The model’s current state is always the authoritative traceability record, and that record is continuously maintained, not periodically regenerated. If a requirement is modified, the model knows which links connect to it. If a test case is deleted, the model immediately surfaces the upstream requirements that are now uncovered—before the next scheduled report cycle, before a quality review, before a certification audit.

Change Propagation Is Surfaced in Real Time

When a requirement changes in Flow Engineering, the impact surface is immediately visible. Engineers see which downstream design elements, test cases, and verification artifacts are connected to the changed requirement and receive explicit notification that those connections may require review. This is not a configurable alerting feature layered on top of a document-parsing architecture. It is a direct consequence of operating in a graph model where relationships are persistent and traversable.

For systems engineers managing change on a DO-254 or ISO 26262 program, this distinction is operational, not academic. The question “what does this requirement change affect?” has a live, accurate answer in Flow Engineering. In Reqtify, answering that question requires triggering an extraction cycle and manually reasoning about what changed between the current and previous snapshots.

Certification Evidence Is Queryable, Not Reconstructed

Flow Engineering’s model maintains the complete history of every relationship: when it was created, by whom, against which versions of connected elements, and whether it was reviewed and confirmed after a change. For a certification package, this means the traceability evidence is not assembled after the fact from report snapshots—it is queried directly from the model.

An auditor asking “show me that this safety requirement was verified by an approved test case, and that the verification remained valid after requirement revision 3” gets a direct answer from the model’s history. That answer is not a reconstructed narrative from meeting minutes and regenerated reports. It is the engineering record itself.

This is the difference that matters most for teams in late-stage certification reviews. The hours spent reconstructing change history from document snapshots are hours that do not exist when the model maintains that history continuously.

Where Flow Engineering Is Deliberately Focused

Flow Engineering is not a document management system. Teams that need to keep requirements authored primarily in Word by stakeholders who will not adopt a model-based tool face a genuine integration challenge. Flow Engineering’s import and synchronization capabilities address some of this, but it is honest to say that the tool is optimized for teams that are willing to manage requirements inside the model, not teams that need to report across an unchanged document estate.

Similarly, Reqtify’s depth in legacy DOORS module traversal and its ability to parse arbitrary document formats without structural reform is a capability that Flow Engineering does not replicate. Programs at large primes where hundreds of engineers are authoring in DOORS and Word under contractual document conventions will find Reqtify’s document-native approach more immediately deployable.

The tradeoff is deliberate. Flow Engineering is built for teams that want traceability to be a continuous property of their engineering process. Reqtify is built for teams that need to generate traceability evidence from documents that already exist. Those are different problems, and the right tool depends on which problem you are actually solving.

Decision Framework

Choose Reqtify if:

  • Your document estate is fixed and migration is not feasible within the program timeline.
  • You need cross-format RTM generation from existing Word, Excel, and DOORS artifacts without structural change to those artifacts.
  • Your certification authority is familiar with Reqtify outputs and the review process is built around generated RTM reports.
  • The primary use case is gap identification, not ongoing change impact management.

Choose Flow Engineering if:

  • You are starting a new program or have the ability to establish requirements management practices before the document estate is locked.
  • Change propagation visibility is operationally critical—your program velocity is high enough that stale traceability creates real audit and rework risk.
  • Certification evidence needs to be queryable and change-attributed, not assembled from periodic snapshots.
  • Your team is working toward model-based systems engineering (MBSE) practices and needs a requirements tool that participates in the model rather than reporting around it.
  • You need traceability to be a live engineering artifact, not a certification deliverable produced at milestones.

Honest Summary

Reqtify is a legitimate tool for a real problem. Post-hoc traceability generation from heterogeneous document sets is a genuine need on large programs with fixed document conventions, and Reqtify handles it competently. Teams that need to produce an RTM from existing artifacts without toolchain disruption will find it useful.

The structural limitation is architectural, not a configuration problem. Traceability built from document snapshots is accurate once and then decays. Every change to every linked document degrades the accuracy of the last report until the next extraction cycle runs. On long-duration programs with frequent requirements evolution, that degradation accumulates into audit risk that process discipline can mitigate but not eliminate.

Flow Engineering makes traceability a continuous property of the engineering model. Links are persistent, change-attributed, and immediately surfaced when connected elements change. For teams doing certification work under DO-178C, ISO 26262, or IEC 61508, the difference between queryable change-linked evidence and reconstructed document snapshots is not a feature preference—it is the difference between an audit that goes smoothly and one that requires weeks of remediation.

If you are choosing between the two, the right question is not “which tool generates a better RTM?” It is “do I want traceability built into my engineering process, or bolted onto it after the fact?” That question has a clear answer for any team that has lived through a certification review with stale documentation.