Optional. If provided, the tool uses it to frame requirement statements consistently. It is never inserted into rationale or verification fields.
Enter free‑form text, a draft requirement, or a description of system behaviour. The tool converts it into a structured, testable requirement table.
Converts your input into a full INCOSE/ISO‑29148‑aligned requirement table: ID, Requirement Statement, Requirement Type, Rationale, Verification Method, Priority.
When a row is selected in the output table, this rewrites only that requirement—preserving the ID and improving clarity, atomicity, and testability, while showing a diff of exactly what changed and why.
It can also operate standalone by transforming any pasted or typed requirement into a full, compliant table (including splitting when needed).
Downloads the current requirement table as a CSV file for import into DOORS, Jama, Excel, or any requirements management tool.
Copies the raw Markdown table to your clipboard for pasting into documents or chat.
Clicking a row loads that requirement into the input box. Rewrite mode then applies only to that requirement and shows a diff panel.
A requirement ID is essential for traceability, configuration management, and lifecycle control. Once assigned, an ID must never change — even if requirements are deleted or reordered. Gaps in numbering are normal and acceptable.
A requirement statement must describe what the system shall do, written clearly and without ambiguity. It must be Specific, Testable, Individual (Atomic), and Unique.
The requirement contains concrete details, exact measurements, or clear boundaries, avoiding subjective
adjectives like “fast,” “intuitive,” or “user‑friendly.”
Vague: “The system should load pages quickly.”
Specific: “The system dashboard shall load all user data within 3.0 seconds during peak traffic hours.”
The requirement is written so objectively and completely that a QA tester can design a pass/fail test case for it.
Untestable: “The checkout process should be secure.”
Testable: “The payment gateway shall encrypt all transaction data using AES‑256 encryption.”
Each requirement describes exactly one distinct behaviour or function. Avoid “and” or “then” in a single requirement.
Compound (Bad): “The user shall update their profile and receive an email confirmation and see it reflected on their dashboard.”
Individual (Good):
REQ‑01: “The user shall be able to update their profile information.”
REQ‑02: “The system shall send a confirmation email upon profile update.”
REQ‑03: “The system shall display updated profile information on the user dashboard.”
Each requirement must be clearly distinguishable from all others, assigned a unique ID, and must not duplicate, contradict, or overlap with other specifications.
Functional requirements describe what the system must do.
Non‑functional requirements describe how well the system must perform (performance, security,
reliability, usability, etc.).
The rationale explains why the requirement exists. It may include references to standards, safety justifications, regulatory obligations, operational needs, or constraints that would clutter the requirement statement itself. A good rationale improves traceability and reviewer understanding.
Inspection — visual or documentary check.
Demonstration — show the system performing a function.
Test — measured, instrumented verification.
Analysis — modelling, simulation, or calculation.
Priority guides trade‑off decisions later in the project. It reflects funding constraints, schedule pressure, technical feasibility, and risk appetite. High‑priority requirements are protected; lower‑priority ones may be relaxed to meet cost, schedule, or technical constraints — especially when pushing performance into unproven technology areas.
INCOSE — International Council on Systems Engineering
Global professional body for Systems Engineering. Publisher of the INCOSE Handbook and SE standards.
NASA Systems Engineering Handbook
Free, high‑quality SE guidance widely used across industry.
SEBoK — Systems Engineering Body of Knowledge
Comprehensive reference for SE principles, lifecycle models, and best practices.
ISO/IEC/IEEE 29148
International standard for writing high‑quality requirements.