Requirements are the foundation of regulated quality work. Every test, every risk assessment, every CAPA record, every design control artifact traces back to a requirement. If your requirements are poorly structured, poorly tracked, or poorly linked, everything downstream suffers.
Get monitors, keyboards and dev gear delivered free — and shop member deals
- Fast, free delivery on millions of items
- Access to Prime Big Deal Days deals on October 6–7
- Prime Video, Amazon Music and more included
QAtrial treats requirements as first-class entities with structured metadata, lifecycle management, bidirectional traceability, AI-assisted enrichment, and audit trail coverage. This article walks through the complete requirements management workflow.
Management
bidirectional
structured links
Creating a Requirement
Navigate to the Requirements tab and click the Requirement button in the top-right corner. A modal opens with three fields:
- Title (required): A concise statement of what must be true. Good requirement titles are testable: “System shall log all user authentication events with timestamp and user ID” is better than “Authentication logging.”
- Description (required): The detailed specification. Include acceptance criteria, boundary conditions, and any context an auditor or tester would need to understand what compliance looks like.
- Status: Draft (default), Active, or Closed.
Click Save. The requirement is assigned an auto-generated ID following a sequential pattern: REQ-001, REQ-002, REQ-003.
requirements management software for QA
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
The ID System
QAtrial generates IDs automatically and sequentially. You do not choose IDs, which prevents duplicates and gaps. The prefix REQ- makes requirements immediately distinguishable from tests (TST-) and other entities in audit trails, traceability matrices, and reports.
IDs are stable. Once assigned, an ID does not change even if the requirement is edited. If a requirement is deleted, its ID is not reused. This is a regulatory expectation: audit trails must be able to reference records unambiguously by ID, and reusing IDs would create confusion.
regulated quality requirements tracking tool
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Enriched Metadata
Requirements generated from templates (via the setup wizard) include metadata beyond the basic title, description, and status:
Tags are categorical labels like “audit-trail”, “data-integrity”, “electronic-signatures”, or “risk-management”. Tags serve two purposes: they make requirements searchable by category, and they drive automatic test linking during template composition. When the wizard generates tests, it matches test tags against requirement tags to create links.
Risk Level classifies the requirement as low, medium, high, or critical. This feeds into the risk dashboard, the compliance readiness score (which penalizes critical-risk requirements), and the AI risk classification workflow. Template-generated requirements come with a default risk level based on the regulatory domain.
Regulatory Reference is the specific clause or standard that the requirement addresses. For example, “21 CFR 11.10(e)” for an audit trail requirement, or “ISO 13485 Section 7.3” for a design control requirement. This metadata is essential for auditors and regulatory submissions. It answers the question: “Which standard requires this?”
Jurisdictions indicate which country codes the requirement applies to. A requirement generated for a US project carries the US jurisdiction flag. If you later need to scope your quality system for a specific market, you can filter by jurisdiction.
Verticals indicate which industry verticals the requirement is relevant to. This is primarily used by the template system to compose requirements correctly, but it also helps in multi-vertical organizations that need to understand which requirements apply to which product lines.
Evidence Hints suggest what evidence is needed to demonstrate compliance with the requirement. For example, a data integrity requirement might have an evidence hint of “system log exports showing ALCOA+ compliance.” These hints guide QA engineers during evidence collection without being prescriptive about exact documentation format.
AI-assisted requirements management system
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Status Lifecycle
Requirements follow a three-state lifecycle:
Draft --> Active --> ClosedDraft is the initial state. The requirement is being written, reviewed, or refined. It has not been baselined. Draft requirements are included in coverage calculations but signal that the project is not yet mature.
Active means the requirement has been reviewed, approved, and baselined. It is the current, authoritative version. Tests should be executed against Active requirements. The compliance readiness score weights Active and Closed requirements positively.
Closed means the requirement has been fully verified, superseded, or is no longer applicable. Closed requirements remain in the system with their full history. They are not deleted.
Status changes are recorded in the audit trail. If your project uses the workflow engine, status transitions can require formal approvals.
As an affiliate, we earn on qualifying purchases.
Searching, Sorting, and Filtering
The requirements table is built on TanStack Table and supports:
Search: A text search box at the top of the table filters requirements by matching against title and description text. This is a real-time filter — results narrow as you type.
Column sorting: Click any column header to sort ascending or descending. Sortable columns include ID, title, status, risk level, and regulatory reference. Click again to reverse the sort order.
Pagination: For large requirement sets, the table paginates automatically.
These features matter more than they might seem. In a project with 200+ requirements, the ability to quickly find “all critical-risk requirements” or “all requirements referencing ISO 14971” is the difference between a manageable workspace and a wall of text.
AI Features Per Requirement
Each requirement row has two AI action buttons (visible when an AI provider is configured):
Test Generation
Click the test generation icon to open the AI Test Generation Panel. The AI reads the requirement title, description, risk level, regulatory reference, and project context (country, vertical, standards), then generates four to six test cases. Each generated test includes a title, description, expected outcome, and pre-linked requirement reference.
The generated tests appear as proposals. You review each one, modify if needed, and accept the ones you want. Accepted tests are created in the system with proper IDs and links. This is a human-in-the-loop design: the AI drafts, you decide.
For a requirement like “System shall enforce password complexity: minimum 8 characters, at least one uppercase, one lowercase, one digit, one special character,” the AI might generate tests for: valid password accepted, each complexity rule violated individually, boundary conditions (exactly 8 characters), and special characters in various positions.
Risk Classification
Click the risk classification icon to open the AI Risk Classification Panel. The AI proposes a severity rating and a likelihood rating using the risk taxonomy appropriate to your vertical (ISO 14971 for medical devices, ICH Q9 for pharma, GAMP 5 for software).
The proposal includes a rationale explaining why the AI assigned the specific ratings. You can accept, modify, or reject the classification. Accepted classifications update the requirement’s risk metadata and feed into the 5×5 risk matrix dashboard.
Linking Requirements to Tests
Requirements and tests have a many-to-many (n:m) relationship. A requirement can be covered by multiple tests. A test can verify multiple requirements.
Links are managed from the test side: when creating or editing a test, you select which requirements it links to via checkboxes. This design choice means the test is the entity that “claims” which requirements it covers, which aligns with how testing typically works — you write a test to verify one or more requirements.
From the requirements table, you can see how many tests are linked to each requirement. Requirements with zero linked tests are flagged as orphaned in the dashboard, indicating a coverage gap.
Approval Workflow and Electronic Signatures
Requirements can be formally approved using electronic signatures. Click the signature icon on a requirement row to open the Electronic Signature Modal.
The signature process:
- Re-authentication: You must enter your password again, even if you are already logged in. This is a 21 CFR Part 11 requirement to ensure the person signing is who they claim to be.
- Signature meaning: Select from authored, reviewed, approved, verified, or rejected.
- Reason: Enter the reason for the signature (e.g., “Reviewed and confirmed requirement aligns with ISO 13485 Section 7.3”).
- Confirmation: Submit the signature.
After successful re-authentication, a 15-minute window allows additional signatures without re-entering the password. Every signature event is recorded in the audit trail with the signer’s identity, timestamp, meaning, and reason.
If the workflow engine is configured, requirement approval may require multiple signatures from specific roles. For example, the default Requirement Approval workflow requires three steps: review (by QA Engineer), approval (by QA Manager), and signing (by Reviewer).
Audit Trail
Every operation on a requirement generates an audit trail entry:
- Creation: who created it, when, with what initial values
- Edits: who changed it, when, which fields changed, old values, new values
- Status changes: who changed the status, from what to what
- Deletion: who deleted it, when
- Signatures: who signed it, with what meaning and reason
The audit trail is viewable by clicking the Audit Trail button in the header toolbar. You can filter by entity type, user, date range, and event type. Export to CSV or PDF for audit packages.
The audit trail is append-only. Users cannot edit or delete audit entries. This immutability is a core requirement of 21 CFR Part 11 and EU Annex 11.
Import and Export
Requirements can be exported as part of the full project JSON export (via the Import/Export toolbar button). This includes all metadata, links, and status information.
For bulk operations, the JSON format allows you to prepare requirements externally and import them. The AI Requirements Extraction feature (v3.0) also supports pasting regulatory text and having the AI decompose it into individual, testable requirements with regulatory references and risk levels.
Practical Tips
Write testable titles. A requirement titled “Data integrity” is not testable. A requirement titled “System shall generate a unique, immutable timestamp for each data modification event” is testable. The AI test generator produces better output from well-written requirements.
Set risk levels early. Risk level drives the compliance readiness score, the risk dashboard, and AI-generated test priority. Leaving all requirements at the default level reduces the value of these features.
Use regulatory references consistently. When an auditor reviews your requirements, the regulatory reference tells them why the requirement exists. “21 CFR 11.10(e)” means something specific. “Regulatory requirement” does not.
Review generated content. Template-generated requirements are starting points based on the standards that apply to your country and vertical. They are not a substitute for your organization’s specific quality objectives. Review each one. Edit descriptions to match your product. Delete requirements that do not apply. Add requirements that the templates missed.
Requirements management is not the most visible part of quality work, but it is the part that everything else depends on. Getting it right in QAtrial means getting your traceability, compliance scoring, and audit readiness right by extension.
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
