How do I set up a requirements management platform for tracking engineering requirements during vehicle architecture planning?

To set up a requirements management platform for engineering requirements during vehicle architecture planning, aim for a system that connects requirements → architecture decisions → validation evidence → change control. Here’s a practical setup approach.

1) Define the scope and workflow

Start by clarifying what the platform must manage.

Typical requirement types

• Customer / market needs
• Vehicle-level system requirements
• Subsystem requirements
• Interface requirements
• Regulatory / safety / compliance requirements
• Derived requirements from architecture decisions

Core workflow

1. Capture requirement
2. Review and approve
3. Baseline for an architecture milestone
4. Allocate to systems/components
5. Link to verification method
6. Track changes and impact
7. Close with evidence

---

2) Choose the platform capabilities

Whether you use IBM DOORS Next, Jama, Polarion, Codebeamer, or a custom tool, make sure it supports:

Must-have features

• Hierarchical requirements structure
• Unique IDs and versioning
• Traceability links
• Review/approval workflows
• Baselines and configuration management
• Change requests and impact analysis
• Verification/validation tracking
• Role-based permissions
• Search and reporting dashboards
• Export/import for engineering data

Nice-to-have features

• SysML/model integration
• PLM/ALM integration
• Safety case linkage
• Issue/task management
• API access
• Collaboration comments and electronic signatures

---

3) Set up your requirements taxonomy

Create a standard classification scheme so every requirement is searchable and traceable.

Example taxonomy

• Level: stakeholder / vehicle / system / subsystem / component
• Domain: body, powertrain, EE, thermal, chassis, ADAS, etc.
• Type: functional, performance, interface, safety, regulatory, diagnostic
• Lifecycle: concept, architecture, detailed design, validation
• Priority: must / should / could
• Status: draft, in review, approved, baselined, changed, retired

Example requirement ID format

• VEH-FUNC-0012
• ADAS-IF-0045
• SAFE-REQ-0021

---

4) Define a requirement template

Standardize how requirements are written.

Good requirement characteristics

Each requirement should be:

• Clear
• Unambiguous
• Testable
• Atomic
• Traceable
• Feasible
• Necessary

Template fields

• ID
• Title
• Requirement statement
• Rationale
• Source
• Owner
• Priority
• Safety/compliance classification
• Verification method
• Acceptance criteria
• Related requirements
• Linked architecture element
• Status
• Revision history

Example

• Requirement: “The vehicle shall maintain cabin temperature between 20°C and 24°C under ambient conditions from -20°C to 45°C.”
• Verification: Test + analysis
• Linked architecture element: HVAC thermal model / subsystem concept

---

5) Build the architecture linkage structure

For vehicle architecture planning, the key is not just storing requirements, but linking them to architecture decisions.

Connect requirements to:

• Functions
• Logical architecture blocks
• Physical components
• Interfaces
• Variants/configurations
• Performance budgets
• Constraints

Recommended traceability chain

Stakeholder need → Vehicle requirement → System requirement → Subsystem requirement → Component requirement → Verification evidence

This makes it easier to:

• analyze impact when architecture changes
• identify gaps or over-allocation
• show coverage for reviews
• manage variants and platform derivatives

---

6) Set up roles and governance

Define who can create, approve, and change requirements.

Common roles

• Requirement author
• System architect
• Domain lead
• Chief engineer
• Verification lead
• Safety/compliance engineer
• Change control board (CCB)

Governance rules

• Only approved requirements can enter a baseline
• Every change must have rationale and impact assessment
• Architecture decisions must reference linked requirements
• No orphan requirements without source/owner
• Verification method must be assigned before design freeze

---

7) Create baselines aligned to architecture milestones

Baseline requirements at key program gates.

Example baselines

• Concept baseline
• Vehicle architecture baseline
• System architecture freeze
• Design release baseline
• Validation baseline

This gives you a stable reference point for:

• trade studies
• supplier discussions
• change control
• compliance evidence

---

8) Configure traceability and impact analysis

This is one of the most valuable parts.

Traceability views to create

• Requirement-to-requirement
• Requirement-to-architecture element
• Requirement-to-test case
• Requirement-to-risk/safety hazard
• Requirement-to-change request

Impact analysis questions

• Which architecture blocks are affected?
• Which downstream requirements change?
• Which verification activities are impacted?
• Which variants are affected?
• Does this break compliance or safety coverage?

---

9) Establish verification planning early

Requirements should not be complete until they can be verified.

Verification methods

• Test
• Analysis
• Inspection
• Demonstration

Add verification metadata

• Planned method
• Responsible team
• Required environment
• Acceptance criteria
• Evidence link
• Status: planned / in progress / passed / failed

---

10) Integrate with other engineering tools

A requirements platform works best when it’s connected to the broader toolchain.

Useful integrations

• CAD / MBSE tools for architecture models
• PLM for part structures and released configurations
• ALM / software tools for ECU/software requirements
• Test management for validation execution
• Issue tracking for defects and actions
• Document management for specifications and reports

This reduces duplicate entry and improves consistency.

---

11) Build dashboards and reports

You need visibility for architecture planning decisions.

Useful dashboards

• Requirements by status
• Coverage by system/subsystem
• Unverified requirements
• Open changes by impact area
• Compliance requirement coverage
• Requirements with no architecture link
• Requirements with no owner
• Overallocated or conflicting requirements

Key reports

• Architecture requirements allocation matrix
• Traceability matrix
• Verification status report
• Change impact report
• Baseline comparison report

---

12) Define data quality rules

Create validation checks to keep the repository clean.

Examples

• Requirement must have an owner
• Requirement must have a source
• Requirement must be testable
• Requirement must be linked to at least one architecture element
• Requirement must have a verification method
• Duplicate detection enabled
• Deprecated requirements marked inactive, not deleted

---

13) Pilot before scaling

Don’t deploy across the whole vehicle program at once.

Pilot scope

Choose one domain, such as:

• HVAC
• EE architecture
• ADAS
• battery system
• body structure

Pilot goals

• Validate requirement templates
• Test workflow approvals
• Confirm traceability needs
• Measure usability
• Refine reporting

Then expand to the full vehicle architecture.

---

14) Train users and define operating rules

Tool success depends on process adoption.

Training topics

• How to write requirements
• How to trace requirements
• How to baseline and change control
• How to use architecture links
• How to create verification evidence
• How to avoid “document dumping”

Operating standard

Create a lightweight handbook covering:

• naming conventions
• review cadence
• approval authority
• change request process
• baseline rules
• reporting expectations

---

15) Suggested implementation roadmap

Phase 1: Foundation

• Select tool
• Define taxonomy and templates
• Set up roles and permissions
• Configure workflow and baselines

Phase 2: Pilot

• Load sample requirements
• Connect to one architecture domain
• Validate traceability and reporting
• Fix process gaps

Phase 3: Rollout

• Migrate real requirements
• Train teams
• Integrate with adjacent systems
• Establish governance meetings

Phase 4: Optimization

• Automate import/export
• Improve dashboards
• Add compliance and safety views
• Refine metrics and audits

---

16) Metrics to track success

• % requirements with complete metadata
• % requirements traced to architecture elements
• % requirements with verification method assigned
• % requirements verified before milestone
• Number of change requests by category
• Average approval cycle time
• Number of orphan or duplicate requirements
• Coverage by domain and variant

---

If you want, I can also provide:

1. a sample requirements management workflow,
2. a template schema for vehicle architecture requirements, or
3. a tool comparison for DOORS/Jama/Polarion for automotive use.