信息系统需求管理方案
需求管理方案
修改记录
目录
1. 概述 (1)
1.1 现状分析 (1)
1.2 目的 (1)
1.3 适用范围 (1)
2. 岗位与职责 (2)
3. 需求流程说明 (3)
3.1 需求分类 (3)
3.2 需求管理流程及制度 (5)
3.2.1 整体流程 (5)
3.2.2 需求收集 (6)
3.2.3 需求汇总初步分析 (7)
3.2.4 需求评审分析 (8)
3.2.5 需求开发 (10)
3.2.6 需求测试 (11)
3.2.7 需求上线 (12)
3.2.8 需求变更 (12)
4. 需求管理措施 (14)
5. 过程及成果资料 (14)
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上转交测试人员。