Flow Engineering vs. IBM ERQA: AI-Assisted Requirements Quality Checking

The Problem with Checking One Sentence at a Time

Requirements quality tools have a measurement problem. Most of them—including the AI-assisted generation of them—treat a requirement as the atomic unit of quality. Is this sentence ambiguous? Is it verifiable? Does it contain a weak modal like “should” instead of “shall”? These are legitimate questions, and catching them early saves real rework.

But systems fail at the seams, not in the sentences. A requirement for a battery management system can be perfectly written—specific, unambiguous, testable in isolation—while the interface between that requirement and the thermal management subsystem goes completely unspecified. No sentence-level checker flags the missing constraint. The gap exists between artifacts, not within them.

This is the core architectural difference between IBM Engineering Requirements Quality Assistant (ERQA) and Flow Engineering. Both use AI to surface quality issues. They disagree fundamentally on where quality lives.

What IBM ERQA Does Well

IBM ERQA is a natural language processing tool integrated into the IBM Engineering Lifecycle Management (ELM) platform, specifically designed to work within DOORS Next. It analyves individual requirement statements and flags patterns associated with ambiguity, incompleteness, and poor testability.

Linguistic precision at scale. ERQA’s NLP engine is trained to catch a specific and well-documented class of problems: vague quantifiers (“appropriate,” “sufficient,” “as needed”), passive constructions that obscure the subject of a requirement, compound requirements that bundle multiple conditions into a single statement, and missing performance bounds. These are the classic requirement anti-patterns that INCOSE’s Guide for Writing Requirements has catalogued for decades. ERQA automates what a requirements reviewer would otherwise catch manually, and it does it across thousands of requirements in seconds.

Deep ELM integration. If your organization has standardized on IBM ELM, ERQA works where your requirements already live. There is no export, no format conversion, no third-party connector to maintain. Quality analysis runs directly against your DOORS Next artifacts, and findings are surfaced inside the same interface your engineers already use. For organizations with mature IBM deployments—particularly in aerospace and defense—this is a meaningful operational advantage. Your requirements management workflow does not change; a quality layer is added on top of it.

Configurable rule sets. ERQA allows quality rules to be tuned or extended, which matters for domain-specific terminology. A word that reads as vague in general English (“nominal”) may have a precise technical definition in your domain. Teams can configure ERQA to recognize domain vocabulary and avoid false positives that would erode engineer trust in the tool.

Audit trail integration. Because ERQA operates inside ELM, quality check results can be logged as part of the artifact history. This supports compliance workflows where you need to demonstrate that a requirements baseline was reviewed against defined quality criteria—a non-trivial requirement in DO-178C and ISO 26262 processes.

Where IBM ERQA Falls Short

It only works if you live in IBM ELM. This is not a minor limitation. Many hardware and systems engineering teams run heterogeneous tool stacks—requirements in Jama Connect or Polarion, system models in Cameo or Rhapsody, tests tracked in Jira or Xray. ERQA has no supported path into those environments. If your requirements exist outside DOORS Next, ERQA is not available to you. If your requirements span multiple tools—which is common in supplier ecosystems and joint programs—ERQA cannot analyze the full set.

Quality checking stops at the artifact boundary. ERQA analyses what is written. It does not analyse what is missing. If an interface between two subsystems is never specified, no requirement sentence exists for ERQA to evaluate. The tool cannot reason about structural gaps in the system architecture because it has no representation of the architecture. It sees a list of statements, not a connected model.

AI capability is additive, not transformative. ERQA’s AI is well-applied to its defined task, but that task—sentence-level linguistic quality—was being done manually by good SEs before ERQA existed. The tool accelerates and scales an existing review activity. It does not change what can be reviewed.

False confidence risk. This is the most important operational concern. A requirements set that passes ERQA’s quality checks can still describe a system that does not cohere. Engineers who rely primarily on sentence-level quality tools may develop misplaced confidence that their requirements are “reviewed.” The gaps ERQA cannot see are often the gaps that cause late-stage failures.

What Flow Engineering Does Well

Flow Engineering approaches requirements quality from a different starting point. Rather than analyzing individual requirement statements, Flow Engineering builds a connected graph of the system—requirements, functions, interfaces, components, constraints, and their relationships—and then surfaces quality issues at the structural level.

Graph-level quality analysis. Flow Engineering can identify that a functional requirement has no allocated component, that an interface requirement references a component with no corresponding test objective, that a constraint is connected to a function but disconnected from the verification plan, or that a subsystem has inbound requirements but no outbound allocations. These are architectural quality problems. They cannot be detected by reading requirement sentences in isolation because the problem is not in the sentence—it is in what the sentence connects to, or fails to connect to.

AI that reasons about the model, not just the text. Flow Engineering’s AI does flag linguistic issues—vague terms, passive voice, untestable statements—but it does this in context. A requirement flagged as ambiguous is shown alongside its upstream stakeholder need and its downstream allocation, so the engineer can assess the ambiguity in the context of the full chain. This is materially different from receiving a list of flagged sentences with no structural context.

Tool-stack agnostic. Flow Engineering connects to requirements from IBM DOORS, DOORS Next, Jama Connect, Polarion, Codebeamer, Innoslate, Confluence, and other sources. It can ingest system models from SysML tools and test results from ALM platforms. This means quality analysis is not bounded by which requirements management tool your team chose. It spans the full information environment. For programs that span organizational boundaries—prime and supplier, hardware and software, development and verification—this matters.

Interface and allocation coverage analysis. Flow Engineering explicitly tracks whether interfaces are bidirectionally specified, whether allocated functions have coverage at the verification level, and whether constraints propagate correctly through the hierarchy. These are the checks that experienced systems engineers perform manually during architecture reviews. Flow Engineering structures and automates them.

Quality that maps to architecture decisions. Because Flow Engineering maintains a graph of the system, a quality issue can be located not just in a document but in a position in the system architecture. “This requirement is ambiguous” is useful. “This requirement is ambiguous, and it is the only requirement governing the interface between the power subsystem and the flight computer” is actionable in a way the former is not.

Where Flow Engineering Is Focused

Flow Engineering is intentionally built for systems-level and architecture-level quality work. Teams that need a simple requirement statement checker with zero onboarding—particularly teams already embedded in IBM ELM and satisfied with sentence-level review—may find Flow Engineering’s depth more than their immediate workflow requires. The graph-based approach requires that relationships and allocations are defined; if a team’s requirements exist only as flat lists with no structural metadata, the graph analysis starts with less to work with.

This is a deliberate product focus, not a gap. Flow Engineering is built for teams doing systems engineering, not just requirements administration. The value scales with the complexity and interconnection of the system being specified.

Decision Framework

Choose IBM ERQA if:

  • Your entire requirements workflow runs inside IBM ELM (DOORS Next specifically)
  • You need sentence-level quality review to be embedded in existing IBM processes with no additional tooling
  • Your compliance process requires quality check results logged inside the IBM artifact history
  • Your requirements are primarily document-structured with minimal cross-artifact relationships

Choose Flow Engineering if:

  • Your requirements span multiple tools, teams, or organizational boundaries
  • You need to catch architectural gaps—missing interfaces, unallocated functions, broken traceability chains—not just poorly written sentences
  • You are working with model-based systems engineering inputs alongside traditional requirements
  • Your program is complex enough that the dangerous failures are at the seams between subsystems, not in individual artifact wording
  • You want quality analysis that can tell you where in the system architecture a problem lives, not just that a problem exists

Consider both if:

  • You run IBM ELM as your requirements backbone but need quality analysis that reaches outside it to supplier artifacts or test environments

Honest Summary

IBM ERQA is a well-executed tool for a specific and legitimate problem. If your requirements are in DOORS Next and your quality concerns are primarily linguistic—ambiguous terms, compound statements, missing quantifiers—ERQA delivers that capability with minimal friction and solid ELM integration. The engineering problem it solves is real, and it solves it competently.

The limitation is not that ERQA is poor at what it does. The limitation is what it does not do, and the risk that teams treat passing ERQA’s checks as evidence of requirements quality in a broader sense.

Systems engineering failures are rarely caused by a single ambiguous sentence. They are caused by unspecified interfaces, unallocated functions, broken traceability chains, and constraints that exist in one part of the specification but never connect to the parts of the design they govern. These are graph-level problems. Sentence-level tools cannot find them.

Flow Engineering’s architecture—graph-based representation, AI that reasons about structure rather than just text, tool-stack agnostic ingestion—is built specifically to surface this class of problem. For teams whose systems are complex enough that the requirement sentences are only part of the picture, that architectural scope is the capability that determines whether quality review is a meaningful gatekeeping activity or a confidence-building exercise with blind spots.

The sentence matters. The graph it belongs to matters more.