☞ ░ 前往老猿Python博客 ░ https://blog.csdn.net/LaoYuanPython
一、背景
需求处理各环节的各参与方人员存在变更，知识背景不同，导致需求提出、分析设计、测试、交付各环节容易出现考虑不完整，从而限制了整个研发过程的效率以及质量的提升，无法有效的匹配当下市场需求迭代速度:
- 需求收集过程中，容易出现需求描述不完整、需求冲突、需求重复、需求内容遗漏等问题；
- 需求分析过及设计程中，容易存在分析不全面，设计考虑不周，特别是系统关联性、功能关联性考虑不周，容易导致需求方案存在缺陷甚至风险；
- 测试方案制定时，由于需求内容文档和方案设计文档的不完善，以及测试人员限于各种知识了解程度不同，导致测试方案不完善；
- 需求交付运维过程中，由于参与人员对业务知识及维护知识了解不够，导致在需求交付运维时，提供的内容不全，维护关注点不广等，没有。
随着这些问题的出现，开发管理条线管理上采用专家咨询和审核来提升需求各环节的质量，但一方面专家有限，另一方面专家也不是全知全能，导致这种解决办法无法达到根本上扭转需求开发中的各种问题。
二、解决方案介绍
2.1、概述
为降低系统开发中需求提出、分析设计、研发测试、部署运维各角色环节的消耗，湖北移动结合基于知识图谱的"知识库"管理技术，引入行业词库、知识图谱、知识库技术，整合已有需求数据、测试数据、问题数据、风险数据等，构建基于知识图谱的智能辅助需求管理体系，实现需求开发管理过程的智能辅助，提升需求开发管理的质量和效率。
2.2、为需求处理各环节提供专家级解决方案
2.2.1、构建行业知识库
行业知识库部分包括行业词库、同义词库和行业词汇树三个子库以及词库知识维护管理功能模块，在系统建设初期通过数据收集一次性导入，后续随时间推移和业务发展不断更新。
1.行业词库构建
行业词库内保存着体现行业特点的词汇，如电信业务中常见的词汇"流量"、"通话"、"详单"、"账单"、"身份证认证"、"人证一致性验证"、"一证五号"等都是与电信业务紧密相关的行业词汇，一个需求中出现的行业词汇表达了需求内容方向的典型特征。将行业词汇保存到数据库中，就可以构建独立的行业词库。湖北移动的需求行业词库目前记录行业词汇3683个行业词汇。
典型的行业词库具有如下4个特征：
1)随着业务的发展和时间的推移不断完善；
2)表征业务的特定行业词汇可能存在多个，如"人脸识别"、"人证一致性验证"是相同的含义，"详单"、"清单"、"话单"都是表征类似含义；
3)表征某类特征的行业词汇之间存在一定的关系，包括类属关系（如"国际流量"、"流量提醒"、"流量"这三个词汇存在类属关系，请参考后续部分的"行业词汇树"的相关介绍）、并列关系（如"国内流量"、"国际流量"）等；
4)表征同一特征方向类属关系的词汇，类目细分越详细，特征越明确，同时下层词汇是上层词汇的一个特征知识点，这种上下层级结合在一起就表征了某个特征知识点包含的细化特征知识点，可以根据细化特征知识点是否齐全判断上层知识点的描述是否完整。
2.同义词库构建
前面已经介绍，表征业务的特定行业词汇可能存在多个，它们表示的需求方向是基本相同的，为了在需求处理时，支持这种相近或相同的词汇都能正确处理，我们需要构建行业同义词库，同义词库以行业分词的"标准词汇"（是否是标准词汇无所谓，关键是一个相同业务特征只能指定一个标准词汇）作为主键，其包含的近似或相同的行业词汇作为表达式要素。当一个词汇无同义词时，则无需定义同义词，其自身就是"标准词汇"。
下表是部分同义词的定义样例：
3. "行业词汇树"构建
由于行业词汇代表的知识存在一定的知识类属属性，因此取行业词汇中的标准词汇构建由维护人员手工构建"行业词汇树"。
下图为行业词汇树中表征流量业务的几个词汇以及类属关系的一个"词汇分支"，可以看到从一级节点"流量"逐渐往下，业务特征越清晰。
从行业词库的角度，行业词汇树其实并不是一个真正的树状结构，只是表征词汇之间的类属关系。在行业词汇树最上层，没有一个词汇可以作为根节点，只有众多的一级节点，其次不同的分支可能会指向到下层相同的节点，如上图的"国际流量"与"定向流量"存在相同的叶子节点。
4.设置每个行业词的计算权重
当行业词汇库构建后，由于不同行业词表征的需求特征的作用不同，需要针对不同的行业词根据影响情况设置不同的权重，为了简化设置，本项目采用了基于"词汇树"的层级方式设置权重，在"词汇树"一级节点的词汇，权重设置为1，"词汇树"叶子节点的词汇，权重设置为10，其他中间节点的词汇权重设置为5。
2.2.2、需求预处理
可以看到，有了行业词库，还需要建立分词的知识关联关系，也就是知识图谱，基于知识图谱的知识库管理平台，能提供知识搜索功能，在支持"精确搜索"的前提下，同时提供将原有以"已知"搜索"已知"变为"已知"搜索"未知"的能力。便于各处理环节获取与目标相似的已存在信息。例如"发票打印"可以关联"税票打印"、"票据打印"，下面是一个"发票打印"通过知识图谱关联搜索出来的知识。
1.构建历史需求行业词库特征信息库
在行业词库构建后，对需求管理平台的所有存量需求进行行业词库匹配（匹配时按最长匹配原则匹配），建立每个需求包含的行业分词数据库，这个需求行业分词数据库就表征了每个需求的特征。
2.需求提交时进行重复需求检测以及需求内容完整性检测
当新提交一个需求时，首先生成该需求的行业特征，然后与历史需求的需求特征进行匹配，设定相似度超过某个阈值的需求认为是潜在的重复需求，告知需求提出人进行人工判断处理。
同时通过行业词库，可以判断需求内容是否完整，例如在一个需求中如果检测到了"流量"、"流量提醒"特征词，但没有"流量查询"特征，就认为需求内容可能考虑不完整，提示其是否需要增加流量查询的内容。
3.需求分析设计和测试方案完整性检测
首先在需求分析设计和测试方案设计时，对分析设计文档和测试方案文档进行分词识别处理，与需求特征分词进行匹配，确认需求的特征是否完整的在分析设计文档和测试方案文档中出现。
其次构建需求方案设计知识库和测试方案两个各自独立的知识库，针对某些发现的重要关注点进行方案提醒，如"流量提醒"需要同时考虑实时提醒和定时提醒，需要关注实时提醒的几种不同阈值（50%、90%、100%）的场景等等，帮助完善两种方案设计。
4.需求交付风险以及运维知识检测
构建需求风险知识库和运维知识库，需求风险知识库和运维知识库的知识是需求处理以及业务运营过程各环节处理人发现或遇到的风险以及运维的经验，经评估后录入知识库中，将这些风险点与运维经验与特定行业分词进行关联。
例如针对"流量提醒"，增加风险知识点"提醒短信内容的变更属于高风险，需要在上线前和上线时进行重点验证测试，并在上线后先生成短信但不能发送，待检查一定量短信后才能打开进行发送。"，这样当需求内容、分析设计文档中存在"流量提醒"相关的特征时，即触发风险检测提醒。
这样需求交付前，结合需求风险知识库和运维知识库，生成需求可能包含的风险和运维知识，为上线交付过程以及上线后业务以及系统运维提供风险指引，尽量确保不踏入同一条风险河流。
三、需求知识库的实现
下面是需求管理平台需求知识库以及智能辅助系统的功能框架：
系统中各组件详细技术内容：
1、行业知识词库
行业知识词库主要是基于电信行业现有知识库及收集到的行业业务知识，按照业务进行分类，分为专有词库、营销词库、系统词库、研发用语、运维配置用语五类，每类词库中均包含不同词性的业务词，有名词、动词、动名词等。
行业词库新增主要对大量的结构化数据、半结构化数据和非结构化数据进行分析处理，按照数据来源分为两类，一是现有的知识库管理，可以人工新增相关词库；二是现有工单数据，对描述内容、附件等文本提取后进行综合合并分析，过滤掉已经存在于词库中的内容，将可能的新词提取出来加入词库。然后再对这些知识进行融合分析，将可能的新词提取出来，经审核后加入词库由此即可形成自维护数据词库。需求专有词库如下：
2、数据清洗及文本处理
鉴于电信行业词库及语料具有固定性、特征词明确的特点，本项目采用基于MMSEG的改进分词算法，使之更符合电信行业应用。使用行业词修正的MMSEG技术（complex的匹配方法加行业词规则），可显著提高行业文本数据的文本识别准确性。应用实例如下：
【普通文本处理结果】托 收 发票 模式 改为 电子 发票 ， 托 收 扣款 完成 后 ， 系统 可以 自动 为 用户 推送 电子 发票 。 增加 托 收 发票 开具 电子 发票 个人 信息 录入 功能 （ 单位 名称 、 纳税人 识别 号 、 地址 电话 、 银行 及 账号 等 信息 ） 。
【MMSEG（complex行业词）处理结果】托收发票 模式 改为 电子发票 ， 托收扣款 完成 后 ， 系统 可以 自动 为 用户 推送 电子发票 。 增加 托收 发票 开具 电子发票 个人信息 录入 功能 （ 单位名称 、 纳税人识别号 、 地址 电话 、 银行 及 账号 等 信息 ） 。
其中黄色部分为使用MMSEG（complex行业词）技术识别出的文本。其实现算法如下：
maxO描述为按文本逆向检索，字符及词语在已知词库下最大字符距离，约束及为附加的行业词条件。
3、知识图谱及内容推理
知识图谱是由一些相互连接的实体以及它们的属性构成的。经过业务词库、业务语言处理后形成的文本，可被知识提取，知识简单表示为实体与实体之间的关系，用S，P，O三元组模型（属性-关系-值）来表达，这也是是知识图谱最基本的数据结构。行业知识图谱与普通知识图谱的不用之处在于数据单元是以行业词构建的，主要是增强文本判别度及准确性。同时相同的词在行业语境中天然的获得"唯一释义"属性。
a)数据抽取
通过数据抽取可以将知识三元组抽取出来，也就是说数据抽取主要是针对半结构化知识和非结构化知识进行的实体抽取、关系抽取、属性抽取。实体抽取从电信行业知识中获取关键的实体信息,属性抽取的主要任务是获取属性和属性值，关系抽取则获取关系。
b）知识融合
采用人工融合要自动融合相结合的方法进行知识融合。其中结构化的知识可以直接进行知识合并，而抽取出来的实体往往存在相同的物体不同名或者相同的名称不同物体的情况，需要进行实体关联和实体聚类。
c) 知识加工
知识加工主要进行本体构建与知识推理，还需要对知识进行质量评估，经过质量评估的知识即可构建知识图谱。
知识图谱schema构建除简单关系外，各S、O之间还有另外的关系，所有的关系和逻辑层次即为，相当于为其建立本体（Ontology），最基本的本体包括概念、概念层次、属性、属性值类型、关系、关系定义域（Domain）概念集以及关系值域（Range）概念集。
知识融合后，在实际运用过程中，DevOps要求在各环节根据需求提出推理出需求、方案、问题、测试案例、风险描述、运维关注点等相似数据，提升各环节交付效率。运用到的知识推理及路径张量分解算法可描述为，在含有n个实体和m个关系的知识图谱G中，可以使用一个三阶张量Xxnm，如果实体与实体之间存在某种关系k，则使用张量的第k层Xk表示，通过分解，第k层张量可近似表示为Xk≈ARkAt，k=1,2，......m，其中A为nd的矩阵，d为特征数，Rk=d d，张量分解问题优化为如下问题：
如果存在三元组（S,P1,O1）(O1,P2,O2) (O2,P3,O)通过关系路径传递，可推出实体h和t间可能存在的三元组（S,P,O）。
在本项目后期，为了优化上述张量分解方法在大规模知识库表示学习过程中学习效率低的问题,很多研究者转向对于知识库中的基本语义单元: 三元组进行独立建模。这类方法通常将知识库中的三元组表示为(h,r,t),h表示头实体,r表示关系,t表示尾实体,它们的向量分别表示为h,r,t.其假设h和t经过某种与r相关的映射后得到向量应该相似或者相等的。为了刻画这一过程,通常定义基于三元组的能量函数为fr(h,t),则学习的目标函数为
d)开发管理支撑平台中的相关内容推理模型
由业务专家建立需求收集、分析设计、开发测试、交付运维中的关系定义域，按多级结构组织关系，可由人工、机器协同创建。人工创建关系定义的1-2级，由机器按照"相似"关系自动补充3-4层的关系描述，人工可进行审核提高准确度。根据DevOps体系要求，在本项目中，各推理模型均包括"交付内容"。
4、知识存储
系统知识库可自定义库类型，即知识库模型。根据不同的模型，支持不同的应用场景，单个知识库中，知识分为多层级进行存储、管理。在同一层、或不同层间，知识利用可定义的"匹配规则"及"知识关联关系"进行连接，并根据不同的输入及推理模型，对外输出推理结果。本系统涉及的五大知识库如下：
a)需求完整性知识库：包含需求完整性相关知识，服务于需求完整性检测，即在用户输入需求时，检测用户输入的内容，利用"需求完整性知识库"中的知识进行推理，提示用户可能缺失的需求、结合存量需求数据提示重复或相似的需求，并在用户完成输入后，标记缺失状态。
b)设计方案完整性库：包含设计方案完整性相关知识，知识及其关联关系来源于存量及新增设计方案的内容分析及训练，服务于设计方案完整性检测，即在输入设计方案内容后，对内容进行检测，利用"设计方案完整性"库中的知识进行推理，提示设计人员缺失的功能要素、软件资产、运维说明等。
c)风险知识库：包含风险点相关知识，知识及其关联关系来源于存量数据及人工编辑校对的内容，侧重应用于风险自动提示、自动完善风险评估报告等功能，即在设计方案确定后，可对方案自动进行风险评估，同时支持专家对评估结果进行人为修正，生成风险评估报告，修正的结果会作为"风险知识库"的自我修复依据参与库模型的训练。
d)测试方案完整性库：包含测试方案完整性相关知识，知识及其关系来源于存量及新增测试方案、用例的内容分析及训练，服务于测试方案完整性检测，即在确定设计方案后，将内容与"测试方案完整性库"中知识进行匹配，提示方案设计人员缺失的测试用例、测试场景。
e)运维知识库：包含各知识点需要关注的重点运维知识，在新功能开发过程中，对于新功能中使用到的已有知识，自动提取知识库中的运维知识作为需求交付运维文档的内容，同时在需求开发各环节的处理责任人可以根据处理情况添加该功能需要新关注的运维内容，并根据有关知识点补充到运维知识库中。
5、全流程运维内容交付
在运维交付时，根据运维知识库及各环节新增的运维关注内容统一生成需求相关的运维交付文档：
6、增量数据训练模型及算法
DevOps要求在各环节交付时，内容可追溯，产生的新数据可重复用于生产，在本项目环境下，即产生的新需求、方案、问题、测试案例、风险描述、运维关注点等数据，可通过知识提取、训练的方式，重新加入到知识图谱中，形成新的知识，为后续生产提供数据支撑。
a) 设知识存储单元为基本三元组结构（SPO），关系有一个属性，不可逆
b) 将最小单元链接起来成为一个有向图（graph），每个节点是一个一个实体，每条边是一个关系，或者说是一个事实（fact），链接通过训练完成组合。
c) 引入TransE算法提升上述基本训练方式的训练效率，即基于实体和关系的分布式向量表示，将每个三元组实例（SPO）中的关系P看做从实体S到实体O的解释，通过不断调整S、P和O(S、P和O的向量），使（S + P） 尽可能与 O 相等，即 S + P = O。设S:sub，P:rel，O:obj，则元祖关系训练可表示如下：
d)使用应用图例可简单表示如下：
7、知识可视化
基于特征向量中心性的知识图谱采样算法, 使用知识图谱的特征向量中心性作为抽样方法的基础, 考虑了节点和关系的类型, 因此更适用于知识图谱采样。可视化表达上使用力导向布局来显示采样网络, 不同颜色代表不同类型的节点, 节点大小对应于每个节点的特征向量中心性的值, 同时也表示此节点在网络中的重要性, 从而使用户能够轻易辨别某个节点的重要性。
8、应用案例
原始需求：托收发票模式改为电子发票，托收扣款完成后，系统可以自动为用户推送电子发票。增加托收发票开具电子发票个人信息录入功能（单位名称、纳税人识别号、地址电话、银行及账号等信息）。
通过文本处理层，系统自动从原始文本中抽取行业词
-
需求收集完整性推理
在需求收集阶段，根据推理结果，需求提出方和收集方，在进入需求分析环节前，即可对需求进行完善，同时根据相似工单，可避免重复、冲突的需求，省去反复沟通、专家参与。需求分析人员从推理结果中可很清晰分析出以下三个问题：
1)电子发票只支持普票，如果原来开具专票的场景怎么处理？
2)如果用户没有登记电子邮箱怎么处理？
3)增加的"纳税人识别号"会引起哪些问题？
完善后的需求如下：
托收发票模式改为电子发票，托收扣款完成后，系统可以自动为用户推送电子发票，同时对用户信息进行改造，要求必填邮箱，如未填写邮箱信息，需短信提示用户。增加托收发票开具电子发票个人信息录入功能（单位名称、纳税人识别号、地址电话、银行及账号等信息），对于个人证件客户与原有电子发票流程相同无需处理，对于政企客户根据用户需要确认是否单独手工输入。
-
分析及设计推理
分析设计阶段中，分析设计推理模型中主要完成利用设计案例库自动为分析设计人员提供案例设计推荐，分析设计人员可加入至自己的设计方案中。具体描述如下：
需求收集后，即完善后的需求进行知识提取，在分析设计环节系统的推理将会按照实际完善修改后的需求内容进行推理。系统首先提取业务词，分析设计推理模型将业务词进行过滤（分析设计关系值域），提取关系后进行推理。
分析设计人员可直接选择案例加入本次设计方案，也可修改后加入（修改后的内容作为新数据进行训练）：
- 开发测试自动风控
在开发测试过程中，问题及风险描述与需求本身的文本内容往往相差较远，无法依靠协同过滤、相似等算法获得很好的效果，故在开发测试推理（推荐）模型中，采用基于需求涉及系统、模块及分配的开发厂商、团队、负责人等属性信息进行"属性过滤推理算法"。
推理算法，由于从需求属性，即格式化的数据中抽取的知识相对精确，不需使用相似等关系进行训练，故只需将该抽取的知识作为确定的反馈内容，辅以设计内容中的部分文本内容，利用隐式反馈算法即可获得结果，算法简述如下：
开发人员可将风险案例加入研发过程，或将风险案例提交至运维（在进入交付运维时体现），作为交付内容之一；测试人员可根据推理的测试数据，评估测试风险，是否要增加测试场景或测试案例。
丰富交付运维场景，增加运维覆盖内容
交付运维内容推理模型训练方法与生成风险控制模型训练思路类似，不同的是更加侧重于功能点涉及的系统模块，依据系统模块、研发功能点，并将其作为反馈内容进行推理。除此环节推理的内容外，在"分析设计""开发测试"环节由人工选择、人工输入的交付内容，会作为已有内容提交至运维交付。
在此种训练方式下，结果会更少，但描述会更通用（图中来源为"系统提示"）
小结
本文介绍了一种基于知识图片的只能辅助需求管理体系，该体系借助需求处理各环节处理专家的知识，将其整理成知识库知识，结合需求处理各环节的平台支持，进行需求内容、分析设计、测试方案以及交付各阶段的输出内容的质量提升，从而提升整体需求的处理效率，这个过程是一个随需求处理不断循环往复、逐步完善的过程，颇为契合Devops的理念。
