Overview
Use Steps serve as intermediate work items that bridge user needs (operational requirements) and system requirements. They decompose high-level use cases into discrete, traceable actions that can be analyzed for safety implications, mapped to functional requirements, and verified through test scenarios.
| Aspect | Details |
|---|
| Work Item Type ID | useStep |
| Module Constraint | useCasesModule (Use Cases folder) |
| Parent Type | User Need (implicitly, via document hierarchy) |
| Child Type | None (leaf item) |
| Link Relationships | refines → System Requirement; verified by ← Test Case |
| Custom Fields | stepNumber (integer), preCondition (text), postCondition (text), actor (enum) |
| Status Workflow | draft → inProgress → inReview → pendingApproval → approved |
| Typical Creator Role | Requirements Engineer, Safety Engineer |
| Typical Reviewer | Safety Engineer, Systems Architect |
Standard Properties
| Property | Type | Default | Description |
|---|
| ID | String | Auto-generated | Unique identifier in format US-#### within the Use Cases module |
| Title | String | Required | Clear, action-oriented description (e.g., “Driver observes obstacle at 50m distance”) |
| Description | Text | — | Detailed narrative of the action, including conditions and outcomes |
| Status | Enum | draft | Workflow state: draft, inProgress, inReview, pendingApproval, approved, rejected, obsolete |
| Outline Number | String | Auto-numbered | Hierarchical numbering reflecting parent use case and step sequence (e.g., UC-01.3) |
| Assignee | User | — | Owner responsible for elaborating and maintaining the use step |
| Priority | Enum | normal | Priority level: low, normal, high, critical |
| Created | Timestamp | Auto-set | Date and time of creation |
| Modified | Timestamp | Auto-set | Date and time of last modification |
| Created By | User | Auto-set | Author of the work item |
| Modified By | User | Auto-set | User who made the last change |
Custom Fields for Use Steps
Step Number
| Field | Value |
|---|
| Name | stepNumber |
| Type | Integer |
| Default | Auto-incremented from parent use case |
| Required | Yes |
| Description | Sequential index of the step within its parent use case (1, 2, 3, …). Enables sorting and cross-reference numbering in documentation. |
Use Case UC-001: Emergency Braking Activation
Step 1: Sensor detects obstacle
Step 2: ECU calculates distance
Step 3: ECU initiates braking
Step 4: Vehicle decelerates to safe speed
Pre-Condition
| Field | Value |
|---|
| Name | preCondition |
| Type | Text (long) |
| Default | — |
| Required | No |
| Description | Conditions that must be true before this step executes. Used in SOTIF analysis to define preconditions for safe operation and failure scenarios. Example: “System powered on, sensors initialized, no faults active” |
Pre-Condition: AEB system operational, camera and radar sensors initialized
and synchronized, vehicle speed > 5 km/h, no active system faults
Post-Condition
| Field | Value |
|---|
| Name | postCondition |
| Type | Text (long) |
| Default | — |
| Required | No |
| Description | State or outcome guaranteed after step execution completes. Defines the transition point to the next step or use case exit. Used in requirements traceability to define acceptance criteria. |
Post-Condition: Braking command transmitted to CAN bus, brake actuator
receives control signal within 100ms, brake pressure begins increasing
Actor
| Field | Value |
|---|
| Name | actor |
| Type | Enumeration |
| Default | System |
| Allowed Values | Driver, System, Environment, ECU, Sensor, HMI |
| Required | Yes |
| Description | The entity performing this step. Distinguishes system actions (automatic) from driver actions (manual) or environmental factors. Critical for SOTIF analysis of SOTIF-triggering events vs. system behavior. |
- Driver: “Driver applies accelerator pedal”
- System: “AEB system calculates deceleration profile”
- Sensor: “Camera detects pedestrian in lane”
- Environment: “Road surface transitions to ice”
- ECU: “Safety processor verifies sensor data against reference model”
- HMI: “Display shows “AEB Active” indicator”
Traceability Relationships
Refines System Requirements
| Link Role | Direction | Target Type | Cardinality | Purpose |
|---|
refines | → outgoing | System Requirement | 1..* | Each use step refines one or more system requirements, creating bidirectional traceability from the functional narrative to implementation specifications |
- Use Case UC-001: Emergency Braking Activation
- Use Step US-001.1: Sensor detects obstacle
- refines > SR-010: System shall detect obstacles within 100m
- refines > SR-015: System shall classify obstacles by size/type
- refines > SR-020: System shall initiate obstacle tracking within 50ms
When to Establish:
- After use step is drafted and system requirements are available
- During requirements refinement phase (ISO 26262 Part 3 Concept Phase)
- Validated by Safety Engineer during design review
Verified By Test Cases
| Link Role | Direction | Target Type | Cardinality | Purpose |
|---|
verifies (back-link) | ← incoming | Test Case, Validation Test Case | 0..* | Test cases validate that the use step behavior is correctly implemented and verified in the system |
- Use Step US-001.1: Sensor detects obstacle at 50m distance
- verified by TC-010: Obstacle Detection at 50m - Normal Lighting
- verified by TC-011: Obstacle Detection at 50m - Low Lighting
- verified by TC-012: Obstacle Detection at 50m - Wet Surface
Verification Approach:
- Validation Test Cases: Verify that the use step scenario occurs as described in the operational environment
- Verification Test Cases: Verify that the system correctly implements the step behavior in controlled test conditions
Integration with PowerSheets
Use Steps Sheet
The Use Steps PowerSheet provides a tabular view of all use steps organized by parent use case, enabling bulk editing and relationship management:
| Column Group | Columns | Purpose |
|---|
| Use Case Info | Use Case ID, Use Case Title, Step Number | Identifies parent use case and step sequence |
| Step Details | Step Title, Description, Actor, Step Type | Describes the action and who/what performs it |
| Conditions | Pre-Condition, Post-Condition, Exception Handling | Defines entry/exit conditions and alternative flows |
| Requirements | Refined System Requirements (with links), Classification (SC/CC) | Shows which requirements this step refines and safety criticality |
| Verification | Test Cases (with links), Coverage Status, Evidence | Tracks validation test cases covering this step |
| Metadata | Status, Assignee, Priority, Modified Date | Workflow and ownership tracking |
Workflow States and Transitions
Use Steps follow the standard seven-state lifecycle:
| Transition | From | To | Condition | Notes |
|---|
| Start Work | draft | inProgress | Assignee required | Begin elaboration of use step |
| Send to Review | draft, inProgress | inReview | Assignee required | Request peer review from safety engineer |
| Send to Approval | inReview | pendingApproval | Assignee required | Initiate formal approval workflow; auto-adds project_approver signers |
| Approve | pendingApproval | approved | Min 1 approval, no disapprovals | Mark as complete and ready for implementation reference |
| Reject | pendingApproval | rejected | Resolution required | Document why use step was rejected; can reopen for rework |
| Reopen | approved, rejected, pendingApproval | draft | — | Clear all approvals; reset for material revision |
| Mark Obsolete | any state | obsolete | Resolution required | Deprecate use step (e.g., feature removed, use case changed) |
Standards Compliance Mapping
Use Steps support ISO 26262, ISO 14971, and ISO 21448 (SOTIF) requirements:
| Standard | Section | Application |
|---|
| ISO 26262-3 | 7.2 (Hazard Analysis and Risk Assessment) | Use steps describe operational scenarios for HARA; pre/post-conditions identify safe and unsafe states |
| ISO 26262-3 | 7.4 (Functional Safety Concept) | Use steps narrative forms basis for functional safety concept; step actors distinguish system vs. driver responsibility |
| ISO 26262-4 | 5.2 (System Design) | Use steps refine into system requirements during architectural design |
| ISO 14971 | 7 (Risk Analysis) | Use steps identify hazardous situations in medical device operation; pre-conditions define intended use |
| ISO 21448 (SOTIF) | 6.4 (SOTIF Evaluation) | Pre-conditions and actor transitions highlight SOTIF-triggering events and system transitions outside safe operation envelope |
Common Use Patterns
Safety-Critical Use Case with High-Risk Steps
Use Case: Emergency Braking Activation
US-001.1:
Title: System detects obstacle
Actor: Sensor
Pre-Condition: |
AEB system powered on, sensors initialized,
vehicle speed > 5 km/h
Post-Condition: |
Obstacle detected, position and velocity
calculated, tracking initiated
Classification: SC (Special Characteristic)
Refines: SR-010, SR-015, SR-020
Verified By: TC-010, TC-011, TC-012
US-001.2:
Title: ECU calculates deceleration profile
Actor: System
Pre-Condition: |
Obstacle detected and tracked,
vehicle dynamics available
Post-Condition: |
Deceleration target (0-1.0g) calculated,
safety margin applied
Classification: SC
Refines: SR-030, SR-035
Verified By: TC-020, TC-021
US-001.3:
Title: System initiates braking
Actor: System
Pre-Condition: |
Deceleration profile calculated,
no system faults active
Post-Condition: |
Brake command transmitted within 50ms,
brake pressure increasing
Classification: SC
Refines: SR-040, SR-045
Verified By: TC-030, TC-031
SOTIF-Relevant Use Case with Environmental Factors
Use Case: Sensor Degradation Response
US-002.1:
Title: Environmental condition affects sensor
Actor: Environment
Pre-Condition: |
Normal operation, AEB system armed,
visibility adequate
Post-Condition: |
Sensor signal degradation detected
(SNR < threshold)
Classification: SC
Refines: SR-050 (System shall detect sensor degradation)
Verified By: TC-040 (Rain obscuration test), TC-041 (Fog test)
US-002.2:
Title: System initiates graceful degradation
Actor: System
Pre-Condition: |
Sensor degradation confirmed,
performance below specification
Post-Condition: |
Braking command inhibited,
driver alert displayed (HMI)
Classification: SC
Refines: SR-051 (System shall inhibit braking when sensors degraded)
Verified By: TC-042 (Graceful degradation test)
Best Practices
Number use steps sequentially within each use case (1, 2, 3…). The stepNumber field auto-fills but should reflect logical execution order. This enables test case naming conventions (e.g., TC-UC001-S02 for step 2 of use case 1) and traceability navigation.
Be explicit in pre-conditions about system state, initialization, and faults. Vague conditions like “system ready” lead to ambiguous test scenarios. Example: “AEB system powered on, camera and radar sensors initialized and synchronized within last 100ms, vehicle speed > 5 km/h, no active DTC (Diagnostic Trouble Code), CAN bus healthy.”
Use the actor field to distinguish between:
- System actions (automated, deterministic) → SOTIF evaluation focus
- Driver actions (discretionary, user-dependent) → Intent-aware analysis
- Environment factors (external, not controlled) → SOTIF-triggering event
This separation ensures SOTIF analysis covers system-initiated failures and environmental triggers correctly per ISO 21448. If a use step refines a SC/CC-classified system requirement, mark the use step as SC/CC. This propagates safety criticality through the traceability chain and flags high-risk test scenarios requiring additional verification evidence.
Link each use step to at least one validation or verification test case. Use the Use Steps PowerSheet to identify uncovered steps (Coverage Status = “0 tests”) and create test cases before design phase closure. This ensures all operational scenarios are validated.
