Derived Requirements: Keep Parent and Reason Attached

A mechanical engineer picks a brushless DC motor to hit a top-level torque spec. That one choice immediately spawns five new requirements: a 24V bus voltage, an inverter packaging envelope, a four-hole bolt pattern on a 42 mm circle, a minimum dissipation area on the aluminum chassis, and thermal interface material rated to 120 degrees Celsius. None of those constraints were in the customer specification. An engineering decision created them.

These are derived requirements, and they make up roughly 70 to 80 percent of all requirements in a complex hardware build. Yet in most programs they become dark matter. They sit in slide decks, CAD model annotations, or team chat messages. When the motor changes six months later, the mounting pattern and heat dissipation limits stay locked in place because nobody remembers why they were defined.

A derived requirement is only trustworthy while it stays explicitly attached to its parent requirement and the design rationale that justified it. This guide covers how to capture derived requirements, keep their context intact through CAD iterations, evaluate them during design reviews, and close them out with verification evidence.

Step 1: Recognize a derived requirement when a design decision creates one

Decomposed requirements and derived requirements are not the same thing. Treating them as identical is one of the fastest ways to lose control of your system architecture.

A decomposed or allocated requirement is a direct mathematical or functional division of a parent requirement. If a vehicle has a mass budget of 1,200 kg, you allocate 400 kg to the chassis, 300 kg to the powertrain, and 200 kg to the battery pack. The physics do not change, and the parent relationship is a simple sum. Allocation assigns requirements to system elements, whereas derived requirements are developed through analysis and must be validated against higher-level requirements.

A derived requirement arises because you chose a specific implementation, architecture, physics domain, or manufacturing process. The customer did not ask for a die-cast aluminum enclosure with a 2-degree draft angle. They asked for an IP67 enclosure that survives an 810H shock profile. The moment your mechanical team picks high-pressure die casting over CNC machining, the draft angles, minimum wall thicknesses, rib placements, and parting line tolerances become derived requirements.

Every technical decision creates derived requirements in three main categories:

1. Architectural choices: Selecting a dual-redundant CAN bus creates derived requirements for termination resistors, transceiver power rails, and wiring harness routing.

2. Component selections: Picking a specific sensor creates derived optical clearance angles, calibration fixture interfaces, and I2C address assignments.

3. Manufacturing processes: Choosing injection molding creates derived radius limits, ejector pin keep-outs, and tool sink allowances.

Train your team to spot this exact transition. Whenever an engineer answers 'how' we meet a specification, the output of that answer is a set of derived requirements for the team building the subsystem.

Step 2: Record the parent requirement and the decision that produced it

A derived requirement written without a parent is an orphan at birth. If a requirement states, 'The power supply heatsink shall have a surface area greater than 150 square centimeters,' an incoming engineer cannot know whether it exists to satisfy a component junction temperature limit, a human-touch burn prevention rule, or a target ambient operating condition.

Every derived requirement entry needs three metadata fields filled before any CAD work begins: the parent requirement ID, the design decision identifier, and the owner.

First, link the parent requirement. This link establishes the flowdown chain. If parent requirement REQ-045 ('Maximum external skin temperature shall not exceed 45 degrees Celsius at 35 degrees Celsius ambient') changes to 50 degrees Celsius, your engineering database must flag every child requirement connected to it. Learn more about maintaining allocation integrity in our guide to requirements flowdown.

Second, record the driving decision. This is where standard requirements management systems fall flat. Most tools record a parent link but skip the design decision that bridges the two. The parent requirement did not directly demand an extruded heat sink. An architecture decision chose passive conduction over forced-air cooling. Documenting that decision closes the logical gap between the functional spec and the physical parameter.

Tandem handles this with a dedicated systems engineering module where visual system architecture, custom attributes, and requirements live together. Instead of isolating text in an external document, Tandem connects architecture nodes directly to requirements and CAD context. When an engineer views a derived thermal requirement, they see both the parent specification and the architectural decision that created it.

Step 3: Write the rationale so it survives handoffs

Weak rationale creates ghost requirements: rules that everyone follows but no one can defend. Writing 'Needed for structural integrity' or 'Per thermal team guidance' is not rationale. It dodges engineering record-keeping.

A defensible rationale has three parts: the governing physics or constraint, the mathematical source, and the margin applied. Engineers leave programs, contractors roll off, and organizations shift. The rationale must explain the requirement so completely that a new engineer can read it two years later and decide whether to keep, modify, or eliminate it.

Here is a standard, inadequate requirement entry:

• Requirement: Battery enclosure lid bolt pitch shall be <= 45 mm.

• Rationale: Required to maintain seal.

Compare that to a complete entry that survives:

• Requirement: Battery enclosure lid bolt pitch shall be <= 45 mm along perimeter.

• Parent: REQ-088 (Ingress Protection IP6K9K per ISO 20653).

• Rationale: Bolt pitch calculated using beam deflection analysis between fasteners under 0.2 MPa gasket compression load. At this spacing, fastener torque preserves the nominal compression required by the gasket specification. Includes a 1.25x safety factor on compression margin.

See the difference. If an engineer later switches from an EPDM gasket to a liquid silicone dispensed bead that needs only 10 percent compression, they can calculate the new bolt spacing on the spot. If the rationale had said only 'Required to maintain seal,' the engineer would either keep the expensive 45 mm spacing out of fear or change it arbitrarily and risk a field leak.

Step 4: Re-check derived requirements when the parent or the driving CAD changes

Hardware requirements do not fail in static environments. They fail when geometry moves in CAD and the text database stays frozen.

A common failure happens during packaging optimization. A mechanical engineer working in SolidWorks or Siemens NX needs room for a secondary wire harness. They shift a structural bulkhead 12 mm inboard. The top-level stiffness requirement is unaffected, and the CAD model shows no physical interference. But three derived requirements sat on that bulkhead: an electrical ground lug clearance, a local resonance frequency limit of 85 Hz for a gyro mounted to its face, and a maximum fastener reach distance for assembly tooling.

Unless your engineering platform links requirements to CAD objects, that 12 mm shift silently breaks those derived requirements. The problem will not surface until physical integration testing or factory assembly.

Tandem closes this gap by tracking CAD changes against requirements, design intent, and validation evidence. When an assembly changes, engineers can see what the modification affects and assess the impact on downstream derived parameters before committing the design.

Set a strict check: every Engineering Change Notice or major CAD commit must include an impact query on derived requirements linked to modified parts. If a mounting plane shifts, the engineer responsible for the derived thermal, electrical, and structural constraints tied to that face must sign off on the geometry update.

Step 5: Review derived requirements at design reviews

Preliminary Design Reviews (PDR) and Critical Design Reviews (CDR) often burn hours debating whether the top-level system will work, while skipping the derived requirements where failures actually start. Top-level requirements are usually clear: weight, battery life, unit cost, payload capacity. The failure points sit in the hundreds of intermediate choices derived by individual engineers.

At your next design review, set aside time for a dedicated derived requirement cross-examination. Group them by parent subsystem and put three standard verification questions to each:

1. Is the driving decision still valid? If the derived requirement came from a decision to use off-the-shelf linear actuators, but the team later pivoted to a custom lead screw, the derived voltage limits and mounting points tied to that actuator need review.

2. Are the margins compound or real? When the structural engineer adds a 20 percent margin, the thermal engineer adds 15 percent, and the power engineer adds 25 percent, the resulting component-level requirement can inflate component size to double what is needed. Read the rationale to find stacked margins.

3. Can the derived requirement be verified with available test assets? If a derived requirement sets an operating temperature range inside a sensor cavity, confirm that your test team can actually get an RTD or thermocouple into that cavity during thermal chamber testing.

Put this evaluation directly in your review decks. Our breakdown of what to include in a critical design review package shows how to structure the evidence.

Step 6: Close each derived requirement against verification evidence

You cannot close a parent requirement until every child derived requirement beneath it has verifiable proof of closure. Yet many teams declare top-level compliance based on a whole-system test and leave derived requirements unverified.

Take a medical fluid dispensing pump. The top-level requirement demands dosing accuracy of plus or minus 1 percent. The system passes an end-of-line verification test at 20 degrees Celsius. But an unverified derived requirement demanded that the motor drive lead screw runout stay under 5 microns to prevent flow pulsation across the full operating temperature range of 10 to 40 degrees Celsius. The team closed the top-level requirement without verifying that derived mechanical tolerance, so the pump starts dosing erratically in cold clinics.

Every derived requirement must go into a verification cross reference matrix with a defined verification method: Test, Analysis, Inspection, or Demonstration.

• Analysis: Use for thermal profiles, structural finite element models, and tolerance stack-ups. The closure record must reference the specific simulation report ID and version-controlled mesh configuration.

• Inspection: Use for mechanical dimensions, coating thicknesses, and fastener torque marks. The closure record is an inspection report or CMM scan file.

• Test: Use for physical behavior, dynamic loading, and electrical margins. The closure record must be a raw test run log with sensor serial numbers and calibration dates.

• Demonstration: Use for simple qualitative operations, such as confirming that a maintenance hatch unlatches without special tools.

Tandem puts this validation evidence in the same system where design intent and requirements live. Instead of storing test results on a separate shared drive and cross-referencing them in a disconnected spreadsheet, verification data attaches directly to the derived requirement node. When an auditor or chief engineer asks for proof of compliance, the whole path is visible in one place: top-level specification, design decision, derived constraint, CAD model, and test log.

Troubleshooting: orphaned, duplicated and stale derived requirements

Derived requirements suffer from three recurring maintenance problems during hardware execution: orphan status, duplication, and staleness. Here is how to diagnose and fix each one.

Orphaned requirements occur when a parent requirement is modified or deleted during an architecture re-baseline, but nobody deletes the child items. If a program drops an underwater submersion capability to hit a schedule deadline, all derived O-ring squeeze percentages, gland geometries, and potting compound requirements must be retired immediately. Run an orphan query every two weeks. Any derived requirement with an empty or broken parent link must either be re-justified against an active parent or archived.

Duplicated requirements happen when two engineering disciplines create separate derived constraints for the same interface without talking to each other. The electrical team derives an internal enclosure volume requirement to keep component clearance. The mechanical team derives an internal enclosure volume requirement based on heat dissipation ribs. Both write slightly different numbers into their own subsystem tables. Fix this by organizing requirements around physical architecture nodes rather than functional org charts. If both requirements point to the Enclosure Chassis node, the conflict surfaces immediately.

Stale requirements occur when a design decision changes but the derived requirement persists because engineers fear touching legacy specifications. An engineer switches an alloy from 6061-T6 aluminum to 7075-T6 for fatigue performance. The derived anodizing bath specification, tailored for 6061 corrosion resistance, stays unchanged and ruins the first batch of 7075 components. Whenever an engineering change order alters a component material, interface, or manufacturing method, the driving design decision link must trigger an automated review of all derived requirements attached to that node.

Conclusion

A hardware program does not fail because the team forgot what the customer wanted. It fails because the hundreds of engineering decisions made between the initial spec and the factory floor lost their connection to reality. When derived requirements live as unlinked notes in drawings or disconnected cells in spreadsheets, engineering changes become slow, blind, and defensive.

Stop treating derived requirements as disposable downstream notes. Treat them as first-class architectural records that preserve the reason, the parent specification, and the CAD reality.

Tandem is built for engineering teams that need complete visibility across their hardware programs. It connects design intent, requirements, CAD modifications, and verification evidence in one context layer, so your derived requirements stay accurate through every revision. Book a demo with Tandem to see how structured traceability keeps your engineering decisions defensible from early definition through release.