实施需求管控前置化质量管理方法研究【毕业论文】

1、密 级:毕业设计（论文）题目：实施需求管控前置化质量管理方法研究学生姓名 班 级 学院名称 专业名称指导教师学位论文原创性声明本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行 研究工作所取得的成果。除文中已经注明引用或参考的内容外，本论文不含 任何其他个人或集体已经发表或撰写过的作品或成果。对本文的研究做出重 要贡献的个人和集体，均已在文中以明确方式标注。本人完全意识到本声明的法律结果由本人承担。论文作者签名： 日期：年月日学位论文版权协议书本人完全了解关于收集、保存、使用学位论文的规定，即：本校学生在 学习期间所完成的学位论文的知识产权归所拥有。有权保留并向国家有关部 门或机构

2、送交学位论文的纸本复印件和电子文档拷贝，允许论文被查阅和借 阅。可以公布学位论文的全部或部分内容，可以将本学位论文的全部或部分 内容提交至各类数据库进行发布和检索，可以采用影印、缩印或扫描等复制 手段保存和汇编本学位论文。论文作者签名： 导师签名：日期：年 月 日日期：年 月 日实施需求管控前置化质量管理方法研究摘要新一代项目实施开发全生命周期的过程包括需求、分析、设计、 开发、部署、测试、切换七个阶段，实施需求管控通过实施需求管控 跟踪矩阵，在项目实施的每个重点阶段都会以不同的形式跟踪需求的 实施落地情况，但最重要的职责则是在项目的应用分析阶段对需求分 析成果进行进度追踪和质量管理。本文以实

3、施需求管控的基础一实施需求基线为出发点，详细介绍 基线五张表的内容、意义及规则，论述实施需求基线填报方式的变革, 并梳理出目前需求管控各专项质量检查的管控点及管控规则。在梳理 论述的过程中，加入学员工作一年以来的思考，对部分管控方法提出 了改进建议，旨在简化管控方法，提高管控效率。1 绪论21研究背景21.2 研究意义31.3 研究内容31.4 论文结构42 实施需求管控基线52实施需求基线内容及意义52.1.1 实施需求基线的内容及意义52.1.2 实施需求基线管理62.2 实施需求基线填报方式变革62.2.1 新一代二期基线填报62.2.2 新一代三期基线填报72.2.3 实施需求基线基础

4、合规检查规则概览93 需求管控专项质量检查133.1 范围承接率检查133.2 目标覆盖度检查133.3 cpc完整性检查143.3.1 cpc完整性检查内容及规则143.3.2 改进点143.4 用户工作流程还原合理性检查153.5 业务功能还原合理性检查173.5.1 业务功能还原合理性检查内容及规则173.5.2 改进点183.6 用户工作流程全景视图完整性检查183.6.1 用户工作流程全景视图检查内容及规则183.6.2 改进点194 总结与展望214.1 总结214.2 展望221绪论1.1研究背景新一代需求管控工作的整体目标在于有效管理项目目标以及实现目标的业 务需求和技术需求、

5、建立与实施工艺相配套的需求跟踪矩阵以及跟踪项目业务、 技术需求在各实施阶段的实现状态。新i代项目实施开发全生命周期的过程包括 需求、分析、设计、开发、部署、测试、切换七个阶段，需求管控通过实施需求 管控跟踪矩阵，在项目实施的每个重点阶段都会以不同的形式跟踪需求的实施落 地情况。而实施需求管控最重要的职责则是在项目的应用分析阶段对需求分析成 果进行进度追踪和质量管理。需求管控以应用分析阶段的重要产出物-应用分析 说明书为基础，结合需求管控方法和需求管控工具，以周为单位，对项目的应用 分析进行检查和推进；通过对应用分析书中主要管控点进行结构化整合，提炼出 需求管控的基础一实施需求管控基线（以下简称

6、“基线”），包括功能差异分析列 表、用户工作流程列表、业务功能列表、用户工作流程全景视图列表及实施效果 分析说明列表。这五张基线表覆盖内容全面广泛，彼此之间存在着复杂严谨的勾 稽关系。在新一代二期的需求管控过程中，我们摸索并初步形成了一套基于基线的质 量管控方法体系，这套方法的实施可以保证基线内容的完整和合规。但是缺点在 于所有的管控内容和手段都是后置的，即项目组先按分析成果填写基线，填写完 成后提交至需求管控组，需求管控组对基线内容的完整性和合规性发起一系列专 项质量检查，并出具检查结果报告，项目组根据检查结果报告对基线内容进行整 改。这样最终能达到使基线完整合规的目的，但操作起来比较繁琐费

7、吋，反复地 整改更是会加大项目组的工作量。基于二期的管控经验，在新一代三期的管控中, 我们采用vba编程模式，开发出一个配合需求管控的自动化填报及检查工具，从 而形成合规内容自动检查，专项质量检查问题人工过滤的检查模式，达到填报基 本内容事先控制的要求。我们将所有检查规则事先跟项目组进行沟通，保证项目 组在填写前便了解所有规则。当项目组填写部分内容后点击工具里的“检查”按 钮，不合规的单元格会自动报红，相应的报错提示信息也会详细列示在对应的单 元格里，如此项目组可以边填写边检查边修改，当项目组填写完成提交到需求管 控组吋，已经是一版通过合规性检查的基线。这次突破较人地节省了项目组填写 合规基线

8、的吋间，提高了需求管控效率，得到了三期项目组的一致认可。尽管如此，所有的专项质量检查，包括cpc完整性检查、用户工作流程还原 合理性检查、业务功能还原合理性检查等还是在项n组提交基线之后通过一个个 单独的工具进行，一轮轮专项检查及整改工作仍然会耗费较多时间和精力。本文 旨在详细梳理需求管控基线的所有完整性和合规性检查规则，厘清各专项质量检 查工作中的管控点，并理顺各项规则之间的关系，将所有单独零散的专项检查进 行整合，形成一个完整关联的质量检查体系，为开发岀一个将所有检查规则前置 的新的自动填写和检查工具提出需求，以便更高效地对实施需求慕线进行管理。1.2研究意义在新一代二期需求管控过程中，我

9、们采用项目组填报，需求管控组专项检查 整改的事后管理模式（先填表，后检查）完成所有的合规性和完整性检查，这种 检查方式能有效地达到质量把控要求，但弊端在于操作过于繁琐费吋，项目组填 写、整改工作量较大。基于二期管控方法的弊端，在新一代三期需求管控过程中, 我们采用vba编程模式，开发出一个配合需求管控的自动化填报及检查工具，从 而达到合规内容自动检查，专项检查问题人工过滤的检查模式。全新的自动化填 报及检查工具通过需求管控基线控制关键要素间的钩稽关系，以达到全面、准确 的应用分析结果；项目组边填写边修改，实现填报基本内容事先控制的要求，相 较于需求管控二期的“事后”控制方法在效率上有了很大提升

10、。本文试图进一步解决需求管控事后控制的问题，将专项检查的规则和管控点 也进行前置管理，实现事先引导而不是事后整改。同吋，将之前零散的专项质量 检查进行梳理整合，形成一整套完整关联的质量管控体系，为开发出一个将所有 检查规则前置的新的自动填写和检查工具提岀需求，实现更高效的实施管控。1.3研究内容首先，本论文对需求管控基线的内容和意义进行阐述，并对基线填报内容的 合规性规则进行梳理。其次，论文对目前需求管控所有专项质量检查的内容和检查规则进行整理， 厘清其中的主要管控点。同时，结合学员过去一年的工作心得，对部分检查内容 提出改进点。最后，将所有零散的专项质量检查规则进行整合，形成一整套完整关联的

11、质 量管控体系，并将其嵌入前置化自动填报及检查工具，为新填写工具的开发提岀需求。1.4论文结构本论文共分为五章。第一章，绪论（即本章）。介绍论文的研究背景、研究意义、研究内容以及 论文的组织结构。第二章，需求管控基线的内容和意义阐述。介绍目前需求管控基线内容的构 成及每张表的意义。第三章，介绍目前需求管控的专项质量检查内容及规则，同时，结合学员过 去一年的工作经验，以及学员在参与管控工作中的思考和总结，对部分质量检查 提出改进意见。第四章，总结与展望。本章在对本文里提岀的主要改进意见进行了总结和梳 理，同时，对未来自己的学习方向开展了思考。2实施需求管控基线2.1实施需求基线内容及意义2.1.

12、1实施需求基线的内容及意义新一代项目实施开发全生命周期的过程包括需求、分析、设计、开发、部署、 测试、切换七个阶段。实施需求管控在项目实施的每个重点阶段，都会以不同的 形式跟踪需求的实施落地情况，而其最重要的职责就是在项目的应用分析阶段对 需求进行进度追踪和质量管理。需求管控以应用分析阶段的重要产出物应用分 析说明书为基础，结合需求管控方法和需求管控工具，以周为单位，对项目的应 用分析进行检查和推进。通过对应用分析书中主要管控点进行结构化整合，提炼 出需求管控的基础一需求管控基线，包括功能差异分析列表、用户工作流程列表、 业务功能列表、用户工作流程全景视图列表及实施效果分析说明列表。功能差界分

13、析列表通过比对建模成果和现状系统之间交易码层级的对应关 系，分析根据建模述原出来的业务功能能否覆盖现状系统的所有功能，并要求项 目组对存在的差界标注处理类型，通过此表可以评估企业级模型和现状系统的差 界，针对性的确定问题解决方向，保证项目的实施不会偏离模型。用户工作流程 列表中，项目组将其实施范围内的三级活动按照cpc等拆分因子还原出差界性的 业务场景及工作流程，通过此表可以检查项目组是否完整分析其实施范围内的三 级活动及三级活动还原成用户工作流程的合理性。业务功能列表中，项目组将其 实施范围内所有的四级任务还原成相应的业务功能，通过此表可以检查项目组是 否完整分析其实施范围内四级任务及四级任

14、务还原成业务功能的合理性。用户工 作流程全景视图列表以全局视角展示岀项目的毎条用户工作流程下调用的所有 业务功能情况，包括自己实施的业务功能、调用其他项目组的业务功能以及不在 本期实施的业务功能，建立起用户共组流程列表和业务功能列表的映射关系，通 过此表可以检查用户工作流程的跨项目组对接情况。分析完所有的用户工作流程 和业务功能，项目组最后通过实施效果分析列表来回顾其分析出流程和功能是否 能完全覆盖自己的业务目标。实施效果分析表中列示了项目的业务目标与其用户 工作流程及业务功能的对应关系以及目标需求项相关的各类信息，通过此表可以 检查项目组的目标覆盖度、先进性需求实现情况以及协同方对接情况。以

15、实施需 求基线为载体，项目组将自己的应用分析成果填写在其中，并通过各种专项检查, 对应用分析的成果进行管理。实施需求基线样表如下：实施需求基线xlsx2.1.2实施需求基线管理项目组将需求管控基线（以下简称“基线”）填写完毕之后，需求管控工作 以基线为基础对项目的应用分析内容进行各种深入的专项检查，包括范围承接率 检查、cpc完整性检查、用户工作流程还原合理性检查、业务功能还原合理性检 查等。针对每项检查，定期发布定制化报告对检查结果及整改进度进行持续追踪 管理，这依赖于一整套强大的需求管控工具。待所有的专项检查结束，一版完 整合规的需求管控基线就形成了，随后的设计开发便在这版基线的基础上进行

16、。 之后项目组如需对基线内容进行变动，必须严格遵照基线变更流程，先经过项目 组口审，审核通过后由pio进行初步审批，审批通过之后再流转到pmo进行进一 步审批，通过三层审批完成后，由实施需求管控组统一对基线进行修改，避免需 求的随意变动影响开发设计工作。2.2实施需求基线填报方式变革实施需求基线作为需求管控对项目应用分析阶段进行管理的基础，是项目 应用分析成果的凝结。如何收集项目的实施需求基线，并保证填报内容的质量， 是需求管控的关键。在新一代二期的需求管控过程中，我们摸索并初步形成了一套“先填报，后 检查”的基线填报及合规性质量检查方法，这套方法的实施可以基本保证基线内 容的完整和合规，缺点

17、在于费时费力。基于二期的管控经验，在新一代三期的管 控屮，我们将“先填报，后检查”变为“边填报，边检查”，实现快速发现问题 并解决问题的机制，在保证基线内容合规的同吋提高了填报效率。2.2.1新一代二期基线填报新一代二期，我们采用“先填报，后检查”的基线填报方式。项目组先按事 先下发的模板填写基线内容，填写完毕后用“需求管控组质量检查工具”对项目 组提交基线表的合规性、范围承接率、cpc完整性等内容进行检查，检查完毕 后生成一份详细的质量检查报告，项目组根据报告中的错误信息提示对基线内容 进行修改，再用工具进行检查，直至基线完全合规。如此反复地填写、检查、修改、再检查，会耗费项日组大量的时间精

18、力，且 项口组修改时需对照质量检查报告，报错信息不够直观简明，不易于项冃组快速 准确地找到错误所在。222新一代三期基线填报新一代三期，为减轻各项目组应用分析人员的基线填报压力，需求管控组借 鉴前期相关工作经验，将基线填报表格和质量检查工具进行融合，开发岀“三期 项目组填写工具”（以下简称“填写工具”），将二期的事后管理方式前置，将“先 填报，后检查”变为“边填写，边检查”，实现事前控制，而不是事后修改。项目组登陆填写工具后，可根据应用分析情况进行填写，涉及某些需求管控 前期已明确的内容时，工具自动调用字典库，如业务目标、三级活动、四级任务 基线，现有系统名称、客户名称等：一jklkbfthr

19、inr 冊crc»j»«lh«a«ubma :ma1 ) « » «谀!郃6的x它刻10）北繼e 洛功sht么 cpcdb子怀.龙厘场汐 "个wu1夹q tfiscpcifai 分祈mm:户丄ftaumi 的u功禅c 用亡工隹趣集it砂盼析 皿昨分侨 皿分侨 珂尸工作忍曲阀 丁无亠cs bs «53 开泣h分比弓 mi!is (霸费护团董g： f® 刃昨 ita * £ jfflwk业务車件名与名你冉户工作点取列茶对gai5pg»必填： 填写戦该用 户工作彌亍 的启

20、动寧件（丁 善 dt 必填顶：811cpcsr 分析右形成的 项目3级用户 丁“mm田立s»ms1)对于当二®客户 对£富目 対£咅户 m£sa> wis 户 口対公户 21讨公專决 0?< 户i三户匚w业也忏:ibfigp丰骞阳七司vttamliiu.画息事件对公喜户捋辄?止证算 whip 对公咅户 科£豪户分行童占誉厠一：仁分行81自整占 户哀*q行总口ass户 卑一寒户互砂h6b?名释c叩顷：必填项：®o：必填如i该込跆1 ）保捋现填写三吸用户晒企lk®hi个事道交状：漁程爲u对应磅动sh+么二则

21、0填.看与现状渓持羽其它变星因cpc因子还彊m( qh 械如体3田ot匸工倉ji保持现状ft不值得彩现状不值猜滴总事件対公客户拮箪毛烬止证寿金电消息事件对公客户恃強幺绝护代祕不值得不值得"t"大塑客户保证淌息事件对公喜户待缰护代收代怫对公喜户椅鞅8j项目组将基础信息填报完毕后，可运行检查，实现项冃组自查功能，女口：出现合规性问题将在单元格位置标红；出现疑似问题，单元格将标黄:项冃组利用填写工具对基础信息合规性进行检查并确定无课后，将填写内容上传至实施需求管控数据库，提交需求管控做进一步检查，从而避免事后检查时出现的种种合规问题，导致项冃组的重复填报。223实施需求基线基础合

22、规检查规则概览需求基线五张表涵盖内容全面丰富，每张表都有自己独特的逻辑，表与表之 间更是存在这复杂的勾稽关系。实施需求基线五张表的合规性检查规则详情如下 表所示：表1：用户工作流程列表合规检查规则规则序号规则描述a01必填列：cel,m,n,pa02d列【二级活动】不为空且不为新增时，以分析中心、分析项目组、二期批次、二期 实施策略为实施的为条件，如果不在【项目范围-level3】中，在建模成果1.5中，则 报黄色，建议修改；如果既不在【项目范围-level3】中，也不在建模1.5中，则报红， 必须修改a03e列【用户工作流程场景名称】不能有重复项,否则报红a04f列【客户名称】不为空时,必须

23、在字典表中能找到,否则报红a05g列【产品名称】不为空时，必须在字典表中能找到,否则报红a06h列【渠道名称】不为空时,必须在字典表中能找到,否则报红a07h列【渠道】不为空时,则j列【渠道部署说明】必填,否则报红a08n列【适用范围】为"全部"或"境外"时，0列【对应的越卜机构名称】必填，且 必须在【字典表-海外机构名称】中，否则报红a09j列【渠道部署说明】不为空时，必须是下拉列表中的选项a10m列【cpc还原类型】不为空时，必须是下拉列表中的选项alln列【适用范围】不为空时，必须是下拉列表中的选项a12p列【工作流实现方式】不为空时，必须是下拉列

24、表中的选项程2：业务功能列表合规检查规则规则序号规则描述b01必填列：d,f,nb02c列【四级任务】不为空且不为新增时，以分析中心、分析项目组、批次、二期实施 策略为"实施."为条件，如果不在【项目范b-level4中，在建模成果1.5字典 表-四级任务与逻辑应用组件映射表v15中，则报黄色，建议修改；如果既不在【项 目范围-level4中,也不在建模1.5中，则报红，必须修改b03c列【四级任务】不为空且对应多个业务功能时，e列必填，否则报红b04d列【业务功能名称】必须在【功能差异分析】表中，否则报黄b05d列【业务功能名称】不能有重复值,否则报红b06f列【是否补充

25、或修订目标业务模型】与【功能差异分析】表中p列的对应关系是： 在业务功能相等的条件下，p列如果有下拉列表中的第2或第3项时，则f列也必须 为第2或第3项，否则报红;p列如果没有下拉列表中的第2或第3项，但有第1项 时，则f列必须为第1项，否则报红。错误报在【业务功能分析】表中b07h列【客户名称】不为空时，必须在字典表中能找到,否则报红b08i列【产品名称】不为空时，必须在字典表中能找到,否则报红b09j列【渠道名称】不为空时，必须在字典表中能找到，否则报红b10n列【适用范围】为"全部或"境外"时，0列【对应的海外机构名称】必填，且 必须在【字典表-海外机构名称

26、】中，否则报红b11f列【是否补充或修订目标业务模型】不为空时,必须是下拉列表中的选项b12g列【业务功能分类】不为空时，必须是下拉列表中的选项b13n列【适用范围】不为空时，必须是下拉列表中的选项表3：功能差异分析列表合规检查规则规则序号规则描述c01必填列：k,vc02d列【4级任务名称】为【字典表-四级任务与逻辑应用组件映射表v15】中的四级任 务时，b列【业务组件名称】、c列【3级活动名称】不能为空，且b列【业务组件 名称】、c列【3级活动名称】、d列【4级任务名称】的对应关系得与【字典表-四 级任务与逻辑应用组件映射表v15表中的对应关系保持一致c03d列【四级任务】不为空且不为新增

27、时，以分析中心、分析项目组、批次、二期实施 策略为"实施为条件，如果不在【项目范围-level4中，在建模成果1.5字典 表-四级任务与逻辑应用组件映射表v15中，则报黄色，建议修改；如果既不在【项 目范围-level4中,也不在建模1.5中，则报红，必须修改c04除（k列选择"目标功能需求没提现状有"且p列选择"丢弃"）外，e列必填c05k列【已实现系统功能支持情况分类】不为”目标功能需求有现状没有”且不为"没 有建模也没有现状系统”时,h,i,j丄列必须填写,否则报红c06k列【已实现系统功能支持情况分类】不为”目标功能需求有现状

28、没有”且不为"没 有建模也没有现状系统"时，如果l列、m列不为空时，必须在字典表中，否则报红。c07p列【差异处理类型】为"目标业务模型内容不全需补充"或"无对应目标业务模型 需补充时，q列必须填写,否则报红c08k不为"目标功能需求没提现状有"且p列不为"丢弃"时，t列【分配的应用组件 名称】与u列【分配的现有系统名称】两列必须填写一列，且在字典表中能找到。否 则报红c09k列不为"目标功能需求二现状系统功能"时,n,o,p列不能为空c10v列【是否需要配套改造】为"是&q

29、uot;时，w列,x列不能为空c11。列【4级任务名称】和e列【业务功能名称】的对应关系必须在【业务功能分析】 表中能找到,否则报红c12k列【已实现系统功能支持情况分类】不为空时，必须是下拉列表中的选项c13p列【差异处理类型】不为空时，必须是下拉列表中的选项c14r列【是否是上收功能】不为空时，必须是下拉列表中的选项c15v列【是否需要配套改造】不为空时，必须是下拉列表中的选项c16z列【业务处理类型】不为空时，必须是下拉列表中的选项c17aa列【查询特性】不为空时，必须是下拉列表中的选项c18ab列【业务处理特性】不为空时，必须是下拉列表中的选项c19ac列【批量处理类型】不为空时,必须

30、是下拉列表中的选项c20ad列【报表特性】不为空时，必须是下拉列表中的选项表4：实施效果分析列表合规检查规则规则序号规则描述d01必填列:bcefgijpd02b列【业务目标名称】与c列【业务目标协冋关系】的对应关系必须与数据库表【业 务目标】中保持一致，否则报红d03e列【业务功能】必须在【业务功能分析】的d列【业务功能名称】中能找到,否则 报红d04c列【业务目标协同关系】为"主目标"，且e列【业务功能】与d列【用户工作流 程】不为空时，业务功能与流程名称的映射关系必须与【用户工作流程全景视图】表 中保持一致，否则报红d05k列【问题归属】不为空时,则l列m列,n列,0

31、列不能为空，否则报红d06k列【问题归属】为"建模问题"时，l列为"3级活动流程定义不完整"或"4级任 务定义问题"或"业务活动或任务之间协作关系定义问题"或"cpc还原问题"或"其 他"，否则报红。d07k列【问题归属】为"业务问题"时，l列为"缺乏业务解决方案"或"监管政策要 求"或"客户服务流程定义不完整"或"其他",否则报红。d08k列【问题归属】为"其他问题

32、"时，l列为"资源问题"或"时间问题"或"其他", 否则报红。d09p列【是否补充需求】为是，则q列【补充需求具体内容说明】必填d10如果g列【是否是先进性需求】为 堤"，则h列必填d11如果j列【应用分析结果是否匹配业务目标】不为"完全匹配"时，1列丄列,m列,n 列q列都不能为空，否则报红d12c列【业务目标协同关系】不为空时，必须是直接列表中的选项d13f列【是否是增补目标一含修订】不为空时，必须是直接列表中的选项d14g列【是否是先进，性需求】不为空时，必须是直接列表中的选项d15列是否

33、是急迫性需求】不为空时，必须是直接列表中的选项d16j列【应用分析结果是否匹配业务目标】不为空时，必须是直接列表中的选项d17k列【问题归属】不为空时，必须是直接列表中的选项d18p列【是否补充需求】不为空时，必须是直接列表中的选项表5：用户工作流程全景视图列表合规检查规则规则序号规则描述e01必填列：cghe02c列【用户工作流程名称】与b列【三级活动】的映射关系必须与【用户工作流程表】 中保持一致，否则报红e03b列【三级活动】与e列【四级任务】的对应关系。如果e列【四级任务】不在【字 典-四级任务与逻辑应用组件映射表v15】中，则报黄。如果e列【四级任务】在【字 典-四级任务与逻辑应用组

34、件映射表v15】中，则一四级的对应关系必须与【字典-四 级任务与逻辑应用组件映射表v15】中保存一致，否则报红。三级活动或四级任务为 空或为（新增）时不査，e04e列【四级任务】与f列【业务功能】必须填写一列，否则报红e05g列【实施类型】选择第1、2、3、4、7项t期已经实现"或"2期已经实现"或"本期优化"或"本期新增"或"现有系统实现"时，f列必须填写,否则报红e06g列【实施类型】选择第5、6项"其他组件实施"或"非系统支持任务"时，e列 必须填写，否则报红

35、e07g列【实施类型】选择第3、4项"本期优化"或"本期新增”时，f列【业务功能】 与e列【四级任务】的对应关系必须与【业务功能分析】中的业务功能与四级任务的 对应关系保1寺一致，否则报红e08g列【实施类型】为"现有系统实现"，则h列填写最新系统基线中的系统英文简称, 否则报红e09g列【实施类型】为t期已实现"或"2期已实现"或"本期优化"或"本期新增" 或"其他组件实施",则h列填项目组名称，否则报红e10g列【实施类型】为"非系统支持任务

36、"，则h列选e列【四级任务】对应的组件名 称，否则报红ellg列【实施类型】为"非系统支持任务"，则e列【四级任务】在【字典四级任务 与逻辑应用组件映射表v15】中对应系统支持应为"n",否则报红e12g列【实施类型】选择第5项"其他组件实施"时，则f列必填（对接完成后查）e13i列【是否需要多个组件协同实现】选择"是"，贝，列填写的组件名称必须在【字 典表-四级任务与逻辑应用组件映射表v15】中e14g列【实施类型】不为空时，必须为下拉列表中的选项e15i列【是否需要多个组件协同实现】不为空时，必须为下

37、拉列表中的选项e16c列【用户工作流程名称】必须在【用户工作流程表】中的c列中能找到,否则报红3需求管控专项质量检查项目组将需求管控基线填写完毕之后，需求管控组会以基线为基础对项目 的应用分析内容进行各种深入的专项检查，包括范围承接率检查、目标覆盖度检 查、cpc完整性检查、用户工作流程述原合理性检查、业务功能还原合理性检 查和用户工作流程全景视图完整性检查。需求管控组以周为单位，通过pmo需 求管控周报和周例会的形式，对检查结果及整改进度进行持续追踪管理。3.1范围承接率检查企业级流程建模通过梳理我行各领域业务流程，进行标准化、去差异化和业 务组件化，形成易于理解的高阶流程模型。流程建模通过

38、标准化、结构化地描述 银行业务全貌，形成银行业务的知识库，有助于全行提高管理水平，加快产品创 新，实现功能公用，是承接全行战略转型目标的的关键举措。在新一代核心系统 建设过程中，流程建模作为唯一的需求来源指导开发实施，而需求管控正是承接 模型，将企业级转型全面落地的关键环节。在项目进行应用分析之前，业务部门、领域组以及信息委等相关各方通过集 中会议讨论划分各项目组应承接的模型需求（包括三级活动和四级任务），并以 此作为项目应用分析的范围。项目实施范围一经确定，不得随意更改。需求管控 组的职责之一就在于对划定的项0实施范围进行管理，包括追踪项目的应用分析 进度，接收项目的实施范围变更申请并协调相

39、关各方对申请问题予以解决。在项 目应用分析阶段，需求管控组每周对项目的范围承接率进行检查，督促项目组按 照建模要求完成应用分析。三级活动承接率二应分析已分析三级活动/应分析三级活动四级任务承接率二应分析已分析四级任务/应分析四级任务3.2目标覆盖度检查在企业级建模过程中，流程建模人员通过梳理我行各领域业务流程，提炼岀 多项能力主题需求，并细化成流程能力，凝练岀项目实施需要实现的业务价值方 向，并以此作为项目应实现的业务目标。业务目标分为主目标和协同目标两类， 所谓主目标是指本项目可独立实现的目标，协同目标乂分为牵头协同和配合协 同，需要双方乃至多方配合实现的目标对于其中的主动项目组而言就是牵头

40、协同 目标，对于其中被动的项目组而言就是配合协同目标。在项目进行应用分析之前，业务部门、领域组、信息委以及项口组等相关各 方也会通过集中会议讨论等方式划定各项目组应实现的业务目标。每个业务目标 下面对应多个需求项，项目组在应用分析过程中，需将本项目组应实现的业务目 标和本项冃组实施范圉内的四级任务对应上，确保冃标的实现。在项冃应用分析 阶段，需求管控组也会每周对项fi的fi标覆盖进行检查，保证项冃组冃标的实现。主目标覆盖度二应分析已分析主目标/应分析主目标协同冃标覆盖度二应分析已分析协同r标/应分析协同目标3.3 cpc完整性检查3.3.1 cpc完整性检查内容及规则流程建模中对每个标准化的三

41、级活动和四级任务对应的c（customer客户）、 p （product产品）和c （channel渠道）都进行了定义。在应用分析阶段，项目 组对三级活动和四级任务进行还原，将三级活动还原成用户工作流程，将四级任 务还原成业务功能。从完整承接建模的角度来看，某个三级活动还原成多个用户工作流程时，这 些流程对应的客户（产品、渠道）的总和应该能完全覆盖建模中对该三级活动对 应客户（产品、渠道）的定义。同理，某个四级任务还原成业务功能吋，还原出 的业务功能对应的客户（产品、渠道）的总和应该能完全覆盖建模中对该四级任 务对应客户（产品、渠道）的定义。我们开发出“cpc完整性检查工具”，将不 符合上述情

42、况的三级活动及对应用户工作流程、四级任务及对应业务功能标注为 存疑，并在工具中将明细列示击来供项目组查看。项目组可对存疑的部分进行深 入分析，发现问题及吋整改，如项目组认为分析合理，可在工具中对未覆盖建模 的情况进行解释说明，供pio和pmo进行复核。如项目组理由充分，解释合理, 得到pio和pmo认可，便可通过检查，否则则需进行整改，直至符合pmo要 求为止。3.3.2改进点上一章提到过，新一代三期，项冃组可通过我们开发的自动化填报工具进行 基线填报，我们以用户工作流程列表的填写为例。项目组在填写用户工作流程列表时，填写到客户（产品、渠道）列，系统会 自动推送出建模中全量的客户（产品、渠道）

43、清单供项目组勾选，避免项目组手 工输入带来的差错。然而，项目组在进行cpc分析时，可能对该三级活动在建 模中对应的客户（产品、渠道）并不是十分清楚，甚至可能存在项目组完全不查 看建模的情况，这样填写岀来的客户（产品、渠道）必然与建模存在较大岀入。试想，如果项fi组在填写用户工作流程列表时，填写完三级活动和用户工作 流程后，填写对应的客户（产品、渠道）列，系统自动推送的不是建模中全量的 客户（产品、渠道）清单，而是优先推送该三级活动在建模中对应的客户（产品、 渠道）供项fi组进行参考，再进一步支持“其他”选项，如项fi组对建模进行了 扩充，点击“其他”选项，就会显示除建模外全量的客户（产品、渠道

44、）清单， 供项目组进行选择。项目组将用户工作流程列表填写完毕后，进行合规性检查， 如存在某个三级活动还原成出的多个用户工作流程时对应的客户（产品、渠道） 的总和不能完全覆盖建模中对该三级活动对应客户（产品、渠道）的定义时，系 统会对该三级活动和对应的流程进行标注，并提供说明框，供项冃组填写未覆盖 理由。如此，既能将cpc完整性的检查规则融合进填写工具中，避免多个工具 多重检查带来的繁冗操作，又能做到事前引导项目组的应用分析。3.4用户工作流程还原合理性检查将项目实施范围内的三级活动进行用户工作流程还原，是应用分析屮的关键 一环，保证用户工作流程还原的合理性对保证项目的应用分析质量具有重要意 义

45、，用户工作流程还原合理性检查的作用便在于此。需求管控对用户工作流程还 原合理性进行的检查主要从以下三方面开展：检查承接建模：承接模型完整性、正确性分析用户流程是否承接建模三级活动目的、定义、范围分析用户流程是否反映行内泳池和行外泳池的交互关系 分析用户流程是否覆盖建模三级活动流程分支和任务节点检查需求满足度：建模成果对需求的满足度检查转型目标需求项满足度检查主线需求满足度检查应用分析补充需求满足度检查便函需求满足度检查影响用户流程因子：用户工作流程影响因子分析的合理性分析完善后的三级活动流程分支和任务节点识别用户工作流程的影响因子回归三级活动模型通过新一代二期需求管控的经验，我们将在用户工作流

46、程还原合理性专项检 查工作中发现的存疑典型问题梳理成三类，如表6所示：表6：用户工作流程还原存疑典型问题问题分类典型问题承接建模类 问题问题一：由于还原其他应用的三级活动分支形成用户工作 流程导致的映射关系不符-问题二：用户工作流程调用业务功能的关系与相应的三级 活动和四级任务的映射关系不符问题三：该应用范围中，本项目组仅实施用户工作流程中 的1-2个业务功能-问题四：本项目组需调用其他项目组功能，但未包含在用 户工作流程中分析问题五：公共分支未涵盖全分析执行类 问题-问题六：分段还原三级活动（按用户分解还原/按三级活 动流程某段还原）问题七：业务功能颗粒度影响用户流程还原模式选择-问题八：同

47、一活动还原多个用户工作流程，但调用的业务 功能一致用户体验类 问题问题九：三级活动下仅有1-2个四级任务为系统化支持-问题十：三级活动下的某个分支仅有1-2个四级任务为系 统化支持问题十一：针对主线需求如预约预处理、客户识别、前后 台分离、客户消息推送等体验设计问题新-代二期的用户工作流程还原合理性检查全部采用人工识别的方式，由于 二期用户工作流程数量太多，工作量巨大，所以采用三级活动重点抽查的方式， 但仍然动用大量人力物力，并耗时1个多月。新一代三期，我们将二期梳理的典 型问题进行整理，开发出“用户工作流程还原合理性检查工具”，将大部分典型 问题作为规则，利用工具进行自动匹配检查，部分无法写

48、入规则的再进行人工抽查，如此节省了大量的时间和精力。3.5业务功能还原合理性检查3.5.1业务功能还原合理性检查内容及规则业务功能是承接业务模型四级任务，是系统用例设计、服务设计的依据。业 务功能列表通过分析四级任务的cpc因子，结合对现状系统功能、业务增补需 求、功能实现部署要求的考虑，形成并确认项目开发的业务功能清单及定义。包 括：通过cpc述原的方式验证并完善四级任务模型的业务功能，根据项目实施 策略定义的过渡期业务功能，无指定业务目的查询，满足生产运维的业务功能， 满足业务参数维护的业务功能，不包括技术监控、技术h常运维、投产时配套的 切换功能等。建模中定义四级任务时满足以下四个特征：

49、由一个角色执行考虑时效性、操作连续性考虑人工决策点完成一个完整的业务目的根据建模分析方法，结合二期实施过程中的相关变化，我们识别岀四级任务 还原业务功能时，在考虑cpc的基础上，述需深入考虑业务触发界常事件、其 他变量因子以及数据标准（渠道）的变更影响。结合二期业务功能述原合理性检 查的经验，我们将项目组常见的典型问题分为以下两大类四小类：表7：业务功能还原存疑典型问题问题分类典型问题体验设计类问-针对核心设计如服务记忆、客户消息整合等体验设计问 题题-针对主线需求如手工登记簿电子化、减少补录等体验设 计问题分析执行类问-分步骤还原四级任务题分用户还原四级任务根据业务功能还原的原则，原则上来说

50、，业务功能与四级任务应该是一一对应，当然也有一个四级任务对多个业务功能或一个业务功能对多个四级任务的情 况，要结合还原的具体情况进行判定。新一代二期，需求管控在进行业务功能还原合理性检查时，全部采用人工辨 别的方式，工作量巨大。新一代三期，我们开发岀“业务功能还原合理性检查工 具二将业务功能和四级任务不符合一一对应情况的全都标注为存疑，并在工具 中将明细列示岀来供项目组查看。项目组在分析完成之后，利用“业务功能还原合理性检查工具”进行自查，对 于还原出的业务功能和四级任务不符合一一对于情况的，项目组再次进行深入分 析，发现问题及时进行整改，如项目组认为还原合理，可在工具中对还原因子和 还原方式

51、进行解释说明，供pio和pmo进行复核。如项目组理由充分，解释合 理，得到pio和pmo认可，便可通过检查，否则则需进行整改，直至符合pmo 要求为止。3.5.2改进点“业务功能还原合理性检查”是项目在基本完成应用分析后进行的一项专项 质量检查，属于先分析还原，后检查整改。这种事后的检查在某种程度上仍然显 得低效。在上一章里我们提到过，在新一代三期的管控中，项目组的基线提交已经由 新一代二期实行的“先填写后检查”变革成了 “边填写边检查”，大大提高了填 报效率，而我认为业务功能还原合理性的检查规则相对简单，也可以一并加入“填 写工具”的规则里，将业务功能还原合理性的检查也部分前置，避免了多个工

52、具、 多项检查的繁复，尽量做到一个工具涵盖所有检查。当然，业务功能还原过程中，对于部分特殊情况，存在业务功能和四级任务 不符合一一对应的情况，项目组提供说明的，仍然需要人工识别，这部分工作是 工具无法替代的。3.6用户工作流程全景视图完整性检查361用户工作流程全景视图检查内容及规则用户工作流程全景视图列表（以下简称“全景视图”）反映的是本项目应用 实施范围内三级活动还原出的全部用户工作流程，及各用户工作流程调用的全部 节点，包括：1）本项冃组实施的业务功能（包括业务功能以及必需的it功能）；2）其他项目组实施的四级任务（完成跨项目组对接后更新为业务功能）；3）改造类项目已实现且本期无优化需求

53、的系统功能。根据用户工作流程全景视图列表的作用，我们梳理出对用户工作流程全景视 图进行完整性检查的规则，包括：1、用户工作流程列表中分析的所有用户工作流程，都必须在全景视图列表 中进行分析，否则称全景视图列表中用户工作流程分析不完全；2、用户工作流程列表中每个三级活动对应的所有用户工作流程在全景视图 列表里对应的所有四级任务，应该完全覆盖建模中该三级活动下的所有的四级任 务，否则称该三级活动还原出的用户工作流程存在节点缺失。我们运用“用户工作流程全景视图完整性检查工具”，对项目组填写的全景 视图进行检查，将分析不完全的用户工作流程和存在节点缺失的三级活动标注为 存疑，并将明细列示出来供项目组查

54、看。对于分析不完全的用户工作流程，项目组应补充分析完整。对于存在节点缺 失的三级活动，项目组应进行深入分析，发现问题及时进行整改，如项目组认为 还原合理，可在工具中对节点缺失的理由进行解释说明，供pio和pmo进行复 核。如果项目组理由充分，解释合理，得到pio和pmo认可，便可通过检查， 否则则需进行整改，直至符合pmo要求为止。3.6.2改进点学员结合三期管控经验，将部分用户工作流程全景视图节点缺失的正常情况 进行了梳理：1、两个或多个项目组同时实施一个三级活动，双方各承接三级活动下的部 分四级任务，某一个项目组在分析用户工作流程时，调用的业务功能对应的四级 任务不包扌舌对方项目组承接四级

55、任务，因而存在节点缺失。这种情况属于正常的 节点缺失，无需项目组进行整改。2、工具在检查节点缺失时，采用将用户工作流程列表中每个三级活动还原 出的所有用户工作流程在全景视图列表里对应的所有四级任务，与该三级活动在 建模中的所有四级任务进行比对的方式。部分非系统化的四级任务无需在应用分 析阶段进行分析，也无需进行业务功能还原并在用户工作流程中进行调用，这种 节点缺失，也属于正常的节点缺失，无需项目组进行整改。对于以上两种情况，其实我们可以通过简单地修改“用户工作流程全景视图 完整性检查工具”的检查规则，避免这类不必要的“伪存疑”的出现，避免耗费 项目组太多时间精力进行分析和填写解释说明。我们在利

56、用工具在检查节点缺失 检查时，将用户工作流程列表屮每个三级活动还原出的所有用户工作流程在全景 视图列表里对应的所有四级任务，与该三级活动在建模中对应的四级任务在本项 目组实施范围内的部分进行比对，即可以避免以上两类“伪存疑”的岀现。同时，按照尽量避免多个工具多重检查的繁复的原则，我们还可以将用户工 作流程还原合理性检查的规则融合进基线填写工具，实现项fi组自觉的“边填写 边检查边修改”，替代管理组发起的专项质量检查。4总结与展望本章中，学员回顾导师责任制实施一年以来在需求管控组参与的主要工作实 践，并对在本文中提出的部分改进点进行总结。4.1总结学员入职一年以来，一直在需求管控组参与实践工作。

57、通过导师的指引和各 位同事的帮助，学员系统全面地学习了需求管控方法论，并在参与实践的过程中 掌握了需求管控的基本内容和流程。本文中，对需求管控的重要内容一专项质量检查进行了梳理，并对部分检查 的方法提出了自己的想法和改进意见。主要体现在：1、cpc完整性检查学员提出，在项目组填写基线吋，可以通过自动推送建模中三级活动/四级任 务对应的cpc的方式，引导项目组在应用分析中承接建模。同|寸，将cpc检查 的规则加入基线填写工具，实现项目组边填写边检查边修改，取消该专项检查， 可以避免多个工具多重检查的繁复。2、业务功能还原合理检查目前，业务功能还原合理性检查的规则相对简单，即检测是否存在四级任务 与业务功能不符合一一对应的情况，这项检查规则也可以一并加入基线填写工具 的规则里，将业务功能还原合理性的检查前置。3、用户工作流程全景视图完整性检查学员结合新一代三期项目管控经验，将用户工作流程全景视图节点缺失的正 常情况进行了梳理，并提出，我们在利用工具在检查节点缺失检查吋，对检查规 则进行简单修改，即可避免这些“伪存疑”的出现。我们可以对规则进行如下修 改：将用户工作流程列表中每个三级活动还原岀的