Top 5 work item templates - when to use them and what to build

Functional safety engineering is fundamentally about structure: linking hazards to requirements, requirements to evidence, and evidence to arguments that satisfy a standard. WCGW Safety Suite ships with 15+ templates that encode common safety-engineering patterns, but if you're starting out, focusing on the most versatile five will get you the furthest, fastest.

Below are the five templates you'll reach for again and again, sorted roughly in the order you'd encounter them in a typical project lifecycle.

1. Linear Safety Chain Template (LSC-001)

The pattern: Item → Hazard → Safety Goal → Functional Safety Requirement → Technical Safety Requirement

When to use it: At the very beginning of a project, when you need to trace a single hazard through to its technical implementation. This is your bread-and-butter template for any IEC 61508–based system.

What it builds: A clean, linear traceability chain for one hazard. Each step derives from the previous one, making it easy for auditors to follow the logic. The DERIVES_FROM and MITIGATES relation patterns keep everything connected.

Practical example — Autonomous mobile robot: Your item is an AMR. You identify the hazard "collision with a human while navigating." The safety goal becomes "the AMR shall avoid collision with humans." That drives a functional requirement: "the AMR shall maintain a minimum 0.5 m distance from detected humans." Which in turn drives a technical requirement: "the laser scanner shall detect humans at ≥ 5 m range and trigger deceleration within 100 ms." You've now built one complete chain that an assessor can verify.

Why it matters: This template works with all ASIL levels (A through D), all project phases from Item Definition through Technical Safety, and it's the easiest way to learn the WCGW tool. Start here.

2. Hazard Mitigation Web Template (HMW-001)

The pattern: Multiple hazards converging on shared safety goals and functional requirements.

When to use it: As soon as your system accumulates multiple hazards that map to overlapping safety goals. In any real-world system, hazards don't exist in isolation — several hazardous events can be mitigated by the same safety mechanism.

What it builds: A many-to-one network. Unlike the linear chain, this template captures the fact that a single safety goal (e.g., "prevent unintended motion") may mitigate several distinct hazards (e.g., "software logic error," "sensor noise," "communication glitch").

Practical example — Industrial robot arm: You have three hazards: (1) unexpected torque during manual guidance, (2) tool collision with fixture, and (3) cable snagging. All three are mitigated by the shared safety goal "the arm shall halt motion within 200 ms of any fault detection." A single functional requirement — "implement a redundant safety-rated monitoring circuit" — refines that goal for all three hazards. The web template surfaces this convergence naturally, preventing redundant work.

Why it matters: Without this pattern, engineers often clone the same requirement across hazard sheets, creating sync problems. The web template eliminates duplication and enforces consistency.

3. Modular Component Tree Template (MCT-001)

The pattern: Hierarchical decomposition of an item into subsystems, each with its own requirement tree.

When to use it: When your system has clear architectural boundaries — separate electronic control units, software modules, sensor assemblies, or actuators. This is the go-to template for systems-of-systems.

What it builds: A tree structure where the top-level item decomposes into child components, each with its own functional and technical safety requirements. The REFINES and DEPENDS_ON relation patterns capture parent-child and peer dependencies.

Practical example — Drive-by-wire vehicle: The top-level item "steering system" decomposes into "steering wheel sensor module," "steering controller ECU," and "steering actuator." Each child gets its own functional safety requirements (e.g., "the sensor module shall detect handwheel position within ±1°") and technical safety requirements (e.g., "the ECU shall compare sensor readings from two independent channels"). The tree keeps everything organized while supporting composition — you can swap a child module without rewriting the parent's requirements.

Why it matters: This template supports the widest range of project phases (Item Definition through Software Design) and it's the only template that also works for hardware and software requirement decomposition. It's also where platform reuse starts to make sense.

4. Safety Case Template (SC-001)

The pattern: Safety Goal → Functional Safety Requirement → Test Case → Verification Report — structured into a safety argument with evidence.

When to use it: When you're preparing for certification or an internal assessment. The safety case is the deliverable that answers the question "why is this system acceptably safe?" It should be built alongside the requirements, not as an afterthought.

What it builds: A structured argument. Each claim (e.g., "the braking system meets ASIL D integrity") is supported by sub-claims and linked to evidence — test reports, analyses, design reviews. The VALIDATES relation pattern connects requirements to the test cases that prove them.

Practical example — Medical infusion pump: You claim "the pump shall not deliver more than 10% overdose under any single fault condition." You derive a functional safety requirement "the flow rate shall be monitored by two independent sensors." Your test case verifies that a simulated sensor fault triggers pump shutdown within 50 ms. The verification report becomes the evidence node. The safety case template ties all of this into a GSN-like (Goal Structuring Notation) argument that an assessor can evaluate.

Why it matters: Without a safety case, you have requirements and tests but no coherent argument. With it, you can prove — not just claim — that your system is safe. This template is essential for ASIL D systems.

5. Validation Network Template (VN-001)

The pattern: Functional / Technical Safety Requirements connected bidirectionally to test cases and verification reports.

When to use it: Throughout development, but especially during the Verification and Validation phases. Every requirement needs a corresponding test, and every test needs to trace back to a requirement.

What it builds: A validation network — not a tree or a chain, but a graph where requirements, test cases, and reports all relate to each other. The VALIDATES and DEPENDS_ON relation patterns let you ask questions like "which requirements are not yet tested?" or "if this test fails, which safety goals are impacted?"

Practical example — Industrial safety PLC: You have a functional requirement: "the PLC shall execute the safety function within the safety reaction time of 250 ms." Your network links this requirement to three test cases — one for normal operation, one for worst-case scan cycle, and one for communication delay. Each test traces to a verification report. The network view shows you at a glance that coverage is complete. When a test fails, you can immediately see which safety goals are affected and whether any derived requirements need rework.

Why it matters: Traceability is the backbone of every functional safety audit. The validation network template makes traceability visible and actionable, rather than a checkbox exercise you scramble to fill before an audit.

Quick Reference

Getting Started

If you're new to WCGW Safety Suite, begin with the Linear Safety Chain template — build one complete chain from item through technical requirement. Then evolve to the Hazard Mitigation Web as hazards accumulate. When the system grows complex enough to split into modules, adopt the Modular Component Tree. Parallel to all of this, start drafting your Safety Case and use the Validation Network to ensure every requirement has a test.

These five templates cover roughly 90% of what you'll need for an IEC 61508, ISO 26262, or ISO 13849 compliance project. The remaining templates (ASIL Decomposition, Change Impact, Platform Reuse, etc.) are situational additions that you'll discover naturally as your project matures.

Need a walkthrough of a specific template? Contact us — we're happy to help tailor WCGW Safety Suite to your project's needs.