Product
1. Introduction of Sanplex features
1.1. Core Management Framework
1.1.1 Program
1.1.2 Project
1.1.3 Product
1.1.4 Execution
1.1.5 Management Models
1.2. Dashboard
1.2.1 Getting Started with Tutorials
1.2.2 Quick Add
1.2.3 Notification Center
1.2.4 Effort Tracking
1.2.5 Dashboard - Project and Execution
1.2.6 Dashboard - My Work, Contribution, and Recents
1.2.7 Dashboard - Approval
1.2.8 Contacts
1.3. Program
1.3.1 Program List
1.3.2 Program Kanban
1.3.3 Create Program
1.3.4 Create Sub-Programs
1.3.5 Project Charter Management
1.4. Product
1.4.1 Create Product
1.4.2 Manage Modules
1.4.3 Multi-Branch and Multi-Platform Management
1.4.4 Manage Plans
1.4.5 Manage Requirements
1.4.6 Requirement Reviews
1.4.7 Requirement Status and Phase
1.4.8 Create Releases
1.4.9 Track Progress
1.4.10 Business Requirements and Multi-Level Requirements
1.5. Project
1.5.1 Scrum Project
1.5.2. Waterfall Project
1.5.2.1 Manage Project Phases
1.5.2.2 Project Design
1.5.2.3 Project Matrix
1.5.2.4 Project Reports and Earned Value Management
1.5.2.5 Project Baselines
1.5.2.6 Project Change
1.5.3. Kanban Project
1.5.3.1 Set Up Kanban Projects
1.5.3.2 Configure Kanban Boards
1.5.3.3 Use Kanban Boards
1.5.4 Hybrid Agile Project
1.5.5 Hybrid Waterfall Project
1.5.6. Project Settings
1.5.6.1 Project Setup
1.5.6.2 Project Executions
1.5.6.3 Project Requirements
1.5.6.4 Project Builds
1.5.6.5 Project Tests
1.6. Admin Settings
1.6.1 Confluence Data Import
1.7. Workflow

Business Requirements and Multi-Level Requirements

2026-08-18 00:18:18
Sanplex Content
554
Last edited by Jing WANG on 2026-08-18 10:22:59
Share links
Summary: Learn how Sanplex organizes multi-level requirements through Epic, Requirement, and Story concepts, and how to manage their hierarchy, permissions, phases, links, Projects, workflows, notifications, and configuration.

Catalog

Overview

The multi-level requirement hierarchy helps connect higher-level business goals with detailed implementation work. Sanplex organizes requirements through configurable concepts such as Epic, Requirement, and Story, allowing teams to progressively refine requirements while maintaining traceability between different levels.

Organizations can configure the terminology used for these concepts to match their own requirement management practices. For example, Epic, Requirement, and Story can be used to represent different levels of business, user, and development requirements.

This structured hierarchy helps teams clarify requirement scope, improve cross-functional collaboration, and maintain traceability from higher-level objectives through detailed delivery work.

Use Cases

  • Translate higher-level goals into executable work: Break broad requirements down into progressively more detailed items so implementation work remains aligned with the original objective.
  • Improve requirement understanding across roles: Different teams can work at the requirement level most relevant to them while maintaining a shared hierarchy.
  • Structure complex requirements: Parent-child relationships make it easier to organize large requirements, review scope, and identify missing work.
  • Trace the impact of changes: Hierarchical and linked relationships help teams identify related upstream and downstream items when requirements change.

I. Product

Sanplex supports a multi-level requirement hierarchy through Epic, Requirement, and Story concepts. Stories can also be further organized through parent-child relationships and sub-stories.

This creates a progressive hierarchy from higher-level requirements to detailed implementation items.

Product Epic list showing a hierarchical requirement structure with nested requirement items, including UR, SR, and sub labels, together with status, phase, subitem progress, and available actions.

Open a requirement item to view its parent-child structure and related information. The details page can display its parent item, sub-requirements, history, and linked objects.

Requirement details page showing a Parent Story in Basic Info, a SubRequirement table with child items, and Linked Objects containing related Epic and Story items.

1. Configure Requirement Concepts

Go to Admin > Features > Product > Story Concept to configure the terminology used for the requirement hierarchy.

The configuration defines the names used for the Epic Concept, Feature Concept, and Story Concept. For example, the Feature Concept can be named Requirement while the Epic and Story concepts remain Epic and Story.

Admin Product Story Concept page showing configurable Epic Concept, Feature Concept, and Story Concept values, including a configuration that uses Epic, Requirement, and Story.

2. Configure Permissions by Requirement Module

Requirement-related permissions can be managed separately by module.

Go to Admin > Users > Permission and click Assign Permissions by Modules. Administrators can select Epic, Requirement, or Story as the Module and then configure the corresponding Permission Sets, Methods, and Privileges for different permission groups.

This allows access and actions for each requirement level to be managed according to users' responsibilities.

Admin Permission page with Assign Permissions by Modules highlighted. The Action Permissions dialog shows Module, Permission Sets, Method, and Privilege columns, with Story, Requirement, and Epic available as separate modules.

3. View the Requirement Hierarchy

Requirement lists support different display modes for reviewing hierarchical information.

Use the hierarchy controls and view buttons to switch between a hierarchical view and a flatter list-oriented view.

  • A hierarchical view makes parent-child relationships easier to follow.
  • A flat list is useful when searching, filtering, or comparing requirement attributes across multiple items.

Project Story page showing hierarchy controls and buttons for switching between different list display modes.

4. Track Subitem Completion

For requirement items that contain child items, the Subitems column shows the completion progress of their direct children.

For example, 1 / 2 indicates that the item contains two direct subitems and one of them is completed.

Product Epic list with the Subitems column highlighted. A parent item shows 1 / 2, with a tooltip indicating that it contains two substories, one of which is completed.

5. Work with Leaf Stories

Detailed implementation work is performed through Stories at the lower levels of the hierarchy. Depending on the item and its current state, available actions can include creating child items, linking downstream work, and managing related delivery information.

Execution Story list showing multiple Stories and their available action icons for managing related Story operations.

6. Track Requirement Phases

The Phase field reflects the current development or delivery progress of requirement items.

For implementation-level Stories, available phases include values such as:

Waiting, Planned, Initiated, Designing, Design Completed, Developing, Dev Completed, Testing, Test Completed, Accepted, Rejected

Higher-level requirement items use their own progress phases based on their hierarchy and child-item progress.

For detailed Phase rules, see Requirement Status and Phase.

Execution Story page with the Phase search criterion open, showing phase values including Waiting, Planned, Initiated, Designing, Design Completed, Developing, Dev Completed, Testing, Test Completed, Accepted, and Rejected.

7. Link Related Objects

Requirement items can also maintain relationships with related objects outside the parent-child hierarchy.

On the details page, use Linked Objects to view or add related items. The Relation Graph provides another way to review these relationships.

Story details page with the Linked Objects section highlighted. The section contains a Linked Objects button, Relation Graph button, and related Task and Test Case entries.

8. Link Requirement Items to Plans

Plans can contain items from different levels of the configured requirement hierarchy.

Open a Plan to view its Linked Stories. The list identifies the linked item types and summarizes the number of Epic, Requirement, and Story items currently included in the Plan.

Plan details page showing Linked Stories containing items from different requirement levels. The summary indicates the numbers of Epic, Requirement, and Story items on the page.

II. Project

Requirement items can also be linked to Projects so teams can connect Product requirements with delivery work.

The Project Story page provides a consolidated workspace for viewing linked requirement items and working with Stories.

1. Create and Link Stories

On the Project Story page, use Create Story to create a Story.

To create multiple Stories, open the Create Story menu and select:

Batch Create > Story

Existing requirement items can be added to the Project through Link Stories.

Project Story page with the Create Story menu open. Batch Create is displayed with Story as the available batch creation option, while Link Stories is available beside the Create Story button.

2. Configure Story Concepts for a Project

When creating or editing a Project, the Story Concept section determines which requirement concepts are included in the Project.

The available concepts shown in the current configuration include Epic, Requirement, and Story.

Project settings page showing the Story Concept section with Epic, Requirement, and Story options.

3. View Linked Stories in a Project

The Project Story page provides hierarchy controls and display options for reviewing linked Stories and their related requirement structure.

Project Story page showing linked Stories together with hierarchy controls, list display buttons, status, phase, assignee, and available actions.

4. Link Stories to an Execution

Within an Execution, open Story and click Link Stories to select existing Stories.

Search criteria can be used to locate the required Stories before linking them to the Execution.

Execution Link Stories page showing search criteria and a list of available Stories with fields including Priority, Phase, Product, Module, Linked Plan, Branch, Creator, and Estimate.

III. Workflow (Standard)

Sanplex provides separate built-in Product workflows for different requirement concepts.

Under Admin > Workflow > Product, built-in workflows can include Epic, Feature/Requirement, and Story, depending on the terminology configured under Story Concept.

This allows the workflow for each requirement concept to be managed independently.

Admin Workflow page filtered by Product, showing separate built-in workflow cards for Epic, Feature, Story, Release, Product Plan, and Product.

IV. Feedback (Standard)

Feedback can be converted into a requirement item for further Product management.

Use the To Requirement action for the required Feedback item to continue managing it as a Requirement.

Feedback list with the To Requirement action highlighted for a Feedback item.

V. Admin

1. Configure Requirement Features

Under Admin > Feature Options, Product-related optional features include Requirements and Epics.

Enable the required Product features and save the configuration.

Admin Feature Options page showing the Product module with Requirements and Epics enabled under Optional Features.

2. Configure Requirement Notifications

Go to Admin > Notifications > Settings to configure notifications for requirement-related objects.

The settings provide separate rows for Epic, Requirement, and Story, with notification options available through channels such as:

  • Email
  • System Notification
  • Webhook
  • SMS

Available events can include Create, Comment, Submit Review, Close, Assign, Edit, Change, Reviewed, and Activate.

Admin Notification Settings page showing separate Epic, Requirement, and Story rows with configurable Email, System Notification, Webhook, and SMS events.

3. Configure Epic, Requirement, and Story Settings

Under Admin > Features > Product, Epic, Requirement, and Story each have their own configuration page.

Depending on the selected requirement concept, administrators can manage settings such as:

  • Required Field
  • Type
  • Priority
  • Source
  • Closure Reason
  • Development Phase
  • Status
  • Review Rules
  • Review Result
  • Review Process

This allows each level of the requirement hierarchy to follow configuration rules appropriate to its role in the Product lifecycle.

Admin Features Product page showing separate Epic, Requirement, and Story tabs. The Epic configuration page displays options including Required Field, Type, Priority, Source, Closure Reason, Development Phase, Status, Review Rules, Review Result, and Review Process.

Write a Comment
Comment will be posted after it is reviewed.