标签：需求 项目经理 规范 评审 任务 测试 研发 手册 变更
规范篇2
二，需求规范
1，目的： 目前存在需求描述不明确，录入、评审不规范等问题，本文档的目的是通过需求管理规范化，确保团队的成员在项目过程的做符合项目目标的事，以便提高团队的整体效率，及时完成项目的目标，交付可用的产品。
2，需求管理规范
2.1.创建和评审需求
2.1.1 创建需求
（1）需求的标题、所属模块、需求来源、来源备注 是必填项。 （需求备注：填写具体的需求填写人）
（2）所属计划，可以暂时保留为空。
（3）录入需求时默认必须评审。优化、修复，轻微调整可自行判断是否需求评审。不评审，需求则默认处于草稿状态。
（4）需求描述内容必须包含不限于： 图片、原型设计 以及文字描述。有其他参考文件如：单据、Excel。可以以附件方式上传。
（5）需求录入必须填写 验收标准。
2.1.2 需求的列表页标签： T B C 的说明
T：T 是任务（Task）的缩写，表示该需求所分解的任务数。
B：B是Bug的缩写，表示与该需求相关联的Bug数。
C：C是用例（Case）的缩写，表示该需求所创建的用例数。
2.2 需求评审
2.2.1 在创建需求的时候，有一个"不需要评审"的复选框，如果选中该复选框的话，需求的创建是激活中的。但大部分情况下面，需求还是需要评审的。
即使产品完全由一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。新增需求的评审流程如下：
2.2.2 具体的需求评审操作
（1）在需求列表中选择，“眼镜图标”点击，进入评审。
（2）根据评审结果编辑评审结果。
（3）评审通过后，状态则变为激活。
2.2.3，评审注意事项：
评审结果可以选择确认通过、有待明确、拒绝等操作。如果选择“确认通过”，则需求的状态改为“激活中”，然后就可以关联到项目中进行开发了。
如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创建者头上，有其继续进行完善。
如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：
由谁评审是记录的参与评审的人员名单，可以输入用户名来自动筛选。一般来讲需求评审可以是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可。
2.3 变更和评审需求
2.3.1 需求变更流程
2.3.2 需求变更
禅道专门提供了需求的变更流程。凡是对需求 标题、描述、验证标准和附件的修改，都应该走变更流程。变更之后的需求状态为 已变更。
（1）编辑操作是无法修改需求的标题、描述、验收标准和附件的。
（2）在变更需求的时候，如果选择了“不需要评审”，则需求状态自动变成激活，不需要再走评审流程。
（3）在变更需求的时候，会列出该需求的影响范围。
（4）通过需求的详情页面查看变更前后的变化
点击需求名称，进入需求详情，在下方导航中点击“变更”按钮。
2.3.3 评审需求
（1）评审结果可以选择确认通过，撤销变更，有待明确或者拒绝。如果选择确认通过，则需求的状态从“已变更”变为“激活中”。
（2）如果选择撤销变更，则取消当前的变更，并回退到之前的版本。
（3）如果选择有待明确，需求被打回到需求的变更者，继续进行完善。
（4）如果选择拒绝，则需要给出相应的拒绝原因。
（5）同样在评审需求的时候，也会列出相应的影响范围，评审者可以参考。
2.3.4 确认需求变更
当需求变更被评审确认之后，研发团队和测试人员需要确认需求的变更。在需求中的影响范围里可以看到该变更的需求影响的项目任务、bug和用例，评审后，需要做相应的确认。
如图：
2.4 需求状态和研发阶段
2.4.1 需求的状态
需求状态(status)字段，总共有四种状态，分别是 草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有：创建、变更、审核、关闭、激活，其状态流转图如下：
2.4.2 需求的研发阶段
需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有 未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。
禅道可以通过编辑操作，来修改研发阶段。
但我们更提倡另外一种方案，就是在创建任务的时候，仔细设置任务的类型，比如开发，测试。禅道的程序会自动根据不同类型任务的变化来自动计算需求的研发阶段，其规则如下：
- 如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是"未开始"。
- 如果需求关联到了计划，还没有关联到项目中，则需求的研发阶段是"已计划"。
- 如果需求关联到了项目中，但还没有分解任务，则需求的研发阶段是"已立项"。
- 如果需求关联到了项目中，且进行了任务分解:
如果有一个开发任务进行中，并且所有的测试任务还没有开始，需求的研发阶段为“研发中”。
如果所有的开发任务已经完成，并且所有的测试任务还没有开始，则为“研发完毕”。
如果有一个测试任务进行中，则视为“测试中”。
如果所有的测试任务已经结束，但还有一些开发任务没有结束，则视为"测试中"。
如果所有的测试任务已经结束，并且所有的开发任务已经结束，则视为"测试完毕"。 - "验收"阶段是需要产品经理手工来进行确认的，确认后阶段改为“已验收”。
- 产品→发布中关联的需求后，需求的研发阶段是“已发布”。
2.5 需求注意事项
2.5.1 需求的INVEST原则：
一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。
标签：需求,项目经理,规范,评审,任务,测试,研发,手册,变更 来源： https://www.cnblogs.com/demon28/p/15826846.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。