Process · General Industry
Requirements management
Capturing, analysing, agreeing, baselining and tracing requirements through design and verification, and controlling changes to them. It is usually supported by a dedicated tool so that each requirement can be linked to its tests and evidence.
- Type
- Process
- Domain
- General Industry, Design and product flow
Overview
Requirements management is the discipline of capturing, analysing, agreeing, baselining and tracing a product's requirements, and of controlling changes to them for the life of a project. For a chip, requirements range from customer features and performance targets to power, safety, security and regulatory needs, each of which must be linked to the design and to the evidence that it is met. It is supported by process standards and by tools that hold each requirement as a managed record.
How it works
Requirements come from customers, product marketing, standards, regulations and internal platform goals. Each is written as a separate statement with an identifier, an owner, a rationale, a priority and a way to verify it. ISO/IEC/IEEE 29148 describes the processes involved and the information a requirements record should carry; in practice teams aim for statements that are clear, testable and say what must be true rather than how to build it.
Requirements are refined down a hierarchy: a customer need becomes a product specification item, which splits into SoC, subsystem, block and software requirements. Once reviewed and agreed, a set is baselined. From then on, changes go through a change request that records the reason, the impact on design, schedule and tests, and the decision. Traceability links connect each requirement to its parent, to the design that implements it and to the tests that check it.
Many teams use tools such as IBM DOORS or Jama Connect, and companies can exchange requirements through the OMG Requirements Interchange Format (ReqIF). The hard part on chip projects is scale and connection: thousands of requirements, and links into RTL and verification data that general tools do not understand, so spreadsheets and manual linking remain common sources of error.
Examples
- A customer ASIC project where the customer's specification arrives through ReqIF and each item is reviewed and answered before the contract is fixed.
- An automotive microcontroller whose safety requirements are derived from system safety goals and linked to safety mechanisms and verification results.
- A late change request that raises the maximum junction temperature, with the impact on timing signoff, packaging and qualification assessed before approval.
- A derivative SoC that reuses the baselined requirement set of its parent and records only the differences.
Why it matters
Missed or misunderstood requirements are among the costliest problems in chip development, because a silicon respin or a customer escape costs far more than a correction on paper. Architects, systems engineers, verification leads, functional safety managers and programme managers rely on an agreed requirement set, and ISO 26262 makes the management of safety requirements and of changes an explicit supporting process.
In the chip lifecycle, requirements are captured at product definition and architecture, refined through design, closed out in verification and validation, and kept under change control through production and any derivative products.
It matters most to: Customer ASIC Architect, Functional Safety Manager, Process Quality Engineer (Automotive SPICE), Safety Work Product Author, Systems Engineer
Common confusions
- Not the same as requirements traceability
- Traceability is one part of requirements management: the links from each requirement to its source, design and tests. Requirements management also covers capture, review, baselining and change control. Requirements management vs requirements traceability
- Not the same as a PRD (product requirements document)
- A PRD is one document stating what a product must do. Requirements management is the ongoing process that keeps such documents, and the requirements in them, controlled and linked.
- Not the same as project management
- Project management tracks tasks, schedule and cost; requirements management tracks what the product must do and whether it does it. The two meet when a change is assessed.
Related standards
- ISO/IEC/IEEE 29148 (requirements engineering processes and information items)
- ISO 26262-8 (road vehicles functional safety: supporting processes)
- OMG ReqIF (Requirements Interchange Format)
Sources
- ISO/IEC/IEEE 29148:2018 Systems and software engineering, Life cycle processes, Requirements engineering (opens in a new tab), ISO, 2026-10-22
- ISO 26262-8:2018 Road vehicles, Functional safety, Part 8: Supporting processes (opens in a new tab), ISO, 2026-10-22
- About the Requirements Interchange Format Specification Version 1.2 (opens in a new tab), Object Management Group, 2026-10-22
- Traceability, Unfamiliar But Critical (Paul Graykowski, 6 January 2022) (opens in a new tab), Semiconductor Engineering, 2026-10-22
- Requirements management (Wikipedia) (opens in a new tab), Wikimedia Foundation, 2026-10-22
Related terms
Part of the General Industry glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 29 pages of the Hub. In each group, the pages that mention it most come first.
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary