Skip to main content

Managing Hierarchy

Learn how to navigate, organize, and work with the requirements hierarchy tree.

Understanding the Tree View​

The hierarchical tree shows all requirements with visual indentation based on hierarchy level, not just parent depth.

Tree Structure​

CR-001: Vehicle Requirements
  SYS-001: Powertrain System
    SUB-001: Engine Subsystem
      FUN-001: Combustion Function
        SFUN-001: Fuel Injection
          L6-001: Injector Timing
        SFUN-002: Ignition Control
      FUN-002: Cooling Function
    SUB-002: Transmission Subsystem
  SYS-002: Safety System
CR-002: Software Requirements

Indentation Rules​

Indentation is based on hierarchy level, ensuring consistent visual structure:

  • Customer Request (Level 1): 12px indent
  • System (Level 2): 36px indent
  • Subsystem (Level 3): 60px indent
  • Function (Level 4): 84px indent
  • Subfunction (Level 5): 108px indent
  • Detailed (Level 6): 132px indent
Why Level-Based Indentation?

Even if two requirements share the same parent, they indent differently based on their hierarchy level. This makes it clear that a Detailed Requirement (L6) is lower-level than a Subfunction, even under the same Function parent.

Expanding and Collapsing​

Expand Node: Click ▶ icon to show children

Collapse Node: Click ▼ icon to hide children

Expand All (Coming Soon): Show entire tree

Collapse All (Coming Soon): Hide all children

Selecting Requirements​

Click any requirement to:

  • View details in detail panel
  • Edit fields
  • See parent and children
  • Access delete option
  • Create child requirement

Tree Sorting​

Requirements are sorted numerically by custom ID:

CR-001
CR-002
CR-003
  CR-003.SYS-001
  CR-003.SYS-002
    CR-003.SYS-002.SUB-001
    CR-003.SYS-002.SUB-002
  CR-003.SYS-003

Children under each parent also sort numerically.

Working with Parents and Children​

Viewing Relationships​

When you select a requirement, the detail panel shows:

Parent Information:

  • Parent custom ID (if applicable)
  • Link to navigate to parent

Children List:

  • All direct children
  • Count of children
  • Links to navigate to each child

Creating Child Requirements​

Two ways to create children:

Method 1: From Parent​

  1. Click parent requirement in tree
  2. Click "New Requirement"
  3. Parent is pre-selected
  4. Choose child type
  5. Fill in details and save

Method 2: From New Button​

  1. Click "New Requirement" at top
  2. Manually select parent from dropdown
  3. Choose type
  4. Fill in details and save

Orphaning Requirements​

You can move any requirement to root level:

  1. Edit requirement
  2. Set parent to "Root"
  3. Save

The requirement becomes a top-level item (numbering updates).

Reorganizing Requirements​

Moving Requirements​

To move a requirement to a different parent:

  1. Select Requirement

    • Click requirement in tree
    • Click "Edit"

  2. Choose New Parent

    • Select from parent dropdown
    • Or choose "Root" for top-level

  3. Verify Type Compatibility

    • System enforces hierarchy rules
    • Invalid parents won't appear in dropdown

  4. Save

    • Click "Save"
    • Tree updates immediately
    • Custom IDs regenerate

Impact of Moving​

When you move a requirement:

✅ Updates:

  • Custom ID regenerates based on new parent
  • All descendants update recursively
  • Tree position changes
  • Numbering recalculates

⚠️ Considerations:

  • External references to old custom ID will break
  • Traceability to FMEA preserved (by internal ID)
  • Audit trail preserved

Example:

Before move:
CR-001.SYS-001.SUB-001.FUN-001
  ├── CR-001.SYS-001.SUB-001.FUN-001.SFUN-001
  └── CR-001.SYS-001.SUB-001.FUN-001.SFUN-002

Move FUN-001 to CR-002.SYS-003:

After move:
CR-002.SYS-003.FUN-001
  ├── CR-002.SYS-003.FUN-001.SFUN-001
  └── CR-002.SYS-003.FUN-001.SFUN-002

Deleting Requirements​

Delete Single Requirement​

  1. Select Requirement

    • Click requirement in tree
    • Click "Delete" button

  2. Confirm Deletion

    • Modal asks for confirmation
    • Shows children count (if any)

  3. Deletion Behavior

    • Requirement is deleted
    • Children become orphaned (moved to parent)
Cascade Deletion

If you want to delete requirement AND all its descendants, you must delete children first, working from bottom to top.

What Gets Deleted​

❌ Permanently Removed:

  • Requirement data
  • Custom ID (won't be reused)
  • Field values

✅ Preserved:

  • Children (orphaned to parent)
  • FMEA links (updated to show broken reference)
  • Audit logs

Recovering Deleted Requirements​

Currently, deletion is permanent with no undo.

Coming soon:

  • Soft delete with trash bin
  • Version history
  • Restore capability

Search and Filters​

Current Capabilities​

Basic tree navigation only:

  • Scroll to browse
  • Expand/collapse nodes
  • Click to select

Coming Soon​

  • 🔍 Search: Find by custom ID, title, description
  • 🏷️ Filter by Type: Show only specific types
  • 👤 Filter by Owner: See your requirements
  • 📊 Filter by Status: Draft, Approved, etc.
  • ⭐ Filter by Priority: High, Medium, Low
  • 🌳 Filter by Branch: Show only subtree

Keyboard Shortcuts​

Currently not supported. Coming soon:

  • ↑ / ↓: Navigate up/down
  • ← / →: Collapse/expand
  • Enter: View details
  • N: New requirement
  • E: Edit selected
  • Delete: Delete selected

Best Practices​

Organizing Large Trees​

  1. Use Meaningful Titles: Easy to scan tree
  2. Consistent Granularity: Similar detail at each level
  3. Logical Grouping: Related items under same parent
  4. Collapse Branches: Hide irrelevant sections
  5. Name Patterns: Use prefixes for easy grouping

Maintaining Structure​

  1. Plan Hierarchy: Design before creating
  2. Start Top-Down: Create parents first
  3. Review Regularly: Ensure structure makes sense
  4. Refactor Early: Reorganize before too many dependencies
  5. Document Decisions: Note why requirements are grouped

Performance Tips​

For projects with 1000+ requirements:

  1. Keep Most Nodes Collapsed: Expand only what you're working on
  2. Use Search: Don't scroll through entire tree (coming soon)
  3. Create Subprojects: Split very large projects
  4. Archive Old Versions: Don't keep all historical projects active

Migration Tool​

If your organization changes hierarchy configuration, you'll need to migrate existing projects.

See: Hierarchy Migration Guide (Admin only)

What's Next?​