How Should a Hardware Team Handle Requirements for Third-Party or COTS Components?

A COTS component — commercial off-the-shelf hardware, software, or firmware — arrives with someone else’s requirements baked in. The manufacturer wrote those requirements for a market, not for your system. That gap between what the manufacturer specified and what your application demands is where programs fail, where safety cases collapse, and where late-cycle redesigns begin.

The answer is not to trust the datasheet and move on. The answer is a deliberate process: ingest the external specification, derive the requirements your system actually needs, document what the specification does not cover, and maintain that linkage across the program’s life. This article covers how to do that practically, what each major regulatory framework demands, and what good tooling looks like.

What You’re Actually Managing When You Manage COTS

Engineers sometimes treat a COTS datasheet as if it were a requirement. It is not. A datasheet is a characterization of what a component does under the conditions the manufacturer chose to test and document. Your system imposes conditions — temperature, load, interface protocol, update cadence, safety integrity level — that may or may not overlap with those conditions.

You are managing three distinct artifacts:

  1. The external specification — the manufacturer’s datasheet, interface control document, user manual, or certification documentation. You don’t own it. You can reference it.
  2. Derived requirements — statements your team authors that express what your system needs from the component, in your system’s vocabulary and at your system’s level of integrity.
  3. Assumption records — explicit documentation of what you believe is true about the component that the external specification does not directly state.

If you conflate these, your traceability is fiction. You will have a link from your system requirement to a datasheet page number, with no one accountable for the inference that connected them.

Writing Derived Requirements from COTS Specifications

A derived requirement from a COTS specification follows the same structure as any other derived requirement: it is a verifiable, system-context-specific statement that traces upward to a parent requirement and traces downward to a verification method.

The process:

Step 1: Extract the relevant specification clauses. Pull the specific sections of the COTS documentation that bear on your use case. A 600-page microcontroller reference manual contains maybe 40 pages that matter for your design. Identify them formally — not by memory, not by highlighter on a printed copy.

Step 2: Translate each clause into your system’s requirements language. A datasheet entry that reads “Operating voltage: 1.71 V to 3.6 V” is not your requirement. Your requirement might read: “The 3.3 V power rail supplying the STM32H7 processor shall be maintained between 3.135 V and 3.465 V under all operating modes, including peak transient loads during DMA transfers.” That statement has a verification method (measurement), an owner (power systems), and an interface (defined load profile).

Step 3: Assign verification ownership. Derived requirements from COTS specs often fall into a gap — power systems says it’s a processor requirement, processor integration says it’s a power requirement. Name the responsible subsystem at authoring time.

Step 4: Link the derived requirement bidirectionally to its source clause. This is not optional bookkeeping. When the COTS vendor releases a new datasheet revision, you need to know which of your derived requirements may have been invalidated.

Common categories of derived requirements from COTS specs:

  • Interface electrical requirements (voltage, current, timing, loading)
  • Interface protocol requirements (initialization sequence, error recovery, timeout behavior)
  • Environmental requirements (operating temperature, humidity, shock/vibration — do your system’s environmental requirements fit within the component’s rated range?)
  • Functional limitation requirements (if the component cannot do X, the system requirement that depends on X must be reallocated)
  • Configuration requirements (if the component requires specific configuration for your use case, that configuration is a requirement, not an engineering note)

Managing Requirement Gaps

A gap is a condition your system imposes that the COTS specification does not address. Gaps are not failures of the COTS vendor — they are inherent to the nature of general-purpose components meeting application-specific demands.

The dangerous response to a gap is silence. When an engineer reviews a datasheet, finds no specification for a parameter they care about, and proceeds anyway, they have made an implicit assumption. That assumption is now undocumented, unverified, and invisible to the rest of the program.

The correct response is an assumption record: a formal document that states the assumption explicitly, identifies who made it, identifies what evidence supports it (test data, similar-application precedent, vendor application note), and identifies what verification will be performed to validate it.

An assumption record for a COTS component might read:

Assumption ID: COTS-MCU-004 Component: STM32H7A3 microcontroller Assumed property: CAN-FD peripheral maintains timing accuracy within ±0.1% under simultaneous operation of all four CAN-FD instances at 5 Mbit/s data phase. Basis: Vendor application note AN5014, section 4.2, which tests two simultaneous instances; engineering judgment extrapolated to four. Risk: Medium — not directly validated by vendor documentation. Verification plan: Lab test on target hardware under thermal soak at +85°C. Owner: [Name], Communications Subsystem Lead

This record is a requirement-level artifact. It should live in your requirements database, linked to the relevant system requirement, not in a comment thread or a notebook.

Gap management has a lifecycle: identify, record, assign a verification plan, execute that plan, and close the assumption with evidence. At program completion, you should be able to demonstrate that every assumption about every COTS component was either confirmed by vendor documentation or validated by your own testing.

COTS in Safety-Critical Applications

Each major safety framework handles COTS differently, and the differences matter.

DO-178C — COTS Software

DO-178C does not exempt COTS software from software level (DAL) obligations. If you use a COTS operating system or middleware in a DAL B application, that software must be qualified or its impact on safety must be limited by architectural means (partitioning, monitoring).

The primary path is Tool Qualification (for development tools) or satisfaction of DO-178C objectives through one of three methods: (1) the vendor provides a certification package that satisfies the applicable DO-178C objectives; (2) you perform your own verification against the COTS software to the required DAL; or (3) you bound the COTS software’s potential failure effects through architecture so that no single COTS failure can cause a DAL A/B hazard.

The practical implication for requirements: your COTS software integration requirements must explicitly state which DO-178C objectives the COTS component is being credited for satisfying, and via which path. “We use VxWorks, it’s certified” is not a requirements statement. “The real-time executive shall be an RTOS qualified to DAL B via supplier certification package, with configuration control maintained per Section 7.2.6 of the project PSAC” is a requirements statement.

DO-254 — COTS Hardware

DO-254 Section 11.3 provides guidance on COTS electronic components used in airborne electronic hardware. The key concept is service history: demonstrating that the component has been used in sufficient quantity, in sufficiently similar applications, with documented absence of relevant failure modes.

Derived requirements for DO-254 COTS hardware must include:

  • The specific version/revision of the component for which service history is claimed (part number traceability)
  • The operational envelope over which service history applies
  • Any functional limitations or derating requirements that maintain the component within its qualified envelope
  • Configuration control requirements that prevent unauthorized substitution of a different revision

The requirement gap problem is acute under DO-254 because the “similar application” judgment is qualitative. Your assumption records for DO-254 COTS hardware should document the basis for the similarity claim explicitly.

ISO 26262 — SEooC (Safety Element out of Context)

ISO 26262 Part 10 introduces the Safety Element out of Context (SEooC) concept for components developed without knowledge of the target application’s safety requirements. A COTS component with a functional safety claim — an SBC (system basis chip) rated for ASIL B, for example — is typically a SEooC.

The integration obligation falls on your team: you must verify that your application’s safety requirements are consistent with the assumptions the SEooC developer made when developing the component. Those assumptions are documented in the SEooC’s Safety Manual and Assumptions of Use.

This is a formal requirement gap process, mandated by the standard:

  1. Obtain the component’s Safety Manual and Assumptions of Use.
  2. For each assumption, verify that your application satisfies it — or derive a requirement that ensures it will be satisfied.
  3. Document unverified assumptions as open items with a closure plan.
  4. Demonstrate, in your safety case, that all assumptions are satisfied.

A common failure mode: teams obtain the Safety Manual, file it in a document management system, and never formally work through the assumptions. At functional safety assessment, this produces findings that delay approval. The assumptions must be traced to requirements, not filed and forgotten.

Obsolescence Requirements

Obsolescence is not a procurement concern that arises late in the program. It is a systems engineering constraint that must be specified at the start.

An obsolescence requirement is a verifiable constraint on the acceptable lifecycle of a COTS component relative to the program’s service life. Examples:

  • “The selected processor shall have a manufacturer-committed production lifetime of not less than 15 years from the date of platform entry into service, or an identified form-fit-function-compatible replacement shall exist at the time of selection.”
  • “COTS components with a last-time-buy date within the platform’s projected service window shall not be selected without approval of the Chief Engineer and documentation of a lifetime buy or obsolescence mitigation strategy.”
  • “The design shall not incorporate components listed on the GIDEP (Government-Industry Data Exchange Program) obsolescence alert database at the time of design freeze.”

Obsolescence requirements need verification methods. For a 15-year production lifetime commitment, the verification method is review of manufacturer product longevity documentation at PDR and CDR, with a monitoring requirement through production.

Linking obsolescence requirements to COTS component records in your requirements tool means that when a component enters end-of-life, the impact on program requirements is immediately visible — not discovered during a bill of materials audit five years later.

How Modern Tooling Supports COTS Management

Most legacy requirements tools treat COTS specifications as external documents to be referenced by filename. That approach breaks traceability: you cannot query which of your requirements depends on a specific COTS specification clause, and you cannot automatically flag the impact of a COTS specification revision.

Graph-based requirements management tools handle COTS differently. External specification clauses are imported as nodes in the requirements graph — not as documents you link to, but as typed entities with their own attributes (source, version, clause ID) that participate in the same traceability graph as your internal requirements.

Flow Engineering implements this model. Teams use it to import COTS specification content — datasheet parameters, interface control document sections, Safety Manual assumptions — directly into the requirements graph as external specification nodes. Internal derived requirements are then linked to those nodes, so the full derivation chain is traversable: from system requirement, through derived requirement, to the specific COTS specification clause that grounded it.

The practical payoff comes at two points. First, interface mismatch detection: Flow Engineering’s graph model can flag conditions where a derived requirement’s stated parameter falls outside the range specified in the linked COTS clause — a 3.45 V supply maximum linked to a 3.6 V component rating is fine, but a 3.7 V maximum linked to a 3.6 V rating is a flagged conflict, not a silent error in a spreadsheet. Second, assumption tracking: unmet COTS assumptions (nodes with no linked verification evidence) are visible as open items in the traceability view, not buried in a document whose review depends on someone remembering to look at it.

Flow Engineering is focused on hardware and systems engineering teams. It is not a general-purpose requirements tool, and teams needing deep integration with legacy document vaults in IBM DOORS or Polarion will encounter friction in migration. For programs starting fresh or running mixed portfolios where COTS integration complexity is a primary risk driver, that specialization is an asset.

Practical Starting Points

If your team currently manages COTS with a combination of datasheets in SharePoint, derived requirements in a Word document, and assumptions in review comments, here is a minimum viable process to move toward:

  1. Create a COTS component registry — one record per component, linking to the specific versioned specification document, recording the part number, revision, and program-specific configuration.

  2. Audit your existing derived requirements — identify which requirements trace to COTS specifications and which do not. The ones that don’t are either missing a trace or shouldn’t exist.

  3. Walk every COTS specification against your use case — systematically, not from memory. Document every parameter you rely on and every parameter the spec doesn’t address that you need.

  4. Open an assumption record for every gap — with an owner and a closure plan before the next design review.

  5. Write your obsolescence requirements before component selection — not after.

  6. Treat Safety Manual assumptions as requirements — assign ownership, trace to your application requirements, and close them with evidence.

The goal is a requirements set where every COTS dependency is visible, every assumption is documented, and no one discovers a gap for the first time during certification review.