零壹移动互联
需求管理制度（版，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.需求变更申请表
1目的 对项目的需求分析活动进行控制，明确需求规格说明书的要求。 2适用范围 适用于项目的用户（包括确定顾客和潜在顾客）需求分析活动。 3职责 项目负责人指定人员组成用户需求分析小组，并委任需求分析负责人。 需求分析组了解和分析用户的需求，并编制《需求规格说明书》。 项目负责人负责组织对需求规格说明书的评审。 4工作流程 4.1确定需求分析人员 在项目立项，完成项目策划后，项目负责人指定人员组成需求分析小组，并委任负责人。 4.2需求分析实施 需求分析小组进行用户需求分析工作，主要了解以下的内容： 用户业务与项目有关的部分； 用户的工作流程； 用户的相关部门及职责； 使用人员的技术水平； 用户原有系统的现状； 用户对项目交付成果的期望和具体要求。 4.3编制《需求规格说明书》 在充分了解用户需求的基础上，需求分析小组编写《需求规格说明书》，要求参见《需求规格说明书》模板。该模板规定了《需求规格说明书》的内容和要求，编写时可根据具体的项目情况进行调整。必要时，可在有关的章节中引述其它资料作为附录。 4.4需求评审 为保证需求定义的正确性、完整性和清晰性，应对《需求规格说明书》进行评审，
评审主要考虑以下准则： 客户或潜在客户需要的可追溯性； 与客户或潜在客户需要的一致性； 可测试性； 系统(子系统)设计的可行性； 操作和维护的可行性。 4.5需求管理 《需求规格说明书》经评审后，按《配置管理程序》进行管理；需求的修改与变更，应按照《更改控制程序》执行。 5相关程序文件 序号名称编号 1 配置管理程序WAYOUT-QP-02 2 更改控制程序WAYOUT-QP-03 6记录 序号名称模板编号 1 需求规格说明书WAYOUT-QF-05 2 评审报告WAYOUT-QF-06
A公司股份有限公司 IT需求管理办法 第一章总则 第一条为了实现对信息系统开发需求的有效管理，保证系统需求收集、分发、实施等各环节的顺畅流转，强化推行系统需求开发的成本核算管理思路，提高软件开发的计划性，特制定《A公司股份有限公司IT需求管理办法》（以下简称“本办法”）。 第二条软件开发需求（以下简称“需求”）是指为了完善信息系统已有功能、开发新的功能或系统而提出的需求。 第三条本办法的管理过程包括需求问题沟通体系、需求年度预算管理、需求季度跟踪管理、需求月度开发进度管理、计划外需求管理、立项需求管理、需求优先级评估、需求成本分析与投资收益跟踪、突发重大问题处理、版本发布管理等部分。 第四条IT需求管理处负责全面系统建设需求及相关联事宜管理，架设于企划部下，具体职责包括： -支持IT规划：协助集团信息技术，结合产险业务发展规划，进行产险IT规划； -需求管理： ?日常需求管理：需求审核，需求优先级排定，需求计划制定，版 本发布相关工作推进； ?项目需求管理：项目可行性分析及立项审核，项目状态监控； ?日常运营监控：运营流程优化，运营问题收集及跟踪；
-资源管理：业务部门IT资源使用情况监控，确保系统开发在年度预算范围内进行； -突发问题处理：对系统日常运行过程中的突发异常状况及时响应； -流程管理：确保业务与IT间工作的有序流转，顺畅衔接。 第五条IT需求管理处人员岗位 -承保岗：负责各业务条线投承保部分需求管理协调； -理赔岗：负责各业务条线理赔部分需求管理协调； -财务统计岗：负责财务、统计分析部分的需求管理协调； -综合岗：负责日常综合事务处理，包括公文发布、会议召集、报告整理、问题分发等工作。 第六条角色说明 机构需求管理责任人：二级机构、三级机构均指定唯一系统需求及问题处理责任人。负责机构日常系统使用问题的第一时间响应，对于无法处理的问题及时上报。负责日常机构使用系统问题的定期收集与解决情况的定期反馈。 业务部门IT接口人：总公司各业务部门指定唯一IT接口人。负责本部门、本业务条线的需求统筹工作，包括需求计划的排定、原始业务需求说明的提交及必要的需求沟通等，以保障需求沟通的有效性和及时性，降低沟通成本。如果业务部门提出的需求涉及多个部门，由需求提出部门负责需求的整体协调及沟通确认。负责结合业务管理制度整理系统操作手册，负责系统上线前的培训实施。 信息技术中心需求接口人：信息技术中心某一系统板块指定唯一需求接口人。协助IT需求管理处完成需求成本预估，并接收IT需求管理处分发的需求项目，推进后续需求开发相关事宜并有效跟进。
系统研发部门管理制度 为加强对公司系统研发部门工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高开发效率，加强研发各流程环节的规范性，特制定系统研发部门管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及产品立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、编码实现、系统测试、产品发布、产品维护、项目总结。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1.立项：项目立项报告、市场需求文档（MRD）。 2.需求分析：产品需求文档（PRD）、产品Backlog、项目开发计划、项目风险分析清单。 3.系统设计：系统架构设计文档、模块详细设计文档等。 4.软件实现：Sprint Backlog、源代码、单元测试代码、模块测试代码、源代码说明或者 注释、复盘报告。
5.系统测试：测试方案、测试用例、测试报告。 6.产品发布：产品使用手册。 7.产品维护：产品维护记录、用户反馈记录。 8.项目总结：提交客户方的项目总结。 软件过程成果表：
第三章、岗位设置
第四章、项目立项 1、产品经理进行市场调查与分析，确认产品的需求，进行产品研发立项，立项需提供《项目立项报告》《市场需求文档》。 2、产品立项通过后，系统研发部门根据项目对资源的需求成立项目开发组，指派研发经理，由部门和研发经理共同来确定具体项目配置、知识技能要求、团队成员及团队的角色等。第五章、项目计划与监控 1、以项目为单位，研发经理负责编写整个项目的《项目开发计划》、《项目风险分析清单》，由测试经理针对项目编写《项目测试计划》。以上文档需提交部门进行评审。 2、在整个项目研发过程中，研发经理定期检查项目进度和完成情况，调整人员分工和安排，测试经理负责组织人员对项目的质量进行跟踪管控。 第六章、需求分析 1、产品经理在立项时提供《项目立项报告》《市场需求文档》，研发经理组织项目组对需求进行分析汇总，梳理用户的业务流程和详细的功能定义，并最终形成《产品需求文档》、产品Backlog文档。
公司软件研发管理制度 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。
5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，
明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
需求规格文档 1 导言 1.1 目的 [说明编写这份项目需求规格的目的，指出预期的读者] 1.2 背景 说明： a)待开发的产品的名称 b)本项目的任务提出者、开发者、用户及实现该产品的单位 c)该系统同其他系统的相互往来关系 1.3 编写说明 [缩写] [缩写说明] 列出本文件中用到的外文首字母组词的原词组 1.4 术语定义 [术语] [术语定义] 列出本文件中用到的专门术语的定义
1.5 参考资料 [编号]《参考资料》[版本号] 列出相关的参考资料 1.6 版本更新信息 具体版本更新记录如表所列。 表版本更新记录 2 任务概述 2.1 系统定义 本节描述内容包括： ●项目来源及背景； ●项目要达到的目标，如市场目标、技术目标等； ●系统整体结构，如系统框、系统提供的主要功能，涉及的借口等； ●各组成部分结构，如果所定义的产品是一个更大的系统的一个组成部分，则应说 明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明 该系统和本产品其他各部分的联系和接口。 2.2 应用环境 本节应根据用户的要求对系统的运行环境进行定义，描述内容包括： ●设备环境； ●系统运行硬件环境； ●系统运行软基纳环境； ●系统运行网络环境； ●用户操作模式； ●当前应用环境。 2.3 假设和约束 列出进行本产品开发工作的假定和约束，例如经费限制、开发期限等。列出本产品的最终用户特点，充分说明操作人员、维护人员的教育水平和技术专长以及本产品的预期使用频度等重要约束。
3 需求规定 3.1 对功能的规定 本节依据合同中定义的系统组成部分分别描述其功能，描述应包括： ●功能编号； ●所属产品编号； ●优先级； ●功能定义； ●功能描述。 3.2 对性能的规定 本节描述用户对系统的性能需求，可能的系统性能需求有： ●系统响应时间需求； ●系统开放型需求； ●系统可靠性需求； ●系统可移植性和可扩展性需求； ●系统安全性需求； ●现有资源利用需求。 3.2.1 精度 说明对该产品的输入、输出数据精度的要求，可能包括传输过程中的精度。 3.2.2 时间特性要求 说明对于该产品的时间特性要求，如对： A）响应时间； B）更新处理时间； C）数据的转换和传送时间； D）计算时间等的要求。 3.2.3 灵活性 说明对该产品的灵活性的要求，即当需求发生某些变化时，该产品对这些变化的适应性能力，如： a)操作方式上的变化； b)运行环境的变化； c)同其他系统的借口的变化； d)精度和有效时限的变化；
目录 2 1.前言......................................................................................................................... 3 2.需求管理背景......................................................................................................... 3 3.需求管理流程......................................................................................................... 4 4.指导规范................................................................................................................. 6 5.需求管理体系......................................................................................................... 6 5.1.制度 .............................................................................................................. 7（一）总则 .............................................................................................................. 7（二）机构职责 ...................................................................................................... （三）总体工作流程 ............................................................................................ 10 10（四）需求提出 .................................................................................................... 10（五）需求分析 .................................................................................................... 11（六）需求评审 .................................................................................................... 12（七）需求跟踪 .................................................................................................... 12（八）需求实现 .................................................................................................... 12（九）附则 ............................................................................................................ 13 5.2.细则 ............................................................................................................ 13 5.3.流程图 ........................................................................................................ 14 5.4.评审细则 .................................................................................................... 15 5.5.模板 ............................................................................................................ 5.6.编写指南 .................................................................................................... 16 16 6.合理性评价...........................................................................................................
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
业务需求管理制度 第一条总则 规范各部门有关业务需求的提出、变更及维护，为整体业务系统建立统一的需求管理机制和跟踪机制，从而提高沟通效率及需求反馈的响应速度和透明度，保障产品开发结果与需求的一致性，特制定本细则。 第二条适用范围 本规定适用于管理所有业务部门提交到本部的所有需求。 第三条定义 1、业务需求：对需要在整体业务系统中实现或调整的业务功能的说明或描述； 2、业务需求方：为公司整体业务系统提出所要实现或调整功能的部门，包括无线运营部、销售服务部和财务结算部等； 3、业务需求承接方：负责承接业务需求，目前由产品技术部的产品专员对接各部门的需求。 第四条需求的重要程度 需求部门所需功能对整体业务系统的影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a)非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节； b)重要：业务系统所需的该项功能对整体业务系统影响大； 页脚内容1
c)一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。第五条需求的紧急程度 需求部门所需功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。 a)非常紧急：所提业务需求非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施； b)紧急：所提业务需求比较急迫，如不尽快实现，业务流程不能被正确执行，但存在可替代措施或方法； c)一般：所提业务需求急迫性一般，不会对现有流程存在较大影响。 第六条需求提交 各部门通过JIRA填写详细需求信息，向需求承接方发起需求任务，在需求提出时需注意以下几个方面： 1、详细描述需求背景、需求内容，包含需求介绍、功能性需求详细描述及数据需求描述，明确本部门需求对接人； 2、提出需求时应说明需求的重要程度和紧急程度； 3、提出需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理； 4、为更加清楚地说明业务需求变更情况，可附带附件、附图等文档。 第七条需求分析 1、需求承接方就接受到的需求进行需求分析，需求不明确的地方与需求方及时进行沟通，并在 页脚内容2
产品研发管理制度 第一章总则 第一条产品研发过程的管理，指产品研发项目确定后，进行产品研发，形成可交付使用的软件产品的过程。在产品的研发过程中，做好研发流程的管理和控制，是确保产品研发质量和研发进度的关键。 第二条本流程制定的目的是为了对产品研发进行有效的组织实施，使产品研发处于受控状态，保证软件开发的最后成功，向用户提供高质量的软件产品。 第二章产品的需求分析管理 第三条需求的采集 采集的渠道分为市场反响、竞争对手分析、客户反馈、运营数据分析、公司内部的建议等方面。 第四条需求的分析及编制文档 采集到的需求经过深入了解和系统分析，通过跟用户的讨论验证，并形成产品需求文档，让开发、设计人员理解产品的概念，功能、特点及产品各个部分的逻辑。产品需求文档包括业务需求、用户需求、功能需求和非功能性的需求。 1、业务需求：反映客户对系统、产品高层次的目标要求，在项目定义与范围文档中予以说明。 2、用户需求：描述用户的目标，或用户要求系统必须要完成的任务，这在使用实例或方案脚本中予以说明。 3、功能需求：规定开发人员必须在产品中实现的软件功能，使用户利用这些功能来完成任务，从而满足了业务需求。 4、非功能性需求：描述软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。包括系统的完整性（联机帮助、数据管理、用户管理、软件发布管理、在线升级等）、性能、可靠性、可维护性、可扩充性、适应性等。 工作责任人需求分析工程师 工作职责概述需求采集、用户调查、业务分析、系统分析、变更管 理、用户验证
工作关系客户、市场、公司内部员工 工作成果产品需求文档 第三章产品的可行性分析报告、原型及评审管理 第五条可行性分析报告 产品可行性分析报告的编制是为了明确产品项发立项之前的市场、技术、财务、生产等方面的可行性，论述为了实现产品研发目标而可能选择的各种方案、投资及效益分析、潜在的风险因素，论证所选定的方案的可行性。 可行性分析报告编制完成后，由公司技术战略委员会组织完成对产品可行性分析报告的可行性初审和复审，形成相关议决后报总经理审批。 第六条产品需求规格说明书 确定客户需求、根据产品需求文档形成产品需求规格说明书。用于保证软件开发的质量、需求的完整与可追溯性，通过产品需求规格说明书，以保证用户与需求分析人员、开发人员、测试人员及其它相关利益人对需求达成共识，确保产品需求的实现。 第七条产品原型 原型图是对流程图中“界面元素”的展现，将页面的模块、原素、人机交互的形式，利用线框描述的方法，将产品脱离皮肤状态下更加具像跟生动的进行表达。 工作责任人产品经理、产品助理 工作职责概述用户和市场分析、产品规划、产品需求管理、产品设计、推动产品研发进程、产品发布管理、产品宣传推广工作关系产品中心经理、需求分析工程师、研发中心、客户 工作成果产品可行性分析报告、产品需求规格说明书、产品原型设计 第四章产品的立项及评审管理 第七条产品立项报告书 产品立项报告书含以下内容：
招聘需求分析制度 精品文档值得下载值得拥有招聘前的准备关于对眉山市彭山县中国移动人力资源助理招聘我们制定了一下要求，从而达到招聘要求。一．招聘的准备阶段要完成的工作? 制定招聘计划? 明确招聘策略? 组建招聘团队? 选择招聘来源和渠道 1.制定招聘计划? 获取人员需求信息? 选择招聘信息的发布时间和发布渠道? 初步确定招聘团队及其分工? 初步选择确定考核方案? 明确招聘预算? 编写招聘工作时间表? 草拟招聘广告样稿2、明确招聘策略? 招聘地点策略：? 在全国乃至世界范围内招聘企业的高级管理人才或专家教授? 在跨地区的市场上招聘中级管理人员和专业技术人才? 在招聘单位所在招聘一般工作人员和技术工人
招聘时间策略：? 出现职位空缺后，确定每一招聘步骤可能占用的时间，以便决定填补空缺职位需要花费的全部时间? 设置一个实际的时间线，从希望雇员实际在职和从事生产的那一天开始进行倒算? 雇佣一个符合质量要求的雇员的时间目标一经确定，就要将这种时间与空缺岗位可以等待的时间进行比较。在有些情况下，招聘所要花费的时间比等待的时间要长，在这种情况下，不要迫于完成雇佣目标的压力，轻易降低雇佣标准。对付这种职位空缺的典型方法有：外包给他人，雇佣临时工人以及职位职责的再分配。? ? 招聘渠道或方法的选择：精品文档值得下载值得拥有精品文档值得下载值得拥有企业可以根据招聘计划所要求的候选人的数量和类型来选择不同的招聘方法和渠道。在后面的渠道选择中将会重点介绍这一内容。? 组织宣传策略：? 人员招聘是组织向社会展示形象的机
会，因此应该密切地与人才及媒介沟通。组织在招聘过程中应创造尊重知识、重视人才的氛围，给社会以良好的印象，增强组织吸引力，能够吸引人才主动来到企业。? 招聘备择方案设计：? 招聘的成本比较高，因此公司在招聘之前应认真考虑它的备择方案，包括兼职雇员和临时工，雇员租赁和策略性外包等。? 3、组建招聘团队招聘与选拔在直线和职能部门之间的职责划分? 合格招聘人员的基本要求? 良好的个性品质和修养? 具备相关的专业知识? 丰富的实践经验? 良好的自我认识能力? 善于把握人际关系? 熟练运用各种面试技巧和人员测评方法? 有效控制招聘各个过程环节? 公正客观评价应聘人员? 招聘团队组建的原则：? ? ? ? ? 知识互补：不同知识结构取长补短，互为补充，丰富招聘团队整体的知识深度和广度，易于对不同知识结构的人员进
软件开发管理制度 版本：V1.0 2013年1月
第一节总则 第一条为规自有软件研发以及外包软件的管理工作，特制定本制度。本制度适用于公司总公司软件研发与管理，分公司参照执行。 第二条本制度中软件开发指新系统开发和现有系统重大改造。 第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进行系统设计、软件开发、集成和相关的技术支持工作，一般仅向外购置有关的硬件 设备和支撑软件平台；合作开发是公司与专业IT公司（合作商）共同协作 完成IT应用的项目实施和技术支持工作，一般形式是公司负责提供业务框 架，合作商提供技术框架，双方组成开发团队进行项目实施，IT系统的日常 支持由IT技术中心和合作商共同承担，IT技术中心负责部（一级）支持， 合作商负责外部（二级）支持；外包开发是指将IT应用项目的设计、开 发、集成、培训等任务承包给某家专业公司（可以是专业的IT公司或咨询 公司等），由该公司（承包商）负责应用项目的实施。 第四条软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求 管理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验 收、系统上线和数据迁移。 第五条除特别指定，本制度中项目组包括业务组（或需求提出组）、IT组（可能包括网络管理员和合作开发商）。 第二节立项管理 第六条提出开发需求的信息技术部门参与公司层面立项，进行立项的技术可行性分析，编写《立项分析报告》（附件一），开展前期筹备工作。《立项分析报 告》应明确项目的围和边界。 第七条应用系统主要使用部门将《立项分析报告》上交公司总裁室进行立项审批，以保证系统项目与公司整体策略相一致。 第八条《立项分析报告》得到批准后，成立项目组（如果是外包开发，则成立外包商项目组；如果是合作开发，则与外包商共同成立合作开发项目组，以下统 称“项目组”），项目组应包括业务组（由公司相关业务部门组成）和IT组 （自行开发为办公室网络管理员；外包开发为外包商成员；合作开发为网络
产品销售管理制度 第一章总则 第一条：销售工作是企业经济活动的重要环节，是联系企业生产和社会需求的纽带，为了规范销售工作程序，加强销售管理，特制定本制度。 第二章售前管理 第二条：销售业务员及各销售站点驻站人员，要认真作好市场调研工作，广泛搜集整理市场信息和经济情报，建立和完善销售公司用户档案，每月底出具市场调研报告，以便公司决策层平衡产、销，及时做出有效的市场应对措施。 第三条：销售部长依据市场调研报告，做深层次的市场预测，分析和调研，积极开拓市场，寻找客户和客户进行价格、数量、质量等谈判，报公司总经理批准后，签订正式销售合同作为档案资料和结算依据。 第四条：签订合同应按规定，逐项填写供方单位名称、需方单位名称及双方的开户银行、帐号、税号、电话号码、地址、产品的规格、数量、价格、质量指标、验收方式、定货日期、交货地点、结算方式、合同签订地点（一般定为我方地点），经济纠纷的解决地点（一般为我方地点）和方式等，经双方签字，加盖公章后生效，各项不得遗漏，需由国家公证机关公证的，必须进行公证。
第五条：建立销售合同文书的三级审核制度，即销售部、企管部、公司分管领导三级审核后才能签订正式合同；合同一式四份，销售部、财务部、企管部、对方客户分别留存。 第三章产成品的入库 第六条：由销售部、企管部、生产部、财务部共同组成产品质量联合监察组，对产成品质量指标和焦炉单孔出焦重量进行不定期抽查，发现问题及时处理，原则上每月抽查两次，并以抽查结果为依据办理入库手续。 第七条：每月由企管部统计员积累数据，26日早开具入库单焦场保管员签字,核算员加盖企审专用章，分管领导签字财务部入帐。 第八条：产成品入库单一式三联，对方一联，销售核员一联，财务部一联。 第九条：保管员依据入库单保管联建立产成品实物保管帐，销售核算员依据入库单计划联建立产成品三级明细帐，要求日清、月结、记帐凭证加装封面，按月装订成册。 第四章产成品的销售与出库 第十条：产成品的销售分为赊销和现款或预付款销售两种形式。 第十一条：公司总经理办公会制定产品售价，销售部起草售价（调整）通知，报财务部、销售部执行。 第十二条：属于赊销的由销售部长按合同填制赊销申请单（要求明确赊销数量、价格、付款期限、责任人）书面通知开票员、销售核算员，具体操作程序为：
IT信息化需求管理制度 第一章总则 第一条明确集团信息技术（IT）需求管理流程、定义及职责，合理分配信息资源，加强集团信息系统的统一规划，促进信息技术需求统一管理并共享成果，提高工作效率。 第二条本办法所指 IT 需求包括：计算机技术相关的软、硬件采购、配置、使用、优化、调整、维护等一系列需求，可由集团或集团下属任何公司、部门提出，对其工作能产生帮助，符合公司利益。 第三条适用范围：集团总部及分公司。 第二章需求管理职责 第四条集团信息部作为 IT 需求的主责部门，发挥 IT 专业价值，统筹 IT需求的统一管理。 第五条集团及下属公司的任何部门，作为 IT 需求的提出部门，负责提出合理需求，并互相配合、积极沟通、协调一致、共同完成需求的实现工作。 第六条集团信息部每年随集团要求制定次年预算开始，主动收集年度 IT需求。业务部门有任何IT 需求在日常均可主动提出。未经集团信息部允许或未向集团信息部报备，集团及集团下属公司的任何部门，不得自行委托外部机构合作信息化相关需求或项目，否则由此可能产生的成本（包含时间成本、人力成本、资金成本等）由其自行负责。 第三章需求管理流程 第七条需求管理的总体流程将按照“提出—分析—实现—验收”的核心步骤进行。 第八条提出需求：IT 需求的提出必须填写《IT 需求申请单》（附件一，可在 OA 申请），审批通过后方可执行。具体流程与分类如下： （1）集团总部：申请人—申请部门负责人审核—申请部门分管领导复审—信息部负责人审批—信息部分管领导—归档。 （2）子公司：申请人—申请部门负责人审核—申请部门分管领导复审（如有）—所属公司负责人—集团总部相关业务部门负责人—信息部负责人审批—信息部分管领导—归档。
1.1项目背景 1.2项目定义与用户期望 1.3项目目标 1.3.1公司管理系统 1.3.2移动端 1.3.3门户网站 1.4服务模型 1.4.1系统服务用户 1.4.1.1高级管理员 拥有公司的所有权限。 1.4.1.2用户管理员 拥有管理公司系统用户的权限。可以登记用户的个人信息，添加用户，修改用户信息，删除用户和查询用户资料的权限。 1.4.1.3员工管理员 拥有管理公司员工的权限。等级员工的基本信息，包括姓名，用户名，密码，躲在公司，职位，员工编号，联系电话和员工的简介。可以添加员工，修改员工信息，删除员工和查询员工信息。 1.4.1.4水类管理员 拥有管理公司产品的权限。可以添加、删除、修改水的种类和数量。 1.4.1.5订单管理员 拥有管理用户订单的权限。记录订单信息，包括用户姓名和联系方式，水的种类和数量，下单时间，用户地址，总价格，付款状态信息和运送状态信息，运送员工编号这些信息。可以添加订单，修改订单信息，删除订单，查询订单信息。 1.4.1.6公司管理员 拥有管理分公司的权限。登记分公司的名称和地理位置。可以添加公司，修改公司信息，删除公司。 1.4.1.7业绩管理员 拥有管理公司员工业绩的权限。统计员工完成订单的数量，并且生成表格。可以打印员工的业绩信息，具有发送邮件和输出信息的权限。 1.4.1.8权限管理员 拥有管理公司员工权限的权限。可以对公司所有岗位进行权限的分配。 1.4.2服务功能模块 1.4. 2.1公司管理系统 1)财务部 主管送水公司的财务工作的财务部，其主要任务是根据国家有关财经工作的法 律、法规、政策和企业发展战略，认真搞好财务管理，周密计划，仔细运筹， 合理收支，准确核算，及时分析，严格监管，确保企业资产和财产的效益和安 全，保证各项工作的正常进行和不断发展。 1)制定与调整修订财务定额、费用开支标准。、 2)拟定并执行企业各项财务管理制度。 3) 制定、分解和落实财务预算和各项财务计划。 4) 参与水类价格的制定。 5) 制定与实施内部控制制度。 6) 调度与配置资金。
精心整理 互联网IT 行业项目管理制度 一、制度目的 为规范项目研发、加强项目管理，保证信息系统符合业务一致性、内控合规性、系统稳定性、系统安全性，使我公司新产品开发能够严格遵循科学管理程序进行，板。四、主要角色及职责
（1）需求申请人提交《产品需求申请单》（详见附件1）至业务归管部门进行业务评审，评审通过后，报至产品技术中心。 （2）产品技术中心根据产品需求进行分析，形成评审报告进行内部评审，评审通过后列入部门工作计划，并提交至公司中高决策层。评审报告内容主要包括预计工作量和成本、风险、可行性分析等（详见附件2：《产品需求文档（PRD）模板》）。
（二）立项管理 经评审确认后的产品需求由产品技术中心提交公司中高决策层，讨论通过后立项。 （三）项目计划与监控 对于产品需求，软件开发采用项目形式管理，项目经理负责整个项目的计划、 形成《评 5.对已确认的系统设计进行修改，需项目经理及技术组负责人及测试负责人审批。 （五）系统实现 1.系统实现包括程序编码、单元测试和集成测试。
2.在系统实现时保证开发、测试和生产环境独立，为各环境建立访问权限控制机制，并明确项目成员的职责分工。对生产环境、测试环境与开发环境在物理或逻辑方面应该做到隔离。 3.项目组进行单元测试和集成测试，出具《单元测试报告》、《集成测试报告》和《系统测试用例》，测试人员签字确认测试结果（详见附件3：《×××系统_测 1.网络运营中心根据项目规模及影响决定试运行策略。 2.研发事业部组织制定《试运行计划》并提交网络运营中心审批。 3.研发事业部进行相关系统部署工作，准备培训资料，对相关用户和信息技术人员进行培训。
(金融产品名称) 需求分析说明书 制作单位：(业务部门或科技部门) 规格标准的版本号:V1.0 文档编号:(按照中国银行文档资料统一编码规则编制文档编号)版本号:（按照中国银行关于版本号管理的有关规定填写）
需求负责人（技术）: 需求负责人（业务）: 编写人员: (参加需求编写的所有人员,包括软件中以参加人员、业务部门参加人员) 校对人员:
技术部门主管签字： 年月日
目录 第一章引言 (4) 1.1编写目的 (4) 1.2项目背景 (4) 1.3基本定义 (4) 第二章产品概述 (5) 2.1目标 (5) 2.2运行环境 (5) 2.3条件与限制 (5) 第三章业务流程分析 (6) 3.1业务流程分析 (6) 3.2业务数据流图 (6) 3.2数据词典 (6) 3.3数据采集 (7) 第四章功能需求 (8) 4.1功能划分 (8) 4.2功能描述 (8) 4.3软件接口 (8) 4.4故障处理 (8) 第五章其它需求 (9) 5.1应用环境 (9) 5.2其它要求 (9) 参考资料 (10)
第一章引言 1.1 编写目的 ?阐述编写需求分析说明书的目的及意义。 1.2 项目背景 ?阐述当前业务系统现状以及业务未来的发展情况 ?阐述新系统与其它系统的关系 1.3 基本定义 ?列出文档中所用到的专门述语的定义和缩写词的原文。
第二章产品概述 2.1 目标 ?描述要开发产品应达到的目标。 2.2 运行环境 ?描述产品所应用环境的框架。包括软件组成、硬件组成、网络构成、系统架 构及其说明等。 2.3 条件与限制 ?给出产品设计应遵守的条件和受到的限制。主要有如下几方面： 1.开发单位或部门应具备的条件。 2.开发者完成开发工作的期限。 3.系统在推广、上点的时间和条件限制。 4.应用环境受到的限制，如网络带宽。 5.可维护性、可移植的限制。 6.软件使用者、管理者对计算机了解的限制。应根据软件所面向的对象（业 务人员、个人、企业等），设计时给予不同的考虑。 7.系统应用规范的限制，包括应用机构数、终端数等。 8.业务规模的限制（百万笔／小时），即对系统处理能力的要求。
零壹移动互联 需求管理制度（2.0版，2015年） 拟制人肖波日期20150630 审核人日期 批准人日期 修改记录 日期版本 作者/修 改者 描述审核人 20150701 V2.0 肖波修改需求开发管理流程与相关人员 分工 -1-
目录 第一章总则 (3) 第二章职责与分工 (3) 第三章需求总体说明 (4) 第四章需求提交 (7) 第五章需求评估 (7) 第六章需求开发 (10) 第七章系统测试 (11) 第八章需求上线 (13) 第九章生产问题管理 (14) 第十章需求变更控制与管理 (14) 第十一章需求进度监控及查询 (17) 第十二章附则 (17) -2-
第一章总则 第一条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制订本制度。 第二条本制度适用于研发部的所有系统开发需求。 第三条本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。 第二章职责与分工 第四条职责分工 角色职责 需求提交人员1.负责需求调研与编辑、编写业务需求申请表、提交业务需求审批。 2.根据需求评审和评估意见，及时修改业务需求，并发给需求相关干 系人。 3.配合需求开发、测试人员提供业务知识的支持。 4.协助确认需求开发结果。 5.负责需求上线后验证工作。 项目管理人员1.负责需求审批、评估、技术文档评审、测试、上线等需求管理流程 的整体协调工作。 2.组织需求评估会议。 3.处理测试申请----提交测试部门进行分配与测试。 4.维护需求信息、跟进需求变更以及需求处理进展，定期向相关领导、 部门汇报需求进展。 需求开发负责人1.参与需求评审，从技术角度对需求实现方式、风险等进行评估。 2.制定需求开发计划，分配需求开发人员。 3.负责需求所有工作的沟通、协调管理。 4.负责需求开发进度、成员、变更管理。 5.负责或参与需求所有成果的审批。 需求评估人员1.从架构、业务、技术、风险等方面对业务需求的内容和实现方式进 行全面评估，并提出评估意见。 2.审核根据评估意见修改后的业务需求。 -3-
产品运营部制度
产品运营部管理制度 目录 一、产品运营部部门职能 二、产品经理职能 三、运营经理职能 四、UI设计师职能 五、客户服务职能 六、产品设计要求 七、产品质量评级标准 八、产品需求评审及变更流程 九、产品发布流程 十、WEB、WAP站需求（内容）变更流程 十一、WEB、WAP站软件版本替换流程 一、产品运营部部门职能
1、竞争对手分析和产品调研； 2、产品功能的定义、规划和设计； 3、保证产品质量、按时完成和发布； 4、搜集产品新需求、竞争产品的资料； 5、用户体验组织和推进； 6、产品内部体验推进产品优化； 7、产品运营数据分析，包括用户行为、市场推广效果分析等； 8、产品设计标准、流程的制订和提升，负责各相关制度的执行和监督； 9、产品UI设计，制订UI设计规范与流程； 10、运营平台维护； 11、输出产品相关文档； 二、产品经理职能 1、调研互联网及行业同类产品，了解竞争对手和潜在合作伙伴的情况。持续了解产品运营过程中的使用情况，通过后台数据和用户反馈来对产品进行调整，并为升级产品做好规划； 2、搜集和提出产品需求，对产品进行全面设计，如功能，特性，使用流程，UI，性能要求等； 3、产品线的策划、设计、定义、开发的质量控制以及产品管理的最终上线； 4、产品线与产品生命周期的管理，目标市场评估；协助市场部门做好产品的宣传资料的设计和制作；
5、通过运营数据分析，分析用户行为和用户需求，优化产品功能、UI及市场推广策略，完善用户体验； 6、产品开发资源的协调，如适配手机、UI等； 7、召集产品评审会议及会签 8、产品发布后组织内、外部用户体验工作 9、撰写产品各类使用手册及产品发布相关的各类产品资料文档：如《产品需求文档》、《需求变更申请》、《产品报备文档》、《用户手册》、《beta版本体验报告》 三、运营经理职能 1、负责线上产品运营管理和维护 2、运营平台管理和维护 3、负责运营配置 4、产品UI体验 5、负责WEB、WAP网站维护及软件版本替换 6、内部运营的协调和推动 7、运营平台内容审核和发布 8、运营规范、流程制定 四、UI设计师职能 1、负责产品的用户界面及交互设计，制作和实现风格统一的用户界面 2、与产品经理配合，主动与软件工程师沟通协作，确保UI效果的无缝整合、实现