Why Hardware-Software Co-Design Is Breaking Traditional Systems Engineering Processes

The V-model was an honest description of how hardware products were built for decades. System requirements flowed down. Hardware architecture was locked. Software requirements were derived from that stable hardware baseline. Testing closed the loop. The model worked because it matched the economic reality of the time: changing silicon was expensive, so you froze it early and adapted everything else around it.

That economic reality has not disappeared — tape-out still costs millions — but it has been complicated by something the original V-model authors did not anticipate: the growing number of products where the software is not an afterthought layered on top of hardware, but a co-equal design partner that shapes the hardware itself.

AI accelerator chips are the clearest example. The tensor operations a chip must support, the memory bandwidth it requires, the sparsity patterns it should exploit — these are not discovered after the RTL is written. They are determined by studying the neural network models the chip is meant to run, which are software artifacts. The chip’s architecture and the software stack’s requirements evolve together, in tight coupling, across a timeline measured in months, not the sequential years the V-model implies.

Autonomous vehicle ECUs present the same challenge from a different angle. Functional safety requirements for a domain controller depend on the software partitioning model. The software partitioning model depends on available compute and memory resources. Those resources depend on silicon decisions that have their own cost and thermal constraints. Nothing in this chain is truly stable until very late — and waiting for stability at each layer before starting the next is not a viable strategy when competitors are shipping.

This is the co-design reality, and it is breaking the assumptions baked into most systems engineering processes — and most systems engineering tools.

What the V-Model Actually Assumes

Before diagnosing what breaks, it is worth being precise about the assumption under stress. The V-model is not simply a waterfall diagram. It has genuine engineering value: it forces explicit verification planning, it links every requirement to a test, and it creates a clear accountability structure. None of those properties are wrong.

The assumption that creates friction is temporal sequencing: system requirements precede hardware requirements, which precede software requirements, which precede implementation. Each level is substantially stable before the next begins. Traceability runs parent-to-child, and change management flows downward — a change at the top propagates down, but changes rarely propagate sideways across domains or upward against the flow.

In a co-design program, this directed graph becomes a mesh. A software performance requirement for a neural network inference engine discovers that the proposed memory subsystem cannot sustain the required bandwidth. That discovery is not a verification failure — it is a design input. It drives a hardware architecture change. That hardware architecture change affects power envelope. The power envelope change drives a thermal management requirement. The thermal management requirement has software implications for throttling behavior. The throttling behavior must now be verified against the original inference performance requirement.

That is a cycle. The V-model does not handle cycles.

What Actually Breaks in Practice

Engineering teams on co-design programs encounter the same class of failures repeatedly, regardless of industry.

Requirements ownership becomes ambiguous at interfaces. In a sequential process, the hardware team owns hardware requirements and the software team owns software requirements. At the interface — the firmware API, the register map, the interrupt model — ownership is genuinely shared. When a co-design program accelerates and interface specs change frequently, no traditional tooling makes it obvious which downstream requirements are affected, on which side, or who is responsible for updating them.

Traceability breaks at domain boundaries. Most requirements tools are organized around a single repository or a single domain. Hardware requirements live in one instance of DOORS or Polarion. Software requirements live in another. Cross-domain links are maintained manually, in spreadsheets or through integrations that are fragile and rarely up to date. When the hardware team revises an interface timing requirement, the software team does not automatically know which of their real-time requirements is now suspect.

Change impact analysis is performed by humans, not tools. When a requirement changes in a co-design environment, someone must mentally walk the chain: what hardware specs depend on this? What software specs reference that hardware spec? What test cases verify those software specs? In a complex program — an AI accelerator with thousands of requirements across firmware, RTL, system software, and hardware abstraction layers — this mental walk is slow, error-prone, and does not scale.

Review cadences become misaligned. Hardware and software teams often run separate requirements review cycles with separate cadences. In a co-design program, a hardware requirement can change between software review cycles, creating a state where approved software requirements reference superseded hardware requirements. The artifact record says everything is approved and traced. The actual requirements are inconsistent.

How Leading Teams Are Adapting

The teams doing this well have made structural changes to their processes before reaching for new tools. Tools can support a good process; they cannot substitute for a bad one.

Interface specifications become first-class artifacts with dedicated ownership. The boundary between hardware and software — the hardware abstraction layer spec, the firmware interface document, the register map — is treated as a primary system artifact, not a derivative of either hardware or software documentation. A specific team or working group owns it, it has its own change control process, and both hardware and software requirements are explicitly derived from it, not the other way around.

Requirements reviews are conducted jointly, not in separate silos. Hardware and software leads review interface-touching requirements together, on a shared cadence. This sounds obvious; it happens rarely in practice because it requires coordinating organizations that have historically operated with significant independence.

Change impact scope is declared at the requirement level. Each requirement is tagged with the domains it touches. When a change is proposed, the scope declaration pre-identifies which teams must be looped in for impact analysis. This does not replace traceability — it accelerates the triage step before traceability analysis begins.

Prototyping and simulation replace frozen baselines as synchronization points. Rather than waiting for hardware architecture to stabilize before software requirements begin, teams use cycle-accurate simulators, FPGAs, or software models of the hardware as a shared ground truth. The simulator becomes the interface specification in executable form. Requirements on both sides are validated against the same model.

These adaptations reduce the cost of the co-design feedback loop. They do not eliminate the underlying traceability problem, which is fundamentally a tooling problem.

What Tooling Must Do Differently

The requirements tooling most programs use today was designed for the world the V-model described: hierarchical document structures, parent-child traceability links, single-domain repositories, and change management workflows that assume unidirectional flow.

Co-design demands something structurally different.

Requirements must be modeled as nodes in a graph, not entries in a document. A graph model allows bidirectional links, cross-domain links, and the expression of dependency relationships that are not simply parent-to-child. When a hardware timing requirement and a software real-time requirement both depend on an interface specification node, that dependency is visible in the graph. When the interface specification changes, the tool can surface both dependencies simultaneously.

Change propagation must be automated across domains. When a requirement changes, the tool should immediately identify every linked requirement in every domain that is potentially affected, flag it as suspect, and notify the relevant owners. This is not a feature that requires AI — it requires the graph model to be in place first. Once the graph exists, propagation is a straightforward traversal.

Cross-domain traceability must be a native capability, not an integration. Tools that silo hardware and software requirements in separate repositories and connect them through API integrations will always be fragile in a co-design environment. The integration layer adds latency, has synchronization gaps, and typically supports only a subset of the link types that co-design programs need.

The tool must support concurrent modification with conflict detection. Hardware and software requirements on a co-design program are being updated simultaneously, by different teams, often to the same interface region. A tool that serializes changes or lacks meaningful conflict detection creates bottlenecks that slow co-design cadence.

How Modern Tools Are Responding

The established players — IBM DOORS Next, Jama Connect, Polarion, Codebeamer — are all capable tools with deep feature sets and significant installed bases. They were not, however, designed with co-design as a primary use case. Their data models are document-centric or hierarchy-centric. Cross-tool integrations exist but require ongoing maintenance. Change propagation across domain boundaries is largely a manual process supported by notification workflows, not automated graph traversal.

This is not a knock on these tools. They solve real problems for the programs they were designed for. Sequential hardware development programs, regulated industries with mature documentation requirements, large organizations that need auditable approval workflows — these are legitimate use cases, and the established tools handle them well.

The gap they leave is specific: they were not architected for bidirectional, cross-domain, high-velocity requirements evolution. That gap is where newer tooling is differentiating.

Flow Engineering (flowengineering.com) is one of the clearer examples of what an AI-native, graph-first approach looks like in practice. Requirements in Flow Engineering are modeled as interconnected nodes from the start — not documents with links added later. Cross-domain traceability between hardware and software requirements is a first-class capability, not an integration project. When a requirement changes, the tool propagates suspect status automatically across linked nodes regardless of which domain they belong to, surfaces the affected requirements to the relevant owners, and provides an AI-assisted impact analysis that identifies non-obvious downstream dependencies.

For co-design programs specifically, this graph model addresses the core traceability problem directly: the tool can represent the interface specification as a shared node that both hardware and software requirements link against, making cross-domain impact analysis something the tool does rather than something engineers reconstruct manually.

Flow Engineering’s deliberate focus is on hardware and systems engineering teams — it does not attempt to be a general-purpose ALM or PLM platform. For programs that also need deep integration with software development lifecycle tooling on the software side, or for organizations with mature Polarion or DOORS deployments they are not prepared to migrate, that focus means integration work is still required. That is a real consideration, not a disqualifying one — but it should be part of the evaluation.

Honest Assessment

Co-design is not going to become less common. The product categories driving it — AI inference hardware, software-defined vehicles, advanced SoCs with programmable fabric — are growing, not contracting. The V-model assumption of sequential stability was always a simplification; it is now an actively harmful one for a significant portion of hardware programs.

The engineering process adaptations described here — joint reviews, first-class interface artifacts, simulation-as-ground-truth — are achievable without new tooling. Teams should implement them regardless of what tools they use.

The tooling problem is real and separate. Maintaining cross-domain traceability manually in a co-design program is not just inefficient — it is a risk management failure. Requirements that appear traced in the artifact record but reference superseded hardware specifications are creating hidden compliance gaps and late-discovered integration failures. The cost of those failures, measured in schedule slip and respins, dwarfs the cost of tooling that surfaces them earlier.

The question is not whether to take cross-domain traceability seriously. The question is whether the tools in use today are actually capable of supporting it — or whether they are being used to create paper traceability that provides the appearance of control without the substance.

For most programs running on legacy document-centric tooling, the honest answer is the latter.