Introduction to Requirements Management in Automotive & Embedded Software Development
Automotive and embedded software development teams are building products with increasingly complex interactions between hardware, firmware, applications, communication networks, and external systems. As these products evolve, managing requirements across spreadsheets, documents, emails, and disconnected tools becomes difficult to sustain.
A missed or misunderstood requirement can lead to design rework, integration failures, delayed testing, compliance gaps, or costly changes late in the development lifecycle. For safety-critical and regulated products, teams also need to demonstrate how stakeholder expectations were translated into verified system and software behaviour.
This is why requirements management in automotive and embedded software development is more than a documentation activity. It is a structured way to capture what a product must do, explain why it must do it, connect requirements to engineering work, control changes, and maintain evidence that the intended requirements have been addressed.
If your automotive or embedded teams are managing requirements across spreadsheets, disconnected repositories, or multiple supplier systems, MicroGenesis can help establish a structured and traceable process through its ALM software solutions.
What Is Requirements Management in Automotive Software Development?
Requirements management is the systematic process of capturing, organizing, analysing, documenting, reviewing, approving, tracing, changing, and maintaining requirements throughout the product lifecycle.
In automotive software development, requirements may originate from several sources, including:
- Customer and market expectations
- Hardware and electronic control unit constraints
- Functional safety objectives
- Cybersecurity risk assessments
- Regulatory and industry standards
- Manufacturing and service requirements
- Software architecture and interface definitions
- Verification and validation activities
These requirements are gradually refined as development moves from the vehicle level to systems, hardware, and software.
A simple example
Consider a vehicle requirement stating that the vehicle must provide a warning when the driver approaches an obstacle at a specific speed.
That single requirement may need to connect to:
- Sensor performance requirements
- Signal-processing requirements
- ECU software requirements
- Human-machine interface requirements
- Timing and latency requirements
- Safety analysis and risk controls
- Verification and validation test cases
- Defect records and release baselines
Without a connected requirements structure, teams may implement only part of the expected behaviour or struggle to prove that the requirement was fully verified.
Requirements management is therefore not simply about storing statements. It is about maintaining a reliable connection between product intent, engineering decisions, implementation, and evidence.
Why Requirements Management Matters in Automotive and Embedded Systems
Automotive and embedded products involve multiple engineering disciplines, suppliers, tools, and development stages. A requirement created by a system engineer may later be refined by a software architect, implemented by a developer, and verified by a separate testing team.
Without a consistent process, information can become fragmented and difficult to maintain.
1. Managing complex system dependencies
A vehicle function may depend on several ECUs, sensors, actuators, networks, and software components. A change in one requirement can affect multiple downstream elements.
For example, changing the response time of a braking-related function may affect:
A structured requirements environment helps teams identify these dependencies before changes create unexpected consequences.
2. Connecting hardware and software requirements
Embedded software operates within physical constraints. Requirements must account for memory, processor capacity, timing, power consumption, interfaces, communication protocols, and hardware availability.
A software requirement that appears reasonable in isolation may not be feasible on the selected hardware. Requirements management helps system, hardware, and software teams review these relationships early.
3. Supporting safety and cybersecurity activities
Automotive products may involve engineering and process expectations associated with Automotive SPICE, ISO 26262, and ISO/SAE 21434.
These frameworks involve disciplined engineering activities, documented decisions, traceability, verification, and controlled changes. Requirements management supports this work by connecting safety goals, technical safety requirements, system requirements, software requirements, risks, and verification evidence.
4. Coordinating multiple suppliers and engineering teams
Automotive development commonly involves OEMs, Tier 1 suppliers, Tier 2 suppliers, software vendors, and specialist engineering partners. Each organization may use different tools, naming conventions, review processes, and release cycles.
A common requirements structure and agreed traceability model help teams collaborate without losing ownership or accountability.
5. Supporting product variants and reuse
Automotive platforms often support multiple vehicle models, powertrain configurations, regional variants, and optional features. Embedded products may also reuse software components across several product lines.
Requirements management helps teams distinguish common requirements from variant-specific requirements and ensures that changes are applied to the correct configurations.
6. Reducing late-stage rework
When requirements are unclear or poorly controlled, defects may be discovered only during integration or testing. At that stage, correcting the issue may require changes to architecture, code, hardware, documentation, and test cases.
A disciplined process helps identify ambiguity and inconsistency earlier, when changes are easier to manage.
Requirements Engineering, Requirements Management, Traceability, and ALM
These terms are closely related, but they describe different parts of the engineering process.
Requirements engineering
Requirements engineering focuses on discovering, analysing, defining, and validating what stakeholders and systems need.
It includes activities such as:
Requirements management
Requirements management controls requirements after they are captured. It covers:
Requirements traceability
Requirements traceability establishes relationships between requirements and other engineering artefacts, such as:
Application Lifecycle Management
Application Lifecycle Management, or ALM, provides a broader environment for managing requirements alongside development, testing, defects, changes, releases, and governance.
For automotive organizations, requirements management becomes more effective when it is part of an integrated ALM process rather than a standalone documentation activity.
The Automotive Requirements Management Lifecycle
Requirements management continues throughout the product lifecycle. It does not end when the initial requirements document is approved.
A practical lifecycle typically includes the following stages.
1. Capture stakeholder and customer needs
The process begins by identifying what customers, vehicle programmes, business teams, regulators, and other stakeholders expect from the product.
At this stage, requirements may be expressed in business, functional, operational, safety, performance, or user-oriented language. The goal is to capture the need without prematurely deciding how it will be implemented.
2. Define system-level requirements
Stakeholder needs are translated into system requirements that describe the expected behaviour and constraints of the complete product.
For example:
The vehicle shall provide an audible and visual warning when an object is detected within the defined proximity range while the vehicle is operating below the specified speed threshold.
System requirements should establish measurable expectations while remaining independent of unnecessary implementation details.
3. Decompose requirements into hardware and software requirements
System requirements are allocated to hardware, embedded software, application software, communication interfaces, and other system elements.
This decomposition should preserve the relationship between the original system intent and the lower-level requirements.
4. Analyse and refine requirements
Requirements are reviewed for:
- Safety and cybersecurity relevance
Ambiguous terms, conflicting conditions, missing interfaces, and undefined performance limits should be resolved before implementation begins.
5. Review and approve requirements
Relevant stakeholders review requirements based on their responsibilities. Depending on the project, reviewers may include:
- Functional safety specialists
- Test and validation teams
Approved requirements become controlled project inputs.
6. Establish baselines
A baseline is a formally reviewed and approved version of a set of requirements.
Baselines provide a stable reference for development, testing, audits, and release planning. When requirements change after baselining, the change should follow a controlled process rather than being silently edited.
7. Link requirements to implementation and verification
Requirements should be connected to architecture, design, code, test cases, test results, defects, and release versions.
This provides visibility into progress and helps teams identify unimplemented or unverified requirements.
8. Manage changes throughout the lifecycle
Requirements change because of customer feedback, technical discoveries, regulatory updates, safety findings, supplier changes, or product strategy decisions.
Each change should be assessed for its impact on scope, architecture, software, hardware, testing, safety, cybersecurity, schedule, and cost.
9. Verify, validate, and maintain
Teams must confirm that requirements have been implemented correctly and that the final product meets stakeholder needs.
Requirements remain relevant after release because maintenance, field issues, software updates, and new product variants may introduce additional changes.
Best Practices for Automotive Requirements Management
Good requirements management depends on disciplined working practices as much as it depends on software tools.
1. Establish a clear requirements hierarchy
A well-structured hierarchy makes it easier to understand how requirements relate to one another.
A typical hierarchy may include:
- Vehicle-level requirements
- Verification requirements
The hierarchy should reflect the product architecture and development process. It should also make ownership clear.
2. Write clear, atomic, and testable requirements
A good requirement should express one primary obligation or behaviour. It should avoid vague words such as:
Instead, requirements should define measurable conditions wherever possible.
Weak requirement:
The system shall respond quickly to driver input.
Improved requirement:
The system shall initiate the defined control response within 100 milliseconds after receiving a valid driver input signal.
The improved version is easier to analyse, implement, and verify. The actual value and conditions should be determined by the project’s engineering requirements.
3. Give every requirement a unique identifier
A unique ID makes it easier to reference a requirement across documents, tools, reviews, and test reports.
For example:
The naming convention should be consistent and meaningful to the organization.
4. Separate requirements from implementation decisions
Requirements describe what the system must do. Design and implementation documents describe how the team intends to achieve it.
For example:
Requirement:
The software shall detect the specified sensor communication fault and transition to the defined fallback state.
Implementation decision:
The software will use a timeout monitor to detect missing sensor messages.
Keeping these separate makes it easier to evaluate alternative designs without rewriting the original requirement.
5. Define verification criteria early
A requirement should have a clear answer to the question:
How will we know this requirement has been satisfied?
Depending on the requirement, verification may involve:
- Hardware-in-the-loop testing
For example, a requirement about software response time should identify the conditions under which the response is measured and the expected result.
6. Maintain bidirectional traceability
Bidirectional traceability means being able to follow a requirement in both directions.
Forward traceability answers:
What design, code, and test activities were created to satisfy this requirement?
Backward traceability answers:
Why does this design element, code component, or test case exist?
A strong traceability model may connect:
Stakeholder need → System requirement → Software requirement → Architecture → Code → Test case → Test result → Release
This helps identify:
- Requirements without implementation
- Requirements without test coverage
- Test cases without a valid requirement
- Code changes without a related requirement
- Defects affecting critical functions
- Unverified safety or cybersecurity requirements
7. Connect requirements with risks and hazards
In safety-critical development, requirements should be linked to relevant hazards, risks, safety goals, and mitigation measures.
This relationship helps teams understand why a requirement exists and what could happen if it is not implemented correctly.
For cybersecurity, requirements may also be connected to:
- Security verification activities
8. Use formal change control
Not every change has the same impact. A minor wording correction may require a simple review, while a change to a safety-related timing requirement may affect the entire system.
A controlled change process should include:
- Change request creation
- Reason for the change
- Affected requirements
- Impact analysis
- Review by responsible stakeholders
- Approval or rejection
- Implementation
- Verification
- Baseline update
- Change history
This process helps prevent uncontrolled changes from entering development.
9. Apply baselines and version control
Requirements should be versioned and baselined at important project milestones, such as:
- System requirements review
- Software requirements review
Teams should be able to compare versions, identify changes, restore earlier baselines, and understand who approved each update.
10. Support variants and configuration management
Automotive programmes often share a common platform while adapting features for different vehicle models, markets, or hardware configurations.
A requirements management solution should support:
- Variant-specific requirements
- Product-specific releases
Without configuration control, teams may apply a requirement change to the wrong vehicle or software variant.
11. Integrate requirements with development and testing
Requirements should not remain isolated from engineering execution.
Integration with development and test environments helps teams connect requirements to:
- Continuous integration and delivery
This improves visibility and reduces duplicate data entry.
12. Introduce reviews and quality checks early
Requirements quality should be evaluated before implementation.
Review checklists can assess:
- Safety and cybersecurity relevance
Automated quality checks can also identify duplicate requirements, missing attributes, inconsistent terminology, or incomplete relationships.
13. Define ownership and governance
Every requirement should have a clear owner or responsible team.
Governance should define:
- Who performs impact analysis
- Who confirms verification
- Who maintains compliance evidence
A tool cannot compensate for unclear ownership or inconsistent processes.
Requirements Traceability for ASPICE Compliance
Requirements traceability is a central part of disciplined automotive development. It helps demonstrate that requirements are analysed, implemented, verified, and controlled throughout the lifecycle.
For teams preparing for Automotive SPICE assessments, traceability should be understood as more than creating links between documents. It should provide meaningful evidence that engineering activities are connected and that project outputs are consistent with defined process expectations.
A practical ASPICE-oriented traceability structure may connect:
- Customer requirements to system requirements
- System requirements to software requirements
- Requirements to architecture and design
- Requirements to test specifications
- Test specifications to test results
- Defects to affected requirements
- Changes to impact analysis and approvals
Traceability also supports gap analysis. For example, if a safety-related software requirement has no linked test case, the project team can identify the gap before release.
However, requirements management and traceability do not automatically guarantee ASPICE compliance or certification. They provide the process foundation and evidence needed to support disciplined engineering and assessment readiness.
Requirements Management for Functional Safety and Cybersecurity
ISO 26262 and functional safety
Functional safety requirements must be managed with particular care because they are connected to hazards, safety goals, risk reduction, and verification obligations.
Requirements management can help teams maintain relationships between:
- Functional safety requirements
- Technical safety requirements
- Hardware safety requirements
- Software safety requirements
When a safety-related requirement changes, teams should be able to identify the affected architecture, implementation, tests, and safety analysis.
ISO/SAE 21434 and automotive cybersecurity
Cybersecurity requirements may originate from threat analysis and risk assessment activities. These requirements should be linked to security controls, design decisions, verification activities, and vulnerability management.
For example, a cybersecurity requirement for secure communication may affect:
A connected requirements environment helps cybersecurity teams collaborate with system, software, and test engineers while maintaining traceability across the product lifecycle.
Selecting the Right Requirements Management Tool
The right tool should be selected based on engineering and governance needs rather than feature lists alone.
Important evaluation criteria include:
- Requirements authoring and organization
- Version control and baselining
- Review and approval workflows
- Bidirectional traceability
- Variant and configuration management
- Integration with development and test tools
- Collaboration across suppliers
- Security and access control
- Usability for engineering teams
A tool should support the process, not become a replacement for having a clear process.
IBM Engineering Lifecycle Management and DOORS Next
IBM Engineering Lifecycle Management provides an integrated environment for requirements, development, testing, and lifecycle governance.
IBM Engineering Requirements Management DOORS Next supports requirements authoring, organization, traceability, reviews, baselines, and relationships with other engineering artefacts.
For automotive and embedded organizations, IBM ELM can support structured requirements processes by helping teams connect requirements with development and verification activities.
Organizations evaluating IBM DOORS Next should consider how it will fit into their existing engineering ecosystem, including development tools, test management platforms, modelling environments, reporting systems, and supplier workflows.
IBM DOORS Next and PTC Codebeamer
Both IBM DOORS Next and PTC Codebeamer can support requirements management, traceability, change control, and regulated product development. However, the appropriate choice depends on the organization’s existing tools, process maturity, integration requirements, product complexity, and compliance priorities.
- Requirements modelling and authoring capabilities
- Test and risk management integration
- Configuration and baseline management
- Reporting and auditability
- Integration with existing engineering tools
- Long-term platform strategy
The decision should be based on a practical assessment of the complete lifecycle rather than the requirements module alone.
How to Implement Requirements Management in an Embedded Project
Implementation should be approached as a process improvement initiative, not simply a tool installation.
Step 1: Assess the current process
Document how requirements are currently created, stored, reviewed, changed, and verified.
Identify problems such as:
- Disconnected test evidence
- Multiple versions of the same document
- Limited visibility into verification status
Step 2: Define the target operating model
Establish the future requirements lifecycle, including roles, workflows, review gates, approval rules, baselines, and change control.
Step 3: Design the requirements structure
Define the hierarchy, attributes, naming conventions, relationships, requirement types, and traceability rules.
Step 4: Select and configure the tool
Configure workflows, permissions, templates, dashboards, integrations, and reporting based on the target process.
Step 5: Migrate and clean existing requirements
Migration should include more than importing documents. Existing requirements should be reviewed for:
Step 6: Pilot the process
Start with a representative project or subsystem. Use the pilot to validate workflows, templates, traceability relationships, reporting, and user experience.
Step 7: Train engineering teams
Training should cover both tool usage and the reasoning behind the process. Teams need to understand why requirements must be atomic, why baselines matter, and how traceability supports engineering quality.
Step 8: Measure and improve
Track process metrics and use project feedback to improve templates, workflows, integrations, and governance.
Measuring Requirements Management Effectiveness
Traceability coverage
Measures the percentage of requirements linked to the expected downstream and upstream artefacts.
Requirements volatility
Tracks how frequently requirements change during a project phase. High volatility may indicate unclear scope, unstable interfaces, or changing stakeholder expectations.
Review and approval cycle time
Measures how long requirements remain pending review or approval.
Unlinked or orphan requirements
Identifies requirements without implementation, verification, ownership, or source justification.
Test coverage
Shows how many requirements have linked test cases and completed verification results.
Defects linked to requirements
Helps identify requirements that are unclear, incomplete, inconsistent, or difficult to implement.
Rework caused by requirements
Tracks engineering effort spent correcting issues caused by missing or misunderstood requirements.
Baseline compliance
Measures whether development and testing activities are using approved and controlled requirement versions.
Metrics should be used to identify process improvements rather than simply to report performance.
Common Requirements Management Challenges
Even organizations with established processes can face recurring problems.
Requirements are spread across multiple tools
Teams may use spreadsheets for requirements, documents for specifications, issue trackers for changes, and separate tools for testing.
Practical response: Define which system is authoritative for each type of information and establish clear links between systems.
Requirements are written too late
When requirements are treated as documentation created after design decisions have already been made, ambiguities may remain hidden.
Practical response: Involve engineering and verification stakeholders early, before implementation is too far along.
Traceability is created only before an assessment
If traceability is treated as a last-minute reporting exercise, links may be incomplete or difficult to trust.
Practical response: Make traceability part of the normal development workflow.
Changes are approved without impact analysis
A change may appear small but affect several downstream artefacts.
Practical response: Require impact analysis before approval, with the level of detail based on the risk and scope of the change.
Teams focus on tool features instead of process needs
A tool may offer many capabilities, but that does not mean every feature is necessary.
Practical response: Start with the engineering problems to be solved, then configure or select tools accordingly.
How MicroGenesis Can Support Requirements and ALM Initiatives
Requirements management often involves more than selecting a tool. Organizations may also need help defining workflows, improving traceability, integrating engineering systems, and aligning requirements activities with broader application lifecycle management practices.
MicroGenesis provides ALM services that can support organizations evaluating or improving their requirements and lifecycle management processes. The appropriate approach depends on the existing tool environment, engineering workflow, and project objectives.
For organizations working with IBM’s engineering lifecycle management ecosystem, MicroGenesis also offers IBM Engineering Lifecycle Management services. The specific scope of support should be evaluated against the organization’s tools, processes, and implementation needs.
Conclusion
Requirements management is a foundational capability for automotive and embedded software development. It helps organizations manage complexity, control change, improve traceability, support functional safety and cybersecurity activities, and reduce the risk of late-stage rework.
A mature approach combines:
- Clear and testable requirements
- Structured requirement hierarchies
- Bidirectional traceability
- Variant and configuration support
- Integration with development and testing
- Strong governance and ownership
- Practical compliance evidence
- Continuous process improvement
The right requirements management tool can strengthen these practices, but successful implementation also requires defined processes, trained teams, reliable data, and consistent engineering discipline.
If your organization is planning to modernize requirements management, improve ASPICE traceability, migrate from legacy tools, or establish an integrated ALM environment, MicroGenesis can help you define a practical roadmap aligned with your engineering and compliance objectives. Explore MicroGenesis ALM services
