Overview

The multi-level requirement decomposition feature is a core tool for connecting strategic goals with execution. It supports progressive decomposition from Business Requirements to User Requirements and then to Development Requirements, while also allowing each level to be refined horizontally and extended vertically. This helps build a complete path from strategy to value to implementation.

This feature helps teams establish a clear requirement structure, reducing problems such as unclear goals, fragmented requirements, inconsistent granularity, and disconnects between upstream and downstream work. It improves cross-functional collaboration and makes product planning more systematic, helping teams maintain a unified development direction and a clear execution path for high-quality, goal-driven delivery.

Use Cases

• Ensure strategic goals are translated clearly into execution: When teams work with abstract goals such as increasing engagement or improving user retention, execution can easily drift without a structured decomposition method. Multi-level decomposition helps teams break Business Requirements down into User Requirements and Development Requirements, creating a clear path from strategy to implementation.
• Reduce misunderstandings in requirement interpretation: In multi-role collaboration, differences in how requirements are understood often lead to high communication costs and execution errors. A unified requirement hierarchy allows each team to focus on the level they know best while still working toward the same overall objective.
• Manage complex requirements structurally to reduce omissions and rework: In complex projects, a flat requirement structure often leads to missing details and unnecessary rework. Multi-level decomposition organizes requirements into a structured tree, helping teams analyze scope more completely and estimate work more accurately.
• Identify the impact of requirement changes more precisely: When a requirement changes, it is critical to understand how upstream and downstream items are affected. A hierarchical structure helps teams trace related requirements quickly, assess impact more accurately, and control change risk more effectively.

I. Product

A Business Requirements level is added under Product, allowing you to decompose Requirements using a three-level structure: Business Requirements, User Requirements, and Development Requirements. This helps define requirement concepts clearly across different levels in your organization.

• In Free, Standard, and Premium, Business Requirements, User Requirements, and Development Requirements support 1 level, 1 level, and 2 levels respectively. Their default level labels are BR, UR, SR, and Child.
• A Business Requirement cannot be split directly into a Development Requirement.

图1

图2

• Based on your organization’s needs, you can disable Business Requirements and User Requirements in the background. You can also customize terminology, for example changing the names to Epic, Feature, and Story.

图3

The Requirements menu under Product is divided into three sections, so you can assign different permissions to users responsible for Business Requirements, User Requirements, and Development Requirements.

图4

The Requirement list supports both Tree View and Flat View.

• Tree View helps you understand end-to-end traceability across the requirement hierarchy. It clearly shows how Business Requirements are split and carried through to Development Requirements.
• Flat View is better for search and filtering, allowing you to focus on attributes such as status and priority without being constrained by hierarchy.

图5

The Requirement list also shows completion progress for child items, but it counts only direct child Requirements.

• For example, if Business Requirement 1 is split into User Requirement 1, User Requirement 2, and User Requirement 3, and User Requirement 1 is further split into Development Requirement 1, then the direct child items of Business Requirement 1 are User Requirement 1, User Requirement 2, and User Requirement 3 — three in total. Development Requirement 1 is not counted because it is not a direct child of Business Requirement 1.

图6

Requirements are decomposed level by level.

• When a parent Requirement changes, notifications are sent only to its direct child Requirements, and then passed down level by level.
• When a parent Requirement is closed, its child Requirements are closed automatically. After all child Requirements are closed, the parent Requirement must still be closed manually.
• When a child Requirement is reactivated, the parent Requirement is reactivated automatically. After the parent Requirement is reactivated, child Requirements must be reactivated manually.
• Only leaf Development Requirements — Development Requirements with no child Requirements — can be broken down into Tasks, linked to Test Cases and Bugs, and used in downstream work. Once such a Requirement is split into child Requirements, it can no longer be split further.
• Releases and Versions can be linked only to leaf Development Requirements.

Requirement stage logic has also been optimized.

• The stages for Business Requirements, User Requirements, and parent Development Requirements are: Not Started, Planned, Project Initiated, In Development, In Delivery, Delivered, Closed.
• The stages for leaf Development Requirements are: Not Started, Planned, Project Initiated, In Design, Design Completed, In Development, Development Completed, In Testing, Testing Completed, Accepted, Acceptance Failed, Released, Closed.

图7

图8

A new feature for linking any Requirement has also been added.

• The original relationship between User Requirements and Development Requirements has been upgraded to a parent-child relationship.
• Requirements can now be linked to any Requirement in any Product and in any status. This helps establish traceable relationships between related Requirements.

图9

Plans now support linking Business Requirements, User Requirements, and Development Requirements. However, Business Requirements and User Requirements can be linked to multiple Plans, while a Development Requirement can be linked to only one Plan.

图10

II. Project

After a Project is created, you can link Business Requirements, User Requirements, and Development Requirements in the Project. This allows teams to associate higher-level requirements early and refine them later as details become clearer.

• In Projects, the separate lists for Business Requirements, User Requirements, and Development Requirements are combined into a single Requirement list, making it easier for project members to view all linked Requirements in one place.
• When a Requirement link is removed, only the current Requirement is unlinked. This does not affect parent-child Requirements linked in other Projects. If you want to remove multiple linked Requirements together, you can select them in batch and remove them.

图11

When creating or editing a Project, an additional switch is available to restrict which requirement concepts the Project can link to. You can use this to control whether Business Requirements and User Requirements should be allowed in the Project.

图12

In Waterfall Projects, the stage types General, Requirement, and Design support managing Business Requirements, User Requirements, and Development Requirements. Other iterations, stages, and Kanban-based work items link only to Development Requirements.

图13

图14

Because requirement concepts and stages now differ, the development board in Execution has been updated to display Business Requirements, User Requirements, parent Development Requirements, and Development Requirements.

图15

III. Workflow (Standard)

Business Requirements and User Requirements both support independent workflow configuration. You can modify their fields and attributes separately.

图16

IV. Feedback (Standard)

Feedback can also be converted into Business Requirements.

图17

V. Admin

A new Business Requirements switch is available in Feature Switches. Once it is turned off, Business Requirements are no longer available in the system.

图18

In Notification Settings, you can configure notification methods for Business Requirements, User Requirements, and Development Requirements.

图19

Business Requirements, User Requirements, and Development Requirements each support independent configuration for status, close reasons, source, priority, type, required fields, and review settings, so you can tailor them to your organization’s rules.

图20