How to Implement Requirements Management in Embedded Projects 

Embedded systems are becoming more complex as products combine software, electronics, connectivity, sensors, control systems, and safety-critical functions. From automotive ECUs and industrial controllers to medical devices and aerospace systems, engineering teams must manage requirements across multiple disciplines while maintaining traceability, controlling changes, and meeting compliance expectations. 

However, many embedded projects still rely on spreadsheets, documents, emails, and disconnected engineering tools. This can create ambiguous requirements, duplicate information, missed changes, limited traceability, and uncertainty about whether the final product satisfies its original objectives. 

A structured requirements management process establishes a reliable connection between customer expectations, system requirements, software requirements, design decisions, implementation, testing, and compliance evidence. 

This guide explains how to implement requirements management in embedded projects, including the key processes, tools, roles, challenges, and best practices involved. 

What Is Requirements Management in Embedded Projects? 

Requirements management is the systematic process of capturing, documenting, organising, reviewing, tracing, prioritising, and controlling requirements throughout the embedded product lifecycle. 

Requirements may originate from: 

• Customer and market expectations 

• Product specifications 

• System architecture 

• Hardware constraints 

• Software functionality 

• Safety and cybersecurity standards 

• Regulatory obligations 

• Manufacturing requirements 

• Environmental and performance conditions 

• Maintenance and service needs 

These requirements should be organised into a structured hierarchy: 

Customer Requirement → System Requirement → Hardware or Software Requirement → Design Element → Implementation → Test Case → Verification Result 

This relationship helps teams understand why each requirement exists, where it is implemented, and how it will be verified. 

Requirements management is not limited to the beginning of a project. It continues throughout development, testing, release, maintenance, and product evolution. 

Why Requirements Management Is Important in Embedded Development 

Embedded projects are especially sensitive to requirements-related problems because hardware and software are closely interconnected. A change in timing, memory usage, communication protocol, or safety behaviour can affect several teams and development stages. 

A formal requirements management process helps organisations:

Reduce Ambiguity

Clear requirements reduce different interpretations between systems engineers, software developers, hardware teams, testers, and customers. 

A good requirement should define: 

• Expected behaviour 

• Operating conditions 

• Performance targets 

• Applicable constraints 

• Verification expectations 

Improve Cross-Functional Collaboration

Embedded development involves systems engineering, hardware, software, firmware, testing, safety, cybersecurity, quality, and product management. 

These challenges are particularly visible in automotive software development, where multiple engineering disciplines must coordinate requirements throughout the vehicle lifecycle. Learn more about requirements management in automotive software development and how structured processes help teams improve collaboration, traceability, and engineering control.

A centralised requirements repository gives these teams access to the same approved information.

Improve Traceability

Traceability connects requirements to architecture, design, code, test cases, defects, and verification results. It helps teams determine whether requirements have been implemented and tested.

Control Change Impact

A small requirement change can affect interfaces, architecture, code, test procedures, schedules, and compliance evidence. Requirements management helps teams identify these dependencies before approving changes.

Support Compliance

Standards and frameworks such as Automotive SPICE, ISO 26262, IEC 62304, IEC 61508, and ISO 21434 require disciplined engineering processes, documented evidence, and traceability. 

A requirements management system helps organisations maintain the information needed for assessments and audits. However, using a tool alone does not guarantee compliance. Process quality, reviews, verification, and evidence management remain essential.

Improve Product Quality

Complete, consistent, and verifiable requirements help teams identify gaps earlier and reduce expensive rework during integration and validation. 

Step-by-Step Process to Implement Requirements Management 

Step 1: Define the Requirements Management Strategy 

Before selecting a tool or creating templates, define how requirements will be managed across the project. 

The strategy should establish: 

• Requirement types and hierarchy 

• Naming and identification conventions 

• Required attributes 

• Review and approval procedures 

• Baseline and version control rules 

• Traceability expectations 

• Change management process 

• Ownership and responsibilities 

• Reporting requirements 

• Compliance obligations 

• Tool usage guidelines 

The strategy should also define whether requirements will be managed at the product, system, hardware, software, subsystem, or component level. 

A typical automotive embedded project may use this hierarchy: 

Customer requirements 

Vehicle-level requirements 

System requirements 

ECU requirements 

Software requirements 

Component requirements 

Test and verification requirements 

A clearly defined strategy prevents teams from using inconsistent processes across departments. 

Step 2: Identify Requirement Sources 

Embedded requirements often come from different documents, stakeholders, and engineering activities. 

Common sources include: 

• Statements of work 

• Product requirement documents 

• System specifications 

• Interface control documents 

• Hardware specifications 

• Software specifications 

• Safety goals 

• Technical safety requirements 

• Cybersecurity goals 

• Regulatory standards 

• Existing product documentation 

• Defect and field-failure records 

• Lessons learned from previous projects 

Each requirement should be associated with its source wherever possible. This provides context during reviews, impact analysis, and future changes. 

Step 3: Establish a Requirements Hierarchy 

A requirements hierarchy organises requirements according to their level of abstraction and responsibility. 

Stakeholder requirements describe customer, business, user, and regulatory expectations. 

Example: 

The device shall operate reliably within the specified industrial temperature range. 

System requirements define what the complete embedded system must achieve. 

Example: 

The controller shall maintain system operation between -40°C and +85°C. 

Hardware requirements describe electrical, physical, and hardware-related constraints. 

Example: 

The control board shall support operation from a 12 V nominal power supply. 

Software requirements define software behaviour and functional logic. 

Example: 

The software shall detect an over-temperature condition within 100 milliseconds. 

Component requirements define detailed behaviour for drivers, modules, or software components. 

Example: 

The temperature monitoring component shall sample the sensor input every 10 milliseconds. 

Verification requirements define how compliance will be demonstrated. 

Example: 

The over-temperature detection response time shall be verified through an automated timing test. 

This structure prevents high-level objectives from being mixed with detailed implementation decisions. 

Step 4: Define a Standard Requirements Template 

A consistent template improves requirement quality and makes requirements easier to review, trace, and test. 

This becomes even more important in safety-critical embedded systems, where poorly written requirements can create ambiguity during design, implementation, verification, and certification activities. Review our requirements writing best practices for safety-critical systems to learn how to create clear, complete, consistent, and verifiable requirements.

A useful requirement should be: 

• Clear 

• Specific 

• Unambiguous 

• Complete 

• Consistent 

• Feasible 

• Necessary 

• Verifiable 

• Traceable 

• Uniquely identifiable 

Weak requirement: 

The system should respond quickly to sensor changes. 

Improved requirement: 

The software shall detect a sensor value exceeding the configured threshold within 50 milliseconds of receiving a valid sensor sample. 

The improved requirement defines the expected behaviour, timing condition, and verification possibility. 

Step 5: Capture and Import Existing Requirements 

Many embedded projects begin with requirements stored in Excel, Word documents, PDFs, legacy databases, customer portals, or issue-tracking systems. 

Before importing them into a centralised platform, teams should: 

Collect existing requirement sources 

Remove duplicate requirements 

Identify obsolete content 

Standardise terminology 

Assign unique IDs 

Classify requirements by type 

Identify missing attributes 

Establish initial trace links 

Review and approve migrated requirements 

Create a baseline 

Simply importing spreadsheets without cleansing the data can transfer existing quality problems into the new system. 

Step 6: Establish Review and Approval Workflows 

Requirements should not move directly from creation to implementation. A defined workflow helps identify defects before they become expensive engineering problems. 

A typical workflow is: 

Draft → Technical Review → Cross-Functional Review → Approval → Baseline → Implementation → Verification 

Reviews may involve: 

• Systems engineers 

• Software architects 

• Hardware engineers 

• Safety engineers 

• Cybersecurity specialists 

• Test engineers 

• Product owners 

• Quality representatives 

• Customer representatives 

Reviewers should evaluate whether each requirement is necessary, correct, complete, consistent, feasible, testable, traceable, and properly classified. 

Approval should also be role-based. For example, a safety-related requirement may require approval from a functional safety engineer before it is baselined. 

Step 7: Create End-to-End Traceability 

Traceability connects requirements to the engineering artefacts that demonstrate their implementation and verification. 

A typical traceability chain is: 

Stakeholder Requirement → System Requirement → Software Requirement → Architecture Element → Code Module → Test Case → Test Result 

Traceability can also work backwards: 

Test Failure → Test Case → Requirement → Design Element → Source Requirement 

This helps teams identify: 

• Requirements without implementation 

• Requirements without test coverage 

• Safety-related requirements without verification 

• Requirements affected by a design change 

• Customer expectations that remain unaddressed 

• Obsolete requirements still present in the project 

Common traceability types include: 

• Forward traceability: Requirements to design, implementation, and verification 

• Backward traceability: Implementation and tests back to originating requirements 

• Bidirectional traceability: Both forward and backward relationships 

• Horizontal traceability: Connections across system, hardware, software, safety, and cybersecurity 

• Vertical traceability: Connections across different levels of abstraction 

For more information, read Requirements Traceability for ASPICE Compliance. 

Step 8: Link Requirements to Verification and Validation 

A requirement is not complete until the team knows how it will be verified. 

Verification methods may include: 

• Inspection 

• Analysis 

• Demonstration 

• Simulation 

• Unit testing 

• Integration testing 

• Hardware-in-the-loop testing 

• System testing 

• Field validation 

Teams should monitor: 

• Requirements with test cases 

• Requirements successfully verified 

• Unverified requirements 

• Failed verification links 

• Requirements with incomplete traceability 

Step 9: Implement Change and Impact Management 

Requirements may change because of customer requests, new regulations, hardware changes, software defects, safety analysis, cybersecurity findings, supplier changes, or integration constraints. 

A change management process should include: 

Change request creation 

Change rationale 

Impact analysis 

Effort and risk assessment 

Stakeholder review 

Approval or rejection 

Requirement update 

Traceability update 

Baseline revision 

Communication to affected teams 

Impact analysis should identify affected requirements, architecture elements, hardware interfaces, software components, test cases, defects, safety analyses, cybersecurity analyses, documentation, and release plans. 

Step 10: Establish Baselines and Version Control 

A baseline is an approved set of requirements used as a reference for a development stage or release. 

Typical baselines include: 

• System requirements baseline 

• Hardware requirements baseline 

• Software requirements baseline 

• Safety requirements baseline 

• Release requirements baseline 

• Customer acceptance baseline 

Baselines help teams determine: 

• Which requirements were approved for a release 

• Which requirements changed after approval 

• Who approved the changes 

• Which version was used for testing 

• What the requirement state was at delivery 

Requirements should not be overwritten without preserving their history. 

Common Requirements Management Challenges 

Embedded projects commonly face the following challenges: 

Disconnected Tools 

Separate tools for requirements, architecture, code, testing, and defects make traceability and impact analysis difficult. 

Spreadsheet-Based Requirements 

Spreadsheets can be useful for initial collection, but become difficult to manage when projects include thousands of requirements, multiple contributors, and frequent changes. 

Hardware and Software Dependencies 

A change to a hardware interface may affect drivers, communication protocols, timing behaviour, test cases, and system integration. 

Safety and Compliance Evidence 

Safety-critical projects require evidence that requirements were reviewed, allocated, implemented, verified, and controlled. 

Product Variants 

Different hardware configurations, markets, and feature sets make configuration management essential. 

Late Requirement Changes 

Late changes can require modifications to architecture, code, hardware, testing, and documentation. Early impact analysis helps reduce this risk. 

Selecting a Requirements Management Tool 

A requirements management tool should support the complexity and compliance needs of the embedded project.

When evaluating platforms for automotive requirements management, engineering teams often compare capabilities such as traceability, workflow control, baselines, integrations, reporting, and compliance support. Our comparison of IBM DOORS Next and PTC Codebeamer for automotive requirements management provides additional guidance for assessing these platforms. 

Important capabilities include: 

• Centralised requirements repository 

• Hierarchical organisation 

• Traceability across engineering artefacts 

• Version and baseline management 

• Review and approval workflows 

• Change and impact analysis 

• Requirements quality checks 

• Product variant management 

• Integration with development and testing tools 

• Traceability matrices and coverage reports 

• Audit and compliance reporting 

Platforms such as IBM Engineering Lifecycle Management and PTC Codebeamer ALM are commonly evaluated for structured requirements management, traceability, workflow control, and lifecycle integration. 

Organisations can also explore ALM services to assess existing processes, select an appropriate platform, migrate legacy requirements, and establish an integrated engineering lifecycle. 

Best Practices for Successful Implementation 

• Start with a pilot project 

• Involve systems, hardware, software, testing, safety, cybersecurity, and quality teams 

• Standardise terminology and requirement attributes 

• Avoid unnecessarily complex workflows 

• Automate traceability and reporting 

• Assign clear ownership for every requirement 

• Review requirements early 

• Measure requirements coverage and quality 

• Train teams on the process and tool 

• Improve the process based on project feedback 

Useful performance metrics include: 

• Requirements approved on time 

• Requirements with complete traceability 

• Requirements with verification coverage 

• Requirement volatility 

• Change request turnaround time 

• Defects caused by requirement gaps 

• Verification completion rate 

• Percentage of requirements baselined 

How MicroGenesis Supports Requirements Management 

Implementing requirements management requires more than deploying a software platform. Organisations must align processes, engineering teams, data structures, integrations, and compliance expectations. 

MicroGenesis supports embedded and automotive engineering organisations through: 

• Requirements management consulting 

• ALM platform evaluation and implementation 

• Requirements migration and data structuring 

• Traceability and impact analysis 

• Workflow and approval configuration 

• Integration with development and testing tools 

• Reporting and compliance support 

• ALM modernisation and managed services 

Explore MicroGenesis ALM Services to learn how requirements management, traceability, lifecycle integration, and engineering process improvement can be implemented across complex projects. 

Conclusion 

Requirements management is a foundational capability for successful embedded development. It helps engineering teams translate customer and system expectations into clear, testable, and traceable requirements while controlling changes throughout the product lifecycle. 

A successful implementation should include: 

• A defined requirements management strategy 

• Standardised requirement templates 

• A structured requirements hierarchy 

• Centralised requirements storage 

• Formal review and approval workflows 

• End-to-end traceability 

• Verification and validation links 

• Change and impact management 

• Baseline and version control 

• Integration with engineering tools 

• Clear ownership and measurable processes 

When implemented effectively, requirements management reduces ambiguity, improves collaboration, supports compliance, and gives engineering leaders greater confidence that the final embedded product meets its intended requirements.