在用ALM Soft管理需求的时候，很多问题其实不是因为大家不会用这个工具，而是因为最开始没有把需求放对地方，字段写得不清楚，层级也没有统一，如果最开始建需求太随便了，后面评审、开发还有测试工作就都会跟着变乱，特别是需求树的层级如果混在了一起，表面上看只是目录不整齐，但实际里面会影响到需求的追踪、测试的覆盖还有变更的管理，所以我们在用ALM Soft的时候，得先把需求条目建清楚，而且层级关系也需要定期去收拾。

　　一、ALM Soft需求条目的创建步骤

　　1、需要先进入对应项目的需求模块

　　我们在建需求条目之前，得先看清楚现在进的是不是正确的项目，还有版本对不对，一般大家可以先点进【需求管理】或者【Requirements】这个模块，然后再去选对应的需求目录，大家千万不要还没选好项目的位置就直接去点新建条目，这样的话需求很容易就会被挂到错误的目录下面，如果碰上比较大的项目，个人建议大家先建好系统需求、软件需求、接口需求还有性能需求这些基础的目录，之后再把具体的那些需求放进去。

　　2、把需求的标题和描述填好

　　需求的标题虽然要简单，但是也不能写得太随便，像“登录功能”、“权限控制”或者“报表导出”这种标题，大家虽然能看懂大概的意思，但最好还是把它写得更具体一点，比如改成“用户账号密码登录”、“管理员角色权限配置”还有“销售数据报表导出”，这样以后大家去搜的时候会更方便，至于需求的描述，里面要把触发的条件、操作的对象、系统的动作以及最后输出的结果都写清楚，不能只写一句“实现某某功能”就应付过去了，如果描述写得太模糊，开发人员理解起来还有测试人员去验证的时候，就特别容易想偏。

　　3、还要把类型、优先级和状态补齐

　　在建需求条目的时候，需求类型、优先级、版本、负责人还有状态这些字段也都是要填的，比如业务需求、系统需求、软件需求和接口需求这些得区分开，优先级的话，大家可以按照高、中、低或者P1、P2、P3去选，状态则是从草稿、待评审、已批准、开发中到已验证这样一步步传下去，刚录进去的需求一般是不能直接设成已完成的，除非这个需求真的已经经过了评审和验证。

　　二、ALM Soft需求条目层级混乱的整理方法

　　1、先把数据导出做好备份，再去动层级

　　如果需求的层级已经很乱了，大家可千万别直接在里面批量拖来拖去或者乱删，比较稳当的办法，是先把现在的需求列表导出来，把需求的编号、标题、父级节点、状态、版本和关联关系都留个底，这样就算在整理的时候发现自己移错了位置，也能对照着改回来，特别是那些已经和测试用例、缺陷或者变更单连在一起的需求，更是不敢乱动，否则后面的追溯关系可能就直接断掉了。

　　2、团队要把需求分层的规则统一好

　　在动手整理层级之前，得先定下来项目到底要用哪种分层的方式，常见的有两种：一种是按照“业务需求—系统需求—软件需求—测试需求”这样来分，另一种是按照“模块—功能—子功能—验收点”来分，项目组内部最好只选定一条主线来用，不要一部分按模块分，另一部分又按版本分，甚至还有一部分按人员去分，如果分层的规则不统一，就算这次理好了，过不了多久还是会重新变乱。

　　3、调整好父子关系并处理重复的条目

　　整理的时候，要把那些明显放错位置的需求移到正确的父级下面，就像“密码强度校验”这个需求，它应该被放在“注册”或者“修改密码”的下面，直接挂在项目的根目录上肯定是不对的，要是遇到了重复的需求，不建议大家简单地删掉，可以把描述比较完整、关联关系比较多的那一条留下来，然后把重复的条目改成废弃、合并或者引用，如果碰上太大的需求，也得把它拆成几个可以开发、可以测试的小需求。

　　三、以后ALM Soft需求管理怎么做才规范

　　1、要把标题的写法统一起来

　　为了不让以后新加的需求继续变乱，团队里必须统一好需求标题的写法，标题里面最好能包含对象和动作，比方说“用户可修改登录密码”、“管理员可分配角色权限”、“系统支持导出订单明细”，大家不要再去用“优化功能”、“新增需求”或者“问题处理”这种太宽泛的标题了，标题写得清楚，以后大家找需求、做评审还有筛选版本的时候都会省力很多。

　　2、每一个条目的需求范围要控制住

　　一个需求条目里面最好只写一个相对完整的功能点，不要把好几个功能都揉在一起，像是“用户可以注册、登录、修改密码、找回密码”这种，就不适合塞进同一个条目里，应该把它们拆成好几个需求，这样做的好处是状态容易管，测试的时候也比较好覆盖，如果一个需求只做了一半，大家也能清清楚楚地知道到底是哪一条没做完。

　　3、定期去检查需求的关联关系

　　ALM Soft这个工具的价值不光是用来存需求的，它还要把需求和测试用例、缺陷、任务以及变更记录都连起来，需求整理好以后，大家要定期去查一查哪些需求还没有配测试用例，哪些测试用例没有对应的需求，还有哪些缺陷没有挂到具体的条目上，光是把目录理得好看其实没什么用，只有追溯关系是完整的，以后的项目评审和质量检查才算有了依据。

　　总结

　　在ALM Soft里建需求条目的时候，重要的事情是选对项目的位置，把标题和描述写清楚，再把类型、优先级、版本和状态补上；在需求层级乱掉的时候，得先做备份，再按统一的规则去理父子关系，把重复的和太大的需求处理掉；以后还要规范好标题的写法，控制住单个条目的范围，并且定期去检查需求和测试、缺陷、变更之间的联系，这样需求库才不会越用越乱，项目往前推进的时候也更方便去追踪和管理。