After Plans are created, Requirements can be maintained. To learn how product managers manage Requirements in Sanplex, you can watch the video below:

（视频介绍）

I. Create Requirements

1. Create Business Requirements, User Requirements, and Development Requirements

You can create different types of Requirements by clicking Create Requirement on the list pages under Product > Business Requirements, Product > User Requirements, and Product > Development Requirements.

图1

Sanplex also supports cross-level decomposition settings. Under Admin > Feature Settings > Product > Business Requirements / User Requirements / Development Requirements, you can enable Allow Cross-Level Decomposition in the decomposition workflow settings. After it is enabled, users can select the configured level when creating a Requirement.

图2

图3

2. Split Requirements

• Requirements can be split across the three-level structure of Business Requirements, User Requirements, and Development Requirements.
• In each Requirement list, you can click Split in the action column to split a Requirement.
• A Business Requirement (BR) cannot be split directly into a Development Requirement.

图4

图5

3. Batch Create

Click Create Business Requirement > Batch Create, Create User Requirement > Batch Create, or Create Development Requirement > Batch Create to create Requirements in bulk.

图6

4. Multi-Image Upload

Sanplex supports multi-image upload. With this feature, multiple images can be uploaded in batch and created as Requirements. The image name is used as the default Requirement name.

图7

5. Multi-Line Entry

Sanplex supports multi-line entry, where each line is treated as a separate Requirement.

图8

After saving, you need to manually select information such as Module, Plan, Type, and Priority.

图9

6. Edit and maintain Requirements

After a Requirement is created, the system automatically returns to the Requirement list. You can use the action buttons to Change, Review, Submit for Review, Withdraw Review, Close, Edit, Create Test Case, or Add Child Requirement.

图10

7. Child item information

The Requirement list also shows completion progress for child items. Only direct child Requirements are counted.

• 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.

图11

Requirements are decomposed level by level.

• When a parent Requirement is changed, notifications are sent only to its direct child Requirements, and then continue downward 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, or used in downstream processes. Once a Development Requirement has been split into child Requirements, it cannot be split again.
• Releases and Versions can be linked only to leaf Development Requirements.

II. Feature configuration and maintenance

1. Level name settings

• By default, Business Requirements support one level only, with the level label BR; User Requirements also support one level only, with the level label UR; Development Requirements support two levels, with level labels such as SR and Child.
• Level names can be modified under Admin > Feature Settings > Product > Business Requirements, User Requirements, or Development Requirements, in the Level Settings section.

图12

2. Level decomposition settings

• Multi-level decomposition is supported through the level settings under Admin > Feature Settings > Product > Business Requirements, User Requirements, or Development Requirements.
• Level names can also be modified there, and multi-level decomposition can also be performed from the action column.

图13

III. Permission configuration and maintenance

1. Language settings

Sanplex supports switching or customizing terminology in the background. For example, you can rename levels as Epic, Feature, and Story, or use other naming conventions based on your organization’s needs.

图14

2. Requirement closing settings

Sanplex supports closing Business Requirements and User Requirements. This can be configured under Admin > Feature Switches > Product - User Requirements / Product - Business Requirements.

图15

3. Permission settings

The Requirement menus under Product are divided into three categories. You can assign different permissions to the users responsible for Business Requirements, User Requirements, and Development Requirements.

图16

IV. Switch views

The Requirement list supports both Tree View and Flat View.

• Tree View helps you understand the overall traceability of Requirements. It clearly shows how Business Requirements are decomposed and carried through to Development Requirements.
• Flat View is better for searching and filtering, allowing you to focus on attributes such as status and priority without being affected by hierarchy.

图17

V. Link Requirements to Plans

Plans 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.

图18

In addition to linking a Plan when creating a Requirement, you can also link Requirements in batch from the Plan page. Select the target Plan and click Link Development Requirements.

图19

Select the Requirements you want to link, then click Link Development Requirements.

图20

VI. Link any Requirement

• After the relationship between User Requirements and Development Requirements is upgraded, it is optimized as a parent-child relationship.
• Requirements can be linked to any Requirement in any Product and in any status. This linking feature helps you establish relationships between related Requirements.

图21