How do I set up requirements management tool workflows for hazard analysis and risk assessments in an autonomous vehicle team?

Here’s a practical way to set up requirements management tool workflows for hazard analysis and risk assessments in an autonomous vehicle (AV) team.

1) Start with the process structure

You want one connected workflow from:

Hazard identification → Risk assessment → Safety requirements → System/design requirements → Verification → Traceability

A good setup usually has these main artifacts in your requirements tool:

• Hazards
• Hazardous events / operational scenarios
• Risk ratings (severity, exposure, controllability, likelihood, etc.)
• Safety goals
• Functional safety / technical safety requirements
• System and subsystem requirements
• Verification evidence
• Assumptions, constraints, and open issues

This aligns well with AV safety methods like HARA, STPA, FMEA, and standards such as ISO 26262 and ISO 21448 (SOTIF).

---

2) Define your workflow stages

A good workflow in the tool might look like this:

Stage A: Hazard capture

Anyone on the safety, systems, testing, or autonomy team can create a hazard item.

Required fields:

• Hazard title
• Description
• Operational domain / scenario
• Trigger / cause
• Affected stakeholders
• Initial owner
• Status: Draft

Stage B: Hazard review

Safety engineer or review board validates the hazard.

Checks:

• Is it a real hazard?
• Is it duplicated?
• Is the scenario clear?
• Is the operational design domain defined?

Status: Reviewed

Stage C: Risk assessment

For each hazard, assess risk using your chosen method.

Typical fields:

• Severity
• Exposure
• Controllability
• Likelihood
• Risk class / ASIL / safety priority
• Assumptions used in the rating
• Confidence level

Status: Assessed

Stage D: Mitigation decision

Decide what to do with the risk:

• Accept
• Mitigate
• Transfer
• Monitor

If mitigating:

• Create or link a safety goal
• Derive requirements
• Assign owners

Status: Mitigation Planned

Stage E: Requirement derivation

Safety goals become:

• Functional safety requirements
• Technical safety requirements
• Software / hardware / perception / planning requirements
• Operational constraints

Each requirement should link back to:

• one or more hazards
• the risk assessment
• the safety goal

Status: Approved

Stage F: Verification and validation

Each requirement must have verification methods:

• Test
• Simulation
• Analysis
• Inspection
• Formal methods

Status progression:

• In Verification
• Verified
• Accepted

---

3) Set up object types in the tool

In tools like Jama, Polarion, DOORS Next, Codebeamer, or Helix ALM, create custom artifact types such as:

• Hazard
• Hazardous Scenario
• Risk Assessment
• Safety Goal
• Safety Requirement
• Technical Requirement
• Verification Case
• Verification Result
• Safety Review Comment
• Assumption / Constraint

This makes traceability much easier than storing everything in generic requirements items.

---

4) Establish traceability rules

Make traceability mandatory between:

• Hazard → Risk assessment
• Risk assessment → Safety goal
• Safety goal → Safety requirement
• Safety requirement → Design element
• Safety requirement → Test case
• Test case → Test result

Also useful:

• Hazard ↔ Operational scenario
• Hazard ↔ Assumption
• Requirement ↔ Verification method
• Requirement ↔ Linked parent/child requirements

A simple rule: no hazard is closed unless it has a recorded disposition.

---

5) Use review gates

Add formal review points in the workflow:

Hazard Review Board

Participants:

• Safety
• Systems
• Autonomy / ML
• Perception
• Planning / Controls
• Test / Validation
• Product / Program

Review decisions:

• Approve
• Reject
• Needs more info
• Merge with existing hazard

Risk Acceptance Board

Used when a hazard risk cannot be fully mitigated.

Outputs:

• Accepted residual risk
• Required monitoring
• Explicit sign-off
• Open action items

This helps prevent informal or undocumented safety decisions.

---

6) Standardize templates and fields

To keep the workflow consistent, define templates for each artifact.

Hazard template

• Hazard ID
• Description
• Operational scenario
• System state
• Trigger conditions
• Potential harm
• Notes

Risk assessment template

• Hazard ID
• Severity
• Exposure
• Controllability
• Initial risk
• Residual risk
• Rationale
• References

Requirement template

• Unique ID
• “Shall” statement
• Rationale
• Source hazard(s)
• Verification method
• Priority
• Safety classification
• Owner

---

7) Configure status workflows

Use clear statuses so the tool enforces progress:

Hazard workflow

Draft → Reviewed → Risk Assessed → Mitigation Defined → Closed

Requirement workflow

Draft → In Review → Approved → Implemented → Verified → Released

Verification workflow

Planned → Executed → Passed/Failed → Closed

Keep status transitions limited to prevent bypassing reviews.

---

8) Assign ownership clearly

Each artifact should have:

• Owner
• Reviewer
• Approver
• Due date
• Team

For AV safety work:

• Safety engineer owns hazard/risk items
• Systems engineer owns safety goal decomposition
• Feature owner owns technical implementation
• Validation lead owns test evidence

---

9) Link to scenarios and ODD

AV hazard analysis is much better when tied to:

• Operational Design Domain (ODD)
• Driving scenarios
• Road users
• Weather / lighting / road type
• Fallback / degraded modes

This helps distinguish:

• hazards caused by system faults
• hazards from edge cases
• hazards due to SOTIF issues, unknown perception limits, or misuse

---

10) Build reports and dashboards

Set up dashboards for:

• Open hazards by severity
• Hazards without mitigation
• Requirements without verification
• Residual risk by release
• Hazards linked to unresolved actions
• Coverage by subsystem / feature / scenario

Useful management reports:

• Top risks
• Risk trend over time
• Verification completion by safety goal
• Traceability completeness

---

11) Integrate with engineering tools

If possible, connect the requirements tool to:

• Jira/Azure DevOps for development tasks
• Test management tools
• Simulation platforms
• Code repositories
• Safety case / compliance documentation

This reduces duplicate entry and improves traceability.

---

12) Practical governance model

A lightweight but effective governance setup:

• Weekly hazard triage
• Biweekly risk review
• Monthly safety board
• Release readiness review
• Formal change impact assessment for any requirement change

Any change to:

• ODD
• sensor suite
• autonomy behavior
• fallback logic
• maps
• validation assumptions

should trigger reevaluation of related hazards and risk assessments.

---

13) Common mistakes to avoid

• Using free-text only, with no structured fields
• Letting hazards close without mitigation traceability
• Mixing hazards, risks, and requirements in one generic list
• No owner or approver
• No link to test evidence
• Ignoring ODD and scenario context
• Not re-assessing risks after design changes
• Too many custom fields with no process discipline

---

14) A simple workflow example

1. Engineer identifies: “Vehicle may fail to detect stopped emergency vehicle in low sun glare.”
2. Create Hazard item with scenario and context.
3. Safety review confirms it as valid.
4. Perform risk assessment: high severity, moderate exposure, low controllability.
5. Define safety goal: “The vehicle shall detect and respond to stationary emergency vehicles under defined environmental conditions.”
6. Derive requirements for perception redundancy, fallback behavior, driver/passenger warning, or minimum-risk maneuver.
7. Link verification cases in simulation and closed-course testing.
8. Review residual risk and sign off.

---

15) Recommended implementation approach

If you’re starting from scratch:

Phase 1

• Define artifact types
• Define fields and statuses
• Establish traceability links
• Create templates

Phase 2

• Pilot on one safety-critical feature
• Run review board process
• Refine based on feedback

Phase 3

• Scale to all programs
• Add dashboards and compliance reports
• Integrate with test and issue tracking tools

---

If you want, I can also give you:

1. a sample workflow diagram,
2. a tool configuration checklist, or
3. a Jama/Polarion/DOORS-style artifact schema for AV hazard analysis.