Requirements Tab

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

The Requirements tab contains SHALL statements—one per row, uniquely identified, independently verifiable, and traceable to both user needs and test groups. Each requirement decomposes a user need into a specific, measurable specification that can be verified during testing. Requirements form the bridge between stakeholder needs (User Needs tab) and verification activities (Tests tab). Across AS9100, ISO 13485, DO-178C, IEC 62304, ISO 26262, and ASPICE, requirements are the primary mechanism for ensuring compliance: every regulated requirement must be traceable upward to a user need and downward to a test.

Field-by-Field Reference

The Requirements tab contains eight columns that systematically define, annotate, and track requirements throughout the product lifecycle.

Column	Field Name	Description	Valid Values & Tips
A	ID	Unique identifier for each requirement. Enables traceability across the entire product lifecycle and regulatory documentation.	REQ-001, REQ-002, … or standard-specific SYS-001, HLR-001, LLR-001 (DO-178C) or SWE-001 (ASPICE software). Auto-populated. Use hierarchical naming (SYS → HLR → LLR) to show decomposition levels in DO-178C. Sequential format supports traceability matrix lookups.
B	Statement	The complete requirement text. Must use SHALL language (imperative, mandatory), be independently verifiable, contain measurable acceptance criteria, and avoid implementation details.	Write as: "The system SHALL [action] [condition] [acceptance criteria]." Use SHALL (mandatory), not should (suggestive). Example: "The system SHALL respond to user input within 200ms under nominal load." Avoid vague words: good (too subjective), fast (no metric), reliable (unmeasurable). Each row = one requirement. If your statement has "and" connecting different actions, split into multiple requirements.
C	User Need ID	Parent traceability link. Identifies the user need that this requirement decomposes. Every requirement must trace upward to at least one user need (except derived requirements—see FAQ).	UN-001, UN-002, … Reference the exact ID from the User Needs tab. One requirement may link to multiple user needs (comma-separated); one user need may have multiple requirements. Leave blank only for derived requirements (document source in Notes). Bidirectional traceability is mandatory for regulated environments (DO-178C, ISO 26262, IEC 62304, ASPICE CL2+).
D	Priority	Indicates relative importance and criticality. Guides verification planning, test prioritization, and release decisions.	High \| Medium \| Low — High: safety-critical, essential function, regulatory requirement. Medium: important but not critical to core function. Low: nice-to-have, enhancement. Safety-critical requirements (DAL A/B, ASIL D, Class A) should be marked High. Low-priority requirements may be deferred in time-constrained releases but must still be traced and verified.
E	Test Group IDs	Verification traceability link. Identifies the test group(s) that will verify this requirement. Enables downward traceability to testing activities.	TG-001, TG-002, … Reference test group IDs from the Tests tab. One requirement may link to multiple test groups (for complex requirements verified by multiple test suites). A requirement with no test link indicates incomplete verification planning—flag for closure before release. Ensure every requirement has at least one linked test.
F	Lifecycle Status	Tracks the requirement through the approval workflow. Indicates maturity level and readiness for use in design and verification.	Draft → Review → Approved → Obsolete — Draft: newly created, not yet reviewed. Review: under formal review, awaiting approval. Approved: formal approval complete, ready for design/verification (baseline). Obsolete: no longer active, superseded or removed. Only Approved requirements should be baselined for design. Track status changes and approval dates for audit records.
G	Notes	Free-text field for compliance annotations, safety/criticality tags, standards references, and traceability metadata. Essential for regulatory compliance and cross-reference clarity.	Examples: DAL B (DO-178C), ASIL C (ISO 26262), Safety Class A (IEC 62304), AS9100 §8.3.4, Derived: IEC 62304 §5.3.6, Requires independent V&V. Avoid design commentary; focus on compliance context. See FAQ for detailed guidance.
H	RTMify Status	Automatically populated field indicating traceability completeness. Shows whether this requirement is fully traced through the product lifecycle (user need → requirement → test).	Complete \| In Progress \| Not Started — Complete: requirement has parent user need and child test group(s). In Progress: missing either parent or child. Not Started: neither parent nor child linked. Use this field to identify traceability gaps before design review or release.

Writing Good SHALL Statements

A well-written requirement is the foundation of compliance. It must be specific, measurable, and independently verifiable. Use SHALL language (mandatory), include acceptance criteria, and avoid implementation details.

Good Examples

Timing Requirement

"The system SHALL respond to user input within 200ms under nominal load (≤80% CPU utilization)."

Why: Specific (200ms), measurable (CPU load threshold), independently verifiable (test can measure response time and validate CPU condition).

Signal Strength

"The alarm SHALL produce an audible signal of at least 85 dB at a distance of 3 meters in an ambient noise environment of 75 dB."

Why: Quantified (85 dB, 3m), environmental condition specified (75 dB ambient), can be verified with sound-level meter.

Functional Safety

"The software SHALL detect a loss-of-signal condition on the primary sensor within 50ms and automatically activate the backup sensor without user intervention."

Why: Functional requirement (what happens, not how), time-bound (50ms), acceptance criteria clear (backup sensor activation is observable).

Communication Protocol

"The communication protocol SHALL support CRC-32 error detection for all data packets and SHALL reject any packet with CRC mismatch."

Why: Specific algorithm (CRC-32), unambiguous action (reject), independently verifiable via protocol analysis and test.

Bad Examples

Vague: No Metrics

"The system should be fast."

Why: No measurable criteria. What defines "fast"? 100ms? 1s? 10s? Uses "should" instead of "SHALL".

Subjective: Unmeasurable

"The alarm needs to be loud enough."

Why: "Loud enough" is subjective. Loud enough for whom? In what environment? No decibel specification, no distance reference.

Solution-Focused: Not Verifiable

"The software shall use a multithreaded architecture."

Why: Prescribes implementation (multithreaded). A requirement specifies what, not how. This belongs in design, not requirements.

Ambiguous: Multiple Interpretations

"The system shall communicate reliably with external devices."

Why: "Reliably" is undefined. What error rate? 1 in 1000? 1 in 1,000,000? Over what time frame? No verifiable acceptance criteria.

Compound: Difficult to Trace

"The system shall detect faults, log them to a file, and notify the operator."

Why: Contains three separate requirements bundled together. Creates traceability confusion. Should be split: (1) detect faults, (2) log faults, (3) notify operator.

Key Principles for Writing SHALL Statements

Use SHALL, not should or must: SHALL is legal/regulatory language for mandatory requirements. "Must" can be ambiguous (physical impossibility vs. requirement). "Should" implies optionality (wrong for regulated products).
Include measurable acceptance criteria: Every requirement must specify HOW you will know it is met. Use numbers: time (200ms), distance (3m), decibels (85dB), percentage (95% success rate), binary (pass/fail).
Define environmental or boundary conditions: "Under nominal load," "in temperature range 0–50°C," "with ambient noise ≤75 dB." Conditions set realistic test scenarios.
Specify WHAT, not HOW: "The system SHALL detect a fault within 50ms" (WHAT). Not "The software SHALL use interrupt-driven architecture" (HOW/design). Requirements describe behavior; design documents specify implementation.
Avoid compound statements: "The system SHALL detect faults, log them, and notify the operator" contains three requirements. Split into three rows: one for detection, one for logging, one for notification. Compound requirements create traceability confusion and incomplete testing.
Be independent and atomic: Each requirement should stand alone and be verifiable in isolation. A test should verify one requirement at a time (or a small, well-defined set).

Per-Standard Compliance Mapping

Requirements map to specific clauses and processes in each regulated standard. Below is a standard-by-standard breakdown showing how the Requirements tab satisfies each compliance framework, including ID conventions, annotations, and traceability requirements.

AS9100 Rev D

§8.3.3/4 Design Inputs & Outputs

Requirements define design outputs that meet design inputs (user needs). Must be documented, reviewed, and approved. Configuration management is mandatory.

Guidance: Use standard REQ-nnn IDs. Ensure bidirectional traceability: each design output (requirement) must link to at least one design input (user need). Implement change control and maintain configuration baseline for all approved requirements. Each requirement must be independently verifiable.

ISO 13485:2016

§7.3.3/4 Design Inputs & Outputs

Design outputs must be verifiable against design inputs and include design transfer criteria (§7.3.8). Requirements specify how design outputs meet inputs.

Guidance: Separate system requirements from software/hardware design output requirements. Each design input (user need) requires one or more design outputs (requirements). Document verifiability criteria. Note: Design transfer (§7.3.8) occurs after verification; trace requirements through V&V gates to ensure design outputs are validated before transfer to production.

DO-178C

HLR/LLR Hierarchy & DAL Annotation

High-Level Requirements (HLR) decompose System Requirements. Low-Level Requirements (LLR) decompose HLRs. Each level must map to test objectives (Table A objectives). DAL A/B require independence.

Guidance: Use prefixes: SYS-xxx (system), HLR-xxx (high-level), LLR-xxx (low-level). Annotate each requirement with DAL (Design Assurance Level: A/B/C/D/E) in Notes column. DAL A/B requirements demand independent verification: tests must be developed by someone other than the requirement author. Reference Table A objectives (Table A.1–A.7) by objective number for traceability to test cases.

IEC 62304

§5.2 Software Development Requirements

Software safety classification (Class A/B/C) determines which lifecycle activities are mandatory. Safety Class drives requirement rigor and verification thoroughness.

Guidance: Annotate each requirement with Software Safety Class (A/B/C) in Notes column. Class A (highest hazard) requires formal methods, extensive documentation, and rigorous V&V. Class C (lowest hazard) allows simplified processes. Safety classes may be assigned per requirement or uniformly for the whole software. Ensure traceability from intended use (user needs) through HARA (hazard analysis) outputs to software requirements.

ISO 26262

§8/§10 Safety Requirements & ASIL Decomposition

Functional safety requirements flow from Hazard Analysis and Risk Assessment (HARA). Each safety requirement is tagged with ASIL (Automotive Safety Integrity Level: A/B/C/D). Untagged requirements are treated as Quality Management (QM).

Guidance: Tag each safety requirement with ASIL (A=lowest, D=highest) in Notes column. Only ASIL-tagged requirements receive functional safety verification. Untagged requirements follow QM processes. Ensure bidirectional traceability: safety requirements must map to HARA safety goals and to verification test cases. ASIL D requires the most rigorous verification (e.g., formal methods, back-to-back testing).

ASPICE

SWE.1 (Software Requirements) & SYS.2 (System Requirements)

ASPICE separates system requirements (SYS.2) from software requirements (SWE.1). Capability Level 2+ demands bidirectional traceability. Requirements must be traceable to user needs and to verification activities.

Guidance: Use separate ID prefixes for clarity: SYS-xxx for system requirements, SWE-xxx (or SW-xxx) for software requirements. Ensure all requirements have parent user needs and child test cases/objectives. For CL2+ maturity, perform traceability analysis: every requirement must be reachable from a user need and every user need must be reachable through requirements to a test. Document traceability matrix and review gaps.

Traceability and Independence Requirements by Standard

DO-178C (DAL A/B): Requirements at Design Assurance Level A or B require independent verification. This means the verification (test development, test execution) must be performed by someone other than the requirement author. Document this requirement in the Notes column (e.g., "DAL A – Requires Independent Verification"). Your test strategy and test case documentation must identify independent testers and justify independence claims.

ISO 26262 (Functional Safety): Safety-critical requirements must be tagged with ASIL in the Notes column. Only ASIL-tagged requirements receive functional safety verification and design review rigor. Untagged requirements are treated as quality management (QM) and may follow standard development processes. ASIL D (highest risk) requires the most rigorous verification, including formal methods or back-to-back testing with independent testers.

IEC 62304 (Software Safety Class): All software requirements must be annotated with the applicable software safety class (A, B, or C) in the Notes column. Class A (highest hazard) mandates formal specification review, independence of verification, and comprehensive documentation. Class C permits simplified processes. The safety class is determined during Software Safety Classification (§5.1) based on the intended use and hazard analysis. Ensure consistency: all requirements within a single software safety class should receive the same rigor of verification.

ASPICE (Capability Level 2+): ASPICE maturity levels CL2 and above require bidirectional traceability. Every requirement must have a parent (user need) and every user need must have children (requirements). Conversely, every requirement must have at least one child (test). Perform a traceability analysis during design review or release: identify any orphaned requirements (no parent) or unsourced requirements (no child) and resolve gaps before baseline approval.

Lifecycle Status Workflow

Every requirement progresses through a defined lifecycle: from initial creation (Draft) through formal review and approval (Approved), and finally retirement when no longer needed (Obsolete). Tracking status ensures requirements are not used in design or testing until formally approved.

Draft

Newly created requirement awaiting review. May be edited freely. Not yet part of any baseline. Incomplete or provisional.

Review

Under formal review by requirements team, design, and verification. Comments and revision requests captured. Stakeholder approval in progress.

Approved

Formal approval complete. Baseline established. Ready for design decomposition and test case development. Changes require change control (CR) process.

Obsolete

No longer active. Superseded by other requirements or removed from scope. Document reason in Notes. Retain in historical record for audit traceability.

Transition Triggers and Dates

Draft → Review: Triggered when the requirement author declares it ready for stakeholder review. Record review start date. Assign reviewers from design, verification, and quality.

Review → Approved: Triggered when all review comments are resolved and formal approval authority (program manager, chief engineer, regulatory officer) signs off. Record approval date and approver name. Freeze the requirement baseline.

Approved → Obsolete: Triggered when the requirement is superseded (e.g., by a newer version or refined requirement), descoped from the project, or made redundant. Document the change request (CR) number and reason (e.g., "Obsolete: Superseded by REQ-125 (v2.3) per CR-2024-045"). Retain the obsolete requirement in the spreadsheet but exclude from active compliance assessments.

Best Practice: Add a hidden Date column (Column I) to record status change timestamps. Timestamps provide audit evidence and support traceability queries (e.g., "Show all requirements approved before 2024-06-01").

Frequently Asked Questions

What is the difference between a system requirement and a software requirement?

A system requirement (SYS-xxx or REQ-xxx) describes what the overall system must do, regardless of implementation. It may be met by hardware, software, mechanical components, or human procedures. A software requirement (SWE-xxx or SW-xxx) describes what the software component must do. One system requirement often generates multiple software (and hardware) requirements. For example, the system requirement "Detect a fault within 50ms" might decompose into a software requirement "Monitor sensor input every 10ms" and a hardware requirement "Sensor must settle within 40ms." ASPICE and IEC 62304 explicitly separate these; DO-178C uses SYS/HLR/LLR to show the decomposition hierarchy.

How do I handle derived requirements (requirements with no parent user need)?

Derived requirements are legitimate and common. They emerge from design decisions, standards compliance, or architectural constraints and do not correspond directly to a user need. Examples: "The software shall implement watchdog timer resets every 1s" (derived from safety architecture) or "All memory buffers shall be bounds-checked" (derived from secure coding standards). Document the derivation source in the Notes column: note the regulation, standard clause, or design document that mandates the requirement. Ensure derived requirements are still traced forward to test cases—they need verification just like user-driven requirements. For audit purposes, mark these clearly: you might use a Notes annotation like "Derived: IEC 62304 §5.3.6 – Software Design Review."

Can one requirement link to multiple test groups?

Yes. A complex requirement may be verified by multiple test groups (TG-xxx) or multiple test cases within a group. For example, "The system SHALL operate correctly in temperature ranges 0–50°C (normal) and −40–70°C (extended)" might be verified by both TG-005 (Environmental Testing) and TG-012 (Functional Testing at Temperature Extremes). Conversely, one test group may verify multiple related requirements. The Requirements tab Test Group IDs field holds multiple references as a comma-separated list. During traceability review, ensure every requirement has at least one linked test; unmarked requirements indicate incomplete verification planning.

When should I mark a requirement Obsolete vs. deleting it?

Never delete a requirement row from an approved baseline. Deletion breaks traceability history and audit trails. Instead, mark the Lifecycle Status as "Obsolete" and document the reason in Notes (e.g., "Obsolete: Superseded by REQ-125 (v2.3)" or "Obsolete: Feature removed per change request CR-2024-045"). This preserves the traceability chain, allows you to trace old test results, and shows auditors that you managed the requirement lifecycle intentionally. Obsolete requirements remain in the historical record but are excluded from active compliance assessments. Some organizations archive obsolete requirements to a separate "Retired" worksheet for cleaner working documents.

What goes in the Notes column?

Use Notes for compliance annotations and traceability metadata that do not fit in other columns. Examples: (1) Safety/Criticality Annotations: "DAL B" (DO-178C), "ASIL C" (ISO 26262), "Safety Class A" (IEC 62304). (2) Standards References: "AS9100 §8.3.4 – Design Output Review" or "ISO 13485 §7.3.3 – Design Input Requirements." (3) Derived Requirement Source: "Derived from IEC 62304 §5.3.6 – Requirements Traceability." (4) Change History: "Modified v1.2 – Tightened timing to 200ms per CR-2024-010." (5) Verification Notes: "Requires independent V&V (DAL A)" or "Functional test + formal proof required." (6) Cross-References: "Related to REQ-045, REQ-067" or "Implements UN-012." Avoid free-form design commentary or implementation hints—keep Notes focused on traceability and compliance context.