Skip to main content

Parent Relationships & Traceability

NirmIQ supports many-to-many parent relationships, allowing requirements to have multiple parents with different relationship types for comprehensive traceability.

Understanding Relationship Types​

Unlike traditional hierarchies where a requirement has exactly one parent, NirmIQ allows multiple parents with semantic relationship types.

Relationship Types​

TypeDescriptionUse Case
derives_fromStandard parent-child hierarchySystem requirement derives from customer request
refinesAdds detail to parent requirementDetailed spec refines high-level requirement
implementsImplementation of parentSoftware component implements function requirement
verifiesVerification of parentTest requirement verifies functional requirement
traces_toGeneral traceability linkRequirement traces to external standard/regulation
depends_onDependency relationshipFeature depends on infrastructure requirement
conflicts_withConflict detectionSafety requirement conflicts with performance goal

Why Multiple Parents?​

Real-world requirements often have multiple relationships:

Example: Autopilot Feature

US-042: Autopilot Lane Keeping
├── derives_from: CR-001 (Customer Request for autonomous features)
├── implements: SYS-015 (System Requirement for safety systems)
├── depends_on: SUB-008 (Camera subsystem must exist first)
└── traces_to: ISO-26262 (Automotive safety standard compliance)

This provides:

  • ✅ Complete traceability - See all relationships at once
  • ✅ Impact analysis - Know what's affected by changes
  • ✅ Compliance tracking - Link requirements to standards
  • ✅ Dependency management - Identify prerequisite requirements

Adding Parent Relationships​

From Details Tab​

  1. Select Requirement

    • Click requirement in tree view
    • Click "Details" tab in right panel

  2. Add Parent

    • Scroll to "Parent Requirements" section
    • Click "+ Add Parent" button

  3. Configure Relationship

    • Parent Requirement: Select from dropdown (all requirements shown except self)
    • Relationship Type: Choose semantic relationship (see types above)
    • Link Rationale (Optional): Explain why this relationship exists

  4. Save

    • Click "Add Parent"
    • New parent appears in list immediately

Choosing Relationship Type​

Guidelines:

  • derives_from: Use for standard hierarchical decomposition (most common)
  • refines: When adding specificity without changing hierarchy
  • implements: Software/hardware implementing functional requirements
  • verifies: Test cases, acceptance criteria, validation requirements
  • traces_to: External standards, regulations, stakeholder needs
  • depends_on: Technical dependencies, prerequisite features
  • conflicts_with: Trade-offs, mutually exclusive requirements

Example Choices:

FUN-012: "Engine shall generate 300 HP at 6000 RPM"
├── derives_from: SYS-003 (Powertrain System Requirement)
└── traces_to: EPA-2024 (Emissions regulation)

TEST-001: "Verify engine power output"
├── verifies: FUN-012 (Functional requirement being tested)
└── implements: V&V-PLAN-001 (Test plan requirement)

While optional, adding rationale helps with:

  • Traceability audits (ISO 26262, DO-178C, IEC 62304)
  • Onboarding new team members
  • Understanding design decisions months/years later

Good Rationale Examples:

✅ "Needed to satisfy NHTSA FMVSS 208 crash safety standard"
✅ "Depends on camera subsystem for image processing pipeline"
✅ "Implements acceptance criteria from customer contract §3.2"
✅ "Conflicts with cost reduction goal - safety takes precedence"

❌ Bad: "related"
❌ Bad: "needed"
❌ Bad: "because"

Viewing Parent Relationships​

In Details Tab​

When you select a requirement, the Parent Requirements section shows:

Each parent displays:

  • Custom ID (e.g., CR-001.SYS-003)
  • Relationship Type (badge showing derives_from, refines, etc.)
  • Requirement Text (first line preview)
  • Type (CR, SYS, SUB, etc.)
  • Link Rationale (if provided)
  • Remove button (delete this relationship)

Example:

Parent Requirements
┌──────────────────────────────────────────────────┐
│ CR-001.SYS-003        [derives_from]             │
│ Powertrain shall provide propulsion              │
│ Type: System Requirement                         │
│ Rationale: Standard hierarchy decomposition      │
│                                        [Remove]   │
├──────────────────────────────────────────────────┤
│ STD-ISO-26262        [traces_to]                 │
│ ISO 26262 Functional Safety Standard             │
│ Type: Standard Reference                         │
│ Rationale: Required for automotive safety cert   │
│                                        [Remove]   │
└──────────────────────────────────────────────────┘

In Traceability Reports (Coming Soon)​

Future features:

  • Traceability matrix showing all relationships
  • Relationship graph visualization
  • Orphan detection (requirements with no parents)
  • Coverage reports (% requirements traced to standards)

Removing Parent Relationships​

How to Remove​

  1. Select Requirement - Click in tree view
  2. Go to Details Tab - View parent list
  3. Find Parent - Locate relationship to remove
  4. Click Remove - Confirms and deletes immediately
  5. Confirmation - Relationship removed, parent requirement unchanged

What Gets Removed​

✅ Removed:

  • The specific parent relationship
  • Link rationale (if any)

✅ Preserved:

  • Parent requirement (unaffected)
  • Child requirement (unaffected)
  • Other parent relationships (if any)
  • FMEA traceability links
One-Way Deletion

Removing a parent relationship only removes the link. Neither the parent nor child requirement is deleted.

Traditional vs. Many-to-Many​

Traditional Hierarchy (One Parent Only)​

Old Behavior:

CR-001: Vehicle Requirements
└── SYS-001: Powertrain System
    └── SUB-001: Engine Subsystem
        └── FUN-001: Combustion Function

Limitation: Can't show that FUN-001 also:

  • Implements EPA emissions standard
  • Depends on fuel injection subsystem
  • Verifies performance requirement

Many-to-Many (Multiple Parents)​

New Behavior:

FUN-001: Combustion Function
├── derives_from: SUB-001 (Engine Subsystem) [hierarchy]
├── traces_to: EPA-2024 (Emissions Standard) [compliance]
├── depends_on: SUB-002 (Fuel Injection) [dependency]
└── verifies: PERF-001 (Performance Goal) [validation]

Benefit: Complete traceability without losing hierarchy

Hierarchy Tree Still Works​

The List tab tree view shows traditional hierarchy (using derives_from relationships).

Why? Visual clarity - one tree is easier to navigate than a complex graph.

Other relationships are visible in:

  • Details tab (full parent list)
  • Traceability reports (coming soon)
  • FMEA links (already implemented)

Practical Examples​

Example 1: Automotive Safety Feature​

Requirement: Automatic Emergency Braking (AEB)

US-042: Lane Keeping Assist shall prevent unintended lane departure
├── derives_from: CR-001.FEAT-003 (Autonomous Features)
   Rationale: "Part of Level 2 autonomy feature set"

├── implements: SYS-015 (Safety System Architecture)
   Rationale: "Implements ASIL-D safety requirement per ISO 26262"

├── depends_on: SUB-008.CAM-001 (Front Camera Subsystem)
   Rationale: "Requires camera images for lane detection"

├── depends_on: SUB-009.PROC-001 (Image Processing Unit)
   Rationale: "Requires IPU for real-time lane line detection"

└── traces_to: ISO-26262-ASIL-D (Functional Safety Standard)
   Rationale: "Required for automotive safety certification"

Example 2: Medical Device Compliance​

Requirement: Insulin Dosage Calculation

FUN-023: Insulin pump shall calculate bolus dose based on blood glucose
├── derives_from: SYS-007 (Therapy Delivery System)
   Rationale: "Core therapeutic function"

├── refines: CR-002 (Customer need for automated dosing)
   Rationale: "Adds technical specification to user need"

├── traces_to: IEC-62304-Class-C (Medical Device Software Standard)
   Rationale: "Class C software - highest risk classification"

├── traces_to: FDA-510k-K123456 (Regulatory Approval)
   Rationale: "Predicate device comparison requirement"

└── verifies: RISK-045 (Mitigate overdose risk)
   Rationale: "Primary control for identified hazard RISK-045"

Example 3: Software Testing Hierarchy​

Requirement: Unit Test for Login Function

TEST-089: Unit test for login authentication
├── verifies: FUN-034 (User authentication function)
   Rationale: "Tests implementation of login logic"

├── implements: V&V-PLAN-001.UT (Unit Test Plan Section 4.2)
   Rationale: "Satisfies test plan requirement for auth coverage"

├── depends_on: TEST-INFRA-001 (Test automation framework)
   Rationale: "Requires pytest framework to execute"

└── traces_to: SECURITY-REQ-008 (Password security requirement)
   Rationale: "Validates compliance with security requirement"

Impact Analysis (Coming Soon)​

Future Capabilities​

Change Impact Tracking:

  • See all requirements affected by a change
  • Identify downstream dependencies
  • Flag test cases needing re-execution
  • Alert to compliance requirements

Example:

Changing: SUB-008.CAM-001 (Camera resolution from 720p to 1080p)

Impacts:
✓ 3 requirements derive_from this subsystem
✓ 12 requirements depend_on camera subsystem
⚠ 5 test cases need re-verification
⚠ 2 FMEA analyses may need update

Best Practices​

When to Use Each Relationship Type​

derives_from (Most Common):

  • ✅ Standard parent-child hierarchy decomposition
  • ✅ Breaking down high-level into lower-level requirements
  • ✅ Use for tree structure in List tab

refines:

  • ✅ Adding specificity without creating new hierarchy level
  • ✅ Multiple detailed requirements refining one high-level requirement
  • ✅ Acceptance criteria refining user stories (Agile)

implements:

  • ✅ Software/hardware implementing functional requirements
  • ✅ Design decisions implementing architectural requirements
  • ✅ Test cases implementing test plan sections

verifies:

  • ✅ Test requirements verifying functional requirements
  • ✅ Acceptance criteria verifying user stories
  • ✅ Validation requirements verifying customer needs

traces_to:

  • ✅ External standards and regulations
  • ✅ Stakeholder needs from contracts
  • ✅ Industry best practices
  • ✅ Legal requirements

depends_on:

  • ✅ Technical dependencies (must implement X before Y)
  • ✅ Infrastructure requirements
  • ✅ Third-party integrations
  • ✅ Prerequisite features

conflicts_with:

  • ✅ Trade-offs between requirements
  • ✅ Mutually exclusive features
  • ✅ Design decisions requiring resolution
  • ✅ Budget/schedule conflicts

Organizing Relationships​

  1. Start with derives_from - Build hierarchy first
  2. Add verification - Link test cases to requirements
  3. Add compliance - Trace to standards/regulations
  4. Document dependencies - Capture technical dependencies
  5. Note conflicts - Flag trade-offs for resolution

Traceability for Compliance​

For regulated industries (automotive, aerospace, medical):

✅ Do:

  • Use traces_to for ALL applicable standards
  • Add detailed link rationale (auditors will ask)
  • Link requirements to specific standard clauses (e.g., "ISO 26262 Part 6 Section 8.4.2")
  • Verify bidirectional traceability (requirement ↔ standard)

❌ Don't:

  • Skip rationale ("It's obvious" won't pass audit)
  • Use vague references ("Complies with safety standards")
  • Forget to trace test requirements to standards
  • Mix different relationship types (use correct semantics)

Limitations & Workarounds​

Current Limitations​

No Circular Reference Detection:

  • System allows creating circular relationships
  • Workaround: Manually verify no cycles (A → B → C → A)
  • Coming soon: Automatic cycle detection

No Relationship Versioning:

  • Can't see history of relationship changes
  • Workaround: Use link rationale to note date added
  • Coming soon: Full relationship audit trail

No Bulk Operations:

  • Must add parents one at a time
  • Workaround: Use API for bulk operations (developers)
  • Coming soon: Multi-select and bulk add

Future Enhancements​

  • 📊 Traceability matrix visualization
  • 🔍 Advanced search by relationship type
  • 📈 Coverage reports (% requirements traced)
  • 🔄 Relationship change history
  • 🚨 Orphan detection alerts
  • 🎯 Impact analysis dashboard
  • 📤 Export relationship graph (GraphML, DOT)

What's Next?​