From BOM to Requirements and Back: Building Sourcing Constraints Into Specs

Remember the capacitor shortages of 2021? Digging through datasheets and hunting alternates at the eleventh hour? Or have you ever talked to an engineer who had to reverse-engineer their own decade-old design to replace a non-compliant Wi-Fi module?

Sourcing electronic components can stall production of even the most well-designed products. Weeks of delay, unplanned engineering hours, and missed production windows are common consequences that drain budgets and derail schedules.

What if sourcing requirements were considered as early as functional requirements and visible by all engineers working on the project? When supply chain considerations are captured during requirements gathering, the risk of rework drops, sourcing speeds up, and if the need to find an alternate part arises, the actions that need to be taken to replace it are already well defined. 

This article gives actionable recommendations on how to integrate supply chain constraints into product specifications using proven requirements engineering practices.

Tip: If you are a sourcing professional and you found this content useful, share this article with your engineering colleagues to start the discussion.

Why Supply Constraints Belong in Requirements

BOMs are no longer static lists. They're living documents that change throughout development and production. Waiting for procurement to handle sourcing concerns creates risk, delay, and unpleasant surprises.

Late-stage sourcing issues cost companies time and money. 80% of PCB designs require component replacements, with each taking 40 hours to resolve. Additionally, time to market matters more than product development cost. It is estimated that products that are delayed by 6 months cost companies 33% of their potential profits, even though they were delivered on budget. At the same time, compliance failures that trigger penalties or market withdrawals are becoming more common. 

Capturing sourcing constraints early as requirements can help prevent these costs from materializing.

Requirements should capture more than functional and performance specifications. They should also document:

• Lead time tolerances and acceptable procurement windows
• Obsolescence safeguards and lifecycle expectations
• Compliance criteria such as RoHS, REACH, UL, and AEC-Q standards
• Multi-sourcing strategies or approved alternate components
• Traceability and documentation needs for regulated industries

Sourcing in the Requirements Engineering Process

Integrating sourcing considerations into requirements is about making implicit assumptions explicit and documenting them in a form that can be verified, traced, and validated.

Elicitation Phase

Requirements elicitation (the process of identifying stakeholders and gathering needs) is where you define the scope of what the product must accomplish. This is the right time to bring procurement and sourcing professionals into the conversation.

Tip: Include procurement in your stakeholder mapping.

Ask them questions like:

• What sourcing risks could block this project?
• Are there lifecycle or compliance constraints we should consider?
• What are the most critical components of this system? 

For instance, if you're developing a product with a 15-year support window, that constraint should surface during elicitation, not during design review when someone realizes half the BOM is already flagged as NRND (not recommended for new designs).

Needs Analysis Phase

Once needs are gathered (typically during preliminary design), analysis involves identifying conflicts, dependencies, and risks. Sourcing-related risks belong here alongside performance and safety concerns.

Identify sourcing-related risks early:

• Obsolescence exposure from single-source or end-of-life components
• Long-lead items that could delay production
• Regulatory compliance gaps for target markets

Tip: Tag these risks as potential non-functional requirements (NFRs)—requirements that define constraints and quality attributes rather than what the system does. 

Sourcing constraints fit this category perfectly: they describe conditions the system must meet to be viable in the real world.

Requirements Creation Phase

Requirements documentation (ideally formalized before design begins) turns stakeholder needs into verifiable, traceable statements. Sourcing constraints should be documented with the same rigor as performance or safety requirements.

Tip: Capture sourcing constraints as verifiable requirements with clear acceptance criteria. 

Remember to follow good requirements writing practices. This transforms a vague intent into a testable, traceable requirement. Natural language requirements shall be clear, verifiable, and traceable and describe the “what”—not the “how.”

For example, write: "Critical components shall have at least two approved sources with equivalent form, fit, and function, documented in the approved vendor list (AVL) before production release." 

Additionally, apart from the requirement description, record additional information to provide additional context, such as the requirement type, a rationale, its originator, fit criteria, dependencies, and supporting materials. 

Verification Phase

The work is not completed until the requirements have been verified (the process of checking that you built the product right). This is typically achieved through design reviews, prototype builds, and production readiness milestones. 

Tip: Include BOM reviews in your verification plans and acceptance procedure and attach sourcing artifacts as evidence to prove compliance. 

Verification activities for sourcing requirements might include:

• Collecting Certificates of Compliance (CoC) for regulated components
• Reviewing supplier documentation for lifecycle and availability
• Conducting BOM health checks at key project milestones
• Validating that alternate components meet form-fit-function criteria

Include these checks in your design review checklists and gate criteria, but remember that sourcing isn't something to verify at the end, but something to continuously monitor as the design evolves.

Tools That Connect BOMs and Requirements

By now you should be wondering, "this all sounds good in theory, but how do I put it into practice?"

There are numerous tools out there that tout requirements traceability, but when it comes to electronics sourcing, these are the three capabilities that matter:

• Linking requirements directly to electronic designs, down to the component level
• Showing up-to-date part availability, lifecycle status, and compliance data
• Giving access to requirements and verification status to all internal stakeholders

Having access to a single platform that includes all these capabilities is also extremely beneficial. Disconnected tools create information silos and manual rework. The more seamlessly your requirements, design, and sourcing data connect, the faster you can respond to changes and the lower your risk of overlooked constraints.

If this sounds convincing, consider starting a free evaluation of Requirements Portal, which is included in the newly launched Altium Develop.

Main Takeaways

Here are three actions you can implement tomorrow:

1. Add Sourcing to Your Stakeholder List

For engineers: Include procurement in your next requirements elicitation session. Treat them as a core stakeholder, just like QA, firmware, or manufacturing.

For sourcing professionals: Volunteer to join requirements reviews and design kickoffs. Bring your perspective on supply risk before designs are locked in.

2. Review Your Top 10 Components for Risk

Pull the current BOM and flag the top 10 critical components. Ask: Is it single-sourced? Already NRND or EOL? Does it meet required compliance? What's the current lead time?

3. Formalize a Sourcing Constraint Template

Add a "Supply-Chain Constraints" section to your company requirements standards with the following:

• Maximum acceptable lead time
• Number of approved sources required
• Lifecycle status and expected availability window
• Compliance requirements (RoHS, REACH, conflict minerals, etc.)

Make this section mandatory for design reviews so sourcing risks are visible and documented.

Conclusion

If you're managing requirements without involving sourcing, you will eventually get blindsighted by risk. 

Treat your BOM like you would treat any other design artifact. 

Start upstream by writing sourcing needs into requirements. Finish downstream with tools that give you full visibility from requirements definition through BOM management. 

If you are looking to get started with requirements in your team, Requirements Portal is a requirements and verification management tool integrated directly into Altium’s solutions. Requirements Portal is included in Altium Develop with unlimited requirements and users.

References & Relevant Standards

• ISO/IEC/IEEE 29148: Systems and Software Engineering – Requirements Engineering
• IEC 62402: Obsolescence Management – Application Guide
• SAE AS6081: Counterfeit Electronic Parts – Avoidance, Detection, Mitigation, and Disposition
• IPC-1752A: Materials Declaration Management (RoHS, REACH)
• ISO/IEC/IEEE 15288: Systems and Software Engineering – System Life Cycle Processes