User Needs sit at the top of the validation side (right side) of the V-Model. They are validated by Validation Test Cases and inform the entire requirements cascade on the left side through traceability relationships.
Standard Properties
| Name | Type | Default | Description |
|---|
| ID | Text | Auto-generated | Unique identifier (e.g., UN-001) |
| Title | Text | — | User-facing description of the need |
| Description | Text | — | Detailed explanation of the requirement and rationale |
| Status | Enum | draft | Workflow state: draft, inProgress, inReview, pendingApproval, approved, rejected, obsolete |
| Assignee | User | — | Person responsible for authoring and maintaining the need |
| Priority | Enum | medium | Relative importance: low, medium, high |
| Created On | Date | Auto-set | Timestamp of work item creation |
| Modified On | Date | Auto-set | Timestamp of last modification |
Relationship Fields
| Name | Link Role | Target Type | Cardinality | Direction | Description |
|---|
| Supports | supports | Use Step | One-to-Many | Outgoing | User Need is verified through one or more Use Steps (operational scenarios) |
| Validated By | validated by | Validation Test Case | One-to-Many | Back-linked | Validation Test Cases that verify this user need is met in deployed system |
| Documents | — | LiveDoc | One-to-Many | Outgoing | User needs document which specification (customer requirements, marketing brief, etc.) |
Workflow States
User Needs follow the standard 7-state lifecycle:
All states allow transition to Obsolete (with required resolution).
Custom Fields
User Needs support the following custom fields for automotive safety classification:
| Name | Type | Values | Description |
|---|
classification | Enum | sc, cc, none | Safety/Cybersecurity classification: SC = Special Characteristic (safety-critical), CC = Critical Characteristic (cybersecurity-critical), none = standard requirement |
sourceDocument | Text | — | Reference to originating document (e.g., “Customer Requirements v2.3”, “Regulatory Brief”, “Marketing Spec”) |
User Needs can be marked as Special Characteristics (SC) or Critical Characteristics (CC) if they impose safety or cybersecurity obligations on the design. SC/CC needs automatically trigger enhanced traceability requirements through the entire V-Model.
Traceability Model
Upstream Relationships
User Needs are top-level requirements and typically do NOT have upstream refinement relationships. They represent the “voice of customer” or “voice of regulator.”
Downstream Relationships
RTM Expansion Path
The User Need Validation PowerSheet expands user needs to their linked validation test cases:
This creates denormalized rows where each user need appears with all its associated validation test cases.
Properties Table (Detailed)
Core Properties
| Property | Type | Default | Mandatory | Searchable | Example |
|---|
id | String | Auto | Yes | Yes | UN-042 |
title | String | — | Yes | Yes | System shall detect obstacles at 50m distance |
description | Markdown | — | No | Yes | The AEB system must reliably detect obstacles up to 50 meters away during daylight and low-light conditions to enable timely braking activation |
status | Enum | draft | Yes | Yes | approved |
assignee | User | — | No | Yes | jane.smith@company.com |
priority | Enum | medium | No | Yes | high |
createdOn | Timestamp | Auto | No | No | 2026-01-15T10:30:00Z |
modifiedOn | Timestamp | Auto | No | No | 2026-02-10T14:22:00Z |
author | User | Auto | No | Yes | john.doe@company.com |
resolution | Text | — | No | Yes | Approved per executive review on 2026-02-10 |
Custom Safety Fields
| Property | Type | Default | Mandatory | Enum Values |
|---|
classification | Enum | none | No | sc, cc, none |
sourceDocument | String | — | No | — |
Document Constraints
User Needs are constrained to documents of type customerRequirements (typically named “Customer Requirements Specification” or “User Needs Specification”):
Document Type: customerRequirementsSpecification
Module Type: UserNeedModule
Allowed Work Items: UserNeed
Auto-Create Behavior: When a document is created with this type, the system automatically creates a UserNeedModule to contain user need items
-
Identification Section
- ID (read-only, auto-generated)
- Title (required, large text box)
- Priority
-
Description Section
- Description (Markdown editor)
- Source Document (classification and traceability metadata)
-
Classification Section
- Classification (SC/CC/none dropdown)
-
Status Section
- Status (workflow state)
- Assignee
- Author (read-only)
- Created On / Modified On (read-only)
-
Links Section
- Supports (outgoing links to Use Steps)
- Validated By (back-linked Validation Test Cases)
- Documents (outgoing links to source LiveDocs)
PowerSheet Integration
User Need Validation Sheet
The User Need Validation Sheet PowerSheet displays user needs alongside their linked validation test cases:
User Need Validation Sheet — Column Groups:
- User Need Group (green theme)
- ID
- Title (bold, sortable, hasFocus)
- Description
- Validation Test Case Group (green theme)
- Test Case ID
- Test Case Title (bold, hasFocus)
- Test Status
RTM Expansion:
- Start:
UserNeed (ordered by title ascending)
- Expand:
userNeed.validationTestCases.validationTestCase
- Result: One row per user need–test case pair
Collapse Behavior:
- User Need group collapses to Title column only
- Validation Test Case group collapses to Test Case Title only
Usage Guidance
When to Create User Needs
Create a User Need when:
- Customer specifies a requirement — “The system must warn the driver 2 seconds before collision”
- Regulator mandates compliance — “ISO 26262 requires functional safety for AEB systems”
- End-user defines operational requirement — “The system shall work in rain, fog, and snow conditions”
- Marketing defines feature requirement — “The AEB system shall be the fastest response time in the market”
Do NOT create User Needs for internal design decisions, component specifications, or software module requirements. Those belong in System Requirements, Design Requirements, or Architecture specifications.
Structuring User Needs
High-level, outcome-focused language:
- ✓ “System shall detect obstacles reliably up to 50 meters”
- ✗ “Camera module shall have 2MP resolution and 60 fps frame rate”
One requirement per user need:
- ✓ Separate: “System shall detect obstacles in daylight” and “System shall detect obstacles in darkness”
- ✗ Combined: “System shall detect obstacles in daylight and darkness with < 50ms latency”
Measurable or verifiable:
- ✓ “System shall respond to braking command within 100ms”
- ✗ “System shall respond quickly to braking”
Traceability Best Practices
-
Link to Use Steps first — User Needs are validated through operational scenarios (Use Steps). Link each need to the scenarios that demonstrate it.
-
Create Validation Test Cases — For each User Need, author Validation Test Cases that verify the need is met in the deployed system (real-world conditions, full system integrated).
-
Check Validation Coverage — Use the User Need Validation Sheet to verify every User Need has at least one Validation Test Case.
-
Apply SC/CC Classification — Mark safety-critical or cybersecurity-critical user needs as SC/CC. These trigger enhanced traceability through characteristics and failure mode analysis.
Standards Compliance
ISO 26262 (Functional Safety)
- Part 2 (Management of functional safety): User Needs represent stakeholder requirements that feed the concept phase (Part 3)
- Part 3 (Concept phase): User Needs must be refined into System Requirements that can be allocated to safety goals
- Part 8 (Functional safety management): Traceability from User Needs → System Requirements → Safety Goals → Verification is a key audit requirement
AIAG-VDA FMEA
- User Needs are the starting point for System FMEA scope definition
- Each failure mode in System FMEA must be traceable back to a user need it could violate
IATF 16949 / APQP
- User Needs represent the “Voice of Customer” in APQP advanced quality planning
- SC/CC-classified needs drive the APQP special characteristics workflow
