系统需求变更申请表

质量管理体系第三层次文件IT系统管理办法（计算机网络维护管理程序)文件编号:Q/SPTD—3009-A版次：A-0编号：2008年10月10日发布 2008年10月15日实施上海邮电设计院有限公司计算机网络维护管理程序第一章总则第一条为不断提高上海邮电设计院有限公司设计生产力，提升网络运行维护管理工作的手段。

明确职责、建立日常管理维护制度和故障（灾难）处理流程,加强公司网络基础平台运行管理和设备维护,保障公司网络基础平台稳定运行，特制定本程序.第二条本程序适用范围为上海邮电设计院有限公司内部网络及全体人员。

第三条本程序主要内容包括部门职责、网络安全制度、维护工作等。

第四条本程序由公司风险管理部解释。

第五条本程序自发布之日起施行.第二章管理职责第六条风险管理部（IT中心）职责一、风险管理部IT中心（以下简称IT中心）是整个公司网络基础平台的管理及维护主体。

二、IT中心负责制定（修改）计算机网络维护管理程序。

三、IT中心负责网络维护方案审核。

四、网络发生重大故障或灾难时,IT中心负责必要的资源协调和处理工作，启动故障（灾难）处理计划。

五、IT中心负责组织落实网络维护安全措施，确保网络安全稳定运行。

第七条职能部门职责一、计划财务部负责计算机类设备的固定资产管理工作.二、各部门应协助配合IT中心进行各项维护管理工作。

第三章设备管理第八条网络设备采购一、风险管理部IT中心应对网络设备的采购作出规划,根据公司业务发展情况及信息系统项目的实施，添置或置换服务器，核心交换机，路由器等核心网络设备。

二、新设备的采购申请由风险管理部或业务部门填写《计算机类设备采购申请单》,风险管理部负责对新设备的采购申请进行审核；重大采购需由公司领导审批。

三、网络设备的使用期限参照财务部门固定资产管理办法执行。

对于达到使用年限的网络设备可以由IT中心提出置换新设备。

四、合同制、派遣制、劳务新员工由风险管理部按人力资源处调令配发计算机。

软件项目的需求变更管理作者：来源：《计算机世界》2010年第48期近年来，国内各级政府部门、企事业单位在信息化建设上取得了长足进步，但由于不少组织整体管理水平相对较低，在信息系统建设上缺乏系统、长远的战略规划，没有先进、适用、可行的管理实践理论作为指导，因此很多软件项目没有在预定的范围、投资总额、工期内完成，工期延期、延误成为普遍现象。

需求管理的常见误区软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。

软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。

“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。

例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

（3）确定调研方案

调研方式
主导型
用户经验不足，认识不清晰，需要调研人员整理需 求概要内容，提交给用户进行分析和初步确认，最 终由用户和调研实施人员对需求内容进行细化、确 认的过程。 对调研人员要求较高； 与用户真实意图可能存在偏差。

（3）确定调研方案

调研方式
引导型
用户有较为完整、系统的知识、经验积累，调研人 员引导用户将需求阐述完整、清晰，最终由用户对 需求进行确认的过程称之为引导型调研。 用户和调研实施人员相互配合程度高 ； 此种调研方式的进度和质量风险最小 。


……
需求工程的主要阶段
需求工程 需求开发 需求管理
需 求 获 取
需 求 分 析
需 求 规 约
需 求 验 证
变 更 控 制
版 本 控 制
需 求 跟 踪
需 求 状 态 跟 踪
需求规格说明书
需求开发
需求验证 —— 帮 助确定实现了正确 的需求 需求获取 —— 搜集 与探索需求的过程
需求开发 过程
组织机构或用户对系统的高层次目标要求用户使用系统必须要完成的任务必须要实现的软件功能内容层次常见非功能需求可用性计划开机时长平均故障时间间隔mtbf等高效性系统如何高效利用处理器磁盘空间通讯带宽灵活性向产品中加入其它功能需要多大劤力完整性阻止未经授权的访问修改互操作性与其他系统交换数据或服务可靠性无错误的软件执行稳健性系统遭遇无效数据或其他干扰时继续正常运作的程度易用性用户友好易于使用符合人机工程维护性是否易于修正一个缺陷或改劢软件移植性把软件从一个操作系统移植到另一个所需的劤力支持平台数重用性为某个应用所设计的模块能被其他应用重复所用的程度测试软件模块或者所整合产品的难易度量化需求需求类型测量范例观感接受率易用性错误率性能与速度响应时间可靠性停工时间移植性平台数稳健性致命非致命错误比例维护性修改所需的时间和工作量大小源代码行数sourcelinescodesloc认证所符合的诸标准需求的来源调研前活动调研前活动调研实施调研实施识别调研范围组建调研团队确定调研方案调研准备前期沟通识别调研范围组建调研团队确定调研方案调研准备前期沟通决定了需求调研对象调研参与人员和调研周期的长短

软件需求分析报告—（模板）目录1. 范围 02。

总体要求 02。

1总体功能要求 02。

2软件开发平台要求 02。

3软件项目的开发实施过程管理要求 (1)2.3.1 软件项目实施过程总体要求 (1)2.3.2 软件项目实施变更要求 (1)2。

3.3 软件项目实施里程碑控制 (1)3. 软件开发 (2)3.1软件的需求分析 (2)3.1。

1 需求分析 (2)3.1.2 需求分析报告的编制者 (3)3.1。

3 需求报告评审 (3)3.1。

4 需求报告格式 (3)3.2软件的概要设计 (3)3。

2。

1 概要设计 (3)3。

2。

2 编写概要设计的要求 (3)3.2.3 概要设计报告的编写者 (3)3。

2.4 概要设计和需求分析、详细设计之间的关系和区别 (3)3。

2.5 概要设计的评审 (3)3.2.6 概要设计格式 (3)3.3软件的详细设计 (4)3。

3。

1 详细设计 (4)3.3.2 特例 (4)3。

3。

3 详细设计的要求 (4)3.3.4 数据库设计 (4)3。

3.5 详细设计的评审 (4)3。

3。

6 详细设计格式 (4)3.4软件的编码 (4)3。

4。

1 软件编码 (4)3。

4.2 软件编码的要求 (4)3.4.3 编码的评审 (5)3.4。

4 编程规范及要求 (5)3.5软件的测试 (5)3.5.1 软件测试 (5)3。

5。

2 测试计划 (5)3.6软件的交付准备 (5)3。

6。

1 交付清单 (5)3.7软件的鉴定验收 (6)3。

7.1 软件的鉴定验收 (6)3.7。

2 验收人员 (6)3.7。

3 验收具体内容 (6)3。

7。

4 软件验收测试大纲 (6)3.8培训 (6)3。

8。

1 系统应用培训 (6)3.8.2 系统管理的培训（可选) (7)附录A 软件需求分析报告文档模板 (9)附录B 软件概要设计报告文档模板 (21)附录C 软件详细设计报告文档模板 (33)附录D 软件数据库设计报告文档模板 (43)附录E 软件测试(验收）大纲.................................................................... 错误!未定义书签。