User Needs Tab

Complete field reference and compliance mapping for the User Needs tab in the RTMify requirements traceability template.

The User Needs tab captures stakeholder expectations and regulatory requirements at the highest level before design or detailed requirements are defined. Each need is a plain-language statement of what customers, regulators, safety analyses, or internal standards expect the system to accomplish—not how it will accomplish it. User needs form the foundation for all downstream requirements, design, and verification activities across AS9100, ISO 13485, DO-178C, IEC 62304, ISO 26262, and ASPICE processes.

Field-by-Field Reference

The User Needs tab contains five columns that systematically capture, prioritize, and track stakeholder needs throughout the product lifecycle.

Column Field Name Description Valid Values & Tips
A ID Unique identifier for each user need. Enables traceability to requirements, design, and verification. UN-001, UN-002, UN-003, … Auto-populated. Sequential format ensures unique identification and supports traceability matrix lookups.
B Statement Plain-language description of what stakeholders expect or require. Should focus on the problem or need, not the solution. Understood by both technical and non-technical readers. 1–2 sentences. Avoid implementation details, solutions, or technical jargon. Example: "The system must detect and report faults within 100ms of occurrence." (Good) vs. "Use interrupt-driven architecture" (Too prescriptive).
C Source of Need Statement Identifies where the need originated. Required for traceability and regulatory compliance. Ensures needs are justified and traceable to authoritative sources. Customer | Regulation | Internal | Safety

— Customer: explicit customer request or use case
— Regulation: regulatory standards, certification rules
— Internal: company standards, design constraints
— Safety: hazard analysis, FMEA, HARA, risk assessment outputs
D Priority Indicates the relative importance and criticality of the need. Guides requirement decomposition and verification planning. High | Medium | Low

— High: safety-critical, regulatory, or essential function
— Medium: important but not critical
— Low: nice-to-have, enhancement, or optional

Safety-related needs (DO-178C DAL A/B, IEC 62304 Class A/B) should typically be High.
E RTMify Status Automatically calculated field indicating whether this user need has been fully traced through the product lifecycle (requirements, design, verification). Complete | In Progress | Not Started

Auto-populated based on linked requirements and verification activities. Use this to identify incomplete traceability chains and audit readiness.

Per-Standard Compliance Mapping

User needs map to specific clauses and processes in each regulated standard. Below is a standard-by-standard breakdown showing how the User Needs tab satisfies each compliance framework.

AS9100 Rev D

§8.3.3 Design Inputs

User needs represent the initial design inputs that establish baseline requirements for aerospace product development. They capture stakeholder expectations, operational constraints, and performance parameters before design begins.

Guidance: Document all customer requirements, operational needs, and regulatory constraints as design inputs. Ensure traceability from each design input through design outputs and verification activities.

ISO 13485:2016

§7.3.3 Design Inputs

User needs encompass both clinical/user expectations and regulatory requirements. Distinguish between intended use needs, performance expectations, and regulatory input requirements (labeling, standards, applicable regulations).

Guidance: Separate user needs into customer needs and regulatory inputs. For medical devices, explicitly identify clinical user needs and regulatory constraints (510(k), PMA, classification). Document the source for traceability.

DO-178C

System Requirements Foundation

User needs form the operational and safety foundation that feeds High-Level Requirements (HLR). They capture system-level operational needs, safety objectives, and performance criteria that HLRs will decompose.

Guidance: User needs should align with aircraft functions and safety objectives. Each need should be traceable to HLRs. Safety-critical needs (DAL A/B) require explicit safety focus. Document need criticality (safety vs. performance).

IEC 62304

§5.2 Software Development Planning & Safety Classification

User needs inform software development planning and establish context for software safety classification. They capture the intended use, operational environment, and hazards that drive safety class assignment.

Guidance: Include needs related to intended use, operational modes, and known hazards. Safety-critical needs influence Software Safety Class (Class A/B/C). Document the relationship between needs and subsequent HARA (Hazard Analysis and Risk Assessment) inputs.

ISO 26262

§8 HARA Safety Goals

User needs capture the operational context and safety objectives that flow from Hazard Analysis and Risk Assessment (HARA). Safety goals derived from HARA outputs become user needs that drive functional safety requirements.

Guidance: Document operational scenarios, hazards, and safety objectives as needs. Include ASIL (Automotive Safety Integrity Level) context. User needs should map bidirectionally with HARA outputs and subsequent functional safety requirements.

ASPICE

SYS.1 Stakeholder Requirements Elicitation

User needs are the primary output of SYS.1, capturing stakeholder expectations, constraints, and acceptance criteria. They form the foundation for system requirements definition and verification planning.

Guidance: Ensure comprehensive stakeholder engagement (customers, end-users, regulators, safety). Document requirement sources and trace through SYS.2 (system requirements) and SYS.3 (architectural design) gates.

Common Mistakes to Avoid

  • ✕Writing requirements instead of needs: User needs describe problems or expectations ("The system must be safe"), not solutions ("Use dual-channel redundancy"). If your statement specifies how to do something, it is a requirement, not a user need.
  • ✕Missing source attribution: Every need must have a source (Customer, Regulation, Internal, or Safety). Undocumented sources create audit failures and traceability breaks.
  • ✕Duplicate or overlapping needs: Review the needs list for statements that say the same thing in different words. Consolidate duplicates and link all downstream requirements to the primary need ID.
  • ✕Vague or unmeasurable statements: Avoid statements like "The system should be reliable" or "Performance should be good." Instead, quantify: "The system shall have a mean time between failures (MTBF) ≥ 10,000 hours."
  • ✕Ignoring safety needs: Safety-critical needs from hazard analyses (FMEA, HARA, TQFP) must be captured as user needs with source "Safety" and priority "High." This is non-negotiable for regulated products.
  • ✕Failing to trace through the lifecycle: User needs are not standalone—they drive requirements (Requirements tab), design (Design tab), verification (Verification tab), and validation. Incomplete traceability results in audit gaps and compliance failures.

Frequently Asked Questions

What is the difference between a user need and a requirement?
A user need is a high-level statement of what stakeholders expect or require from the system, written in plain language without prescribing how to achieve it. A requirement is a specific, measurable specification of how the system will meet that need. One user need may generate multiple requirements. For example, the user need "The system must be safe to operate" might generate requirements like "Fault detection time < 100ms" and "All hazardous functions require dual-channel confirmation."
Can I have multiple requirements for one user need?
Yes, and this is normal. A single user need typically decomposes into multiple requirements that specify different aspects of meeting that need. The RTMify Requirements tab allows you to trace multiple requirements back to a single user need using the UN-ID reference. This creates a one-to-many relationship that supports traceability matrices.
What sources should I capture for user needs?
There are four primary sources: (1) Customer—explicit customer statements and use cases; (2) Regulation—regulatory standards, certification rules, and compliance requirements; (3) Internal—company standards, safety policies, and architectural constraints; (4) Safety—hazard analyses, risk assessments, and safety goals (FMEA, HARA, etc.). Always identify the source to ensure regulatory compliance and traceability.
How specific should a user need statement be?
User need statements should be clear and unambiguous but not overly prescriptive. Avoid specifying implementation details or solutions; instead, describe the problem or expectation. A good statement is 1–2 sentences and can be understood by non-technical stakeholders. For example: "The device shall provide audible and visual alarms when critical parameters exceed safe limits" is good; "Use a 85dB piezo buzzer and red LED" is too prescriptive (that is a requirement).
What if a user need comes from a regulation, not a customer?
Document it as a user need with the source set to "Regulation." Regulatory requirements are stakeholder requirements (your regulator is a stakeholder), and capturing them as user needs ensures they are formally traced through design, verification, and validation. This is especially important for medical devices (FDA labeling, 21 CFR), aerospace (14 CFR), and automotive (ISO 26262, ISO functional safety) contexts.

Related Documentation

Last Updated: March 22, 2026

Standards Covered: AS9100 Rev D, ISO 13485:2016, DO-178C, IEC 62304, ISO 26262:2018, ASPICE 3.1

RTMify is a compliance-aware requirements traceability manager designed for regulated engineering environments. This documentation reflects best practices across aerospace, medical device, automotive, and industrial safety standards.