下载文档原格式
带你全⾯认识CMMIV2.0（三）——实践域实践域以往被称为称为“过程域”，如：配置管理，现在叫做“实践域”。
对于2.0版，则有25个适⽤的实践域。
与以前版本的CMMI模型⼀样，“实践域”介绍了定义实践意图的关键活动的要求和描述。
在新模型下，全部25个实践领都适⽤于成熟度为三级的组织。
另外，值得注意的是，通⽤实践的要求（版本1.3中）不再定义为“通⽤实践”，⽽是被纳⼊特定的实践域。
以前CMMI开发模型（版本1.3）的成熟度三级仅需要18个“过程域”，⽽在⾼成熟度等级（第4和第5级）则另外定义了四（4）个。
⾏动（Doing）包括⽤于⽣产、购买和交付优质解决⽅案的能⼒域。
确保质量(ENQ) – 帮助改进产品和服务质量需求开发和管理（RDM）使开发⼈员能够不断了解解决⽅案的需求和期望，并保持更新。
⽬的：抽取需求，确保利益相关⽅的共同理解，并统⼀需求、计划和⼯作产品。
价值：确保满⾜客户的需求和期望实践总结成熟度等级1RDM 1.1记录要求。
成熟度等级2RDM 2.1抽取利益相关⽅的需求、期望、约束以及接⼝或连接。
RDM 2.2将利益相关⽅的需求、期望、约束以及接⼝或连接转换为优先的客户需求。
RDM 2.3与需求提供者达成对需求含义达成⼀致。
RDM 2.4获得项⽬参与者的承诺，即他们可以落实这些需求。
RDM 2.5开发、记录和维护需求和活动或⼯作产品之间的双向可追溯性。
RDM 2.6确保计划和活动或⼯作产品与要求保持⼀致。
成熟度等级3RDM 3.1开发并持续更新解决⽅案及其组件的需求。
RDM 3.2开发操作概念和场景。
RDM 3.3分配要落实的需求。
RDM 3.4识别、开发并持续更新接⼝或连接需求。
RDM 3.5确保需求是必要且充分的。
RDM 3.6在利益相关⽅的需求和约束条件之间取得平衡。
RDM 3.7确认需求，以确保⽣成的解决⽅案在⽬标环境中按照预期⼯作。
过程质量保证（PQA）可确保遵循过程并产⽣质量解决⽅案⽬的：确定选定结果的原因，并采取措施防⽌不良结果的复发或确保正向结果的复发。
智能运维管理系统V2.0 需求规格说明书修订目 录文档介绍文档目的 文档范围 读者对象 参考文档 术语与缩写解释 系统概述系统建设目标 系统总体结构 用户的特点 设计和实现上的限制 系统功能性需求双活中心工作运行状态监控模块 场景描述用例分析 参与者列表 专用监控功能模块 场景描述 用例分析 参与者列表 故障告警模块 场景描述 用例分析 参与者列表 用例描述 数据配置管理模块 场景描述 用例分析 参与者列表故障切换管理模块场景描述 用例分析 参与者列表 数据接口 场景描述 用例分析 参与者列表 故障处理 场景描述 用例分析 参与者列表 系统非功能性需求易用性需求 方便增加监测设备方便删除监测设备 方便定位故障或者异常设备 监测设备在启动与停止监测之间方便转换 性能、并发性需求 对性能及并发性的特殊要求 扩展性需求 采集和监控服务器的集群支持 支持公司 平台的整合 支持公司单点登录系统的整合 支持对物联网智能设备的直接监测 安全及保密性需求 敏感数据加密 敏感操作进行确认 可靠性需求运行可靠性数据可靠性 可维护性需求 监测设备配置优化 软硬件环境约束 系统备份与恢复要求系统日志 其它需求外部接口说明短信发送接口 应用软件服务监测接口文档介绍文档目的在《智能运维管理系统 立项建议书》的基础上对各个功能模块做出详细的需求分析，为项目后续的设计和开发提供依据。
文档范围本文档包括服务器监测、数据库监测、交换机监测、 平台监测、物联网智能设备监测、应用软件服务监测、个性化主题展现、配置管理的需求规格说明，同时也包括整个系统平台的建设目标、总体结构、网络结构、系统接口描述、用户界面需求和软硬件环境方面的需求规格说明。
读者对象项目的系统设计人员、系统开发人员、系统测试人员以及配置管理人员；公司内部 项目的其干系人、领导、专家等。
参考文档智能运维管理系统 立项建议书，，物联网智能数据采集和控制平台需求规格说明书，， 监控系统 用户指南，术语与缩写解释系统概述系统建设目标公司目前在监控系统方向有两个产品，都是基于 结构，一个是监控系统，另外一个是物联网智能设备监控系统。
需求管理制度V2.0本文是___的需求管理制度（2.0版，2015年），由肖波拟制，经审核人和批准人审核批准。
本文旨在规范公司内部的需求管理流程，提高工作效率和质量。
2-引言随着公司业务的不断发展，需求管理变得越来越重要。
良好的需求管理流程可以有效地避免项目延误和资源浪费，提高项目成功率。
因此，本文制定了一套完整的需求管理制度，以指导公司内部的需求管理工作。
3-范围本文适用于___所有的需求管理工作，包括需求收集、需求分析、需求评审、需求变更等环节。
4-定义需求：指用户对软件系统的功能、性能、安全性等方面的要求和期望。
需求管理：指对需求进行收集、分析、评审、变更等一系列管理活动，以确保软件系统符合用户需求和期望，并满足相关的质量标准和法规要求。
需求文档：指包括需求规格说明书、需求变更记录等在内的所有与需求相关的文档。
5-需求管理流程5.1 需求收集需求收集是需求管理的第一步，也是最关键的一步。
在需求收集阶段，需要与用户、客户、业务代表等进行充分的沟通，了解其需求和期望，以确保需求的准确性和完整性。
5.2 需求分析需求分析是对需求进行深入研究和分析的过程。
在需求分析阶段，需要对需求进行分类、筛选、排序、评估等操作，以确保需求的可行性和优先级。
5.3 需求评审需求评审是对需求进行审核和确认的过程。
在需求评审阶段，需要与相关人员进行充分的讨论和协商，以确保需求的正确性和一致性。
5.4 需求变更需求变更是在需求管理过程中难免出现的情况。
在需求变更阶段，需要对需求进行重新评估和确认，以确保变更后的需求仍然符合用户需求和期望。
6-需求管理的相关人员6.1 需求管理人员需求管理人员负责制定需求管理计划、制定需求管理流程、指导需求管理工作等。
6.2 需求分析人员需求分析人员负责对需求进行分类、筛选、排序、评估等操作，以确保需求的可行性和优先级。
6.3 需求评审人员需求评审人员负责对需求进行审核和确认，以确保需求的正确性和一致性。
需求管理制度V2.0需求管理制度（2.0版，2015年）拟制人：XXX审核人：日期批准人：日期修改记录：xxxxxxxx：作者/修xxxxxxxx：版本改者V2.0XXX：修改需求开发管理流程与相关人员分工目录：1- 目录无需求管理，就没有好的产品。
因此，在产品开发过程中，需求管理显得尤为重要。
本文旨在制定一套完整的需求管理制度，以确保产品开发的顺利进行。
一、需求管理的定义需求管理是指在产品开发过程中，对需求进行全面、系统、规范的管理，旨在确保产品开发的顺利进行，最终实现产品的质量、进度和成本目标。
二、需求管理的流程需求管理包括需求获取、需求分析、需求确认、需求跟踪四个方面。
具体流程如下：1.需求获取需求获取是指在产品开发前期，通过市场调研、用户需求调研等方式，获取产品的需求信息。
2.需求分析需求分析是指对需求进行分析和梳理，以确保需求的全面性、准确性和一致性。
3.需求确认需求确认是指对需求进行确认和评审，以确保需求的可行性和合理性。
4.需求跟踪需求跟踪是指在产品开发过程中，对需求进行跟踪和管理，以确保需求的实现和变更控制。
三、需求管理的相关人员需求管理涉及的相关人员包括需求管理负责人、需求分析师、产品经理、开发人员、测试人员等。
其中，需求管理负责人负责需求管理的全面规划和控制，需求分析师负责对需求进行分析和梳理，产品经理负责对产品的全面规划和控制，开发人员负责产品的开发和实现，测试人员负责对产品进行测试和验证。
四、需求管理的工具和技术需求管理的工具和技术包括需求管理软件、需求跟踪矩阵、需求变更控制流程等。
其中，需求管理软件可以帮助需求管理人员进行需求的收集、分析、确认和跟踪，需求跟踪矩阵可以帮助需求管理人员进行需求变更的控制和管理。
五、需求管理的考核指标需求管理的考核指标包括需求覆盖率、需求准确率、需求变更控制率等。
其中，需求覆盖率指产品需求与客户需求的匹配程度，需求准确率指需求的准确性和一致性，需求变更控制率指需求变更的控制和管理程度。
CMMI基本介绍V2.0目录1组织成熟度级别和类别 (2)2通用目标和通用实践 (3)3RD 需求开发REQUIREMENTS DEVELOPMENT (4)4REQM需求管理REQUIREMENTS MANAGEMENT (5)5PP项目策划PROJECT PLANNING (6)6PMC项目监督和控制PROJECT MONITORING AND CONTROL (7)7RSKM风险管理RISK MANAGEMENT (8)8SAM供应商协议管理SUPPLIER AGREEMENT MANAGEMENT (9)9CM配置管理CONFIGURATION MANAGEMENT (10)10PPQA过程和产品质量保证PROCESS AND PRODUCT QUALITY ASSURANCE (11)11MA度量和分析MEASUREMENT AND ANALYSIS (12)12DAR决策分析和解决DECISION ANALYSIS AND RESOLUTION (13)13TS技术解决方案TECHNICAL SOLUTION (14)14PI产品集成PRODUCT INTEGRATION (15)15VER验证VERIFICATION (16)16VAL确认VALIDATION (17)17OPF组织过程聚焦ORGANIZATIONAL PROCESS FOCUS (18)18OPD组织过程定义ORGANIZATIONAL PROCESS DEFINITION (19)19OT组织培训ORGANIZATIONAL TRAINING (20)20IPM集成项目管理INTEGRATED PROJECT MANAGEMENT (21)21OPP组织过程性能ORGANIZATIONAL PROCESS PERFORMANCE (22)22QPM量化项目管理QUANTITATIVE PROJECT MANAGEMENT (23)23CAR因果分析和解决CAUSAL ANALYSIS AND RESOLUTION (24)24OPM组织性能管理ORGANIZATIONAL PERFORMANCE MANAGEMENT (25)1组织成熟度级别和类别2通用目标和通用实践3RD需求开发Requirements Development目的：引出、分析和建立客户、产品及产品组件的需求。
医院HIS系统需求规格说明书版本历史目录1方案总体介绍 (6)2文档介绍 (7)2.1文档目的 (7)2.2文档范围 (7)2.3读者对象 (7)2.4参考文档 (7)2.5术语与缩写解释 (7)3总体需求描述 (8)3.1背景情况 (8)3.2产品介绍 (9)3.3产品面向的用户群体 (9)4产品范围 (10)4.1产品建设目的 (10)4.2产品建设原则 (10)4.3产品建设范围 (10)5产品的功能性需求 (11)5.1功能层次图 (11)5.2顶层用例图 (12)5.3HIS系统顶层状态图 (12)5.4功能性需求列表 (13)5.5HIS系统分模块描述 (14)5.5.1挂号收费 (14)5.5.1.1病人登记 (14)5.5.2门诊管理 (16)5.5.2.1门诊诊断开药 (16)5.5.1.2病人病例信息查询 (17)5.5.1.3病人病例信息记录 (17)5.5.3药品管理 (18)5.5.3.1药品入库 (18)5.5.3.2药品出库 (22)5.5.3.3药品库存 (22)5.5.3.4药品使用记录 (23)5.5.4住院管理 (23)5.5.4.1入院登记 (23)5.5.4.2住院开药 (24)5.5.1.3病人信息查询 (25)5.5.4.4病人信息记录 (25)5.5.4.5看护记录 (26)5.5.4.6出院结算 (26)5.5.5医务人员管理 (27)5.5.5.1医务人员登记 (27)5.5.5.2部门维护 (27)5.5.5.3职务维护 (28)5.5.5.4值班人员管理 (28)5.5.6系统设置 (29)5.5.6.1系统权限管理 (29)5.5.6.2系统子模块管理 (30)5.5.6.3系统模块管理 (30)5.5.6.4系统用户管理 (31)5.5.6.5系统角色管理 (32)5.5.7个人管理 (32)5.5.7.1个人信息管理 (32)6产品的非功能性需求 (34)6.1用户界面需求 (34)6.2软硬件环境需求 (34)6.3产品质量需求 (35)7附录 (36)1方案总体介绍我国医院的信息处理基本上还停留在手工方式，劳动强度大且工作效率低，医师护士和管理人员的大量时间都消耗在事务性工作上，致使“人不能尽其才”；病人排队等候时间长，辗转过程多，影响医院的秩序，传统的医院模式正在面临着重大变革。
需求管理规范V21. 引言本文档旨在规范需求管理的流程和方法，以确保项目需求的准确性和可追溯性，并提高项目成功的几率。
2. 需求管理流程需求管理包含以下主要流程：2.1 需求识别和收集- 与相关利益相关方进行沟通，确定项目的主要目标和愿景。
- 识别和明确项目的业务需求和功能需求。
- 采用适当的工具和方法，收集和记录需求信息。
2.2 需求分析和验证- 对收集的需求进行细化和分析，确保需求的明确性和可测性。
- 在需求分析过程中，验证需求是否能够满足项目的目标和愿景。
- 与相关利益相关方一起评审和确认需求。
2.3 需求管理和变更控制- 设立有效的需求管理和变更控制机制，确保需求的稳定性和一致性。
- 记录和跟踪需求变更，评估变更的影响并做出决策。
- 对需求进行版本管理，确保对历史需求的追溯和审计。
3. 需求管理方法和工具为支持需求管理流程，可以使用以下方法和工具：3.1 用例分析- 使用用例分析方法，清晰描述系统与用户的交互行为和功能需求。
- 定义用例的前置条件、主法案、次法案和后置条件，帮助理解和验证需求。
3.2 业务流程图- 使用业务流程图表示系统的业务流程，帮助识别和理解业务需求。
- 标示流程中的各个步骤和决策点，帮助推导出系统功能需求。
3.3 需求跟踪工具- 使用需求跟踪工具，帮助记录、追踪和管理需求和变更。
- 可以使用电子表格或专业的需求管理软件进行需求的跟踪和管理。
4. 需求管理的最佳实践以下是一些需求管理的最佳实践：- 与相关利益相关方保持密切沟通，理解他们的需求和期望。
- 确保需求的准确性和可测性，避免模糊或冲突的需求。
- 尽早进行需求分析和验证，以减少后期的变更和风险。
- 设立合适的需求变更控制机制，确保变更的合理性和一致性。
- 定期对需求进行评估和审查，确保其与项目目标一致。
5. 结论本文档提供了一个需求管理的规范和方法，可以帮助项目团队有效管理和控制需求，提高项目的成功率和满足相关利益相关方的期望。
需求管理规范一、引言需求管理是软件开发过程中至关重要的一环，它涉及到对用户需求的收集、分析、确认和跟踪等工作。
本文旨在制定一套规范的需求管理流程，以确保需求的准确性、一致性和可追溯性，从而提高软件开发的质量和效率。
二、需求收集1. 需求来源需求来源可以包括用户、业务分析师、市场调研等。
需求管理团队应建立清晰的需求来源渠道，并及时记录和跟踪需求来源信息。
2. 需求收集方法需求收集可以通过面对面交流、问卷调查、访谈等方式进行。
需求管理团队应根据项目实际情况选择合适的需求收集方法，并确保收集到的需求充分、准确。
3. 需求分类和优先级收集到的需求应按照功能、性能、安全性等方面进行分类，并根据业务价值和紧急程度确定需求的优先级。
需求管理团队应与项目相关方共同确定需求的分类和优先级。
三、需求分析和确认1. 需求分析需求管理团队应对收集到的需求进行深入分析，包括需求的合理性、一致性和完整性等方面的评估。
在此基础上，需求管理团队可以进一步细化需求，并与项目相关方进行沟通和确认。
需求确认是指与项目相关方就需求的内容、范围、交付时间等方面达成一致。
需求管理团队应与项目相关方进行充分的沟通和协商，确保需求的准确性和可行性，并及时记录和确认需求变更。
四、需求跟踪和控制1. 需求跟踪需求管理团队应建立需求跟踪机制，追踪需求的实现情况和变更情况。
需求跟踪可以通过需求跟踪矩阵、需求跟踪工具等方式进行，以确保需求的全程可追溯。
2. 需求变更控制需求变更是项目开发过程中常见的情况，但需求变更必须经过合理的控制和评估。
需求管理团队应与项目相关方进行充分的沟通和协商，评估需求变更对项目进度、成本和质量的影响，并及时记录和确认需求变更。
五、需求文档管理1. 需求文档编写需求管理团队应编写清晰、详细的需求文档，包括需求描述、功能规格、用例等内容。
需求文档应具备易读性和易理解性，以便项目团队成员能够准确理解和实现需求。
2. 需求文档版本控制需求文档是一个动态的过程，随着需求的变更和确认，需求文档也需要进行相应的更新和版本控制。
零壹移动互联需求管理制度（2.0版，2015年）拟制人肖波日期20150630审核人日期批准人日期修改记录日期版本作者/修改者描述审核人20150701 V2.0 肖波修改需求开发管理流程与相关人员分工目录第一章总则 (1)第二章职责与分工 (2)第三章需求总体说明 (3)第四章需求提交 (4)第五章需求评估 (5)第六章需求开发 (7)第七章系统测试 (7)第八章需求上线 (8)第九章生产问题管理 (9)第十章需求变更控制与管理 (9)第十一章需求进度监控及查询 (10)第十二章附则 (11)第一章总则第一条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的工作内容、处理流程、参与-1-人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制订本制度。
第二条本制度适用于研发部的所有系统开发需求。
第三条本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。
第二章职责与分工第四条职责分工角色职责需求提交人员1.负责需求调研与编辑、编写业务需求申请表、提交业务需求审批。
2.根据需求评审和评估意见，及时修改业务需求，并发给需求相关干系人。
3.配合需求开发、测试人员提供业务知识的支持。
4.协助确认需求开发结果。
5.负责需求上线后验证工作。
项目管理人员1.负责需求审批、评估、技术文档评审、测试、上线等需求管理流程的整体协调工作。
2.组织需求评估会议。
3.处理测试申请----提交测试部门进行分配与测试。
4.维护需求信息、跟进需求变更以及需求处理进展，定期向相关领导、部门汇报需求进展。
需求开发负责人1.参与需求评审，从技术角度对需求实现方式、风险等进行评估。
2.制定需求开发计划，分配需求开发人员。
3.负责需求所有工作的沟通、协调管理。
4.负责需求开发进度、成员、变更管理。
5.负责或参与需求所有成果的审批。
需求评估人员1.从架构、业务、技术、风险等方面对业务需求的内容和实现方式进行全面评估，并提出评估意见。
4 管理4.1 RIPT（边缘智能感知）4.1.1 非认证模式4.1.2 WEB认证模式4.2 Band Select 5G优先接入AC L3sw POE AP1STA1G0/5 G0/21测试说明（含经验、教训、建议、小技巧、注意事项）：备注：4.3 用户管理4.3.1 同区域有相同使用需求的用户终端统一接入到相同的AP上AC L3sw POE AP2从STA G0/6AP3AP1G0/7主STA从STA，地址段为10.1.1.0/24给三个AP下发不同的ssid，使得都能够接入sta AC 上配置：vlan 19704.3.2 基于用户数的负载均衡AC L3sw POE AP2STA2G0/6AP1STA1相连，连入AC。
4.3.3 基于流量的负载均衡AC L3sw POE AP2STA2G0/6AP1STA1相连，连入AC。
配置要点说明：测试参考数据：补充测试图片等直观数据，若无留空4.4 公平调度开启公平调度结果如下测试说明（含经验、教训、建议、小技巧、注意事项）：4.5 Qos 限速功能4.5.1 Qos 限速功能（基于wlan 、ap 和用户）ACL3sw POEAP1STA2G0/5STA1PCG0/21测试参考数据：补充测试图片等直观数据，若无留空4.6 远程探针STA1POEPCGi 0/1Gi 0/1Fa 0/2Fa 0/24Fa 0/5AP2Fa 0/6测试步骤：4.7 RF PingSTAAC POEFa 0/2Fa 0/5测试步骤：4.8 射频资源管理(RRM)4.8.1 支持信道自动调整4.8.1.1 支持非wifi 信号干扰检测并调整信道 ACPOEFa 0/2Fa 0/5AP2Fa 0/6测试步骤：4.8.1.2 支持友商AP识别ACPOEFa 0/2Fa 0/5AP2Fa 0/6友商AP测试步骤：4.8.2 支持功率自动调整ACPOEFa 0/2Fa 0/5AP2Fa 0/64.9 AP接入管理4.9.1 通过AP的MAC地址进行AP设备合规性检查4.9.2 通过密码、证书、序列号方式进行ap接入认证4.10 非法AP有线端口检测。
零壹移动互联需求管理制度（2.0版，2015年）修改记录-1-目录第一章总则 (3)第二章职责与分工 (3)第三章需求总体说明 (5)第四章需求提交 (7)第五章需求评估 (7)第六章需求开发 (10)第七章系统测试 (11)第八章需求上线 (13)第九章生产问题管理 (14)第十章需求变更控制与管理 (14)第十一章需求进度监控及查询 (17)第十二章附则 (17)-2-第一章总则第一条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制订本制度。
第二条本制度适用于研发部的所有系统开发需求。
第三条本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。
第二章职责与分工第四条职责分工-3--4-第三章需求总体说明第五条需求分类按需求的提交部门可以分为研发部内部需求和业务部门需求。
按需求的内容可分为功能开发需求、平台网站类需求、数据需求。
按需求的紧急程度可以分为紧急需求和普通需求。
按需求开发工时的大小可以分为大型需求、中型需求和小型需求。
-5-第六条需求开发管理流程图需求开发管理流程为：（建议由项目管理员统一管理需求）需求管理主要包括以下内容：-6-需求的评估、开发、测试和上线阶段的管理细则遵循本制度中相关规定。
不涉及功能开发的平台类需求和数据需求可根据实际情况对需求开发管理过程的部分工作进行裁剪。
各阶段包含的活动及流程请见以下各章节中的详细描述。
第四章需求提交第七条需求提交为提高需求质量和处理效率，减少需求变更的次数，研发部各小组（开发、UI、测试）与产品部门就需求内容和实现方式等达成一致，可形成会议纪要存档，并与《需求申请表》（或邮件的形式）同时提交需求审批。
需求提交前需确认的内容包括：（一）与开发人员沟通，确定需求类型。
（二）需求的可行性分析。
各部门\小组进行可行性分析时需关注的内容为：1.研发部对需求的技术可行性进行初步分析，并帮助需求提交人员识别关联系统。
2.需求关联系统的归属开发人员就需求是否符合业务发展规划，以及需求对系统中已有业务功能的影响进行评估。
3.产品部、开发人员、测试人员对需求的业务逻辑、风险、合规等进行初步评估。
第八条需求会签原则上中、大型项目或需求，需要通过会签流程，征求各部门相关同事或领导审批，审批通过方可进入到后续开发流程。
此条制度视公司具体情况需要，灵活运用。
第五章需求评估第九条需求评估流程-7-需求评估流程说明及职责分工：（一）需求调研，需求文档完成开发后，产品经理需将需求提交至项目管理人员统一管理，项目管理人员需要将需求文档发送至研发部想干的各分部门会签。
会签通过后组织需求评估会议。
（二）项目管理员审核相关要素，包括：参与会签审批的干系人是否齐全，各干系人是否审批通过。
附：紧急需求另行处理（待完善，可划分为业务需求、紧急需求、生产QC等三种类型）（三）需求评估会上要评估的内容包括：-8-1.确认需求内容，分析需求合理性：需求开发负责人从技术层面对需求的技术可行性、性能等进行初步评估；测试部及其他相关产品部门从业务角度，对需求的业务逻辑、业务流程、业务目的、风险、合规等方面内容进行评估。
2.初步确认需求的实现方式。
3.初步评估需求的开发工作量。
4.明确需求系统设计、编码、测试、上线阶段的里程碑以及各阶段的交付物和负责人。
5.确定需求评估结论。
（四）需求评估完成后，填写《需求评估表》（待设计表格），需填写的内容包括：1.不予开发或者有变更的事项；2.该需求对其他关联系统的影响；3.需求所需人力、工时、里程碑以及整体评估结论等。
（五）评估表填写完毕后，评估人员需当场签字确认，项目管理员检查需求评估表的信息是否填写完整、准确。
第十条需求评估考虑层面需求评估主要从技术角度和业务角度进行考虑。
若需求评估通过，会后需求提交人员根据需求评估的结论更新需求，更新后的需求将作为研发部开发的最终依据（避免需求多次变更）。
若出现下列情形之一的，评估组出具意见后可退回需求至产品部重新更新需求或需要征得各部门领导审批。
（一）技术层面1.需对系统结构进行大规模改造的。
2.涉及系统架构变更的。
-9-3.与其他需求有重复的。
4.需求中有不合理事项的。
5.需求不明确需做补充的。
6.当前技术无法实现的。
7.评估时发生重大变更，且变更审批未通过的。
（二）业务层面1.与目前的业务操作流程、运营有矛盾的。
2.需大规模的更改原有的业务流程,增加大量人工后续处理成本。
3.业务需求与业务目的不符的。
4.新需求引起的新业务流程未在需求内一并体现的。
5.业务流程未理顺,业务规则未明确或者没有体现，有可能导致上线后,无法正常进行业务运作，或者存在运营风险的。
因以上原因被退回的需求，需求提交部门如对需求评估小组的评估结果存在争议，可提交各部门领导进行仲裁。
第六章需求开发第十一条需求开发流程（略，具体流程有开发部门制定）第十二条设计开发：需求评估通过后，由需求开发负责人安排、协调需求的设计和开发工作。
（一）开发人员根据需求评估会上通过的业务需求进行设计开发，同时完成《需求技术文档》。
（二）技术文档通过需求开发负责人的审核后，开发人员提交项目管理人员。
此技术文档有-10-必要从架构、环境、安全、性能等层面对技术文档进行评审，及时提出评审意见。
（三）项目管理员审核相关要素，包括：技术文档是否符合要求、评审人员参与度、是否评审通过。
审核通过后需求进入开发阶段。
如审核不通过，项目管理员将技术文档退回给开发人员，开发人员处理完毕后再提交相关干系人评审。
（四）技术文档评审通过后，开发人员将评审通过后的技术文档更新到SVN中并开展开发工作。
紧急需求必须通过需求评估后，才可开展设计开发工作。
设计开发阶段的部分工作在项目管理员审批通过后，可根据实际情况进行裁剪。
第十三条单元测试&集成测试（一）编码完成后，开发人员需进行单元测试、系统集成、编译部署、及主功能测试。
测试通过后编写《单元测试报告》、版本部署操作文档，并提交需求开发负责人审核。
（二）需求开发负责人审核通过后，开发人员将源代码、《单元测试报告》、版本部署操作文档更新到SVN，需求开发负责人将《单元测试报告》、版本部署操作文档上传到SVN。
第七章系统测试第十四条系统测试：单元测试（包含系统集成）通过后进入系统测试阶段，系统测试流程为：-11-系统测试流程说明：（一）需求开发负责人向项目管理员提交系统测试申请。
（二）项目管理员审核相关要素，包括：需求是否通过评估、技术文档是否通过评审、单元测试是否通过、《需求技术文档》、《单元测试报告》及版本部署操作文档是否上传SVN。
审核通过后项目管理员向研发部质量管理部测试经理下系统测试通知单。
如审核不通过，返回开发子流程。
-12-（三）测试经理分配系统测试人员。
（四）系统测试人员验证SVN中的技术文档、版本部署及需求主功能。
验证通过后制定测试计划，如验证不通过，返回开发子流程。
（五）系统测试计划、测试案例、测试报告由系统测试人员编写并组织评审，系统测试主管和需求开发负责人必须参加评审。
（六）补充：测试计划、测试方案、测试案例等测试文档，设计时间参考第六条（需求开发管理流程图）；测试工作遵循尽早参与的原则，遇特殊情况，测试文档也可在测试启动时执行。
第八章需求上线第十五条需求上线：测试验收工作结束后，进入需求上线阶段。
需求上线主要分为业务上线、技术上线。
第十六条需求上线流程需求上线流程说明：（一）需求上线申请需求测试通过后，测试经理检查测试负责人提交的测试工件，审核通过后提交项目管理员协调开发安排上线时间。
（二）上线实施后，需求相关人员需进行上线验证：（三）若上线复核或验证失败，则开发人员将上线版本从生产环境中回退，需求转入开发流程。
第十七条试运行为了对系统的功能、性能、可靠性、稳定性、需求涉及业务和系统的影响情况进行验证，需求上线后，由研发部、产品部，以及其他领导共同商榷，根据项目实际情况实行产品试运行。
试-13-运行的时间、方案、通过标准暂未制定。
第九章生产问题管理第十八条生产问题：指存在于生产系统中的异常现象或缺陷，不包括办公设备、网络故障等非生产系统引起的故障。
生产问题处理流程说明：（一）技术人员收到生产问题后，对问题根源进行深入分析，并对系统问题进行处理。
如不属于非系统问题，技术人员拒绝报障并说明原因，测试人员需整理归档。
（二）生产问题修复完毕后部署到测试环境，提交测试流程。
（三）技术人员提交测试申请，项目管理员审核通过后下测试通知单。
（四）生产问题测试通过后，上线流程与需求上线流程一致。
第十章需求变更控制与管理第十九条需求变更：指研发部受理需求后，需增加、修改、删除需求内容，或将需求挂起、退回、取消的现象。
需求变更控制与管理流程：-14-需求变更控制与管理流程说明及职责分工：（一）需求变更申请人填写《需求变更申请表》（待设计表格），详细说明需求变更的类型、变更原因及变更内容。
（二）需求变更申请人通过邮件\OA\或其他部门间工作联系函将需求变更申请提交需求开发负责人、相关测试负责人及关联系统负责人审批。
审批通过后需求开发负责人判断是否为重大变更。
如审批不通过，评审组说明原因后将需求变更申请退回申请人。
（三）需求变更属于重大变更时，需求变更申请人组织需求变更评审会，由评审组成员共同确定是否允许变更。
如果不属于重大变更，需求开发负责人有权决定是否允许需求变更。
满足以下任一条件的需求变更都属于重大变更。
1.需求变更引起开发工时增加量：大型需求≥10%，中型需求≥15%，小型需求≥20%（仅删除需求内容的变更可不考虑）。
2.需求变更导致里程碑点推迟的。
-15-3.需求变更涉及关联系统变化的。
4.需求变更可能存在风险、合规问题的。
5.需求变更涉及或影响已有业务流程、规则、后台运营的。
（四）需求变更评审参与人员：需求开发负责人、需求提交人员、开发人员、测试负责人、测试人员、关联系统负责人、关联产品部门。
如不属于重大变更，可裁剪此活动。
评审的内容包括：1.技术可行性分析。
2.需求合理性、业务方案可行性分析。
3.关联系统影响分析。
4.变更风险分析。
5.对需求工作量、工期、成本等的影响分析。
6.评审结论：（1）评审通过：需求开发负责人在《需求变更申请单》（待设计表格）填写需求变更详细方案。
（2）评审不通过：在《需求变更申请单》中填写否决意见及原因。
（五）需求变更评审结束时，需求开发负责人在《需求变更申请单》中填写需求变更评审意见，与会人员签字确认。
（六）需求变更评审会后，需求开发负责人将《需求变更申请单》提交项目管理员审批。
审批通过后业务人员更新业务需求。
