很多团队在ALM里把需求、史诗、功能、用户故事都堆进一个层级里，表面上看是“信息都在一起了”，实际一到排期、拆分、追踪测试覆盖，就会发现上下层语义混了。以OpenText ALM Octane和ValueEdge的工作模型来看，需求模块和Backlog模块本来就是两套不同视角：需求模块更适合沉淀正式需求和长期结构，Backlog模块更适合承接史诗、功能和用户故事这类交付项。Requirements模块本身支持文件夹和需求文档的树状层级，Backlog模块则明确是Epic在上、Feature在中、User Story在下的交付层关系。
一、ALM需求怎么分层
先把“长期表达”与“短期交付”分开，需求分层才不会越做越乱。ALM里比较稳的做法，不是把所有东西都放进Backlog，而是先用Requirements管正式需求结构，再把实际实施项放进Backlog，这样需求树负责讲清业务和范围，Backlog树负责讲清怎么做和做到哪一步。
1、顶层先按业务域或产品域建需求树
Requirements模块自带树形结构，支持文件夹和需求文档分层管理，默认整棵树可到12层深。这个能力更适合拿来放业务域、产品线、模块域、流程域这类长期稳定的需求骨架，而不是直接塞冲刺级事项。
2、中层用需求文档承接能力和规则
在需求树的底层文件夹下放Requirement Document，更适合表达一组相对完整的业务目标、范围、规则和验收口径。官方也把Requirements模块定义为记录和跟踪项目需求的中央仓库，既可以存高层描述，也可以做正式项目文档。
3、交付层再交给Epic和Feature
Backlog模块里，官方给出的层级非常清楚，Backlog Items组织在Feature下面，Feature再组织在Epic下面。换句话说，Epic和Feature更像“交付分解层”，它们适合表达阶段性目标和可交付能力，不适合替代整棵需求树。
4、最底层执行项再落到User Story
用户故事属于Backlog Items，是团队真正拉进迭代、看板和状态流转的工作单元。它应该承接Feature下面可实现、可排期、可验收的最小业务切片，而不是再去承载上层的大段背景和制度性描述。
二、ALM史诗需求用户故事如何映射
映射这件事，关键不是强行一一对应，而是先定语义，再定父子关系。ALM现成模型里已经把父子关系定义好了，Story的parent指向Feature，Feature的parent指向Epic；同时Requirements模块又允许把backlog items链接到需求文档，因此更合理的映射方式通常是“需求文档对交付层做覆盖”，而不是“需求文档直接等于某一条用户故事”。
1、一个需求文档可以映射一个史诗范围
如果某个需求文档描述的是一个跨团队、跨迭代的大能力，比如会员体系改造、统一结算、审批流重构，那么它更适合映射到一个Epic的业务边界。这样需求文档负责讲清楚为什么做和做到什么程度，Epic负责承接开发交付视角。这里不是系统字段上的“自动等号”，而是更稳的建模方式。它之所以成立，是因为Requirements已经支持在文档视图里查看相关backlog实体，而Backlog本身又是Epic到Feature到Story的交付树。
2、一个史诗下面拆多个功能
Epic不要直接往下挂太多用户故事，中间最好先过一层Feature。因为在ALM现成数据关系里，Feature本来就是Epic的下级，User Story的parent又是Feature。这样拆完以后，史诗讲目标，功能讲能力块，结构更稳，报表和过滤也更清楚。
3、一个功能下面再拆用户故事
用户故事要表达的是某个角色在某个场景下完成某个动作的最小实现单元，所以它应该挂在Feature下面，而不是直接挂在需求树里。官方导入规则也说明了这一点：导入backlog items时，Epic和Feature字段会共同决定条目创建到哪里；如果你想把一个用户故事放到某个Epic下面的某个Feature里，却没有指定Epic，系统可能会在Backlog root下新建Feature，层级就会跑偏。
4、需求与故事用覆盖关系联起来，不用硬做一对一
Requirements的Manage视图允许把backlog items和tests链接到需求上，Requirement Document里也有Backlog tab用来显示相关的epics、features、user stories、quality stories和defects。实际落地时，更推荐用这种“一个需求文档覆盖多个交付项”的关系，把需求与交付连起来，而不是把一条需求文档机械地拆成一堆一一对应的故事。
三、ALM里最容易做错的几种映射方式
真正让层级失控的，通常不是工具不够用，而是建模习惯有偏差。只要把正式需求层和执行交付层混在一起，后面无论是导入、同步还是追踪测试覆盖，都会越来越难看。
1、把需求树直接当成冲刺看板来用
Requirements模块适合放正式需求结构，Backlog模块适合放Epic、Feature、User Story这些工作项。要是把需求树直接拿来承接冲刺级状态流转，表面上少了一层映射，实际上会把文档层和执行层混在一起。
2、让史诗直接挂大量故事，跳过功能层
系统原生父子关系已经把Story指向Feature、Feature指向Epic。要是团队直接让Epic下面挂一堆故事，短期看似省事，长期会让能力边界模糊，后面再补Feature时还要整体回收整理。
3、把一个需求文档只对应一条故事
这样做最容易把需求文档拆碎。需求文档本来更适合承接一组相关需求，再通过Backlog tab和Related items去覆盖多个Epic、Feature、Story。只做一对一映射，既浪费需求树的表达能力，也会让需求维护成本变高。
4、导入时只填Feature不填Epic
官方导入规则已经提示过，Backlog Item的落点要看Epic和Feature两个字段。如果用户故事本来应放在某个Epic下面的某个Feature里，却漏了Epic，系统可能把Feature建到Backlog root下，最后层级看起来像是“故事找不到上层”，其实是导入映射一开始就没对齐。
总结
ALM需求怎么分层ALM史诗需求用户故事如何映射，最稳的做法可以概括成一句话，就是“需求树讲业务和范围，Backlog树讲交付和拆分”。需求模块用文件夹和需求文档沉淀正式层级，Backlog模块用Epic、Feature、User Story承接交付层级，再用requirement document与backlog items的关联把两边连起来。这样做，史诗不会变成大号需求文档，用户故事也不会被迫承担上层规划信息，整套层级会清楚很多。
