附件1-远东宏信信息化需求管理办法（稽核建议）.docVIP

远东宏信有限公司 需求管理办法 信息管理部 需求与研发中心 2013年5月 修订记录 版 本 编 号 版 本 日 期 修 订 者 说 明 A/0 2013/5/27 包骏 制定 总则 为了加强需求分析评估及管理的规范性，提高需求方案设计和实施策略选择的系统性和科学性，以保证信息化建设能够有效、持续的满足业务的需求，根据公司《信息化建设管理规定》，特制定此办法。 本办法适用于公司以及下属全资或控股子公司所有与信息化系统建设相关的项目。 本办法所称的需求是指由公司内各部门提出，需要借助信息技术手段来实现的需求。 本办法所指需求管理是指从IT需求提出后到系统设计开发阶段前的整个过程，主要内容包括需求分类与需求组织、需求里程碑管理及需求管理规范。其中需求里程碑管理包括需求的里程碑划分、关键任务规范，需求管理规范包括变更管理。 本办法适用于参与IT项目实施过程中需求管理的各部门。 需求分类与需求组织 根据需求的应用范围和我司实际情况，分为A/B/C三类项目需求。A类需求应用对象为单个部门；B类需求应用对象为公司或多部门，但可定位到具体部门；C类需求应用对象为公司或多部门，但无法定位到具体部门。 根据项目的实施性质分为应用实施（软件包）和定制开发，不同的实施性质会影响需求里程碑管理的差异性。 需求管理团队由需求申请人、需求审批人、关键用户、需求设计人员共同组成。需求申请人由需求提出方或代表担任，负责需求申请、需求变更和需求方案编制；需求审批人由战略管理部或相关部门担任，负责需求方案评估；关键用户由需求归口部门（A/B类项目需求）或公司指定人员（C类项目需求）担任，负责需求调研与分析；需求设计人员由信息管理部需求分析师或供应商担任，负责需求设计和需求评审； 需求管理团队需全程参与需求管理过程，辅助协调相关负责人的任务执行。 需求里程碑管理 需求管理分为三大阶段，业务需求、用户需求和功能需求，其中业务需求阶段包括需求申请/变更、需求方案编制与评估；用户需求阶段包括需求调研与分析；功能需求阶段包括需求设计和需求评审，如图一所示。 需求申请：需求申请人对业务需求整理成文档后，起草《需求申请表》，提交至所在部门及相关干系部门进行审核。由相关部门牵头成立项目前期工作组，明确需求管理团队的组织架构。 需求方案编制与评估：相关部门对《需求申请表》进行审核并出具《需求评审表》。审核通过后，用户负责对需求进行概要分析，结合对内、外部资源的评估，确定建设策略，并将结论形成《需求方案》，提交至项目执行小组。项目执行小组进行需求方案评估后出具《需求方案评估意见》。方案评估通过后，由需求申请人负责起草《立项申请书》，并提交审批。 需求调研与分析：关键用户负责制定详细的《调研计划》和《调研提纲》，协同需求提出部门及其他相关部门，对业务需求进行详细的调研和分析，最终形成《业务需求分析书》，同时此交付物也是招标文件中的组成部分。《业务需求分析书》的内容可依据项目具体情况做裁剪，原则上必须遵循把系统要解决的业务逻辑、要实现的功能描述清楚。 需求设计：需求分析人员在《业务需求分析书》的基础上，根据项目实施性质进行差别管理，当项目为应用实施时，编制《产品功能差异说明书》，当项目为定制开发时，编制《需求规格说明书》，并提交至项目组评审。 需求评审：由需求分析人员组织相关业务部门召开需求设计评审会议，使双方对需求的理解达成共识。《需求规格说明书》/《产品功能差异说明书》由项目组根据评审意见修订并确认，作为启动系统设计开发阶段必要输入条件。 图一：需求管理操作流程 需求管理规范 需求方案变更是指在需求方案审批通过后，启动实施之前对需求内容的增减、取消和调整的过程。 需求单位根据业务需求变化，填写《需求变更申请表》，按照本办法规定的需求方案评估程序执行。 信息管理部负责根据审批后的《需求变更申请表》，调整需求方案相关内容。 附则 本办法由信息管理部牵头制定，相关条款由信息管理部负责解释。 本办法中提到的交付物在《远东宏信信息化需求管理操作指引》中列明。 制度名称叫《远东宏信有限公司需求管理办法》，但是从适用范围及后文看，仅针对系统建设项目的需求管理。日常的非单体项目类IT需求好像并不在范围内。 制度名称与适用范围是否不尽一致？ 整体感觉该制度是针对已有的《信息系统建设项目管理办法》的需求环节的具体规范。 是否需要明确相关负责人？是指项目的负责人？还是上述需求申请人、审批人等？ 建议明确。 与3.3中的相关部门是指同一个吗？目前看有歧义。 文中出现了：项目前期工作组、项目执行小组、项目组等称谓，不尽统一，建议在前文对制度中涉及的相关角色、组织集中定义（名称、职责等），后文全部引用该定义。 根据《信息化建设管理规定》规定（上文提及本办法依此规定制定），立项审批需走IT立项流程，