需求管理制度

需求管理制度
零壹移动互联
需求管理制度（版，2015年）
修改记录
⽬录
第⼀章总则................................................. 错误!未定义书签。

第⼆章职责与分⼯........................................... 错误!未定义书签。

第三章需求总体说明......................................... 错误!未定义书签。

第四章需求提交............................................. 错误!未定义书签。

第五章需求评估............................................. 错误!未定义书签。

第六章需求开发............................................. 错误!未定义书签。

第七章系统测试............................................. 错误!未定义书签。

第⼋章需求上线............................................. 错误!未定义书签。

第九章⽣产问题管理......................................... 错误!未定义书签。

第⼗章需求变更控制与管理................................... 错误!未定义书签。

第⼗⼀章需求进度监控及查询................................. 错误!未定义书签。

第⼗⼆章附则............................................... 错误!未定义书签。

第⼀章总则
第⼀条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的⼯作内容、处理流程、参与⼈员以及相关⼲系⼈的职责，在保证需求质量的同时，提⾼需求实现效率，特制订本制度。

第⼆条本制度适⽤于研发部的所有系统开发需求。

第三条本制度适⽤的读者包括需求开发负责⼈、需求提交⼈员、需求评估⼈员、开发⼈员、测试⼈员、⽣产运维⼈员、项⽬管理员等。

第⼆章职责与分⼯
第四条职责分⼯
第三章需求总体说明第五条需求分类
按需求的提交部门可以分为研发部内部需求和业务部门需求。

按需求的内容可分为功能开发需求、平台⽹站类需求、数据需求。

按需求的紧急程度可以分为紧急需求和普通需求。

按需求开发⼯时的⼤⼩可以分为⼤型需求、中型需求和⼩型需求。

第六条需求开发管理流程图
需求开发管理流程为：
（建议由项⽬管理员统⼀管理需求）
需求管理主要包括以下内容：
需求的评估、开发、测试和上线阶段的管理细则遵循本制度中相关规定。

不涉及功能开发的平台类需求和数据需求可根据实际情况对需求开发管理过程的部分⼯作进⾏裁剪。

各阶段包含的活动及流程请见以下各章节中的详细描述。

第四章需求提交
第七条需求提交
为提⾼需求质量和处理效率，减少需求变更的次数，研发部各⼩组（开发、UI、测试）与产品部门就需求内容和实现⽅式等达成⼀致，可形成会议纪要存档，并与《需求申请表》（或邮件的形式）同时提交需求审批。

需求提交前需确认的内容包括：
（⼀）与开发⼈员沟通，确定需求类型。

（⼆）需求的可⾏性分析。

各部门\⼩组进⾏可⾏性分析时需关注的内容为：
1.研发部对需求的技术可⾏性进⾏初步分析，并帮助需求提交⼈员识别关联系统。

2.需求关联系统的归属开发⼈员就需求是否符合业务发展规划，以及需求对系统中已有业务功能的影响进⾏评估。

3.产品部、开发⼈员、测试⼈员对需求的业务逻辑、风险、合规等进⾏初步评估。

第⼋条需求会签
原则上中、⼤型项⽬或需求，需要通过会签流程，征求各部门相关同事或领导审批，审批
通过⽅可进⼊到后续开发流程。

此条制度视公司具体情况需要，灵活运⽤。

第五章需求评估
第九条需求评估流程
需求评估流程说明及职责分⼯：
（⼀）需求调研，需求⽂档完成开发后，产品经理需将需求提交⾄项⽬管理⼈员统⼀管理，项⽬管理⼈员需要将需求⽂档发送⾄研发部想⼲的各分部门会签。

会签通过后组织需求评估会议。

（⼆）项⽬管理员审核相关要素，包括：参与会签审批的⼲系⼈是否齐全，各⼲系⼈是否审批通过。

附：紧急需求另⾏处理（待完善，可划分为业务需求、紧急需求、⽣产QC等三种类型）（三）需求评估会上要评估的内容包括：
1.确认需求内容，分析需求合理性：需求开发负责⼈从技术层⾯对需求的技术可⾏性、性能等进⾏初步评估；测试部及其他相关产品部门从业务⾓度，对需求的业务逻辑、业务流程、业务⽬的、风险、合规等⽅⾯内容进⾏评估。

2.初步确认需求的实现⽅式。

3.初步评估需求的开发⼯作量。

4.明确需求系统设计、编码、测试、上线阶段的⾥程碑以及各阶段的交付物和负责⼈。

5.确定需求评估结论。

（四）需求评估完成后，填写《需求评估表》（待设计表格），需填写的内容包括：
1.不予开发或者有变更的事项；
2.该需求对其他关联系统的影响；
3.需求所需⼈⼒、⼯时、⾥程碑以及整体评估结论等。

（五）评估表填写完毕后，评估⼈员需当场签字确认，项⽬管理员检查需求评估表的信息是否填写完整、准确。

第⼗条需求评估考虑层⾯
需求评估主要从技术⾓度和业务⾓度进⾏考虑。

若需求评估通过，会后需求提交⼈员根据需求评估的结论更新需求，更新后的需求将作为研发部开发的最终依据（避免需求多次变更）。

若出现下列情形之⼀的，评估组出具意见后可退回需求⾄产品部重新更新需求或需要征得各部门领导审批。

（⼀）技术层⾯
1.需对系统结构进⾏⼤规模改造的。

2.涉及系统架构变更的。

3.与其他需求有重复的。

4.需求中有不合理事项的。

5.需求不明确需做补充的。

6.当前技术⽆法实现的。

7.评估时发⽣重⼤变更，且变更审批未通过的。

（⼆）业务层⾯
1.与⽬前的业务操作流程、运营有⽭盾的。

2.需⼤规模的更改原有的业务流程,增加⼤量⼈⼯后续处理成本。

3.业务需求与业务⽬的不符的。

4.新需求引起的新业务流程未在需求内⼀并体现的。

5.业务流程未理顺,业务规则未明确或者没有体现，有可能导致上线后,⽆法正常进⾏业务
运作，或者存在运营风险的。

因以上原因被退回的需求，需求提交部门如对需求评估⼩组的评估结果存在争议，可提交各部门领导进⾏仲裁。

第六章需求开发
第⼗⼀条需求开发流程
（略，具体流程有开发部门制定）
第⼗⼆条设计开发：需求评估通过后，由需求开发负责⼈安排、协调需求的设计和开发⼯作。

（⼀）开发⼈员根据需求评估会上通过的业务需求进⾏设计开发，同时完成《需求技术⽂档》。

（⼆）技术⽂档通过需求开发负责⼈的审核后，开发⼈员提交项⽬管理⼈员。

此技术⽂档有必要从架构、环境、安全、性能等层⾯对技术⽂档进⾏评审，及时提出评审意见。

（三）项⽬管理员审核相关要素，包括：技术⽂档是否符合要求、评审⼈员参与度、是否评审通过。

审核通过后需求进⼊开发阶段。

如审核不通过，项⽬管理员将技术⽂档退回给开发⼈员，开发⼈员处理完毕后再提交相关⼲系⼈评审。

（四）技术⽂档评审通过后，开发⼈员将评审通过后的技术⽂档更新到SVN中并开展开发⼯作。

紧急需求必须通过需求评估后，才可开展设计开发⼯作。

设计开发阶段的部分⼯作在项⽬管理员审批通过后，可根据实际情况进⾏裁剪。

第⼗三条单元测试&集成测试
（⼀）编码完成后，开发⼈员需进⾏单元测试、系统集成、编译部署、及主功能测试。

测试
通过后编写《单元测试报告》、版本部署操作⽂档，并提交需求开发负责⼈审核。

（⼆）需求开发负责⼈审核通过后，开发⼈员将源代码、《单元测试报告》、版本部署操作⽂档更新到SVN，需求开发负责⼈将《单元测试报告》、版本部署操作⽂档上传到SVN。

第七章系统测试
第⼗四条系统测试：单元测试（包含系统集成）通过后进⼊系统测试阶段，系统测试流程为：
系统测试流程说明：
（⼀）需求开发负责⼈向项⽬管理员提交系统测试申请。

（⼆）项⽬管理员审核相关要素，包括：需求是否通过评估、技术⽂档是否通过评审、单元测试是否通过、《需求技术⽂
档》、《单元测试报告》及版本部署操作⽂档是否上传SVN。

审核通过后项⽬管理员向研发部质量管理部测试经理下系统测试通知单。

如审核不通过，返回开发⼦流程。

（三）测试经理分配系统测试⼈员。

（四）系统测试⼈员验证SVN中的技术⽂档、版本部署及需求主功能。

验证通过后制定测试计划，如验证不通过，返回开发⼦流程。

（五）系统测试计划、测试案例、测试报告由系统测试⼈员编写并组织评审，系统测试主管和需求开发负责⼈必须参加评审。

（六）补充：测试计划、测试⽅案、测试案例等测试⽂档，设计时间参考第六条（需求开发管理流程图）；测试⼯作遵循尽早参与的原则，遇特殊情况，测试⽂档也可在测试启动时执⾏。

第⼋章需求上线
第⼗五条需求上线：测试验收⼯作结束后，进⼊需求上线
阶段。

需求上线主要分为业务上线、技术上线。

第⼗六条需求上线流程
需求上线流程说明：
（⼀）需求上线申请
需求测试通过后，测试经理检查测试负责⼈提交的测试⼯件，审核通过后提交项⽬管理员协调开发安排上线时间。

（⼆）上线实施后，需求相关⼈员需进⾏上线验证：
（三）若上线复核或验证失败，则开发⼈员将上线版本从⽣产环境中回退，需求转⼊开发流程。

第⼗七条试运⾏
为了对系统的功能、性能、可靠性、稳定性、需求涉及业务和系统的影响情况进⾏验证，需求上线后，由研发部、产品部，以及其他领导共同商榷，根据项⽬实际情况实⾏产品试运⾏。

试运⾏的时间、⽅案、通过标准暂未制定。

第九章⽣产问题管理
第⼗⼋条⽣产问题：指存在于⽣产系统中的异常现象或缺陷，不包括办公设备、⽹络故障等⾮⽣产系统引起的故障。

⽣产问题处理流程说明：
（⼀）技术⼈员收到⽣产问题后，对问题根源进⾏深⼊分析，并对系统问题进⾏处理。

如不属于⾮系统问题，技术⼈员拒绝报障并说明原因，测试⼈员需整理归档。

（⼆）⽣产问题修复完毕后部署到测试环境，提交测试流程。

（三）技术⼈员提交测试申请，项⽬管理员审核通过后下测试通知单。

（四）⽣产问题测试通过后，上线流程与需求上线流程⼀致。

第⼗章需求变更控制与管理
第⼗九条需求变更：指研发部受理需求后，需增加、修改、删除需求内容，或将需求挂起、退回、取消的现象。

需求变更控制与管理流程：
需求变更控制与管理流程说明及职责分⼯：
（⼀）需求变更申请⼈填写《需求变更申请表》（待设计表格），详细说明需求变更的类型、变更原因及变更内容。

（⼆）需求变更申请⼈通过邮件\OA\或其他部门间⼯作联系函将需求变更申请提交需求开发负责⼈、相关测试负责⼈及关联系统负责⼈审批。

审批通过后需求开发负责⼈判断是否为重⼤变更。

如审批不通过，评审组说明原因后将需求变更申请退回申请⼈。

（三）需求变更属于重⼤变更时，需求变更申请⼈组织需求变更评审会，由评审组成员共同确定是否允许变更。

如果不属于重⼤变更，需求开发负责⼈有权决定是否允许需求变更。

满⾜以下任⼀条件的需求变更都属于重⼤变更。

1.需求变更引起开发⼯时增加量：⼤型需求≥10%，中型需求≥15%，⼩型需求≥20%（仅删除需求内容的变更可不考虑）。

2.需求变更导致⾥程碑点推迟的。

3.需求变更涉及关联系统变化的。

4.需求变更可能存在风险、合规问题的。

5.需求变更涉及或影响已有业务流程、规则、后台运营的。

（四）需求变更评审参与⼈员：需求开发负责⼈、需求提交⼈员、开发⼈员、测试负责⼈、
测试⼈员、关联系统负责⼈、关联产品部门。

如不属于重⼤变更，可裁剪此活动。

评审的内容包括：
1.技术可⾏性分析。

2.需求合理性、业务⽅案可⾏性分析。

3.关联系统影响分析。

4.变更风险分析。

5.对需求⼯作量、⼯期、成本等的影响分析。

6.评审结论：
（1）评审通过：需求开发负责⼈在《需求变更申请单》（待设计表格）填写需求变更详细⽅案。

（2）评审不通过：在《需求变更申请单》中填写否决意见及原因。

（五）需求变更评审结束时，需求开发负责⼈在《需求变更申请单》中填写需求变更评审意见，与会⼈员签字确认。

（六）需求变更评审会后，需求开发负责⼈将《需求变更申请单》提交项⽬管理员审批。

审批通过后业务⼈员更新业务需求。

如审批不通过，项⽬管理员说明原因后将需求变更申请退回需求变更申请⼈。

（七）业务需求更新完毕后，需求开发负责⼈将《需求变更申请单》上传SVN管理，并发布需求变更通知，需求转⼊开发流程。

第⼗⼀章需求进度监控及查询
第⼆⼗条待制度完善（建议引⼊需求管理软件）
第⼗⼆章附则
第⼆⼗⼀条本制度由研发部测试管理部负责制定、解释和修改。

涉及其他部门，可由相关部门协助研发部测试管理部修改。

第⼆⼗⼆条需求管理办法相关⽂件。

1.业务需求申请表
2.需求评估表
3.需求技术⽂档
4.需求变更申请表。