信息系统需求管理方案Word文档下载推荐.docx
《信息系统需求管理方案Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《信息系统需求管理方案Word文档下载推荐.docx（14页珍藏版）》请在冰豆网上搜索。
需求提出时，不够细化、完全，不能完整、准确的反映客户的实际需求。
没有考虑整体性和关联性，有些需求只适用于个别分支机构；
需求上存在理解差异，待功能交付后，用户提出所见非所求，造成需求、bug争论不休，需求变更及bug修复频繁，影响系统稳定并造成成本消耗。
需求提交方式多样，有很多口头或邮件交流内容，存在需求过于简单描述不清。
没有划定需求的优先级，需求进度难以控制，过多的争论造成了临时事务增多，
需求提出后，经过一段时间的开发，后续无人跟踪。
1.2目的
为了更规范更有效的管理需求工作，保证需求工作的可控性，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，特制定本管理办法，相关人员必须严格按照本办法执行新需求相关工作。
1.3适用范围
本制度适用的读者包括：
主要干系人：
项目经理、需求管理员、开发负责人
相关干系人：
实施人员、技术支持人员、开发人员、项目管理专员。
2.岗位与职责
主要干系人职责：
角色
主要职责
项目经理
1.负责需求收集，与甲方沟通、确认需求相关事宜并编写需求文档。
2.配合开发人员提供业务知识的支持。
3.参与需求评审分析。
4.根据需求评审意见，及时修改需求文档，并发给需求相关干系人。
5.维护需求信息、跟进需求变更以及需求处理进展，定期向相关领导汇报。
6.负责需求测试，制定需求测试计划，分配测试任务，对系统功能进行测试确认。
7.测试存在问题的及时反馈开发负责人和需求管理员，并跟进解决情况，完成之后重新进行测试。
8.内部测试完成之后负责与甲方沟通，进行测试，完成需求结果确认。
9.负责需求上线。
需求管理员
1.负责定期收集汇总、整理分类各项目提报的需求并进行审批，与提交人及总公司人员进行沟通确认。
2.组织项目经理、开发人员等召开需求评审会议，从架构、业务、技术、风险等方面对业务需求的内容和实现方式进行全面评估，并提出评估意见，确定需求解决方案。
3.负责收集开发负责人反馈的需求解决计划，并及时告知各项目经理。
4.跟踪需求解决进展情况，协调项目组与开发人员相关事宜的沟通。
5.负责与总公司人员沟通需求，跟踪总公司需求解决进度。
6.定期到各项目组与客户方进行沟通，了解现场问题，收集需求。
7.负责需求开发结果的确认。
开发负责人
1.参与需求评审，从技术角度对需求实现方式、风险等进行评估，确定技术路线。
2.负责向需求管理员反馈开发计划
3.负责需求开发所有工作的沟通、协调管理。
4.负责需求开发进度、成员管理。
5.负责或参与需求所有成果的审批。
6.参与或指定开发人员协助需求提交人员与甲方对于需求的沟通、确认。
相关干系人职责：
实施人员
1.协助项目经理进行需求收集。
3.需要时参与需求评审分析。
4.协助项目经理进行需求测试。
5.协助项目经理进行需求上线。
技术支持人员
1.需求收集阶段协助项目经理与甲方对于需求的沟通、确认。
帮助项目经理分析、确定业务需求。
2.必要时提供技术支持，配合项目经理完成测试环境的搭建。
开发人员
1.协助项目经理与甲方对于需求的沟通、确认。
2.负责需求开发的具体实现。
3.当项目经理对需求确认不通过时，按照反馈结果对需求进行修改。
项目管理专员
1.参与需求评审分析，从项目进度、质量等方面进行评审分析。
3.需求流程说明
3.1需求分类
按照需求内容大致可分为：
需求类型
需求类型定义
功能性
需
求
新业务功能
已有系统中没有此功能，需要在原有基础上新增功能
功能改进
当前系统已经有此功能，因组织架构、制度规范、业务处理流程等发生变化，需要对现有系统的某些功能进行优化调整
需求变更
系统功能上线前，要在原有需求的基础上增加、修改或删除需求内容，但需求内容的变动会引起成本增长过大、对现有业务影响较大、或可能存在风险、合规等问题
系统问题
系统现有功能可以正常使用，但是性能、安全、底层处理逻辑和架构等即将或者未来可能成为业务进一步扩张的瓶颈
界面类需求
前端页面设计、开发、更新修改及维护。
非功能性需求
不直接与系统的具体功能相关的一类需求。
例如：
安全性、可扩展性、响应时间、交付要求等。
按照优先级可分为：
采取的措施
立即解决
1、系统必须实现的，没有其功能就无法完成正常的日常工作及业务处理。
2、严重影响系统要求或基本功能的实现，且没有办法更正。
对于这类需求在项目实施过程中需重点投入资源，优先实现。
高级优先
1、严重影响系统要求或基本功能的实现，但存在合理的更正办法。
2、国家或行业法律法规标准、政府下文要求的。
3、事先已经约定的功能。
4、不重要但做了会产生极佳效果。
正常排队
1、使用者操作不便等对正常业务影响不大的。
2、实现这些需求将增强系统的性能
3、系统最终所要求的
如果项目实施中出现进度、资源等方面的冲突时，可与客户沟通延迟到下一版本。
低级优先
1、系统附加功能
2、使系统更完美，属于锦上添花。
根据项目时间进行安排，排在最后。
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：
《解决方案》
升级会员 