1.简介
需求工程是在软件产品的整个生命周期中获取、指定、验证和维护需求的基本软件工程过程[1]。正如几位作者强调的那样（参见，例如[2,三])需求分析是软件开发过程中最关键的阶段，因为它对修复需求错误的成本有很大影响。在可能导致引入错误需求的各种问题中，例如模糊性、不完整性和不一致性，不同利益相关者及其相关观点的异质性尤为重要。 本文通过重点讨论业务流程符号的扩展，即BPMN（business process Management and notation），来解决这一问题[4]，已被证明对于参与软件需求工程工作的各种利益相关者来说很容易理解，最大限度地减少了误解和遗漏的风险（关于遗漏问题，请参见，例如[5]). 采用业务流程驱动的方法来执行需求工程工作已经被一些作者广泛研究，并应用于各种应用领域[6,7]. 使用能够为业务流程管理和需求工程方法提供有效支持的符号，可以使业务和软件分析师弥合两者之间的差距，从而利用这两种方法[8]. BPMN现在被视为业务流程管理领域的事实标准。然而，当应用于软件需求的定义和规范时，它在数据建模方面显示出很大的局限性[9]。这主要是由于BPMN的性质，引入BPMN是为了为业务流程的规范和分析提供一种清晰、简洁和灵活的语言，因此侧重于流程建模而非数据建模。 在给定流程的各种活动之间流动的数据或实体仅在BPMN模型中以抽象方式定义。为了克服这一限制，本文介绍了轻量级扩展，它专门处理对提供软件需求的完整规范至关重要的结构属性的注释。扩展被表示为轻量级，因为它不会改变BPMN模型的结构。因此，扩展模型仍然是有效的BPMN模型。
同时，提议的扩展足够灵活，可以直接控制在数据建模方面添加什么（使用特殊注释)，以实现有效的需求定义，该定义旨在使负责实现或更新底层信息系统的涉众和软件开发人员易于理解。
因此，BPMN模型可以有效地应用于提供行为和数据属性的集成规范，方法是将数据属性的注释限制到那些感兴趣的实体，以充分满足涉众的需求，并使其对软件开发人员来说清晰易懂。
实际上，数据属性被注释为约束，即业务流程的不同活动必须满足的前置和后置条件。反过来，这些约束是建立在底层信息系统的简化视图上的，由实体具有属性对特定需求及其相关过程活动有意义。此外，需求中涉及的关键属性可以通过将视觉提示，例如直接在BPMN图上编辑的特定颜色。
由此产生的带注释的BPMN模型具有以下优点：
涉众可以在所需的抽象级别定义和使用实体和属性，而无需处理实际的实现细节；
实体及其属性是按需定义的，即当需求涉及与BPMN分支相关的数据属性时（即，当某个边缘由某个数据属性或表达式保护时），不会引入不必要的信息；
BPMN模型明确指定了属性值的使用位置以及不同活动如何更改属性值，以增强模型的可理解性。
总之，其结果是一个以BPMN为中心的需求获取和定义过程，在该过程中，注释模型的可视化表示传达了利益相关者、理解和验证需求以及软件分析师和开发人员所需的所有信息，以轻松地将这些更新映射到相应的软件实现。
所提议的方法并不打算取代现有的需求工程方法，例如面向对象的分析方法[10]或敏捷方法[11]。它旨在支持业务流程管理工作，从而为基础信息系统实现带来新的或更新的需求。 本文的建议在以利益相关者需求和约束的显著可变性为特征的应用领域中尤其有效[12]，例如在医疗领域，业务流程可能需要经常更新，以解决公共当局提出的新建议（请参见，例如[13]). 在这些领域中，基于业务流程的需求工程的使用要求软件分析人员对影响新的或更新的需求的流程更改做出快速反应。 论文组织如下。第2节总结了利用业务流程模型进行需求工程的相关工作。第3节简要描述了本文介绍的需求分析方法。第4节在健康护理相关的案例研究中例举了这种方法，并将其结果与传统需求集成过程的结果进行了比较。然后，在第5节，为了更好地评估其通用性、适用性和局限性，建议的贡献被应用于不同应用领域的另一个真实案例研究，然后在第6节最后，第7节显示了为支持所提出的方法而开发的原型工具，以及第8节概述了结论。 2.相关工作
业务流程管理（BPM）方法有助于缩小组织中业务部门和IT部门之间的差距，通常与采用实现所设计业务流程的信息系统相关，以支持流程改进工作。通常，这些信息系统需要快速适应频繁变化的业务场景中的业务流程更新[12]。因此，在需求工程阶段需要考虑业务流程[8]. 业务流程是通过使用业务分析师必须理解和有用的符号来定义的。如上所述，BPMN目前被用作业务流程定义和相关软件需求工程活动的参考符号[9]. 几位作者已经研究了使用基于BPMN的方法来支持需求工程和信息系统建模，主要涉及根据各种需求工程方法开发方法、语言和启发式方法，以从业务流程模型中导出软件需求，总结如下[14]. 需要处理BPMN在数据建模方面的局限性，这被视为需要通过引入适当的BPMN扩展来解决的常见问题。在中的贡献[15]有效地总结和审查所有此类扩展，这些扩展是通过使用BPMN的本机扩展机制提供的（请参见，例如[16])或者通过正式应用模型驱动工程领域引入的基于元模型的方法来指定特定于域的建模语言（参见，例如[17,18]). 同样，在数据建模方面，可以通过引入非正式（基于自然语言的）注释来定义高度抽象的数据需求，也可以通过使用更正式的方法来处理，这些方法允许详细规范由流程活动操作的特定于域的数据结构[15]. 本文中提出的贡献与之前所有这些贡献的不同之处在于延伸机构基于BPMN模型的非正式但精确的注释，不会改变模型结构，以及多才多艺，适用于各种应用程序域（如下面几节中描述的案例研究所示）。
如上所述，拟议的贡献不打算应用于特定的需求工程方法。然而，本文介绍的基于BPMN的扩展通过简单的迭代方法为管理需求集成任务提供了有效的支持，该方法可以有效地应用于敏捷方法[8]。事实上，虽然敏捷方法想要避免复杂的文档，但它们实际上需要有效的需求捕获和精益文档。例如，所提议的方法可以应用于SCRUM方法，在这种方法中，BPMN模型可以用于传达利益相关者的需求，以便根据所谓的用户情景正确构建需求文档[19]。在这种情况下，建议的方法可以通过保留原始SCRUM流程来使用，从而使BPMN模型不属于产品积压工作（维护工件的列表），或通过将BPMN模型添加到产品积压工作（backlog），以便正确集成用户案例，如中所述[20]. 3.需求分析过程
需求分析在所提议的轻量级BPMN扩展的协助下，通过迭代评审过程完成，其总体结构如所示图1。该流程分配了角色，特别是一个独特的所有者（通常是经理）和几个利益相关者，他们参与确定组织解决方案。 如所示图1流程由所有者/经理启动，他首先编写新的或更新的需求的自然语言描述，并定义要修改的流程模型以实现它。这里，流程模型是通常从所审查系统的整体BPMN模型中提取的BPMN片段。 然后，经理定义审核过程中使用的特殊数据模型。这种数据模型的设计是拟议方法的核心：实际上，一般来说，对需求的高级程序描述往往需要参考与底层信息系统的低级结构有关的细节。然而，对于大多数利益相关者来说，这些可能对IT员工有用的细节是很难理解的，他们应该将重点放在将需求正确集成到高级流程中。为了在需求分析过程中屏蔽这种（不必要的）复杂性，我们创建了这样一个简化的数据模型，然后将其用于BPMN模型。为此，我们采用以下规则，以获得所需的简化，同时保持对底层实现的可追溯性：
对于所引用的每个属性和实体，必须给出描述，阐明其预期含义，以便IT人员能够理解如何从信息系统的实际数据模型中导出它；
复杂表达式可以（并且应该）在适当实体的单个属性中合成。在这种定义中复杂属性，应该选择一种自下而上的方法，并将其构建在复杂性较低的其他属性上。这不会影响BPMN表示，但可以向开发人员提供一些关于如何实际派生属性的高级提示；
通过正确构建复杂属性，应该尝试隔离少量关键属性，我们将致电占主导地位的，这是需求的核心。这些主要属性将在BPMN中给出特定的视觉表示。
这些规则的实际含义将在以下各节所述的案例研究中阐明。
一旦定义了数据模型，管理器就有一个“原样”（片段）BPMN要处理，以及一组应该指导其更新的属性。他现在可以根据上述数据模型属性向BPMN添加适当的新活动并编写前置/后置条件，以满足新需求。通常，这是通过在活动的输入箭头（用于前提条件）和输出箭头（用于后置条件）上放置适当的注释来完成的。为了进一步简化过程分析，我们对主导属性：事实上，我们并没有将其值放在图表上，而是将可能的值映射到少量有意义的子集，并将每个子集与一个可视提示关联，即颜色，它将实际放置在BPMN注释中。域数据模型的适当定义应该允许用户在这些注释中放置非常简单的表达式，例如单个值或范围。如果需要更复杂的表达式（例如公式），则应返回到上一步，并尝试引入更多（复杂）属性，以简化此类表达式。
所有相关的涉众都会审查BPMN模型（以及相应的数据模型）并给出反馈。注意，这里我们假设利益相关者相对于所有者处于从属地位，因此他们不能修改BPMN模型；相反，他们可以向所有者建议所需的修改，但当然可以创建一个更协作的环境，让每个利益相关者都能够直接修改此类文档。
管理者使用反馈来进一步完善BPMN模型和/或数据模型，并且该过程会不断迭代，直到管理者认为涉众的评论不需要进一步更改。
最后，可以将评审工件发送给开发人员，以便相应地更新软件。
4.需求分析：髋部骨折治疗案例研究
为了说明我们的方法，在本节中，我们介绍了一个真实的案例研究。特别是，我们首先描述一组集成在与髋部骨折的治疗最初，这种集成采用了一种临时方法，并得到了几次会议的支持，这些会议产生了非正式规范文件，这些文件后来在医院信息系统以及分发给医院员工的流程手册中得到了实施。一些参与原始流程的工作人员被要求按照本文提出的新方法重复整合。在流程结束时，要求他们报告反馈，将通过新流程整合需求所花费的努力与他们以前的经验进行比较。
新要求如下：
我们记得，建议的方法假设现有流程的BPMN模型已经存在。因此，我们首先要求员工确定当前BPMN中实际会受到这些新需求影响的部分。结果如所示图2. 由于需求1涉及时间约束，因此可以使用定时活动和计时器在BPMN模型中直接表示。另一方面，需求2-4具有更复杂的结构，其中包括几个条件。因此，在下文中，我们将重点分析这些需求。
4.1. 需求分析2
4.1.1. 需求处理
要求2描述了约束动作：我们确实可以将其拆分为以下内容
我们可能会注意到，考虑到我们案例研究的假设，第一个先决条件始终成立。此外，这种行为显然没有明确说明：测试和手术之间的关系是什么？事实上，如果患者患有骨质疏松症，则无法进行手术，因此需要进行测试（阳性测试）。因此，我们的初始操作隐藏了另一组实际保护“手术”操作的前提条件。最终的、扩展的需求结构可以表述如下：
“如果(先决条件)患者疑似髋部骨折(先决条件)病人那时已经60多岁了(行动)进行骨质疏松测试。何时(先决条件)结果可用，如果(先决条件)骨质疏松症测试结果为阴性(行动)进行手术”。
注意，为了简单起见，这里我们将不指定测试为阳性的情况，并在BPMN上用例外.
4.1.2. 域数据模型构建
从要求2中提取的前提条件是指流程中涉及的特定实体的属性。特别是，要求是指患者的年龄，即属性“年龄“的”病人“实体。虽然假设“病人“实体已经在医院信息系统中定义，一般来说，这种实体具有复杂的结构，由许多与当前需求无关的细节组成。此外，“年龄“属性可能不存在，因为它显然可以从出生日期派生。最后，该要求参考了另一个值，即骨质疏松症检测结果。在这种情况下，我们没有处理特定实体的属性：为了从医院信息系统中获取这样的值，我们可能需要对不同的实体执行几次查询，合并结果并给出解释（即，将值与允许范围进行比较）。
因此，遵循第3节，我们创建一个adhoc域数据模型由病人实体，包含两个属性：一个数字年龄属性和骨质疏松测试枚举属性，它可以假定值为“not_required”、“requiremed”、“to_assess”、“positive”和“negative”，并且将是我们的占主导地位的属性。特别是，我们将使用白色表示“必需”，灰色（通常含义为“不确定”）表示“to_assess”，绿色（“ok，proceed”）代表“not_required”和“negative”，红色（“stop，exception”）代表”正“，如所示图3. 这种选择背后的理由是，我们需要年龄来首先选择是否必须进行测试，但在剩下的过程中，我们只需要占主导地位的人骨质疏松测试属性，该属性也是基于年龄构建的（即，如果年龄小于60岁，则设置为“not_required”），以确定要遵循的BPMN路径。
4.1.3. BPMN映射
下一步，我们需要在BPMN中添加适当的新活动，即。，骨质疏松症分析请求和读取结果，并根据上述属性编写其前置和/或后置条件。
生成的BPMN如所示图4其中，为了清楚起见，我们省略了一些活动（包括在图2)与当前需求分析无关。在图中年龄属性被用作第一个条件，一旦选中，将在更高级别中继续隐式考虑骨质疏松测试属性，它由彩色方块表示，这些方块作为“手术室预定”和“骨质疏松症分析请求”活动的前提条件，以及“骨质疏松病分析”活动的后置条件。 与医院工作人员“手动”导出的需求的实际实现相比，通过我们的方法获得的解决方案完全相同。事实上，在这种情况下，要求及其实现是如此明确和直截了当，以至于应用我们的方法无助于发现任何歧义或错误。然而，根据拟议流程创建的正式文档可以被视为附带优势，因为它可以用作进一步集成步骤的坚实基础。
4.2. 需求分析3
要求3规定患者在手术前必须有足够的疼痛缓解。同样，从中的BPMN开始图2，这很容易被视为对涉及疼痛的属性病人实体，它在这个需求中占主导地位，有三个可能的值：“to_assess”、“no_pain”和“pain”，如所示图5. 最初疼痛仍然存在到（_A）然后，所需的行动是提供不同的止痛药，直到疼痛先决条件评估为无疼痛.
如果我们分别使用灰色、绿色和红色对主属性的值进行编码，我们将获得中描述的修改后的BPMN图6. 此外，在这种情况下，考虑到需求的简单性，我们方法的应用并没有给集成本身带来任何特别的好处，但有助于生成整个更新过程的适当文档，这对于生成相应的明确的人类可读文档和，特别是，指导IT员工完成新要求所需的实施变更。
4.3. 需求分析4
最后，最后一项要求“只有在有工作人员会说他/她的语言的情况下，患者才能被转移到特定的医院病房”提出了一个更复杂的实施。
在这里，我们需要在分析中包括三个实体：医生,护士（组成医院工作人员）和病人实际上，按照前面章节中描述的规则，我们可以简单地定义一个支配属性与员工使用通用语言并将其放置在患者实体上。
然而，在这种情况下，我们面临两个问题：首先，获取上述属性的值，即确定患者和工作人员是否共享一种共同语言，是一项复杂的任务，可以通过多种方式实现。其次，“口语”信息不能保证出现在医院信息系统中。因此，我们需要仔细定义我们的属性，以便建议IT人员将此信息添加到系统的实际数据模型中，然后用于导出有_通用语言_带_ staff值。生成的属性定义如所示图7. 然后，我们可以为主导属性定义四个可能的值与员工共同使用语言，即“to_assess”、“yes”、“no”和“not_atmoment”（即存在与患者使用共同语言的工作人员，但他/她目前不在），我们分别将其映射为灰色、绿色、红色和黄色。图8显示了这些颜色如何放置在BPMN上。 请注意，患者以通用语言进入医院急诊室评估（_A）（前提条件），然后退出对或不值（后置条件）。这也暗示了验证这一新要求的地方是急诊室。
在这种情况下，我们方法的应用很快收敛到了整合需求的正确解决方案，而医院工作人员实际使用的“手动”方法最初导致了限制性解决方案，在许多情况下证明是错误的。事实上，最初的解决方案利用了病人国籍从他的文件中推断，寻找能够与他沟通的医生/护士。然而，国籍并不直接意味着患者所说的语言：通常一个人知道其他语言，例如英语，即使没有人知道他的母语，也可以很容易地使用这些语言进行交流。
5.需求分析：自动售货机案例研究
为了说明所提出的方法是如何推广的，以及在哪些应用领域可以取得最佳结果，我们将其应用于另一个完全不同的领域的案例研究：实际上，我们认为一家公司与自动售货机特别是，我们专注于机器重新加注过程，这是公司业务的核心。
在这种情况下，该公司希望为再充值请求添加一个新的、更快的、自动化的渠道。目前，此类请求通过电话发送给公司联络中心，公司联络中心的员工根据客户请求编制纸质表单，并手动发送给后台员工，后台员工最终创建相应的重新填写订单，可能会联系客户询问更多信息，以唯一标识要重新加注的机器，并将其排入公司销售管理系统。该过程如图所示图9. 现在，公司希望订单由销售客户经理（以下为SAM）直接管理，销售客户经理应该能够接收请求（通过电子邮件、电话等）并将其输入到电子请求表中，后台工作人员可以在其中阅读、检查并最终像往常一样创建订单，无需与客户进一步联系。特别是，我们将只关注这一新流程所涉及的两个要求，即：。，
- （A）
为了提交请求，SAM必须确定要重新填充的特定自动售货机；
- （B）
如果客户没有高达100欧元的待付款，则后台工作人员会将重新充值请求添加到订单队列中。
与之前的案例研究一样，公司IT人员按照定制的非结构化集成流程实施了这些新需求，在这两种情况下，需求分析阶段都存在导致实施错误的问题。因此，我们进行了一次模拟，要求员工借助我们的方法重复进行需求集成，并评估其应用可能带来的优势。
5.1. 需求A分析
此要求告诉SAM必须唯一标识要重新填充的自动售货机(先决条件)为了提交相应的请求(行动). 这是为了避免后台与客户联系所必需的，就像之前的流程一样。
通过我们的迭代方法对这样一个（显然很简单的）需求进行建模，使我们能够快速识别和修复一个问题，这个问题以前是在标准分析过程之后，在测试阶段才发现的。
事实上，SAM是参与先前需求分析的唯一利益相关者，最初认为客户名称和位置足以识别自动售货机。然而，在我们流程的第一次迭代期间，后台工作人员强调，如果客户在同一位置有多台机器，为了唯一地确定需要重新填充的机器，有必要指定其销售点代码然而，SAM无法直接访问存储此信息的公司软件：因此，他可能会记住它（从以前的请求中）或向客户询问它（如果可能），或者作为最后手段，向公司总部发出请求，从系统中提取代码。
为了对这种情况进行建模，流程的下一次迭代定义了一个包含机器具有的实体客户名称,客户位置和销售点代码属性，如中所示图10.在这里销售点代码是主要属性，可以设置为“ask”（黄色）、“unknown”（红色）或任何实际代码（绿色）。相应的BPMN如所示图11. 5.2. 需求B分析
此要求表明可以在订单队列中放置重新充值请求(行动)只有当客户的待付款不超过100欧元时，才由后台工作人员执行(先决条件).
前提条件是指顾客实体，尤其是未决付款属性，它显然不是直接可用的，但实际上是复杂查询的结果。因此，用于此需求的数据模型如所示图12，生成的BPMN如所示图13. 然而，在这里，我们的过程被证明不够详细，无法实现正确的实现，并且它遇到了与公司员工以前应用的标准需求集成方法相同的困难。实际上，上面的解决方案包含了一个并发问题：同一请求可能会被多次处理。从BPMN和数据模型来看，很明显，它们并没有对基数约束进行建模，即员工只能管理一次请求，因此只能向订单队列提交一次请求。显然，在以前的基于纸张的请求管理过程中不存在此问题，因为无法同时访问纸张表单。
这个问题后来通过用新的公式修改要求来解决，即“只有当客户的待付款不超过100欧元时，后台人员才能在订单队列中提出再充值请求请求尚未分配”.
需求前提条件的新部分是指地位的属性请求实体，可以是“等待”或“分配”的，也是在公司管理系统上执行查询的结果。该属性在流程中占据主导地位，与黄色（指定）和蓝色（等待）颜色相关，详见图14。相应修订后的BPMN如所示图15. 即使我们的方法可以为正确的解决方案建模，但很明显它在这里失败了，因为它没有传递足够的信息来立即向流程中涉及的涉众披露并发性/基数问题。在这种情况下，更详细的数据模型或类图（包括约束和基数）将很有帮助，但很明显，它将使需求定义只有专家涉众才能理解。
6.讨论
在本节中，我们将讨论所建议方法的关键点，特别是域数据模型的引入以及该方法对实际业务流程的适用性，以便确定可从其应用中受益的流程类别。
所提出的方法基于领域数据模型，该模型是根据正在处理的新的或更新的需求所需的实体和属性“按需”生成的；它旨在消除项目干系人使用的不同术语引起的歧义。建议的注释提供了一个通用词汇表，并在概念（及其语义）和技术实现之间，就底层数据存储和检索的细节而言，引入了明确的分隔。属性反过来用于在BMPN模型上创建简单的条件，然后将这些条件映射到视觉提示（如彩色图标），以便轻松指定数据驱动的决策点。
事实证明，与使用自然语言注释相比，生成的BPMN模型更容易理解，自然语言注释可能含糊不清、过于简明（忽略基本细节）或过于详细（提供不必要的信息），和/或由于文本注释过多而不易阅读。
通过将该方法应用于实际案例研究，对该方法进行了初步验证，以评估其相对于未使用本文建议的传统方法的有效性。本文中报告的案例研究表明，就适用性，本文的贡献在引入小的、非关键的本地更新的需求集成上取得最佳结果，这实际上是实践中最常见的。在这种情况下，通过对原始BPMN模型的特定片段应用几个小的更改和更新来实现新的或更新的需求。
另一方面，当涉及对系统进行复杂的结构修改时，“从头开始”并为整个流程和所涉及的实体定义全新的模型通常很有用。实际上，在这种情况下，该方法可能无法传递足够的信息来完全建模新需求及其集成点。
为了更好地确定可通过建议的方法盈利解决的流程，我们采用了所示的流程矩阵图16，基于原始设计[21]。该表根据“流程环境可变性”和“对客户的输出变量值”这两个变量对流程进行分类，从而确定以下四类： 本文提出的方法可以应用于大规模过程（A类），因为
过程的可变性低，所以系统的复杂性不高；
存在多部门参与，可以利用良好的需求工程方法。
此外，该方法也适用于大规模定制流程（B类），因为
另一方面，所提出的方法无法解决新生过程（C型）和创造性过程（D型），因为它们涉及原型设计和/或与利益相关者甚至最终用户的复杂互动。
中所示的两个案例研究第4节和第5节当应用于适当的流程（即类型a和B）时，让人清楚地印象到拟议方法在有效性和多功能性方面带来的好处。 7.过程和支持工具
特别是，为了支持流程管理器定义初始BPMN片段，在web应用程序中，我们采用BPMN的XML交换格式（可由所有最常用的BPMN编辑工具导出），以允许管理器导入现有BPMN并提取感兴趣的片段。特别是，该工具使用bpmn-js[22]库，它允许您在web上轻松导入、修改和显示BPMN模型（请参阅图17). 然后，经理必须定义要在审查过程中使用的特定数据模型。在web应用程序中，这是通过一个简单的界面实现的（请参见图18)这允许我们将实体及其属性声明为键值对。此类属性可能只有基本类型，即字符串、整数、整数范围、浮点、浮点范围、布尔值、日期和时间。我们还支持上述类型的列表和枚举。每个实体、属性和枚举值都有一个必填项描述经理必须输入其预期含义的明确描述的字段。“主导”复选框允许我们标记主导属性：在这种情况下，管理器将能够定义属性域的许多子集，并将它们与颜色关联。 最后，为了帮助经理将需求作为放置在BPMN上的一组前置和后置条件来制定，web应用程序利用BPMN-js的可扩展性来创建用于映射图上主要属性的“彩色注释”，如前几节所述（请再次参阅图17). 该工具还允许我们在整个BPMN中以自然语言输入更多评论。 此时，该工具向所有相关的涉众（由经理定义）发送通知，其中描述了集成的需求，并提供了进入审查过程的链接。单击链接后，涉众将被验证，他/她可以查看经理在前面步骤中生成的工件（BPMN、数据模型、注释等）。
为了提供反馈，涉众可以留下他们的评论，可能会将其与特定元素（如流程活动或数据模型的属性）联系起来。
系统会通知管理者利益相关者的反馈，并使用该反馈进一步完善人工制品，例如，根据评论更新BPMN。
该过程会反复进行，直到经理认为利益相关者的评论不需要进一步修改和/或指定的时间段内没有评论为止。
在流程的最后，干系人的访问被禁用，经理将所有评审工件发送给开发人员。
上述所有流程步骤都由web应用程序记录到适当的审查日志中，该日志特别跟踪评论和更新，因此每个步骤的责任都是明确的。
注意，鉴于过程中生成和利用的工件的正式和明确的结构（即BPMN模型、域数据模型等），标准模型转换技术也可以应用于派生其他视图和工件，为了简化利益相关者的审查和开发人员的实现任务（例如[5]). 特别是，由于所有数据模型元素都附带了（必需的）自然语言描述，因此可以利用简单的转换来导出整个流程的文本文档，该文档从BPMN开始，其注释与数据模型适当链接，如上图所示。通过这种方式，可以对修改后的业务流程生成一个可读的、非技术性的解释，这将有助于向实际的流程参与者解释它。 8.结论
本文介绍了一种基于BPMN的需求集成方法。具体来说，该方法引入了一个BPMN扩展，允许涉众和软件分析人员在BPMN模型中轻松合并和集成行为和数据属性。所提议的扩展通过提供通用词汇表和数据驱动约束的有效表示，促进了不同利益相关者之间的交互。
论文中报告的初步验证活动表明，该方法可以在以低可变性和多参与者参与为特征的环境中进行有益的利用。未来的工作将解决不同应用程序域中的大规模实验，以便进一步评估方法的有效性，并考虑提出相应的“官方”BPMN扩展的机会。
