Requirements Lifecycle

Every requirement in NirmIQ follows a structured lifecycle from initial creation through verification. This lifecycle provides audit traceability, ensures quality gates are respected, and connects requirements to the implementation workflow.

Lifecycle States

NirmIQ implements an industry-standard lifecycle based on ISO/IEC/IEEE 29148 and INCOSE best practices.

                     REQUIREMENT LIFECYCLE

    ┌────────┐    ┌───────────┐    ┌──────────┐    ┌──────────┐
    │ Draft  │───→│ In Review │───→│ Approved │───→│ Accepted │
    └────────┘    └───────────┘    └──────────┘    └──────────┘
         │              │                                │
         │              │                                ▼
         │              │                         ┌─────────────┐
         │              │                         │ Implemented │
         │              │                         └─────────────┘
         │              │                                │
         │              │                                ▼
         │              │                         ┌──────────┐
         │              │                         │ Verified │
         │              │                         └──────────┘
         │              │
         ▼              ▼
    ┌──────────┐  ┌──────────┐  ┌────────────┐
    │ Rejected │  │ Deferred │  │ Deprecated │
    └──────────┘  └──────────┘  └────────────┘

State Descriptions

Status	Meaning	Color	Who Transitions
Draft	Newly created, not yet reviewed	Gray	Anyone (entry state)
In Review	Under team review for technical soundness	Blue	Author submits
Approved	Technically sound, agreed upon by reviewers	Purple	Reviewer/Lead approves
Accepted	Ready for implementation — triggers work items	Green	PM/Stakeholder accepts
Implemented	Code written and merged	Green	Developer marks complete
Verified	Tests pass, requirement confirmed satisfied	Green	QA/Tester verifies
Rejected	Not valid, will not be implemented	Red	Anyone with authority
Deferred	Valid requirement, but not for this cycle	Orange	PM defers
Deprecated	Was valid, no longer applies (superseded)	Red	Lead deprecates

State Transitions

Not every transition is valid. NirmIQ enforces a state machine:

From	Allowed Transitions
Draft	In Review, Rejected, Deferred
In Review	Approved, Rejected, Deferred, Draft (return for rework)
Approved	Accepted, Rejected, Deferred, In Review (re-review)
Accepted	Implemented, Deferred
Implemented	Verified, Accepted (rework needed)
Verified	Deprecated (if superseded later)
Rejected	Draft (if reconsidered)
Deferred	Draft (if brought back into scope)
Deprecated	(terminal state)

Why "Approved" AND "Accepted"?

Approved means technically correct — the requirement is well-written, testable, and makes sense. Accepted means committed to implementation — the team has decided to build it NOW. A requirement can be Approved but Deferred (technically valid, but not this release). The distinction matters for planning and audit.

The Critical Gate: Accepted

"Accepted" is the trigger for implementation. When a requirement reaches Accepted status:

Audit Trail: The system records WHO accepted it, WHEN, and any rationale provided
Work Item Created: A work item is automatically created in NirmIQ to track implementation
External Sync: If Jira, Azure DevOps, or GitHub Issues are connected, the work item is optionally pushed there
Dashboard Updates: The project health score and progress metrics update

This is a deliberate gate — not every Approved requirement needs immediate implementation. The Accepted transition is a conscious commitment.

Acceptance Audit Record

Every status transition is recorded, but Accepted transitions capture additional detail:

User: Who accepted the requirement (user ID and name)
Timestamp: Exact time of acceptance
Rationale: Optional note explaining why this is being committed to
Version: The requirement version at time of acceptance

This audit trail is essential for compliance frameworks (ISO 26262, DO-178C, IEC 62304) where evidence of deliberate review and acceptance is required.

Requirement Sources

Requirements enter NirmIQ through multiple paths. Each requirement tracks its origin for traceability:

Source	Description	Typical Entry Status
Manual	User creates directly in NirmIQ	Draft
Code Intelligence	AI generates from codebase scan	Draft (from finalization)
Knowledge Base	AI suggests from lessons learned/standards	Draft (from finalization)
FMEA-Derived	Risk analysis reveals missing requirement	Draft
Jira Import	Pulled from Jira issues	Draft
File Import	CSV, ReqIF, or Excel upload	Draft
Template	From industry or sample template	Draft
AI Analysis	AI suggests improvements to existing requirements	Draft

Source Traceability

The requirement's source is permanently recorded and visible in the Details panel. For Code Intelligence and Knowledge Base sources, the system also tracks:

Source file: Which code file generated the requirement
Source document: Which knowledge base entry influenced the suggestion
Confidence score: AI's confidence in the suggestion (0-100%)
AI model: Which AI provider was used

This traceability is critical for the Knowledge Base Flywheel — the system tracks which knowledge base documents led to which requirements, allowing teams to measure the value of their documented lessons.

The Implementation Pipeline

Once a requirement is Accepted, NirmIQ creates a work item and the implementation pipeline begins:

Requirement reaches "Accepted"
    │
    ├── AUDIT: Record who accepted, when, rationale
    │
    ├── AUTO: Create Work Item in NirmIQ
    │         status: 'todo'
    │         source: inherited from requirement source
    │         priority: inherited from requirement priority
    │
    ├── OPTIONAL: Push to external tool (user configures)
    │   ├── Jira → Create issue with [REQ-ID] prefix
    │   ├── Azure DevOps → Create work item
    │   ├── GitHub Issues → Create issue with labels
    │   └── Store external ID for bidirectional sync
    │
    ▼
Developer implements (using any tool)
    │
    ├── NirmIQ work item tracks progress
    │   todo → in_progress → in_review → done
    │
    ├── Requirement status advances
    │   Accepted → Implemented (when work item moves to in_review)
    │   Implemented → Verified (when linked tests pass)
    │
    ▼
Verification
    │
    ├── Test cases linked to the requirement are executed
    ├── Code Intelligence re-scan detects drift
    ├── Requirement marked Verified when all evidence complete
    │
    ▼
Learn (if issues found)
    │
    ├── Add Lesson Learned to Knowledge Base
    ├── Next AI scan incorporates the lesson
    └── Flywheel continues

Two Paths: Internal vs External Implementation

Path A: Track in NirmIQ Only

The work item lives in NirmIQ. The developer uses any tool to write code (Claude, Copilot, Cursor, VS Code, etc.) and updates the work item status manually or through Code Intelligence re-scans.

Path B: Push to External Tool + Track in NirmIQ

NirmIQ always creates its own work item (for health scores and traceability), AND pushes to the team's project management tool. Status syncs bidirectionally:

Jira issue moves to "In Progress" → NirmIQ work item updates
NirmIQ work item marked "Done" → Jira issue transitions to "Done"
External assignee changes sync back to NirmIQ

Lifecycle in the Graph View

The Graph tab in the requirements detail panel visualizes requirements with color-coded status indicators:

Color	Statuses
Gray	Draft, In Review
Purple	Approved
Green	Accepted, Implemented, Verified
Red	Rejected, Deprecated
Orange	Deferred

This makes it easy to see at a glance which requirements are committed, which are in progress, and which have been deferred or rejected.

Best Practices

1. Don't Skip Gates

Resist the temptation to move requirements directly from Draft to Accepted. The review gates exist to catch issues early:

In Review forces a second pair of eyes
Approved confirms technical soundness
Accepted confirms business commitment

2. Always Provide Rationale on Acceptance

When accepting a requirement, add a note explaining the context:

✅ Good: "Accepted for Sprint 14. Critical for SOC2 compliance deadline March 1."
✅ Good: "Accepted per design review 2024-02-15. All stakeholders agreed."
❌ Bad: "" (empty — no context for audit)

3. Use Deferred, Not Rejected, for "Not Now"

Rejected means the requirement is invalid or wrong. Deferred means it's valid but not prioritized for this cycle. The distinction matters when revisiting scope later.

4. Link Tests Before Marking Verified

A requirement should only reach Verified when there is objective evidence:

Linked test cases that pass
Code Intelligence re-scan shows no drift
Review by someone other than the implementer

5. Track Source for AI-Generated Requirements

When AI generates requirements (from Code Intelligence or Knowledge Base), the source traceability helps the team:

Distinguish AI suggestions from manually-written requirements
Evaluate AI quality over time (acceptance rate)
Trace back to the code file or lesson that spawned the requirement
Measure knowledge base ROI (which lessons generate the most accepted requirements)

What's Next?

Creating Requirements - Add new requirements
Editing Requirements - Update status and fields
Graph View - Visual status overview
Work Items - Track implementation progress

Lifecycle States​

State Descriptions​

State Transitions​

The Critical Gate: Accepted​

Acceptance Audit Record​

Requirement Sources​

Source Traceability​

The Implementation Pipeline​

Two Paths: Internal vs External Implementation​

Lifecycle in the Graph View​

Best Practices​

1. Don't Skip Gates​

2. Always Provide Rationale on Acceptance​

3. Use Deferred, Not Rejected, for "Not Now"​

4. Link Tests Before Marking Verified​

5. Track Source for AI-Generated Requirements​

What's Next?​