Getting Started
Requify is an enterprise-grade requirements specification system. It is designed to combine the flexibility of modern rich-text editing with database-driven quality modeling. Unlike traditional static text editors, every paragraph in Requify can be mapped as a strict system/hardware requirement, connected to test suites, and traced down to code commits.
1. Create Project Structure
2. Map Requirements
Creating a Project
Every project starts in the same wizard: choose the document type, how to start, then the project details. New project buttons anywhere in the app open it.
How to start
• Blank: an empty document.
• Standard template: a ready outline for the document type.
• AI draft: describe the product; AI writes the outline and first texts (uses AI tokens).
• Import from Jira: the standard outline, then connect a Jira project and import its issues as linked requirements (Professional plan).
Document types
Software, hardware, system, product, interface and user requirements; the German Lastenheft (DIN 69901-5) and Pflichtenheft; outlines organised around ISO 29148, ISO 9001, ISO 27001, Automotive SPICE, ISO 26262, IEC 62304, DO-178C, the EU Cyber Resilience Act and GDPR DPIAs; user manuals, API documentation and wikis; or your own type.
Standards outlines are a starting structure around the topics of the standard. They do not contain the standard and using them does not by itself make a product compliant.
AI Onboarding & Check
Requify leverages advanced AI models to simplify document onboarding and quality review workflows. Run AI-driven generation and context-aware validation directly inside the platform.
AI Onboarding Draft Generator
Kickstart new specification documents by selecting the AI-Generated Draft option during project setup. Describe your project goals, system architecture, or domain in plain text, and Requify's AI engine will seed the project with an initial structure, complete with draft section headings and descriptions.
Supported AI Validation Modes
- SRS (Software Requirements Spec): Checks for ambiguity, correct use of directive terms (shall, must, should), and missing interface constraints.
- HRS (Hardware Requirements Spec): Focuses on safety metrics, environmental tolerances, electrical power conditions, and physical sizing limits.
- General Grammar & Style: Polishes text readability and formatting without changing technical constraints.
Dual-Apply Actions
After the AI proposes corrections in the check panel, you can review changes side-by-side. You have two apply options:
• Apply to Section: Overwrites the selected section's editor text with the AI corrected version.
• Apply in a new Section: Creates a child section directly underneath and populates it, preserving your original draft.
Requirements & Collaboration
Requirements are the building blocks of your spec. Each requirement has a rigid database schema and is fully collaborative.
Collaborative Presence & Section Locks
Requify supports multi-user editing within the same project. The top dashboard header renders an avatar group showing all Active Workers currently accessing the project. To prevent conflicts, when a collaborator opens a section, it is automatically locked. In the document structure tree, locked sections are highlighted with a dashed amber border, amber background, and the name badge of the lock holder.
Workflow States
A requirement transitions through standard lifecycle states:
• Draft: Being actively edited.
• Reviewed: Checked and ready for approval.
• Approved: Signed off by project authorities.
• Implemented: Developer has coded the feature.
• Verified: Linked test cases have successfully run and passed.
• Rejected / Deprecated: Not accepted, or no longer valid.
Change History & Auditing
Every edit to a requirement creates an immutable audit trail entry detailing:
• Who made the change.
• Which field was modified (e.g. Description, Status, Priority).
• Before and after values, timestamped for regulatory compliance.
Section Review Workflow
For documents that several people write, an owner or admin assigns sections to members and switches on Approval workflow in the Workflow tab of the editor. It is off by default and needs an organization: a personal workspace has nobody to assign sections to.
How it works
1. An owner or admin assigns a section to a member (Assign Section).
2. The member writes it and clicks Submit for review; the section is now in review.
3. Owners and admins approve it, or send it back to draft with a comment.
The tabs All, Draft, Review, Approved, Mine and Unassigned show where every section stands.
Who may change what
The server checks this on every save, not only the editor:
• Owners and admins: everything.
• Project editors: everything, except sections in review or approved and sections assigned to someone else.
• Members assigned only to sections: see and change only those sections and their sub-sections, while they are drafts, and not the project details.
Sub-sections follow their section. Comments stay possible on a locked section. If a save touches a section the person may not change, the stored text is kept and the editor says so.
Who is told
Submitting notifies every owner and admin of the organization. The review result notifies the author. Both appear in the app and go out by email, unless switched off under Settings → Notifications.
Baselines & Sign-off
A baseline freezes all requirements, with their linked tests, at one moment: before a specification goes to a customer, at a release or before an audit. The document text has its own snapshots: Save version.
Create and compare
In the editor, open the Baselines tab. + creates a baseline (BL-001, BL-002, …) with a name and a type.
Choosing a baseline shows what changed in the requirements since then: added, changed (old → new values) and removed.
Signed approvals
The pen icon of a baseline opens its approval record. You sign as authored, reviewed or approved (approving needs the project owner or an admin) after confirming your sign-in again. Professional plan.
Each signature stores your name, the time, your comment and a fingerprint of the baseline and of the previous signature, so a changed baseline or an altered record is shown as such.
This is an internal approval record, not a qualified electronic signature, and it does not by itself make your process compliant with 21 CFR Part 11 or similar rules.
Deleting
A baseline can be deleted while it is not marked Final and nobody has signed it. A signature cannot be withdrawn.
Testing & Traceability
Traceability ensures that every requirement is fully covered by test validation. By linking Test Cases to Requirements, the system establishes a bidirectional link (Requirement ↔ Test Case ↔ Bug Ticket).
Impact analysis shows what a change to a requirement reaches: linked test cases, derived requirements, requirements that depend on it, tickets, document sections and the linked Jira or Azure DevOps item, with an impact score from 0 to 100 and a ripple up to three levels deep. The score shows what each factor adds: linked tests, derived and dependent requirements and open tickets (how far a change spreads), and priority, risk level, complexity and status (how costly it is). The What-If simulator starts from the requirement as it is: change those four values to see how the score would move, then apply them to the requirement if you can edit it. Status offers only the next steps the workflow allows. With a short description of the change, AI also predicts likely affected requirements and tests from the same project, marked AI predicted, and a mitigation plan; if the AI part cannot run, the simulator says so.
Traceability Matrix Tabs & Suspect Links View
The Traceability tab supports a two-way layout:
• Matrix View: Displays a grid showing all requirements mapped against test cases to quickly identify gaps.
• Suspect Links: Displays suspect link flags when requirements are modified. If there are any unacknowledged suspect links, a red badge with the link count is shown on the tab header. A tester must review the requirement changes and click "Clear Suspect" to update the trace status.
Release & Build Tracking
When executing a test case, testers record the specific Build Version (e.g. v1.2.0-rc3) and Environment (QA, Staging, Production). This allows you to track test status history across multiple releases.
Suspect Links & Clearing
If a requirement is edited, linked test cases automatically become **Suspect** (flagged as potentially outdated). Testers can review the change details in the test case pane and click **Clear Suspect** to acknowledge and remove the flag.
Traceability Metrics Glossary
- Orphan Test Cases: Test cases with no linked requirements (unmapped testing effort).
- Orphan Requirements: Requirements with no linked test cases (verification gap).
- Pass Rate: Percentage of linked test cases that recorded "Passed" in their most recent execution.
Excel Import Reconciliation
Round-trip requirements engineering is protected by Requify's Excel Reconciliation Wizard, ensuring safe and selective merging.
Reconciliation Wizard Modal
When importing Excel or CSV sheets to merge with an existing project target, Requify parses the file and opens a 3-way Reconciliation Modal. This wizard computes differences and groups all updates into three distinct categories:
- New Items to Add: Requirements in the import file that do not exist in the target project.
- Modified Items to Update: Requirements where the title, content body, or priority has changed. The UI lists specific differences (e.g. Title changes or body edits) side-by-side.
- Deleted Items to Remove: Requirements present in the target project but missing from the import file.
Using selective checkboxes, you can check or uncheck individual items in each category. Only selected additions, updates, and deletions will be applied upon confirmation.
The Quality Lifecycle Loop
Trace how system artifacts change state in response to developer activity and test executions. Clicking "Record Result" or resolving tickets automatically alters state.
1. Specify Requirement
Requirement is drafted (Draft/Implemented status). Linked to document sections.
2. Generate/Link Test Cases
Test cases are linked to verify the requirement. Multiple tests track verification coverage.
3. Run Test Execution
Tester executes the test case on a specific Build Version and Environment (QA, Staging).
4. Test Fails -> Bug Ticket
Failure automatically creates/reopens a Defect Ticket and demotes Requirement to Implemented.
5. Dev Resolves -> Retest Queue
Dev fixes the bug, sets Ticket status to Resolved. Ticket goes to 'Ready for Retest' queue.
6. Retest Passes -> Verified
Tester re-executes. Passing closes the linked ticket. Requirement promotes to Verified.
Defect Ticket Management
Defect tickets link failed test executions back to the development team for code corrections.
1. SLA & Aging Indicators
Active tickets track their **Age** (time since creation). If an open/reopened ticket is older than 3 days, it displays a pulsing red **Aging** warning. Tickets waiting in the resolved state show exactly how long they've been waiting for retesting.
2. Role-Based Notifications
When a developer resolves a ticket, the original tester (ticket creator) is notified automatically via a **"Ticket Ready for Retest"** alert. Watchers and assignees are also in the loop, ensuring immediate awareness.
Retest Queue & Automatic Promotion
Resolved tickets are categorized in the Test Cases list under the **"Ready for Retest"** tab, highlighted by a pulsing blue indicator next to the test. Executing the test and recording a **Passed** result closes the linked defect ticket and automatically promotes the linked requirement back to **Verified**.
Subscription & Trials
Every account starts on the free Starter plan. Professional comes in two forms; which one you buy depends on the workspace you upgrade.
Plans (prices include VAT)
• Starter (free): 1 project, up to 2 members, PDF export, AI with purchased tokens.
• Professional, personal workspace (1 seat): 29 € per month or 225 € per year. 15 projects, 2M AI tokens per month.
• Professional Team, organization (up to 6 members): 89 € per month or 890 € per year. 15 projects, 8M AI tokens per month for the team.
• Enterprise: higher limits on request.
Free trial
Each person can try Professional once, for 14 days, without a card: Activate 14-Day Free Trial on the projects dashboard. It applies to the workspace you are in.
Upgrading and coupons
Every Upgrade button opens the same dialog: choose monthly or yearly, enter a coupon code if you have one, and continue to Stripe. A coupon entered there shows as a discount on the Stripe page; without one, Stripe offers its own promotion code field. All plans are compared at requify.tech/#pricing.
Billing and organizations
Invoices, payment method and cancellation: Settings → Subscription → Manage billing and invoices. Your first organization is free; further organizations need a Professional plan.
Git & Developer Sync (Git-Ops)
Integrate your requirements specifications directly into your development workflow. Push generated specs as version-controlled Markdown files directly into GitHub or GitLab, keeping business logic and source code fully aligned.
Connecting Your Repository
Go to your project's **Export** tab and select the **Git-Ops Sync** panel.
1. Select your provider (**GitHub** or **GitLab**).
2. Enter the repository name in `owner/repository-name` format (e.g. `acme/smart-hub`).
3. Set your target branch (e.g., `main` or `development`) and file path (e.g., `docs/requirements.md`).
4. Toggle **Enable Synchronization** and click **Save Settings**.
GitHub OAuth Authentication
By default, GitHub uses Clerk's native OAuth connection. Link your GitHub account under **User Profile Settings ➔ Connected Accounts**. Make sure you accept the repository write permissions request during authorization so the app can create commits.
GitLab & Custom Tokens
For GitLab (or to override GitHub credentials), you can provide a **Personal Access Token (PAT)** with repository write permissions. Paste the PAT in the project settings; it will be encrypted at rest using AES-256-CBC and kept secure.
Integrations, API & AI tools
Everything here is part of the Professional plan unless noted. Open the requirements list and use the arrows button (Import, export and sync) for ReqIF and the trackers; API keys and webhooks are under Settings ➔ Developers.
ReqIF
ReqIF is the exchange format of DOORS, Polarion, Codebeamer, Jama and others. Export writes your requirements, their parent/child structure and dependencies. Import (free on every plan) adds the requirements of a .reqif file to the project and never changes existing ones; an ID that is already taken gets a new ID and the original is kept as External ID. Export has been checked against the OMG ReqIF schema, but we recommend trying a round trip with your own tool before relying on it.
Jira Cloud & Azure DevOps
The project owner or an admin connects Jira Cloud (account email and API token) or Azure DevOps (personal access token). The token is stored encrypted and the connection is tested before it is saved.
• Push creates an issue or work item per requirement, or updates the linked one, as plain text.
• Pull reads the status and takes over a title or description edited in the tracker (the text above the --- Requify --- line). If both sides changed since the last sync, nothing is overwritten.
• Jira only: Import issues turns the issues of the project (or of a JQL search) into linked requirements, and the Jira webhook shown on the connection syncs changes automatically and can import new issues.
REST API & webhooks
Create a key under Settings ➔ Developers and send Authorization: Bearer rqf_…. Endpoints: GET /api/v1/projects, GET /api/v1/projects/{id}/requirements (filters: status, query, limit, page), GET …/requirements/{requirementId} and POST …/requirements (needs a read + write key). Limit: 120 requests per minute per key. Webhooks send a signed POST for requirement.created, .updated, .deleted and .imported; verify the X-Requify-Signature header, which is sha256= plus the HMAC-SHA256 of timestamp + "." + body with your secret.
MCP for AI tools
https://your-domain.com/api/mcp speaks the Model Context Protocol over HTTP with the same API keys. Tools: list_projects, list_requirements, get_requirement, check_requirement_text (rule-based wording check, no AI) and, with a write key, create_requirement. Support for URL-based MCP servers with custom headers differs between AI tools; check your tool's documentation.
AI Tokens
AI features (drafts, checks, test case generation, link suggestions, impact analysis, chat and translation) use AI tokens. They follow the project's document type: an ISO 26262 or Automotive SPICE project is checked for ASIL, safety goals and verification methods, an IEC 62304 project for software safety classes and risk controls, a DO-178C project for design assurance levels, and so on; translations keep the terms from the project glossary. Settings → AI usage shows what is available to you right now.
Included every month
• Professional, personal workspace: 2M tokens.
• Professional Team: 8M tokens for the organization; each member can use up to 2M of them per month.
• Starter: none included; buy tokens to use AI.
Included tokens reset on the 1st of every month.
Buying tokens
Buy a pack or any amount under Settings → AI usage: for yourself (usable in every workspace), for the organization (shared by its members) or for one project. Purchased tokens never expire. Order of use: project tokens, the monthly included tokens, organization tokens, then your own. Owners and admins are told when 80% of the monthly tokens are used and when they run out.
Where AI runs
By default AI requests are processed by DeepSeek, on servers in China. Where EU processing is enabled for the service, an owner or admin can switch a workspace to EU processing (Mistral) under Settings → AI usage.
Notifications
The bell in the header shows new notifications; clicking one opens the project or section it is about.
What you are told about
Section and project assignments and removals, a section submitted for review (owners and admins), the review result (author), failed tests and new defect tickets, a fixed ticket ready for retest (creator, assignee and watchers), retest results, accepted invitations, AI token warnings (owners and admins) and Pro offers.
In the app and by email
Email goes out for assignments, reviews, failed tests, tickets, accepted invitations and AI token warnings. Switch email or in-app notifications off under Settings → Notifications. Read notifications are deleted 90 days after they were read.
Frequently Asked Questions
Q: After executing a test case, does the status turn to "passed" immediately, or is there a delay?
A: It is immediate. When you submit a result, a synchronous database transaction updates the test case and immediately re-evaluates linked requirement states. The frontend updates its UI states instantly on receiving the API response.
Q: Why does the "Execute" button still work on test cases that have already passed?
A: Regression and Auditing. Requirements must be retested whenever a new build is released or deployed to a new environment. Allowing infinite executions guarantees you can maintain an audit-compliant history showing that features remain functional across different builds and releases.
Q: Why do requirements need a "pass rate" metric?
A: For verification gating. A complex requirement (e.g. system performance under load) may have multiple verification check-points. A requirement is only fully verified when all linked test cases pass (100% pass rate). The pass rate indicator tells project owners the exact completion and quality status.
Q: Who is notified when a bug is fixed?
A: The creator, assignee, and watchers. When a ticket status changes to resolved, notifications are sent to the user who reported/created the defect (typically the QA tester), the assignee, and all watchers, directing them to retest the item.
Q: What is the behavior when a test case fails?
A: Automatic demotion. If a test case fails or is blocked, any linked requirement that was previously marked verified is demoted back to implemented. This prevents a requirement from displaying a false validated status if verification runs fail.