需求管理要求

《需求管理要求》由会员分享，可在线阅读，更多相关《需求管理要求（7页珍藏版）》请在装配图网上搜索。

1、需求管理要求V1.0目录1 需求受理原则 11.1 追索业务背景 11.2 业务梳理清晰 11.3 无重复、杂糅现象 11.4 内部沟通一致 11.5 外部沟通一致 21.6 投入产出合理 21.7 制度匹配原则 21.8 需求分期实现 31.9 确保按时上线 32 需求管理流程 32.1总图 错误！未定义书签。2.2 预受理 32.3 正式受理 42.4 需求分析 42.5 需求确认 42.6 需求跟踪 41 需求受理原则1.1 追索业务背景【说明】 任何业务需求都必须了解其业务出发点，特别在业务部门跳过业务背景的描述，直接 提出功能点时，尤其需要追根索源了解业务诉求，通过了解业务背景，可以

2、优化需求实现 方式，甚至有可能改变功能点，即改变需求实现方式。在需求文档中可通过增加备注或描述业务背景章节帮助需求阅读人员更深入了解需 求的产生过程。1.2 业务梳理清晰【说明】 需求提出者往往从局部角度提出需求，该需求可能没有联系其他模块进行推敲，甚至 会有自相矛盾、漏洞百出的现象，我们在受理需求时可先通过询问问题来了解该需求是否 准确、清晰，是否与其他功能点和主题有冲突等等，如果业务人员仍存在模棱两可的现象 而导致无法清楚地阐述需求，我们可以不予受理。1.3 无重复、杂糅现象【说明】 重复现象：有些需求可能以前提出过，只是尚未解决，或者已经被否决，总之是重复 需求，对于该类重复需求，可研究

3、原有需求与新需求是否有差异，如果确认重复则不予受 理。杂糅现象：有些需求中包含了多个子需求，其中的某些子需求在其他需求中已经包括， 即需求间存在交叉现象，这种情况下应梳理子需求，确保没有杂糅现象。1.4 内部沟通一致【说明】 需求提出者有时可能只代表个人意见或一个小团队的意见，或者提出者可能并不是业 务主管部门，因此业务需求的提出必须首先在该业务部门内部有权限人员得到认可后才能 代表整个部门意见，否则为无效需求。【示例】 需求提出者：为了提高效率，方便操作，设置某必输字段的默认值为 A。 业务主管部门领导意见：不设置默认值的初衷是让用户重视该字段的选择，以免由于 已经有默认值而忽略对该字段的正

4、确选择。内部沟通后结果：该需求为无效需求。1.5 外部沟通一致【说明】 有些业务需求的提出可能涉及其他部门的业务操作流程，如果该需求的提出没有征得 相关部门的同意，则在后期实现过程中会遇到阻碍，导致该需求无效，因此如果涉及多部 门的需求，需求提出者应与其他部门沟通，在合理的解决方案下征得他们同意。1.6 投入产出合理【说明】 有些业务需求的提出是为了解决一些特殊情况的发生，即小概率事件，但该需求的实 现却需要投入很大的工作量，该类需求可征求业务主管部门意见，必要时可让业务部门出 具小概率事件发生频率报表，从投入产出比的角度谨慎受理需求。1.7 制度匹配原则【说明】 系统建设需制度先行，适当放宽

5、要求也需制度并行，有些需求的提出是先行于制度， 该类需求实现后的问题在于没有配套制度或岗位作为运行的保障，可能导致系统与制度脱 节，反而影响业务的发展。在制度并行的情况下，需求提出者需给出制度下发的计划表，才能保证该需求的有效 性。1.8 需求分期实现【说明】有些需求的实现依赖于另一需求的实现情况，即业务需求是有顺序、按步骤进行的， 在这种情况下我们建议需求可分期完成，如果在一期尚未完成的情况下就提出新需求，可 称为“跳跃性需求”，此类需求我们建议等基础需求实现后再完善。1.9 确保按时上线【说明】不论是新需求还是需求变更，如果涉及层面比较广，可能影响到系统的上线时间，需 谨慎受理，必须征得领

6、导意见，给出可行的方案供领导决策选择，一般方案有三种： 1、 保持现状，等系统上线后再做修改；2、在原有需求上做优化，等上线后再修改；以上两 种方案优先保证系统上线，再考虑需求实现；3、按新需求修改系统，但延迟系统上线时 间，该方案以满足最新需求为准，以牺牲上线时间为代价。2 需求管理流程2.1 需求管理流程图2.2 预受理【说明】1、记录需求：业务部门提出业务需求，需求人员预受理该需求，做好需求记录工作。2、搜集业务资料：预受理后，需求人员可询问业务人员相关业务规章制度，搜集业务 相关管理办法。3、问题确认：分析需求过程中遇到问题可询问业务人员，确保正确理解需求。4、与开发人员初步沟通：将确

7、认好的需求与开发人员进行初步沟通，主要是了解需求 的可实施性和难易程度。5、反馈预受理结果：受理结果包括转为正式受理和拒绝受理。拒绝受理的原因可能会 很多，前文提到的需求受理原则是考虑的主要方面，拒绝受理必须提供原因，必要时可与 业务人员沟通改进业务需求以达到正式受理的结果。2.3 正式受理【说明】1、任务分配，确定责任人：根据需求人员专题分工情况分配该需求的后续跟踪事宜， 确定责任人。2、组织会议：通过与业务人员、开发人员以及内部专家的会议研讨，确定需求解决方 案。2.4 需求分析【说明】1、功能点拆分：从需求实现的角度将业务需求拆分成系统功能点。2、撰写需求说明书：根据功能点以及界面设计和

8、逻辑实现，撰写业务需求说明书。2.5 需求确认【说明】1、需求确认：根据业务需求说明书，与业务人员确认需求实现方式，一方面看是否满 足业务需求，另一方面看界面、按钮设置是否符合操作习惯等。2、需求完善：根据业务部门意见修改和完善业务需求说明书。3、需求评审：将业务需求说明书提交业务部门和相关领导进行评审。4、需求终稿：根据评审意见修改和完善需求，形成需求终稿。2.6 需求跟踪说明】1、需求维护：针对原有需求中尚未完善的规则、表单、流程等进一步维护需求，此类 维护不是需求变更，而是在前期需求分析过程中需要业务部门提供的资料进行完善。2、需求变更：在评审后的需求如果有变动，如果确认接受该变更，则应根据最新的需 求要求完善说明书，并记录变更历史。需求变更必须有一定的流程，并征得业务部门和技 术部门的同意。3、关于需求变更，必须明确以下几个方面：3.1 变更原因（监管要求变动、银行制度调整、原需求分析疏忽或没有前瞻性考虑等 等）3.2 变更程度（尤其涉及其他模块的必须明确其他模块相应变更情况）3.3 变更解决方案