需求管理规范

需求采集

采集说明

1.通过各种形式对用户的需求进行收集，通常的形式有：用户访谈，调查问卷，数据分析，领导提供需求，产品人员需求等。

2.在这个阶段对需求的属性详细记录，并且记录可追溯的反馈人员。

采集要求

1.采集的需求必须符合运营需求。

2.需求必需符合icage产品定义。

3.需求必需具有可实现性、拓展性、可开发和合理性。

4.项目组成员确认，对人员进行，不能有过多相关人员加入

5.满足用户需求和业务需求一致性。

6.对开发周期进行安排，计算人力成本并分析工期合理性。

采集流程

采集阶段的文档

分析说明

1.对需求进行一番分析，确定其基本属性，做了之后会对产品带来哪些商业价值？用户量的提高？一级实现改项目需求最多要付出的人员、时间等系数，确认需求性价比。

2.对于一些bug或是功能的小修改，不做详细分析，直接转为需求处理。

分析要求

1.需求分析人员必须完成相关需求分析文档；

2.分析人员要使用符合大众的习惯性语言表达；

3.分析人员要了解业务及需求

4.需求文档中不能含有模棱两可的文字，如可能、一般等

5.需求分析工期不能超过预期时间

6.需求分析应具备合理性

分析流程

分析阶段的文档

评审说明

1.结合现状对需求进行处理，主要解决做不做？什么时候做，做什么的问题；

2.需求评审以会议形式展开，邀请与项目相关人员及领导参加

3.通过评审，对多个需求进行打包，整理所需的需求点

4.对打包后的需求形成文档，提交领导复核，确认后进行开发周期

评审要求

1.符合icage产品定义

2.需求形式化语言清晰易懂

3.需求必须符合运营需求

4.标示将来产品迭代可预测的需求 

5.需求必须可拓展性及可实现性或者后续产品迭代时人力成本和开发成本及技术实现的难易程度

6.满足用户需求和业务需求一致性

7.需求必须合理

8.开发周期、人力成本、工期需合理

评审流程

评审阶段的文档

处理说明

1.产品定义、功能流程及页面分析应和需求保持一致性；

2.原型设计应满足需求，整体风格全站一致；

处理要求

1.需求分析人员必须完成相关需求分析文档

2.分析人员要使用符合大众的习惯性语言表达

3.分析人员要了解业务及需求

4.需求文档不能含有模棱两可的文字，如可能、一般等

5.需求分析工期不能超过预期时间

6.需求分析应具备合理性

处理流程

处理阶段的文档

跟踪说明

1.验证开发出的新产品是否满足需求

2.将项目可预见的问题最低化，对产品质量负责

3.进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性和完整性

4.确保所有的实现的需求是以用户需求为基础

跟踪要求

1.需求管理系统：需要系统自然需求从开始到结束的整套流程

2.对于共同关注的需求项目，用团队协作工具，建立需求项目，所有相关人员可以查看该需求的进度和进展状况

3.PM自主把控，用excel记录需求进展情况，分阶段报送给相关各方

4.需求描述需正确，清晰易懂

5.确保所有的输出符合用户的需求

6.是否实现所有的需求

跟踪流程

跟踪阶段的文档

验证说明

1.由测试负责人编写测试标准，相关人员严格按照测试标准进行验证

2.验证过程中，遇到需求不明的bug，要找相关负责人进行确认，确认结果通知所有相关人员

3.审核及测试需细心、严谨，尽量减少项目的问题

验证要求

1.需求验证需根据验证标准进行测试

2.验证需求时需细心，将问题最小化

3.验证需求时应考虑兼容性的问题

4.Bug的提交要规范化，语言清晰易懂，不能含有模棱两可的词语

验证流程

验证阶段的文档

变更说明

1.需求变更控制的目的：如果需求变更带来的好处大于坏处，允许变更，但必须按照已定义的变更规则执行，以免变更失去控制，如果需求变更带来的坏处大于好处，拒绝变更。

2.重大需求：指对整个产品定义有改变的需求。

3.建立和维护从需求开始到测试之间的一致性和完整性

4.确保所有的实现是以用户为基础

变更要求

1.需求必须合理

2.需求必须符合运营要求

3.需求必须符合icage产品定义

4.需求必须具备可实现性、可扩展性和可验证性，需考虑实现需求或者后续产品迭代时的人力成本和开发成本及技术实现的难易程度

5.满足用户需求和业务需求一致性

6.开发周期、人力成本和工期需要的合理性

7.评审未通过的需求一定要保留

8.需求变更后所有因需求形成的文档都需要更新，防止需求遗漏或者防止开发错误的需求

变更流程

采集阶段的文档