Requirements
Requirements are the atomic units of system definition. Ngenaire's Requirements workspace gives you three coordinated views — Management, Outline, and Quality Analysis — plus comments, full history, impact analysis, and import/export.
Location:
/system-definition/requirements/*(sidebar: Define → Requirements).
Writing testable requirements with EARS
EARS (Easy Approach to Requirements Syntax) keeps statements unambiguous and testable. Write the statement in plain text — quality checks flag statements that don't match a known EARS form.
| Pattern | Form | Example |
|---|---|---|
| Ubiquitous | "The system shall response." | "The system shall log every authentication attempt." |
| Event-driven | "When trigger, the system shall response." | "When a user submits a form, the system shall validate inputs within 200 ms." |
| State-driven | "While state, the system shall response." | "While in safe mode, the system shall reject configuration changes." |
| Unwanted-behavior | "If condition, then the system shall response." | "If the database connection fails, then the system shall retry every 5 seconds." |
| Optional-feature | "Where feature, the system shall response." | "Where two-factor authentication is enabled, the system shall require a second factor." |
| Complex | combinations of the above | "While charging, when the cell exceeds 45 °C, the system shall halt charging." |
Management view
/system-definition/requirements/management
The default working view — a table of every requirement with filters and inline editing.
- Create Requirement opens a form (Title, Category, and Description are the core fields; write the statement in EARS form).
- Edit any cell inline, or open the side drawer for the full editor.
- Filter and search by category, status, or owner.
- Organize requirements into modules and save saved views for the filter/column setups you reuse.
Comments and history
Open a requirement's drawer to add inline comments in a threaded discussion, and to review its full edit history with field-level diffs that show exactly what changed between revisions.
External links
Attach external links (to a wiki page, ticket, spec, or design file) to a requirement so supporting context travels with it.
Impact analysis and suspect links
Use impact analysis to see a requirement's upstream drivers and downstream dependents before you change it. When a linked requirement changes, the affected links are flagged as suspect so you can review whether the dependent requirement still holds.
Outline view
/system-definition/requirements/outline
A hierarchical tree showing parent/child relationships with computed outline numbers (1.2.3 …).
- Drag a row by its handle to reorder or reparent it.
- Reordering is scoped to siblings; the tree renumbers the affected siblings automatically and persists the new order immediately.
- Scope the outline to a single module or the whole project with the module selector.
Quality Analysis
/system-definition/requirements/quality-analysis
AI-assisted scoring of each requirement across dimensions including testability, clarity, atomicity (single obligation), and completeness. Each flagged issue carries a severity and an explanation, and many offer an auto-fix — an AI rewrite proposal you can review and accept to apply the improved statement. You can analyze a single requirement or run analysis across the whole set, then work the flags down before review.
Custom attributes
Extend the requirement schema with project-specific fields (safety integrity level, regulatory clause, verification class, …). Validation (regex / min / max / enum) is enforced when you save. See Custom Requirement Attributes.
Import and export
- ReqIF — import and export the requirement set in the interchange standard for round-tripping with other RM tools.
- CSV — import and export a spreadsheet-friendly form.
- DOCX — export to a Word document.
- SRS markdown — generate a Software/System Requirements Specification document from the requirement set.
AI Assistant prompts
Decompose REQ-000007 into three children that are individually testable.
Audit the requirement set for ambiguous wording and untestable verbs.
Convert this plain-English description into EARS requirements: "Users should be able to reset their password and the system should email them a link."
Tips
- Keep statements atomic. One verb, one obligation — Quality Analysis flags compound statements.
- Baseline at every review. Snapshot the set at SRR, PDR, and CDR. See Requirement Baselines.
- Manage post-baseline change through ECRs. Once a baseline exists, route edits through a change request.