Smart Import (No AI)

Import requirements from Word documents using intelligent pattern matching - no AI credits required.

Free & Unlimited

Smart Import uses pattern detection, not AI. It's free on all tiers with unlimited imports.

Overview

Smart Import extracts requirements from Word documents by detecting:

• Keywords: shall, must, will, should, may
• Requirement IDs: REQ-001, SYS-001, 1.2.3, [REQ-001]
• Document structure: Headings, bullets, numbered lists
• Sentence patterns: Subject-verb-object structures

Unlike AI Import, Smart Import doesn't interpret meaning - it finds text that looks like requirements based on established patterns.

---

When to Use Smart Import

Smart Import is Best For:

• Documents with clear "shall" statements
• Requirements already numbered (REQ-001, etc.)
• Structured documents with headings and lists
• When you want zero AI credits used
• Quick imports of well-formatted documents

Use AI Import Instead When:

• Requirements are in narrative prose
• Document lacks clear structure
• You need intelligent hierarchy detection
• Requirements are ambiguous or mixed with other content

---

How It Works

Pattern Detection

Smart Import scans your document for these patterns:

1. Requirement Keywords

Keyword	Detection	Priority
shall	"The system shall provide..."	High confidence
must	"Users must authenticate..."	High confidence
will	"The software will support..."	Medium confidence
should	"The interface should display..."	Medium confidence
may	"The system may optionally..."	Lower confidence

2. Requirement ID Patterns

Automatically detected ID formats:

REQ-001         Standard format
SYS-001         Hierarchical prefix
FUNC-0001       Extended format
1.2.3           Numeric hierarchy
[REQ-001]       Bracketed format
Requirement REQ-001:   Labeled format

3. Document Structure

Smart Import uses document structure to determine hierarchy:

Structure	Interpretation
Heading 1	Level 1 (System)
Heading 2	Level 2 (Subsystem)
Heading 3	Level 3 (Component)
Bullet list	Same level as parent
Numbered list	Sequential requirements

4. Type Classification

Requirements are classified by keyword detection:

Type	Keywords Detected
Functional	perform, execute, process, calculate, display
Performance	speed, latency, throughput, accuracy, capacity
Interface	API, protocol, format, communicate, integrate
Safety	safe, hazard, fail-safe, emergency, protect
Security	authenticate, authorize, encrypt, access control
Reliability	MTBF, availability, fault tolerance, redundancy
Constraint	maximum, minimum, within, not exceed

---

How to Import

Step 1: Access Smart Import

1. Open your project
2. Click Import Requirements button
3. In the modal, find the Smart Word section (green icon)

Step 2: Upload Document

1. Click Choose File in the Smart Word section
2. Select your Word document (.docx)
3. NirmIQ parses the document and shows a review screen

Step 3: Review (Dedup Preview)

The preview shows every requirement that will be created, classified against your existing project content:

• New — no similar text already exists in the project
• Near duplicate — text is ≥70% similar to an existing requirement
• Duplicate — text is ≥90% similar (probably the same requirement)

For each row you can choose Create or Skip before applying.

Step 4: Apply

Click Apply in the review modal. The import then:

• Reserves the next available top-level custom_id (e.g. CR017 if the project already has CR001…CR016)
• Creates one new top-level requirement named Imported from <your-filename>.docx with that ID
• Places every imported requirement under this new doc-root parent
• Preserves the Word document's internal section structure beneath the doc-root

The workspace re-renders with the new doc-root visible at the top of the tree, expandable to show every imported requirement.

---

How Imported Requirements Are Organized

Smart Import never interleaves new requirements with your existing ones. Everything from a given import lives under a single doc-root parent, named after the source file.

Numbering Rule

Imported requirements use the doc-root's custom_id as a prefix, then a bare-number Word section path:

Word document section	Imported custom_id (with doc-root = CR017)
1 (top-level section)	CR017.1
1.1 (subsection)	CR017.1.1
1.2	CR017.1.2
1.1.2.3 (deeply nested)	CR017.1.1.2.3

Bare numbers under the prefix make the Word path readable at a glance. The doc-root itself keeps the project's full canonical form (e.g. CR017, with the project's level-1 abbreviation).

Why a Doc-Root?

Before this design, imports were "intelligently embedded" into existing requirements based on text matching. This produced trees where imported and existing reqs sat side-by-side at the root, with no visible "this came from doc X" boundary. Users couldn't tell what was new, and remapping a whole imported batch was painful.

The doc-root pattern provides:

• Visible boundary: At a glance, you see "Imported from spec_v3.docx" and know what's inside.
• Atomic remap: Want to move the whole import under a different parent? Move the doc-root — its descendants follow automatically via NirmIQ's subtree-aware remap.
• Atomic delete: Want to discard a bad import? Delete the doc-root; cascading delete removes every child requirement.
• Source attribution: The doc-root's text and every descendant's Source strip show the original filename, so even months later you can tell where a requirement came from.

Source Metadata Strip

After import, click any imported requirement. The detail panel shows an amber Source strip with:

• File: the original filename (e.g. spec_v3.docx)
• §: the section number from the source document (e.g. 1.5.1.3)
• Source ID: an external identifier the source assigned (e.g. ReqIF SPEC-OBJECT IDENTIFIER, Word [REQ-001] prefix) if present

This metadata is preserved across remaps, edits, and exports. It can't be edited from the UI (provenance is meant to be stable). If you delete an imported requirement and reimport, you'll get the same source values.

---

Reorganizing Imported Requirements

After import you'll likely want to move parts of the imported subtree into your existing project structure. The standard remap works for this:

1. Click the imported requirement you want to move (e.g. CR017.2)
2. Open the remap dialog
3. Pick the new parent (e.g. an existing CR012.SYS005)
4. Confirm

The selected requirement and all its descendants move together. Custom_ids are recalculated in your project's canonical format (e.g. CR017.2.1.1 becomes CR012.SYS005.SUB003.FUN001.SFUN001). Simple-FMEA links pointing at the moved reqs are auto-updated.

See Editing Requirements for details on the remap dialog.

---

Document Preparation Tips

For Best Results

Use clear "shall" statements:

The system shall authenticate users within 2 seconds.
The system shall encrypt all data at rest.
The system shall log all failed login attempts.

Include requirement IDs:

REQ-001: The system shall authenticate users within 2 seconds.
REQ-002: The system shall encrypt all data at rest.
REQ-003: The system shall log all failed login attempts.

Use Word heading styles:

[Heading 1] System Requirements
[Heading 2] Authentication
  REQ-001: The system shall authenticate users...
  REQ-002: The system shall support SSO...
[Heading 2] Data Security
  REQ-003: The system shall encrypt data...

What to Avoid

Mixed content (requirements + prose):

The team discussed requirements for the new system. It was decided that
the system shall authenticate users. This is important for security.

Smart Import may extract the prose as requirements.

Missing keywords:

User authentication within 2 seconds.
Data encryption at rest.
Logging of failed attempts.

Without "shall/must/will", these may not be detected.

Inconsistent numbering:

REQ-001: First requirement
REQ1: Second requirement
Req-002: Third requirement

Inconsistent formats may cause detection issues.

---

Example Import

Source Document

Product Requirements Document

1. System Requirements
   1.1 Authentication
      REQ-001: The system shall authenticate users using username and password.
      REQ-002: The system shall support multi-factor authentication.
      REQ-003: Authentication shall complete within 2 seconds.

   1.2 Data Management
      REQ-004: The system shall encrypt all data at rest using AES-256.
      REQ-005: The system shall backup data daily.

Smart Import Results

Assuming the project's existing top-level reqs are CR001…CR016, the importer reserves CR017 as the doc-root and places everything under it:

Requirements Created: 6 (1 doc-root + 5 imported)

CR017: Imported from product_requirements.docx
  └── CR017.1: The system shall authenticate users using username and password.
        Source: § 1.1
        Type: Security
  └── CR017.1.1: The system shall support multi-factor authentication.
        Source: § 1.1.1
        Type: Security
  └── CR017.1.2: Authentication shall complete within 2 seconds.
        Source: § 1.1.2
        Type: Performance
  └── CR017.2: The system shall encrypt all data at rest using AES-256.
        Source: § 1.2
        Type: Security
  └── CR017.2.1: The system shall backup data daily.
        Source: § 1.2.1
        Type: Functional

Each imported requirement carries the source filename (product_requirements.docx) and the original section number, both visible in the detail panel's Source strip.

---

Comparison: Smart Import vs AI Import

Feature	Smart Import	AI Import
Processing	Pattern matching	AI/LLM analysis
Cost	Free, unlimited	Uses AI credits
Speed	Instant	1-3 minutes
Accuracy	Depends on document format	Adapts to any format
Hierarchy Detection	Based on headings/structure	Semantic understanding
Type Classification	Keyword-based	Context-aware
Methodology Support	No	Yes
Best For	Well-formatted docs	Unstructured docs
Tier Required	All tiers	Advanced+

Choose Smart Import When:

• Document is already well-structured
• Requirements use "shall" consistently
• IDs are already assigned
• You want to save AI credits
• Quick import is priority

Choose AI Import When:

• Document is unstructured narrative
• Requirements need interpretation
• Hierarchy needs to be inferred
• You want AI to apply best practices
• Accuracy is more important than speed

---

Troubleshooting

No Requirements Detected

Causes:

• Document lacks "shall/must/will" keywords
• Text is in images or tables (not parsed)
• File format issues

Solutions:

• Add "shall" statements to requirements
• Extract text from tables before import
• Save document as .docx format
• Use AI Import for unstructured documents

Wrong Hierarchy Levels

Causes:

• Document doesn't use Word heading styles
• Inconsistent structure

Solutions:

• Apply Heading 1/2/3 styles in Word
• Manually adjust hierarchy after import
• Use consistent section numbering

Missing Requirements

Causes:

• Requirement text lacks keywords
• Confidence score too low

Solutions:

• Add "shall" to requirement statements
• Use AI Import for better detection
• Manually add missing requirements

Wrong Type Classification

Causes:

• Keyword detection isn't perfect
• Requirement text is ambiguous

Solutions:

• Edit type after import
• Add type-specific keywords to text
• Use AI Import with methodology document

---

API Endpoint

For programmatic access:

Import:

POST /projects/{project_id}/import-document-smart
Content-Type: multipart/form-data

requirements_doc: [Word file]

Preview (without saving):

POST /projects/{project_id}/preview-smart-import
Content-Type: multipart/form-data

requirements_doc: [Word file]

Response:

{
  "status": "success",
  "message": "Successfully imported 25 requirements",
  "requirements_created": 25,
  "metadata": {
    "total_extracted": 25,
    "document_sections": 4,
    "types_found": ["Functional", "Performance", "Security"],
    "hierarchy_levels_used": 3,
    "extraction_method": "smart_pattern_matching"
  }
}

---

Related Topics

• AI Import - AI-powered document import
• Best Practices - INCOSE 42 rules for requirements
• Export & Import - All import methods compared
• Creating Requirements - Manual creation

---

Need Help?

• Contact Support
• Video Tutorials
• GitHub Issues