1、目 录1. 前言 . 22. 需求管理背景 . 33. 需求管理流程 . 34. 指导规范 . 45. 需求管理体系 . 65.1. 制度 6（一） 总则 7（二） 机构职责 7（三） 总体工作流程 10（四） 需求提出 10（五） 需求分析 10（六） 需求评审 11（七） 需求跟踪 12（八） 需求实现 12（九） 附则 125.2. 细则 135.3. 流程图 135.4. 评审细则 145.5. 模板 155.6. 编写指南 166. 合理性评价 . 16第 2 页 共 16 页1. 前言需求定义和管理是开发流程中最重要的一步， 它能够确保软件项目符合客户的需求， 遵守相关的合同并且在
2、预算计划内按时完成。 此外， 这也是诸如集成的能力成熟度模型 （ CMMI）这类标准、 法规和质量改进计划的要求。 由于需求表达不佳造成的影响是毁灭性的， 它会产生多米诺效应， 导致开发团队需要耗费大量的时间对已完成的开发工作进行返工， 无法按时交付产品，超出预算以及各种法规遵从问题。优秀的需求管理方案从技术上和法律上都可能实现， 能使需求变得完整、 清楚。 保持一致性，不会与其它需求发生冲突。证明系统满足需求，可以对需求进行跟踪，可以对需求进行唯一识别和跟踪。此外，需求应该是模块化的，并且可以修改而不会造成过多的影响。它们还应该独立于设计。为了对需求进行组织和管理，可以采取以下的主要步骤。首
3、先，对需求进行组织，以避免重复和遗漏。接下来，对客户需求、软件需求以及材料等信息进行管理并将其关联起来，通过集中的需求管理数据库来获取规格和要求。然后，对那些决定性能、接口、安全等的非功能要求或者制约因素进行管理。功能和非功能要求的文字版本应该通过直观的建模加以补充， 这种建模包括从简单的白板图纸到精心制作的幻灯片演示在内的一切内容。 此外， 还可通过将它们明确映射至测试案例的方式来保证需求可以测试， 确保每个需求从一开始就可以明确识别， 从而能够更加轻松地满足这些需求并实际证明。 在许多情况下， 可以通过减少需求数量来更好地对需求进行管理。 很少有项目能够完全满足客户的所有请求、 营销创意和
4、业务建议， 并且在预算内按时完成。 通过与利益相关者进行合作， 共同确定项目需求的优先顺序来缩短业务目标和开发制约因素之间的差距。当然， 一个可以重复而且可靠的变化控制流程是至关重要的。 能够让您快速对项目管理活动进行监督并做出响应。对需求管理来说， 另外一个很有用的帮助就是以模板和行业标准的形式开发一个好 （和坏） 需求范例数据库。 将每个项目的需求范例都纳入数据库， 这些需求范例要能够反映企业建立企业知识库所需的各个领域的专业知识。 这样还有助于对需求进行明智地重复利用。 先前项目中确定的好的需求可以供未来使用， 而且伴随需求的链接能够让分析人士随时了解原始需求。这样，就可以将原始需求的任
5、何变化（例如，更新和缺陷修复程序）随时通知重复第 3 页 共 16 页利用这些信息的团队。总之， 需求定义和管理是任何项目活动中最重要的环节。 对高质量的开发来说， 为了在预算计划内按时完成开发，这一点非常关键。2. 需求管理背景XX银行在新核心信息化建设中，需要尽快建立先进的、全面的软件项目需求管理体系。从目前行内现状来看， 现有需求流程不能全面支持全行科技发展政策和战略的实施， 无法保证需求的质量，需求提出、分析、评审和跟踪的能力相对较弱，全行需求管理标准化水平、流程效率有待进一步提高。当前， 业界领先的银行已经建立起了先进的需求管理体系。 参考中国建设银行、 中国工商银行和招商银行等同行
6、业需求管理经验，基于 XX银行当前需求管理工作中存在的不足，相关人员通过深入的访谈和共同讨论，结合业界最佳实践和 XX银行现状，针对新核心建设实际情况，确定需求管理体系优化目标以及实施改进方案，提升需求管理的能力。3. 需求管理流程1. 需求提出部门根据本部门实际的业务需要及本行发展规划进行需求调研。 应收集的如下信息：业务范围、业务流程、业务功能、安全需求、报表凭证、非功能需求等。需求信息将以书面形式进行记录。2. 业务提出部门依据需求调研，按照我行的 XX 银行需求管理制度，编写业务需求和测试案例，对业务需求信息进行详细说明，并提交业务支持组和需求组进行业务需求的预审。3. 业务支持组和需
7、求组对业务需求进行预审，判定其内容是否符合我行规范，业务描述是否明确和清晰。 如果预审不能通过， 将资料及预审意见返回到需求提出部门。 当出现重大的业务需求且需求组无法进行预审时，可以提请架构集成组提供技术支持。4. 业务支持组和需求组作为对全行的业务需求统一管理的机构， 对于通过预审的 业务需求进行整合和条目化，完成业务需求补充完善。5. 业务支持组和需求组在进行需求完善后，编写业务需求说明书。 业务需求说第 4 页 共 16 页明书须按照我行业务需求说明书编写指南进行编写，详细描述业务的流程、关系、特性和规划等信息。6. 架构集成组根据业务支持组和需求组提供的 业务需求说明书 ， 对需求进
8、行可行性的技术分析，并分析支持系统开发的软件需求，编写出架构设计说明书和高层接口说明书，并牵头组织项目组编写软件需求规格说明书。在特殊情况（如项目紧急、项目规模较大等）下，以上 3 份说明书的设计和编写可以并行开展。7. 对符合条件、材料齐全完备的需求，由架构集成组负责填写需求评审申请，提交项目评审材料到科技项目管理委员会进行需求评审。8. 科技项目管理委员会召开评审会议， 对需求的合理性、 全行科技规划等重要事项进行审查， 做出实施审查意见。 详细的评审规范参见本制度的评审部分。 未通过评审的需求申请，需要再次重复以上流程，并在准备完成后提请项目管理委员会进行复议。9. 科技项目管理委员还需
9、对项目预算进行审议。预算大于 1000 万人民币的项目，提请科技与创新委员会进行审批，预算小于 1000 万人民币的项目由科技项目管理委员会进行审批，对于通过审批的项目将进入立项流程，启动项目的开发。如果审批无法通过，将再次重复以上流程，待完善后重新提交申请。10. 项目实施过程中，由项目经理制定项目计划和需求跟踪矩阵，经过审批后由项目需求管理员负责执行，执行范围须涵盖以下部分：需求记录、基线管理、需求跟踪、变更管理和项目终结等需求生命周期管理。11. 项目组在设计、开发和测试阶段，如果出现需求变更，将根据项目计划和需求跟踪矩阵 进入变更流程。 用户验收测试中， 业务部门的需求提出人员需要对开
10、发实现的系统进行验收测试，验证其是否满足业务需求。4. 指导规范第一条 业务部门根据本部门实际的业务需要及本行发展规划进行业务需求调研， 业务需求原则为“以市场为导向，以业务为源点”。第二条 业务部门负责制定本部门年度需求计划，并于每年年初提请需求评审委员会进行评审，并提交到信息技术部报备。第 5 页 共 16 页第三条 业务部门负责编写业务需求，对业务需求信息进行详细说明，并提交业务支持组和需求组进行预审。第四条 业务支持组和需求组负责对业务需求进行预审，审查其内容是否符合相关规程及规范， 业务描述是否明确和清晰。 如需求出现技术无法实现、 风险性高的业务需求，可以出具否决的预审意见。第五条
11、 业务支持组和需求组负责对通过预审的需求进行补充完善，并编写业务需求说明书。详细描述业务的规则、功能、流程、关系和特性等信息。第六条 架构集成组依据业务需求并对其进行技术分析，完成对需求的功能切分，同时进行可行性的技术研究和软件需求分析。 编写 功能切分说明书 和 高层接口说明书 ，并负责组织项目组编写软件需求规格说明书，完成需求分析工作。第七条 对于业务需求预审中出具否决意见的需求， 由业务支持组和需求组将材料及预审意见提交需求评审委员会进行需求评审，裁决需求是否被否决。第八条 对于通过预审的需求， 需求分析完成后， 架构集成组负责组织行内技术专家，对需求分析的各个产出物进行技术层面的需求方
12、案评审讨论， 发现其中的缺陷和不足， 并提出修改意见。第九条 需求方案评审完成后，对符合条件、材料齐全完备的需求，由需求组或者架构集成组负责填写 需求评审申请 ， 提交评审材料到需求评审委员会进行管理层面的需求评审，审定是否实施该需求。第十条 需求评审是需求管理工作中的决策里程碑， 需求评审委员会作为评审的管理组织，须对需求组和架构集成组提交的需求材料进行审核。第十一条 需求评审委员会负责召开需求评审会议， 对需求的合理性、 是否符合全行科技规划等重要事项进行审查，给出实施审查意见。第十二条 需求评审委员会还需对项目预算进行审议。对于预算大于 1000 万人民币的项目，提请科技与创新委员会进行
13、审批。第 6 页 共 16 页第十三条 对于需求评审过程中涉及到的重大业务方案和总体技术方案， 相关部门可请业务专家和技术专家提供参考意见。第十四条 对于通过审批的项目将进入立项流程， 启动项目的开发。 如果审批无法通过，将再次重复以上流程，待完善后重新提交申请。第十五条 需求跟踪是在项目实施阶段， 对需求的实现、 变更和维护进行管理。 由项目组负责进行计划制定和实施操作。第十六条 项目启动阶段，由项目组制定需求管理计划和需求跟踪矩阵，并负责组织需求提出的业务部门编写测试案例。在实施过程中，项目组按照以上需求管理计划进行设计、开发和系统测试。第十七条 项目组需求管理员负责在需求管理过程中负责需
14、求管理计划的执行，以保证需求管理的实施可控，并且对需求管理计划进行监督和管理。第十八条 当需求发生变更时， 项目组启动需求变更管理流程进行处理， 根据影响程度确定需求变更的影响级别。第十九条 项目组负责进行需求基线的管理和需求变更涉及到的需求版本管理， 以及其余项目级需求管理工作。第二十条 项目组完成软件的系统测试后， 由需求提出的业务部门负责进行用户验收测试，测试完成后实现系统上线。5. 需求管理体系本期需求管理体系的内容包含需求管理制度、 实施细则、 管理流程图、 各种文档的模板、模板使用指南和评审部分的细则。5.1. 制度 XX 银行需求管理制度是为了规范我行在信息化建设过程中需求的管理
15、及其实施过第 7 页 共 16 页程而制定的。适用于总行各部门和各级分行的业务、管理、信息技术等职能部门。该制度将解决当前需求管理工作中的职责不清、流程不明、规范不足、标准不严等问题，也将作为需求管理的核心纲领， 指导需求管理的具体工作、 实施过程和相关产出文档的编写。 制度中明确规定了如下几项主要内容：制定本制度的目的、作用、意义及适用范围。需求管理过程中相关部门的责任， 进一步明确工作中角色的划分和相应的职责以及权利。需求管理工作中必须遵循的总体流程框架。需求的“提出、分析、评审、跟踪、实现”等各个阶段的责任人，各个阶段核心工作内容、产出物以及相应的规范。（一） 总则第一条 为规范 XX银
16、行信息技术需求 ( 以下简称需求 ) 的管理体制和运作机制，以确保需求能够高质量的管理，根据商业银行内部控制指引和银行业金融机构信息系统风险管理指引等监管规程和信息技术安全管理规范，特制定本制度。第二条 本制度所指的需求为： IT 软件应用系统要满足业务、标准、规程或其他正式规定文档所需具有的条件或权能。第三条 本办法适用于 XX银行总行各部门及各级分行的业务、 管理、 信息技术等职能部门。各个部门须相互配合、积极沟通、协调一致，共同完成需求的管理工作。第四条 需求管理实施过程中应严格按照 XX银行信息技术制度 中业务、 数据、技术、安全、运行等有关制度、规范与标准的规定。（二） 机构职责第五
17、条 需求评审委员会需求评审委员会是全行需求判定的最高机构。 需求评审委员会由总行信息技术部门与第 8 页 共 16 页相关职能部门的领导组成，实行组长负责制。主要履行以下职责：（一） 负责评审和确定全行业务和软件系统需求， 组织研究和确定相关的发展政策及制度；（二） 审查年度信息化需求规划并监督执行情况， 审定业务部门日常提出的业务需求及重大变更，协调解决科技项目开发、推广中与业务相关的重大问题；（三） 确保评审意见与科技创新委员会 （以下简称科创会） 的协调一致， 保障科技投入得到有效管理并获得最大业务价值；（四） 当业务部门、信息技术部和项目开发单位在需求方面出现重大的分歧或争议时，由需求
18、评审委员会负责协调和裁定。第六条 需求提出部门本制度所称需求提出部门是指总行及各级分行的业务部门， 如： 计划财务部、 会计部、公司业务部、个人业务部、电子银行部等。需求提出部门应履行以下职责：（一） 研究并制定本部门年度需求计划，提请需求评审委员会进行评审，并提交到信息技术部备案；（二） 进行业务需求调研，评估影响、识别风险、估算投入和产出，根据业务的必要性和可行性对需求进行初步筛选；（三） 依据模板编制业务需求，描述需要实现的目标，并对材料的真实性承担责任；（四） 负责将业务需求报送信息技术部业务支持组和需求组预审，并在预审过程中提供必要的业务支持；（五） 参与软件项目开发实施，负责解释具
19、体的业务需求，把握其完整性和准确性，协调、处理和解决相关的业务问题，提供项目所需的业务资源，配合项目组编写测试案例，组织进行用户验收测试，参与系统上线决策，组织试运行和推广，参与项目验收；第 9 页 共 16 页（六） 负责设计或调整与需求配套的组织机构及业务流程，制定相关的业务规程和制度。第七条 业务支持组、需求组本制度所称业务支持组和需求组 （由总行大集中项目开发办公室牵头） 是信息技术部下属分管业务需求受理和完善的部门。业务支持组和需求组应履行以下主要职责：（一） 针对需求提出部门提交的 业务需求 进行预审， 确保提出的业务需求符合行内信息化建设规划及相关制度约束，并给出审核意见；（二）
20、 对业务需求进行补充和完善，编写符合规范的业务需求说明书；如果业务需求牵涉到多个应用系统，该组还将负责编写针对各个应用系统的业务需求说明书；（三） 组织业务需求评审材料， 填写 需求评审申请书 ， 提请需求评审委员会审核；第八条 架构集成组本制度所称架构集成组 （由总行大集中项目开发办公室牵头） 是信息技术部下属分管功能切分和高层接口设计的部门。架构集成组应履行以下主要职责：（一） 本行信息技术架构的总体设计和规划；（二） 按照业务需求说明书制定技术方案，编写功能切分说明书和高层接口说明书，并负责组织项目组编写软件需求规格说明书；（三） 组织需求评审材料，填写需求评审申请书，提请需求评审委员会
21、审核；（四） 对于项目实施给予技术指导；第九条 科技创新委员会XX银行科技创新委员会 （以下简称科创会） 是信息技术项目的最高审批机构， 负责 1000万以上科技项目的立项工作，详细参见 XX银行信息技术项目管理办法。第十条 项目组第 10 页 共 16 页项目组是在信息技术部门的组织下， 建立的项目实施机构。 项目组负责从业务需求到软件功能的实现、开发基础软件构件库、负责其升级工作。详细参见 XX 银行软件开发管理办法。（三） 总体工作流程第十一条 需求管理的总体流程将按照“提出分析评审跟踪实现”的核心步骤进行。每个环节由相应的责任部门按照本制度完成。第十二条 总体流程中核心步骤的各产出物，
22、必须由对应主责任部门负责人签字后，提交相关部门启动下一阶段工作。第十三条 在需求管理过程中， 各个部门必须加强沟通和互动， 相互协作实现需求的高效管理。（四） 需求提出第十四条 业务部门根据本部门实际的业务需要及本行发展规划进行业务需求调研，业务需求原则为“以市场为导向，以业务为源点”。第十五条 业务部门负责制定本部门年度 需求计划 ， 并于每年年初提请需求评审委员会进行评审，并提交到信息技术部报备。第十六条 业务部门负责编写业务需求，对业务需求信息进行详细说明，并提交业务支持组和需求组进行预审。（五） 需求分析第十七条 业务支持组和需求组负责对 业务需求 进行预审， 审查其内容是否符合相关规
23、程及规范， 业务描述是否明确和清晰。 如需求出现技术无法实现、 风险性高的业务需第 11 页 共 16 页求，可以出具否决的预审意见。第十八条 业务支持组和需求组负责对通过预审的需求进行补充完善， 并编写 业务需求说明书。详细描述业务的规则、功能、流程、关系和特性等信息。第十九条 架构集成组依据业务需求并对其进行技术分析，完成对需求的功能切分，同时进行可行性的技术研究和软件需求分析。 编写 功能切分说明书 和 高层接口说明书 ，并负责组织项目组编写软件需求规格说明书，完成需求分析工作。（六） 需求评审第二十条 对于业务需求预审中出具否决意见的需求， 由业务支持组和需求组将材料及预审意见提交需求
24、评审委员会进行需求评审，裁决需求是否被否决。第二十一条 对于通过预审的需求， 需求分析完成后， 架构集成组负责组织行内技术专家，对需求分析的各个产出物进行技术层面的需求方案评审讨论，发现其中的缺陷和不足，并提出修改意见。第二十二条 需求方案评审完成后， 对符合条件、 材料齐全完备的需求， 由需求组或者架构集成组负责填写 需求评审申请 ， 提交评审材料到需求评审委员会进行管理层面的需求评审，审定是否实施该需求。第二十三条 需求评审是需求管理工作中的决策里程碑， 需求评审委员会作为评审的管理组织，须对需求组和架构集成组提交的需求材料进行审核。第二十四条 需求评审委员会负责召开需求评审会议， 对需求
25、的合理性、 是否符合全行科技规划等重要事项进行审查，给出实施审查意见。第二十五条 需求评审委员会还需对项目预算进行审议。对于预算大于 1000 万人民币的项目，提请科技与创新委员会进行审批。第二十六条 对于需求评审过程中涉及到的重大业务方案和总体技术方案， 相关部门可请业务专家和技术专家提供参考意见。第 12 页 共 16 页第二十七条 对于通过审批的项目将进入立项流程， 启动项目的开发。 如果审批无法通过，将再次重复以上流程，待完善后重新提交申请。（七） 需求跟踪第二十八条 需求跟踪是在项目实施阶段， 对需求的实现、 变更和维护进行管理。 由项目组负责进行计划制定和实施操作。第二十九条 项目
26、启动阶段，由项目组制定需求管理计划和需求跟踪矩阵，并负责组织需求提出的业务部门编写测试案例。在实施过程中，项目组按照以上需求管理计划进行设计、开发和系统测试。第三十条 项目组需求管理员负责在需求管理过程中负责需求管理计划的执行，以保证需求管理的实施可控，并且对需求管理计划进行监督和管理。第三十一条 当需求发生变更时， 项目组启动需求变更管理流程进行处理， 根据影响程度确定需求变更的影响级别。第三十二条 项目组负责进行需求基线的管理和需求变更涉及到的需求版本管理， 以及其余项目级需求管理工作。（八） 需求实现第三十三条 项目组完成软件的系统测试后， 由需求提出的业务部门负责进行用户验收测试，测试
27、完成后实现系统上线。（九） 附则第三十四条 本办法由总行制定、修改，由总行信息技术部门解释。第三十五条 本制度中涉及的详细说明和约定，请参见 XX 银行需求管理工第 13 页 共 16 页作实施细则 。5.2. 细则 XX银行需求管理工作实施细则是为 XX银行需求管理制度的实施而制定的在具体工作过程中可操作的指导办法， 明确工作原则和方法， 规范需求管理各个阶段的详细工作内容、要求及标准，界定实际工作中的各个控制点、决策点和风险点，并对各个产出文档的内容和结构进行规范。细则中详细规定了以下内容：依照需求工程的方法，行内需求工作需要遵循的原则和具体实施的方法。在组织管理级和项目开发级两种维度需求
28、管理的主要工作内容。需求管理流程中，各个实施步骤的主要责任人、工作内容、时效、签署报备、规范等要求。各阶段产出物文档的主要内容、编写规范及参考指南。需求管理特殊情况处理：监管部门需求和应急情况的处理办法。5.3. 流程图需求管理流程图 , 是对整个业务流程的形象化描述，该图中清晰说明了需求管理的整体标准化流程，各组织结构的核心工作及产出物，以及各个评审环节的顺序等。第 14 页 共 16 页需求管理实施流程业务支持组需求组 项目组架构集成组需求提出部门科技与创新委员会需求评审委员会开始需求调研提出业务需求需求补充完善需求评审总体设计需求分析预算是否大于 1000万？业务需求说明书功能切分说明书
29、高层接口说明书项目管理流程审批需求计划业务需求是否通过？是通过？项目实施过程结束是否受理？预审完善内部测试集成测试软件需求规格说明书项目计划需求跟踪矩阵测试案例软件技术规格说明书是用户验收测试需求方案评审是否是否否否5.4. 评审细则作为需求管理工作中对于需求的决策重要关键点， 需求评审将以单独的实施办法进行说第 15 页 共 16 页明。 XX银行需求评审细则和 XX银行需求规格检查表的制定，是为了明确需求评审的工作过程和内容细节， 提高需求评审的效率与质量， 规避需求评审中常见的问题。 评审细则包括如下主要内容：需求评审委员会的组织结构和工作职责。评审的形式、负责人及申请部门。评审所需要的
30、材料和参与者。评审的核心流程。评审的决议方式。5.5. 模板需求管理过程中的模板标准化， 将很大程度上提高需求文档的质量， 避免出现信息遗漏，保证需求理解的一致性。需求文档的模板如下表：模板名 模板说明1 需求计划 业务部门提出的年度需求计划。2 模板 _业务需求 业务部门提出的原始业务需求。3 模板 _业务需求说明书 业务支持组和需求组对原始业务需求进行的补充完善材料。6 模板 _需求评审申请书 需求评审正式申请材料。7 模板 _软件需求规格说明书 ( 软件开发类 ) 标准的软件需求说明。12 模板 _需求跟踪矩阵 需求实现的跟踪记录材料。13 模板 _测试需求 业务测试案例的说明。14 模
31、板 _需求管理计划 项目组对开发中需求的管理计划。15 模板 _业务变更申请单 需求变更说明的材料。16 模板 _项目完成需求管理情况总结 需求管理的工作总结。第 16 页 共 16 页5.6. 编写指南编写指南是指业务需求说明书编写指南和软件需求规格说明书编写指南，作为在编写业务需求和软件需求规格说明书时应遵循的写作规范。指南中将介绍编写的工序、 常用模板、 裁剪说明等方法。 编写人员可以根据工作中的实际情况真对文档章节进行修改或者选择更为适合的方式进行编写， 但文档的总体结构和相应内容应该与指南无重大的差异。6. 合理性评价制定一套规范的、适用的需求管理制度，有效提高工作效率和管理方法。需求管理工作的组织机构及职责分工明确，各种约束和管理机制进一步明晰。制定了明确的、 细化的需求管理流程， 明确界定流程中的控制点、 决策点和风险点。编写各种需求文档时按照规范的模板进行， 避免了信息遗漏、 理解错误和多次反复，文档质量得以保证。可以进行需求的基线管理和变更后的需求版本记录。需求实现过程支持变更控制， 避免变更频繁和无序， 满足了风险控制和质量保证的需要。
