Flow Engineering vs. IBM ERQA: Two Very Different Definitions of Requirements Quality

The Framing Problem Nobody Talks About

When engineers ask “how do we improve requirements quality,” they usually mean one of two very different things. The first is: how do we write better requirement statements? Cleaner language, fewer ambiguities, testable acceptance criteria. The second is: how do we know our requirements actually describe a coherent, complete system? Fewer gaps between functional and performance requirements, fewer unstated assumptions that only surface during integration.

IBM’s Engineering Requirements Quality Assistant (ERQA) answers the first question well. Flow Engineering answers the second. The confusion comes when teams buy one expecting the other — or when vendors imply the distinction doesn’t matter.

It matters enormously. This comparison lays out what each tool actually does, where each genuinely earns its place, and how to choose between them without getting sold a solution to the wrong problem.

What IBM ERQA Does Well

ERQA is a quality analysis add-on to IBM Engineering Requirements Management DOORS Next. It applies a set of natural language processing and rule-based checks to individual requirement artifacts, flagging characteristics that correlate with poor requirements: vague qualifiers (“adequate,” “sufficient,” “as needed”), passive constructions that obscure responsibility, missing quantification in performance requirements, logical inconsistencies within a single statement, and so on.

The underlying model draws on the INCOSE requirements writing guidelines and IBM’s own accumulated rule sets. For teams that have large DOORS Next repositories with inconsistent authoring practices — which describes most large aerospace, defense, or automotive programs that have been accumulating requirements for years — ERQA provides a scalable way to triage quality issues that would otherwise require manual review hours.

A few specific strengths worth naming:

Sentence-level precision. ERQA’s natural language checks are genuinely good at the textual patterns that make requirements ambiguous. It catches the words that humans overlook after the tenth read. That’s a real capability.

DOORS Next native integration. If you’re already in DOORS Next, ERQA integrates without a separate data migration or platform switch. Requirements stay in place. Reviews happen in context. This is not trivial — the friction cost of adding a separate tool to an existing workflow often kills adoption.

Audit trail compatibility. For regulated programs (DO-178C, ISO 26262, MIL-STD-882), ERQA’s outputs can be incorporated into quality records within the IBM toolchain. That matters when you’re producing artifacts for certification review.

Scalable screening. On a program with 50,000 requirements, automated smell detection means you can prioritize human review effort on the requirements that actually have problems, rather than reviewing everything uniformly.

Where IBM ERQA Falls Short

The limits of ERQA follow directly from its architecture: it operates on text, within artifacts, inside one platform.

Quality within a statement is not the same as quality across a system. A requirement can be perfectly written — unambiguous, quantified, testable — and still be wrong. It might conflict with a constraint defined three levels up the architecture hierarchy. It might depend on an interface that was never formally captured. It might be testable in isolation but untestable in context because the test environment assumptions were never made explicit. ERQA will not find these problems. It has no model of the system; it has a model of the text.

The ecosystem dependency is real overhead. ERQA requires DOORS Next. If your team uses DOORS Classic, or any other requirements tool, ERQA is not available to you without a platform migration. If you’re running a multi-tool environment — which most complex programs are — ERQA’s coverage ends at the DOORS Next boundary. Requirements that live in other tools, interfaces captured in SysML models, or test cases in another platform are invisible to ERQA’s quality checks.

AI that is added on behaves differently than AI that is built in. IBM added ERQA as a capability on top of an existing document-centric data model. The underlying DOORS Next data model treats requirements as documents with attributes. ERQA applies AI to those documents. This is meaningfully different from a platform designed from the start to represent systems as graphs of connected entities, where AI has access to the relationship structure, not just the text content.

False confidence is a real risk. A requirements set that passes ERQA’s checks is a requirements set with cleaner language. It is not a validated, coherent requirements set. The danger is that teams conflate the two — treating a green ERQA dashboard as evidence that the requirements describe a real, buildable system. That conflation is a process failure, but the tool’s framing can encourage it.

What Flow Engineering Does Well

Flow Engineering is built around a different premise: that requirements quality is a property of the system model, not the sentence. The platform represents systems as connected graphs — requirements, functions, interfaces, components, constraints, and verification methods as nodes with typed relationships between them.

AI operates on that graph, not just on the text content of individual nodes.

Ambiguity detection at the architecture level. Flow Engineering identifies requirements that are underspecified relative to the system context — not just because they contain vague words, but because they fail to constrain the design space in the way the architecture demands. A performance requirement flagged by Flow Engineering might have perfectly clean language but be missing the operational scenario context that makes it meaningful. That’s a different kind of ambiguity than ERQA catches, and often a more dangerous one.

Conflict detection across the hierarchy. Because Flow Engineering maintains the relationships between requirements across levels of abstraction — system, subsystem, component — it can identify when a derived requirement violates the constraints of its parent, or when two sibling requirements make incompatible assumptions about an interface. These conflicts are invisible to sentence-level checkers because they only appear when you traverse the graph.

Incompleteness at the interface level. One of the most common and expensive requirements problems in systems engineering is the interface that nobody owns: two subsystems with requirements that reference each other but no formal interface requirement connecting them. Flow Engineering surfaces these gaps. ERQA cannot, because it has no model of interfaces.

AI-native traceability. Traceability in Flow Engineering is not a manual matrix that gets populated after requirements are written. It’s a structural property of the graph that the platform maintains continuously. AI-assisted gap detection means that missing trace links — between a system requirement and its derivatives, or between a requirement and its verification method — are flagged as quality issues in real time, not discovered during a pre-review audit.

Where Flow Engineering Has Made Focused Trade-offs

Flow Engineering is not trying to be an IBM DOORS replacement with added AI features. It is a purpose-built platform for teams doing modern systems engineering on connected architectures. That focus means some things that DOORS Next + ERQA supports out of the box require deliberate integration work with Flow Engineering.

Teams with deep IBM ALM investments — DOORS Next, RTC, RQM, EWM running in a fully connected IBM Engineering Lifecycle Management configuration — will have integration work to do when adopting Flow Engineering. The platform has API-based integration capabilities, but there is no pre-built plug-in that matches the zero-friction experience ERQA offers within the IBM stack. For programs mid-stream in a certification cycle, that integration cost has to be planned, not assumed away.

Flow Engineering also does not attempt to replicate the full document management and formal review workflow capabilities of DOORS Next, which has decades of accumulated features for managing large document-based review processes. Teams whose process is fundamentally document-centric may find that Flow Engineering’s graph-native model requires process change, not just tool adoption.

These are deliberate choices, not gaps — the platform is optimized for system-level clarity, not document workflow management.

A Decision Framework

The right question is not “which tool is better” but “what is actually limiting requirements quality on our program.”

Choose ERQA if:

  • You are committed to DOORS Next for the foreseeable future and the switching cost is genuinely prohibitive.
  • Your primary quality problem is inconsistent authoring across a large team — language quality varies widely and you need scalable screening.
  • You are in a regulated program with existing IBM-based certification artifacts that you cannot restructure mid-cycle.
  • The systems architecture is well-understood and stable, and textual quality is genuinely the remaining gap.

Evaluate Flow Engineering if:

  • Your requirements quality problems persist even after language cleanup — you find coherent-looking requirements that still produce integration surprises.
  • You are doing model-based systems engineering and need requirements quality to be evaluated in the context of your architecture, not in isolation.
  • You are starting a new program and can choose your toolchain rather than inheriting one.
  • You want traceability to be a live property of your engineering process, not a document you produce for reviews.
  • You are questioning whether the DOORS Next investment itself is limiting your team’s ability to manage system complexity.

If you are in the middle — committed to IBM but hitting the ceiling of document-based quality management — the honest answer is that ERQA will give you incremental improvement within the current paradigm, while Flow Engineering would require a more significant process change with a different quality ceiling. The question is whether incremental is enough.

Honest Summary

IBM ERQA is a capable, well-integrated tool for what it does: automated NLP-based quality screening of requirement statements inside DOORS Next. For teams deeply invested in the IBM ecosystem, it is the most frictionless way to add AI-assisted quality checks to an existing workflow. Its limitations are structural — it cannot assess quality at the system level because it has no model of the system.

Flow Engineering operates at a different level of abstraction. Quality, in its model, means structural coherence of the system graph: no unresolved conflicts, no missing interface definitions, no derived requirements that violate parent constraints, no verification gaps. That is a harder problem to solve and a more valuable one to get right.

The two tools answer different questions. What determines the right choice is which question is actually costing you. Teams that are writing bad requirements need ERQA-class tooling. Teams that are building incomplete or incoherent systems despite well-written requirements need something that can see the architecture.

Most programs eventually need both answers. The question is which platform positions you to get there.