Requirements Overview

NirmIQ's Requirements module helps you organize, manage, and trace requirements through customizable hierarchies.

What are Requirements?

Requirements are specifications of what a system must do or qualities it must have. They form the foundation of any engineering project.

Types of Requirements

IntelliSE supports any requirement hierarchy, but defaults to:

• Customer Request (CR): High-level customer needs
• System Requirement (SYS): System-level specifications
• Subsystem Requirement (SUB): Subsystem specifications
• Function Requirement (FUN): Functional requirements
• Subfunction Requirement (SFUN): Detailed functional specs
• Detailed Requirement (L6): Implementation-level details

Admins can customize this hierarchy to match your methodology.

Key Concepts

Hierarchical Structure

Requirements are organized in a tree structure:

CR-001: Vehicle shall transport passengers
└── SYS-001: Powertrain shall provide propulsion
    └── SUB-001: Engine shall generate power
        └── FUN-001: Engine shall combust fuel efficiently
            └── SFUN-001: Fuel injection shall optimize mixture
                └── L6-001: Injector pulse width shall be 2-10ms

Custom IDs

Each requirement has a unique hierarchical ID:

• Format: TYPE-XXX (root) or PARENT_ID.TYPE-XXX (child)
• Examples:
  • Root: CR-001, CR-002, CR-003
  • Children: CR-001.SYS-001, CR-001.SYS-002
  • Grandchildren: CR-001.SYS-001.SUB-001

Benefits:

• ✅ Shows hierarchy path at a glance
• ✅ Type-specific numbering (counts only same type)
• ✅ Traceable across documents and teams
• ✅ Unique and human-readable

Requirement Fields

Each requirement contains:

Field	Description	Required
Custom ID	Auto-generated hierarchical ID	Auto
Type	Requirement type (CR, SYS, etc.)	✅ Yes
Title	Short description (< 100 chars)	✅ Yes
Description	Detailed specification	Optional
Parent	Parent requirement	Optional
Priority	High, Medium, Low	Optional
Status	Draft, Approved, Implemented	Optional
Owner	Assigned team member	Optional

Requirements Workflow

Typical Process

1. Create Customer Requests - Capture high-level needs
2. Decompose to System - Break down into system requirements
3. Further Decomposition - Continue down hierarchy levels
4. Add Details - Specify implementation requirements
5. Link to FMEA - Connect to failure mode analysis
6. Track Changes - Monitor status and approvals

Tree View

The hierarchical tree view shows:

• Visual indentation based on hierarchy level
• Expandable/collapsible nodes
• Type indicators and custom IDs
• Quick navigation to any requirement

Detail Panel

Click any requirement to see:

• Details Tab: Full description, all fields, inline editing
• AI Analysis Tab: AI-powered requirement analysis and suggestions
• Parent Relationships: Multiple parents with semantic relationship types
• Version History: Track all changes with timestamps and user info
• Linked FMEA entries: Traceability to failure mode analysis
• Edit and delete options

Features

✅ What You Can Do

• Create requirements at any hierarchy level
• Many-to-many parent relationships - Link requirements to multiple parents
• Inline editing - Quick field updates directly in Details tab
• Move requirements between parents (updates hierarchy)
• Edit requirement details (modal or inline)
• AI-powered analysis - Improve requirement text with AI suggestions
• Delete requirements (with confirmation)
• Import from documents with AI (Pro/Enterprise)
• View hierarchical tree structure
• Version history - Track all changes over time
• Search and filter (coming soon)

🚧 Coming Soon

• Requirement traceability matrix
• Version history and change tracking
• Comments and collaboration
• Export to PDF, Excel, Word
• Advanced search and filters
• Requirement templates
• Bulk operations

Best Practices

Writing Good Requirements

1. Be Specific: Avoid ambiguous language

   • ❌ Bad: "System should be fast"
   • ✅ Good: "System shall respond within 200ms"

2. Use "Shall" for Mandatory: Clear obligation

   • ✅ "Engine shall start within 3 seconds"

3. Make it Testable: Can you verify it?

   • ❌ Bad: "User interface should be intuitive"
   • ✅ Good: "90% of users shall complete task without help"

4. One Requirement per Item: Don't combine

   • ❌ Bad: "System shall be secure and fast"
   • ✅ Good: Split into two requirements

Organizing Requirements

1. Start at Top: Begin with customer requests
2. Decompose Gradually: Don't skip levels
3. Consistent Granularity: Similar detail at same level
4. Logical Grouping: Related items under same parent
5. Use Types Correctly: Follow hierarchy rules

Hierarchy Depth

• Too Shallow: Lose detail and traceability
• Too Deep: Overwhelming and hard to manage
• Recommended: 4-6 levels for most projects

What's Next?

• Creating Requirements - Learn how to add requirements
• Editing Requirements - Inline editing and field updates
• Parent Relationships - Many-to-many traceability
• Managing Hierarchy - Work with tree structure
• AI Import - Import from documents (Pro/Enterprise)
• Hierarchy Configuration - Customize structure (Admin)