信息系统需求管理方案

信息系统需求管理方案
信息系统需求管理方案

需求管理方案

修改记录

目录

1. 概述 ................................................. 错误!未定义书签。

现状分析...................................................... 错误!未定义书签。

目的.......................................................... 错误!未定义书签。

适用范围...................................................... 错误!未定义书签。

2. 岗位与职责 ........................................... 错误!未定义书签。

3. 需求流程说明.......................................... 错误!未定义书签。

需求分类...................................................... 错误!未定义书签。

需求管理流程及制度............................................ 错误!未定义书签。

整体流程 ................................................. 错误!未定义书签。

需求收集 ................................................. 错误!未定义书签。

需求汇总初步分析 ......................................... 错误!未定义书签。

需求评审分析 ............................................. 错误!未定义书签。

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

需求测试 ................................................. 错误!未定义书签。

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

需求变更 ................................................. 错误!未定义书签。

4. 需求管理措施.......................................... 错误!未定义书签。

5. 过程及成果资料........................................ 错误!未定义书签。

1.概述

1.1现状分析

目前项目需求管理的过程中,在需求收集、流程设置、工作效率等方面存在着一些问题,导致需求得不到及时有效的解决、项目推进缓慢、客户满意度降低等。比较常见问题如下:

需求提出时,不够细化、完全,不能完整、准确的反映客户的实际需求。

没有考虑整体性和关联性,有些需求只适用于个别分支机构;需求上存在理解

差异,待功能交付后,用户提出所见非所求,造成需求、bug争论不休,需求

变更及bug修复频繁,影响系统稳定并造成成本消耗。

需求提交方式多样,有很多口头或邮件交流内容,存在需求过于简单描述不清。

没有划定需求的优先级,需求进度难以控制,过多的争论造成了临时事务增多,需求提出后,经过一段时间的开发,后续无人跟踪。

1.2目的

为了更规范更有效的管理需求工作,保证需求工作的可控性,明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责,特制定本管理办法,相关人员必须严格按照本办法执行新需求相关工作。

1.3适用范围

本制度适用的读者包括:

主要干系人:项目经理、需求管理员、开发负责人

相关干系人:实施人员、技术支持人员、开发人员、项目管理专员。

2.岗位与职责

主要干系人职责:

相关干系人职责:

3.需求流程说明3.1需求分类

按照需求内容大致可分为:

按照优先级可分为:

3.2需求管理流程及制度

3.2.1整体流程

整体流程示意图:

需求管理主要分为6个阶段:需求收集、需求汇总初步分析、需求评审分析、需求开发、需求测试、需求上线。

需求开发的管理流程:

3.2.2需求收集

3.2.2.1主要参与人员

项目经理、实施人员、技术支持人员

3.2.2.2工作内容及要求

(1)项目经理针对用户提出的需求,采用访谈、会议、问卷等形式收集基础信息(包括相关支持文件,例如会议纪要、下发文件等)(2)从业务方面判断是否合理,若不合理应第一时间告知用户,并解释清楚原因。或是分析判断该需求是否可以通过系统已有的其他功能来实现。

(3)按照模板编写《需求文档》(需求描述要求清晰、全面,对于文字难以描述的可采用示意图、原型设计等方法)。

(4)按照项目组需求确认单样式填写《需求确认单》,并由甲方签字确认。

(5)每周三12点之前汇总本项目需求(含相关支持材料)发送至需求管理员邮箱。紧急需求可立即发送需求管理员邮箱并电话告知。

(6)项目经理及时将新需求录入jira系统提交至需求管理员,并上传由客户签字的需求确认单及其它相关支持材料。紧急需求可提交jira之后立即

电话告知需求管理员。

备注:项目组内的具体工作流程,项目经理根据实际情况进行制定。

3.2.2.3成果资料

《需求确认单》、《需求文档》、《问题确认单》

3.2.3需求汇总初步分析

3.2.3.1主要参与人员

需求管理员

3.2.3.2工作内容及要求

(1)每天对各项目提报的需求进行收集汇总、分类整理形成《需求汇总表》。

(2)进行审批,对填写不符合要求、描述不清楚的及时退回各项目经理。

(3)判断需求是否合理,若不合理及时告知项目经理,项目经理应第一时间告知用户,并解释清楚原因。或是分析判断该需求是否可以通过系统已有的其他功能来实现。

(4)联系总公司相关人员,询问公司系统版本是否已经实现该功能或类似功能。

(5)每天将经过审批之后的需求在jira上及时提交给开发负责人,每周四将经过分析确认的各项目组的需求汇总发送至开发负责人邮箱。

(6)若开发负责人对需求有疑义,需求管理员组织项目经理、开发负责人等相关干系人召开需求评审会议,确定需求解决方案。

3.2.3.3成果资料

《需求汇总表》

3.2.4需求评审分析

需求分析总体流程如下:

3.2.

4.1主要参与人员

项目经理、开发负责人、需求管理员

根据具体情况可通知技术支持人员、开发人员、项目管理专员等相关干系人参会。

3.2.

4.2工作内容及要求

(1)需求管理员组织人员对需求设计从技术和业务方面进行可行性分析,对业务逻辑、业务流程等进行评估。

若出现以下几种情况可退回项目经理:

技术层面:

与其他需求有重复的。

需求中有不合理事项的。

需求不明确需做补充的。

业务层面:

与目前的业务操作流程、运营有矛盾的。

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

若出现以下几种情况需发送给部门领导进行审批。

技术层面:

需对系统结构进行大规模改造的。

涉及系统架构变更的。

当前技术无法实现的。

业务层面:

需大规模的更改原有的业务流程,增加大量人工后续处理成本。

(2)项目经理根据需求评审结果完善《需求文档》,形成最终需求。

(3)分析总公司系统是否已经实现该功能或类似功能,若已实现由需求管理员负责与总公司相关人员进行沟通获取升级包。

(4)如果总公司版本未实现该功能,需讨论分析并确定该需求是本地设计开发还是总公司设计开发。

若为总公司开发,由需求管理员及时将需求提交到jira系统并与总公司人

员联系,确定完成时间。

(5)开发负责人确认需求的实现方式,评估需求的开发工作量,确定需求开发完成时间及开发人员,形成《解决方案》,并在jira系统中备注解决计划。

3.2.

4.3成果资料

《解决方案》、《需求文档》、《需求汇总表》

3.2.5需求开发

3.2.5.1主要参与人员

开发负责人、开发人员

3.2.5.2工作内容及要求

开发负责人:

(1)每天及时登录jira系统,收集需求管理员发送的需求,从技术方面进行可行性分析,并判断该功能是否会影响已有的业务功能,若存在问题应及时告

知需求管理员,由项目经理对需求进行变更并告知甲方,如无问题需在2

个工作日内向需求管理员反馈开发计划并在jira系统中注明。

(2)对于有疑义的,联系需求管理员组织需求评审分析会议,从业务、技术角度对需求实现方式、风险等进行评估,并制定解决计划。

(3)制定需求开发计划,分配需求开发人员,确定技术方案。

(4)及时向需求管理员反馈开发计划。

开发人员:

(1)根据需求评估通过的需求文档及开发计划按时进行设计开发,并在jira中备注解决进展情况。

(2)如果涉及到对数据库结构的变动修改,应及时更新维护数据库结构说明书。

(3)编码完成后,开发人员需进行编译部署、单元测试。

(4)将开发成果提交开发负责人审核确认。

(5)无问题之后在jira上转交测试人员。

3.2.5.3成果资料

《数据库设计说明书》(更新)、《部署文档》、《更新说明》、需求更新包(包含数据脚本)

3.2.6需求测试

3.2.6.1主要参与人员

项目经理、实施人员

3.2.6.2工作内容及要求

(1)制定需求测试计划,分配测试任务,对系统功能进行测试。

(2)测试若存在问题及时反馈开发负责人和需求管理员,在jira中备注测试情况,并跟进解决情况,完成之后重新进行测试。

(3)内部测试完成之后,向甲方提出测试申请,由甲方人员进行系统测试,完成需求结果确认。

3.2.6.3成果资料

《测试报告》、《系统用户操作手册》(更新)

3.2.7需求上线

3.2.7.1主要参与人员

项目经理、实施人员、开发人员

3.2.7.2工作内容及要求

(1)项目经理与甲方沟通,提起上线申请。

(2)对数据库及应用程序进行备份。

(3)系统升级上线,并进行上线验证。

(4)若上线验证失败,则将上线版本从生产环境中回退,需求转入开发流程。

(5)维护更新系统操作手册,上线之后3个工作日内针对适用人员进行操作培训。

(6)项目经理负责与客户确认需求最终结果,由甲方人员在《需求确认单》上进行签字确认并上传jira,关闭需求,进行需求归档。

(7)需求管理员跟进确认结果,重要需求需要需求管理员直接与甲方人员进行确认。

3.2.7.3成果资料

《需求确认单》、《需求汇总表》

3.2.8需求变更

需求变更:指开发人员受理需求后,需增加、修改、删除需求内容的现象。

需求变更流程图如下:

3.2.8.1主要参与人员

项目经理、需求管理员、开发负责人

3.2.8.2工作内容及要求

(1)项目经理根据需求变更内容填写需求变更文档。

(2)按照项目组需求确认单样式填写需求变更,并由甲方签字确认。

(3)需求变更后重新提交jira系统。

(4)需求管理员进行审批,不通过退回至项目经理,通过之后判断是否属于重大需求变更。

(5)重大需求变更需求管理员组织项目经理、开发负责人及相关干系人召开需求评审会,确定解决方案。

(6)开发负责人2个工作日内制定开发计划,并向需求管理员反馈开发计划。

3.2.8.3成果资料

《需求变更文档》

4.需求管理措施

(1)紧急需求项目经理需及时在jira系统中提报需求管理员并电话告知,需求管理员审核之后发送给需求开发负责人,开发负责人需在1个工作日内反馈

解决计划。

(2)普通需求项目经理及时在jira系统中提报需求管理员,需求管理员审核之后发送给开发负责人,开发负责人在2个工作日反馈解决计划。

(3)需求管理员对各项目组需求提报时间的及时性、需求内容的规范性进行审核,并纳入绩效考核。

(4)需求管理员对开发负责人反馈开发计划的及时性纳入绩效考核。

(5)需求评审分析会议可根据实际情况采取现场会议、语音会议等方式进行,参会人员的参加情况纳入绩效考核。

(6)需要部门领导协助的,需在2个工作日的给予指导或反馈解决方法。

(7)各部门人员按照上文职责认真履职,积极配合。

(8)对于提交到总部的需求如果一周内未进行反馈解决计划或未按照反馈时间解决的,需求管理员将该部分需求以邮件的方式发送部门一级领导,抄送相

关分管副总及总经理。

5.过程及成果资料

附件1:《需求文档》

附件2:《需求变更文档》

附件3:《问题提报单》

附件4:《数据库结构说明文档》(已有,如有变动时进行更新)

附件5:《部署文档》

附件6:《更新说明》

附件7:《测试报告》

附件8:《系统用户操作手册》(已有,如有变动时进行更新)

附件9:《需求汇总表》

附件10:需求更新包

附件11:《需求提交情况统计表》

附件12:《解决方案》

相关主题
相关文档
最新文档