Page 283 - 《软件学报》2025年第10期

4680 软件学报 2025 年第 36 卷第 10 期

(2) 需求信息抽取. 这一步基于预处理的结果对规则进行需求信息抽取. 我们使用第 2.2 节中创建的需求信息抽
取模型执行信息抽取任务. 首先, 我们将一些示例业务规则输入需求信息抽取模型, 并对它输出的结果给予反馈. 经
过 5 轮迭代后, 我们将上一步的输出依次输入模型进行信息抽取. 例如, 在子规则 3.3.4.1 的条件部分, 需求信息抽取
模型从输入的规则中抽取并标注了关键信息, 包括交易方式、交易品种、键和数量, 同时确保信息完全对应原文内容.

交易方式: 匹配成交 交易品种: 债券现券 键: 申报数量 数量: 1 000元面额或其整数倍

特别地, 需要注意的是, 在这里为了保证信息抽取的质量, 我们允许人与抽取模型进行必要的少量 (实验显示
5 次即可) 交互, 人的作用是核实和确认这一阶段的中间结果. 这可能比完全无交互的自动化方法效果更好. 这些
任务不要求深厚的领域专业知识, 普通需求工程师即可完成.
(3) 形式化需求的组装. 在将信息抽取的结果转化为形式化需求表示的过程中, 必须深入考虑规则的结构特
性, 确保组装算法充分适应多样化的语言表达习惯. 基于对业务规则表达方式和结构的分析, 我们提出了一套规则
组装算法, 具体步骤如下.
1) 生成形式化需求子句. 该步骤的目标是将抽取模型输出的结果组装起来, 生成形式化子句. 一个形式化子句
由实体、实体类型以及连接它们的谓词这 3 部分组成. 算法从抽取模型输出的结果中提取每一个实体类型-实体
对, 并将其组装为“实体类型 is 实体”格式的形式化需求子句.
2) 组装子句. 在生成子句后, 算法将子句通过 and 连接构成形式化需求的条件部分, 即 if 语句, 并将第 3.1 节中预
处理阶段识别的结果放入结果部分, 即 then 语句. 例如, 上述规则 3.3.4.1 的抽取结果组装得到的形式化需求如下所示.
rule 3.3.4.1
if 交易方式 is “匹配成交” and 交易品种 is “债券现券” and 申报数量 is “1 000 元面额或其整数倍”
then 结果 is “成功”
在这个示例中, 条件部分由 3 个子句组成, 每个子句都描述了一个具体的要求: 交易方式必须是“匹配成交”,
交易品种必须是“债券现券”, 申报数量必须是“1 000 元面额或其整数倍”. 子句之间通过逻辑“and”连接, 所有子句
必须同时满足, 才能触发结果部分. 当条件满足时, 预期的结果是“成功”. 这种形式化的输出使得业务规则一目了
然, 便于理解和执行.
3.2 需求可操作化
上一步生成的形式化需求是直接从业务规则文档中解析得到的, 它只包含规则的直接表述和明确约束, 但有
时可能缺乏实施需求所必需的背景信息和上下文联系, 使得需求不够明确. 因此, 为了构建一个可操作的、具体的
需求集, 我们需要引入交易概念领域知识和上下文信息以补全这些需求. 这一阶段的处理主要包含 4 个步骤, 分别
为必要约束补全、抽象需求具体化、嵌套需求处理以及同属性项组合.
(1) 必要约束补全. 每条需求都有一系列必须要满足的约束条件, 比如该需求适用的交易市场和品种等. 如果
缺少这些约束, 这条需求将无法被执行. 然而, 并非所有需求都完整包含这些约束, 因此, 我们需要对每条需求的必
要约束进行补全. 单条需求需要补全的必要约束被定义在交易概念知识库中, 例如, 对于债券交易, 必要约束包括
交易市场、交易品种、交易方式等. 为了补全需求中缺失的必要约束, 我们结合相应需求的具体上下文和领域知
识获取对应的信息. 以案例 1 中的规则 4.4.4 为例, 原始需求并未包含交易市场、交易方式以及交易品种. 然而, 通
过分析上下文, 我们得知该需求适用于深圳证券交易所的债券交易, 并且与竞买成交方式有关. 因此, 在该步骤中,
我们为这条需求补全相应约束. 补全后的需求如下, 其中, 突出显示部分是在此步骤中补充的约束.

rule 4.4.4.1
if 交易市场 is “深圳证券交易所” and 交易方式 is “竞买成交” and 交易品种 is “债券” and 时间 is “竞买日前”
and 操作人 is “卖方” and 操作 is “修改” and 操作部分 is “竞买预约要素”
then 结果 is “成功”