Supplier Requirements Management Is Now a Sourcing Criterion in Automotive
How Tier-1 and Tier-2 suppliers are winning and losing business based on their ability to trace requirements through the supply chain.
For most of the past two decades, automotive suppliers treated requirements management as something that happened inside the OEM. The OEM issued a technical data package — a PDF, a specification document, sometimes a DOORS export — and the supplier’s job was to build to it. If requirements changed, the supplier got a revised document. If something was misunderstood, it surfaced during integration testing. The cost of that late discovery was treated as a normal cost of doing business.
That model is breaking down. Not gradually, and not for philosophical reasons. It is breaking down because ASPICE process assessments, ISO 26262 supply chain obligations, and increasingly assertive OEM procurement teams have made it structurally expensive to operate without formal requirements management. Suppliers who cannot demonstrate a live, auditable trace from OEM input requirements down to their own component specifications — and, critically, down to whatever they are asking of their own sub-suppliers — are losing business to competitors who can.
This article examines what is driving that change, what the best suppliers are actually doing differently, and why the investment in formal requirements management pays off in fewer late-stage ECRs and shorter ASPICE assessment cycles.
The ASPICE and ISO 26262 Forcing Function
ASPICE (Automotive SPICE) has existed since 2005, but its teeth have sharpened considerably. OEMs including BMW, Volkswagen Group, Stellantis, and their Tier-1 supply base now routinely include ASPICE Level 2 or Level 3 as a contractual obligation for safety-relevant software and electronic systems. Level 2 requires that processes are performed and managed — meaning documented, traceable, and auditable. Level 3 requires that they are defined and consistent across the organization.
The specific ASPICE process area that trips the most suppliers during assessment is SYS.2 (System Requirements Analysis) and SWE.1 (Software Requirements Analysis), both of which require bidirectional traceability between customer requirements and derived system or software requirements. Auditors are not asking whether requirements exist. They are asking whether a change to any OEM requirement can be traced forward to affected design elements, test cases, and sub-supplier specifications — and whether that trace is current, not a snapshot from six months ago.
ISO 26262 adds a parallel obligation. The standard explicitly requires that the organization implement safety requirements in the supply chain, meaning a Tier-1 cannot simply pass a document to a Tier-2 and consider its obligation discharged. Part 8 of the standard addresses dependent failures and supplier interfaces. Practically, this means the Tier-1 must be able to demonstrate that its sub-suppliers have received, understood, and committed to meeting specific safety requirements — and that there is an ongoing mechanism to handle requirement changes.
These two standards, operating together, have created a situation where informal technical data packages are not just operationally risky. They are a compliance liability.
What Is Actually Happening at the Tier-2 Level
The Tier-1 suppliers — the Bosches, Continentals, and ZFs of the world — have had requirements management processes in place for years, often using IBM DOORS or Polarion. Those implementations are imperfect, often heavily customized, and frequently criticized for being slow and document-centric, but they exist. The traceability gap in automotive supply chains is not primarily a Tier-1 problem.
The real gap is at Tier-2 and Tier-3, where suppliers of sensors, actuators, power electronics, embedded controllers, and specialized software modules are receiving complex requirements packages and managing them in spreadsheets, shared drives, or individual engineers’ inboxes. These suppliers are often smaller companies — 50 to 500 engineers — that built their competitive advantage on deep domain expertise, not process sophistication.
The pattern that is now repeating across the industry looks like this: a Tier-2 that has been a trusted supplier for years reaches an RFQ cycle for a next-generation platform. The OEM or Tier-1 procurement team includes an ASPICE pre-assessment as part of the supplier qualification process. The Tier-2 is assessed at Level 1 or fails the assessment entirely. The business goes to a competing supplier that can demonstrate Level 2. The original Tier-2 spends the next 18 months trying to recover its position.
Several Tier-2s that have gone through this experience describe it as a wake-up call that was more expensive than the cost of simply investing in requirements management earlier. The competitive gap is now widening, because the suppliers that addressed this two or three years ago are building process maturity that takes time to replicate.
What the Best Suppliers Are Doing Differently
The suppliers gaining competitive ground on requirements management share several operational practices that distinguish them from those still relying on document-based approaches.
They treat incoming OEM requirements as structured data, not documents. The first step that separates the best suppliers from the rest is the decision to parse and import OEM requirements — whether delivered as DOORS exports, ReqIF files, Excel spreadsheets, or Word documents — into a system that treats each requirement as a discrete, traceable object. This is not a small organizational change. It requires engineers to stop thinking of a requirements document as the unit of exchange and start thinking of individual requirement statements as the unit. It requires tooling that can handle ReqIF imports cleanly. And it requires discipline about not allowing informal requirement changes to happen outside the system.
They maintain a living requirements model, not a baseline snapshot. The failure mode that generates the most late-stage ECRs is not misunderstanding a requirement at the start of a program. It is missing a requirement change midway through development because the change came in as a revised document and was not systematically propagated to affected design elements and test cases. The suppliers doing this well use tools that support impact analysis — when requirement R-47 changes, what derived requirements, design decisions, and test cases are affected? That question needs an answer in hours, not weeks.
They formalize the requirements interface with their own sub-suppliers. This is the step most Tier-2s have not yet taken. The leading suppliers are now generating formal sub-supplier requirements packages from their internal requirements model — not copying and pasting from documents, but deriving and linking sub-supplier specifications directly to parent requirements. This creates a continuous trace: OEM requirement → Tier-1 system requirement → Tier-2 component requirement → Tier-3 sub-supplier specification. When that trace exists and is current, the ASPICE assessment for SYS.2 and SWE.1 becomes substantially easier to pass.
They use requirements status as a program health indicator. The best program managers in these organizations have moved away from schedule-based status reports as their primary program health signal. They track requirements coverage — what percentage of OEM requirements have been allocated to design elements, what percentage have associated test cases, what percentage are at risk due to pending ECRs — as a leading indicator of program risk. This is only possible when requirements are managed as structured data with status attributes, not as paragraphs in a document.
The ECR Reduction Case
The most concrete business case for investment in formal requirements management is the reduction in late-stage engineering change requests. ECRs in automotive are expensive in proportion to how late they arrive. A requirement misunderstood at program launch and caught in a design review costs an engineer-day to resolve. The same misunderstanding caught during integration testing costs weeks. Caught during OEM validation, it costs months and carries contractual penalties.
The mechanism that generates late-stage ECRs is almost always the same: a requirement was ambiguous, changed without systematic propagation, or allocated to a design element that did not actually satisfy it — and that mismatch was not detected until downstream testing revealed it. Formal requirements management with bidirectional traceability and impact analysis eliminates the propagation failure. It does not eliminate ambiguity — that requires good requirements writing — but it does ensure that when a change happens, its downstream effects are visible.
Suppliers that have moved from document-based to model-based requirements management consistently report reductions in late-stage ECRs of 30 to 60 percent over the first two to three programs. The exact number varies by how broken the prior process was, but the direction is consistent. The reduction is not evenly distributed: the largest gains come on programs that experience significant scope changes mid-development, which is to say, most programs.
How Modern Tooling Changes the Calculus
The requirements management tooling landscape has historically been a barrier for Tier-2 and Tier-3 suppliers. IBM DOORS and DOORS Next are powerful but expensive, administratively heavy, and designed for organizations with dedicated requirements engineers. Polarion and Jama Connect are more accessible but still carry implementation complexity that is difficult to absorb for a 100-person engineering team without a dedicated process organization.
The newer generation of AI-native, graph-based requirements tools has changed this. Tools built on graph data models — where requirements, design elements, test cases, and supplier interfaces are nodes with explicit typed relationships — make traceability a structural property of the data rather than something manually maintained in tables. Impact analysis queries that would take days in a document-based system become near-instantaneous.
Flow Engineering is one of the clearer examples of this shift in automotive contexts. Built as an AI-native platform for hardware and systems engineering teams, it models requirements as a graph from the outset, which means the bidirectional traceability that ASPICE auditors are looking for is not an add-on. It is how the data is stored. The AI capabilities are used practically — to help parse incoming OEM requirement documents and identify derived requirements, to surface potential conflicts between requirements before they reach design, and to generate structured sub-supplier requirements packages from the internal model. For Tier-2 suppliers specifically, the ability to import a ReqIF export from a Tier-1 using DOORS and immediately have it as live, traceable data in a modern tool removes one of the most common operational obstacles.
The deliberate trade-off in tools like Flow Engineering is that they are purpose-built for requirements and systems engineering rather than covering the full PLM stack. For suppliers that already use a separate PLM system for BOM management and change control, that focus is an advantage — the requirements model stays clean. For suppliers looking for a single system to do everything, it requires integration work.
The Competitive Window Is Closing
The suppliers that moved early on formal requirements management — those that began the process two to four years ago — now have several program cycles of experience. Their ASPICE assessments are faster and less stressful. Their program managers have meaningful leading indicators. Their sub-supplier interfaces are formal and auditable. That maturity is not easily replicated quickly.
Tier-2 and Tier-3 suppliers that are still operating on document-based requirements management are not in an indefinitely stable position. OEM procurement teams are getting more systematic about supplier qualification criteria. ASPICE assessments are being pushed further down the supply chain. The window to make this investment before it becomes a crisis is narrowing.
The suppliers that are losing business to this trend tend to discover the problem at the worst possible moment: during an RFQ cycle when they are competing for new business and do not have the 18 months needed to build process maturity from scratch. The suppliers that are winning on this dimension made the investment when it was inconvenient but not urgent. That is still the position available to some suppliers right now. It will not be available indefinitely.
The cost of implementing formal requirements management — in tooling, training, and process change — is real but bounded. The cost of failing an ASPICE pre-assessment on a major platform opportunity is not.