CN101996163A - 基于形式分析驱动的需求规格书的演化方法 - Google Patents

Abstract

本发明涉及基于形式分析驱动的需求规格书的演化方法。具体地，提供了一种用于开发规格书的方法，其包括接收限定了规格书的功能的多个需求，其中，使用形式模型表达多个需求。该方法还包括使用算法分析多个需求并且确定多个需求是否满足一组预定准则。该方法还包括产生形式分析的总结并且通过并入被改正的分析结果来改进需求。

Description

基于形式分析驱动的需求规格书的演化方法

背景技术

尽管依赖于特定的设计模型，但是软件开发过程(即，软件生命周期)通常包括一些任务，例如开发需求、设计和测试模型、以及开发代码。总体上，需求是一种将特定产品或服务应当如何实施文件化的需要。更具体地，需求是确定***的必要属性、能力、特性或质量的说明。需求被用作产品开发过程的设计阶段的输入，并且表明了对于特定应用而言什么样的元素和功能才是必需的。

在需求开发期之前可以是可行性研究或者需求收集阶段，其中，从顾客、用户或其他利益相关者那里获取需求。需求期也可被分解为分析、规格化和验证阶段，其中，使需求文件化并且检查一致性、完整性、正确性以及潜在的歧义性。

对需求进行开发，也称为需求工程，是软件密集型***的开发过程中的关键步骤。在软件设计领域的技术人员中间已经完全认可了的是***中的缺陷的很大百分比均可回溯到需求规格书中的缺陷。在***工程的设计、实施和测试阶段，修正需求错误的成本花费以指数方式增长。

需求工程处于***设计和用户期望之间的边界处，并且为确保需求规格书的质量负责。为此，需求工程应当以这样的方式实施，即确保需求规格书精确、非歧义、一致并且完整，而且满足利益相关者的期望。

为在开发质量需求规格书方面支持需求工程师，已经开发了许多工具和方法。这些工具的功能不同，其范围从提供用于储存规格书的储存库到提供基于形式方法的分析引擎来分析规格书。许多工具还提供对规格书进行结构管理和版本管理的能力，并且也提供在***工程生命周期的不同阶段上支持需求可溯性的能力。然而，所需要的是构造成提供迭代开发过程的自动***，该迭代开发过程将形式分析结果直接并入需求规格书的开发阶段中。

发明内容

用于开发规格书的方法，该方法包括接收限定了规格书功能的多个需求，其中，多个需求利用形式模型来表达。该方法还包括利用形式分析来仿真多个需求，并确定该多个需求是否满足一组预定的准则。该方法还包括生成形式分析的总结，并且如果一组预定准则中的至少一个不被满足，则修改多个需求中的至少一个。

本发明还提供了以下方案：

方案1.一种用于开发规格书的方法，所述方法包括如下步骤：

接收限定了所述规格书功能的多个需求，其中，使用形式模型来表达所述多个需求；

使用形式分析来对所述多个需求进行仿真；

确定所述多个需求是否满足一组预定准则；

产生所述形式分析的总结；以及

如果所述一组预定准则中的至少一个准则未被满足，则修改所述多个需求中的至少一个需求。

方案2.如方案1所述的方法，其特征在于，进一步包括修改所述产生的总结，并且使用所述被修改的总结作为规格书条目，由此改进所述规格书。

方案3.如方案2所述的方法，其特征在于，进一步包括使用由所述形式分析提供的反馈来迭代地改进所述规格书。

方案4.如方案3所述的方法，其特征在于，利用所述被修改的总结来重复下述步骤：对所述多个需求进行仿真、确定所述需求是否满足所述一组准则、以及产生总结。

方案5.如方案1所述的方法，其特征在于，所述形式分析的总结指示了所述多个需求是否满足所述一组预定准则。

方案6.如方案1所述的方法，其特征在于，使用形式分析来对所述多个需求进行仿真包括使用至少一个算法来分析所述需求。

方案7.如方案1所述的方法，其特征在于，确定所述多个需求是否满足一组预定准则包括确定所述需求是否具备下列中的至少一个：完整、正确、一致、以及无歧义。

方案8.如方案1所述的方法，其特征在于，进一步包括修改所述需求中不满足所述一组预定准则的部分。

方案9.如方案8所述的方法，其特征在于，进一步包括将所述需求的被修改的部分并入所述规格书中。

方案10.如方案1所述的方法，其特征在于，所述形式模型是以状态机、方案、或结构化英语的形式。

方案11.如方案1所述的方法，其特征在于，所述被修改的总结被并入所述规格书中以改进所述规格书。

方案12.一种方法，包括如下步骤：

接收限定了规格书的功能的多个需求，其中，使用形式模型来表达所述多个需求；

使用形式分析来检测所述多个需求的缺陷；

产生包括了所述形式分析的结果的总结；以及

通过将所述形式分析的结果作为规格书条目并入所述规格书中来改进所述多个需求。

方案13.如方案12所述的方法，其特征在于，使用形式分析来检测所述多个需求的缺陷包括确定所述规格书的行为。

方案14.如方案13所述的方法，其特征在于，基于所述形式分析的结果来改进所述多个需求包括通过指定预期的无缺陷的总结来改正缺陷。

方案15.如方案14所述的方法，其特征在于，进一步包括将所述预期的无缺陷的总结并入所述规格书中。

方案16.如方案12所述的方法，其特征在于，使用形式分析检测所述多个需求的缺陷包括使用至少一个算法来分析所述需求。

方案17.如方案12所述的方法，其特征在于，检测所述多个需求的缺陷包括确定所述多个需求是否具备下列中的一个或多个：不完整、不正确、不一致、或有歧义。

方案18.一种用于开发规格书的***，所述***包括：

构造成接收多个需求的数据库；以及

构造成使用形式分析来对所述多个需求进行仿真的分析引擎，其中，所述形式分析识别出所述需求中的缺陷；

其中，所述需求被改进以改正所述缺陷，并且所述被改进的需求被并入所述规格书中。

方案19.如方案18所述的***，其特征在于，所述分析引擎产生所述形式分析的总结。

方案20.如方案18所述的***，其特征在于，所述形式分析向所述需求应用多个算法以确定所述需求是否具备下列中的至少一个：不完整、不正确、不一致、或有歧义。

其它特征将从以下结合附图的描述及所附权利要求变得明显。

附图说明

图1根据实施例示出了示例性的需求规格书开发***；

图2根据实施例示出了用于开发需求规格书的示例性过程；

图3示出了示例性聚焦操作是状态机；以及

图4示出了示例性状态机子句(clause)。

具体实施方式

本文描述的实施例大致涉及用于开发需求规格书规格书的***和过程，更具体地说，涉及将形式分析结果直接并入需求规格书的开发阶段中的方法。该***包括构造成实施迭代开发过程的软件开发工具，该迭代开发过程将形式分析算法紧密整合到反馈环中，使得分析结果能够被并入规格书中。

利用该方式，分析算法和规格书形式体系彼此互补，其原因在于代表分析结果的数据结构与规格书子句的数据结构是相同的。这允许分析结果被直接用作规格书机制或条目。换句话说，用户可指定意向结果，以便在规格书上执行特定分析。该***提供了规格书和分析的活动之间的非常紧密的相互作用。这种紧密相互作用使得能够进行用于规格书和分析的闭环迭代过程。

该方法将文本需求转换为需求的形式模型，其被证明是一致且完整的。该方法跨越了非形式的需求和形式设计模型(例如通常用在基于模型的软件设计中的状态图)之间的间隙。由于该方法在内部使用了形式模型，所以这使得通过在对规格书进行操作的分析算法的支持下能够进行需求规格书的快速迭代开发。总的方法包括以少量的增加来开发规格书。在规格书的各次增加之后，应用各种分析算法，这些分析算法设计成通过在开发过程的任何给定点处对规格书进行总结或者通过识别规格书中的逻辑缺陷而向用户提供反馈。分析算法产生的总结信息可作为需求被并入规格书中，由此补充并改进规格书。

图1示出了示例性需求开发***10，其具有构造成从用户16接收输入需求14的软件开发工具12。在一个实施例中，用户16例如可以是软件工程师、需求工程师或主题专家。

可使用需求规格书所支持的多种不同设计语言来表达需求14。通常被称为形式体系的设计语言可以本质上是图形化的或者文本的，并且可包括但不限于，转换***(例如，状态机)、事件顺序图表(例如，方案(scenario)或顺序框图)、以及结构化的英语编程。以此方式，用户16能够利用不同的形式体系来开发需求14。这又允许规格书涉及由不同形式体系所指定的***部件之间的相互作用，并且允许规格书作为一个统一的模型而被储存，从而允许向其他***工具的简化导入和导出。需求可被数据库18储存和/或处理。

形式模型被分析引擎20评估，分析引擎20包括多个算法，这些算法构造成对如形式模型(即形式体系)所表示那样的规格书需求14进行仿真。分析引擎20构造成探究在规格书开发过程中的任何给定点处需求已经指定了什么样的结论。特别地，分析引擎20用一组预定准则来评估所指定的需求。分析的结果被总结并返回给用户16，然后用户16便可选择检查这些结果并且将它们添加到规格书中，或者在最前面声明所有的分析结果均将被添加到需求规格书中作为新的规格书条目。添加分析结果给规格书指定了附加约束，从而使得任何进一步分析的结果均必须符合所添加的分析结果(以及附加约束)，由此改进规格书。审查并修改分析结果，以及基于该分析结果来改进规格书的能力形成了反馈环，该反馈环提供用于开发需求规格书的闭环过程。因此，如下面进一步讨论的，规格书中的错误或缺陷在该过程的开发阶段被识别出来并且可通过修订需求而被改正。

在一种方式中，该组准则包括检查需求中涉及正确性、完整性、一致性和歧义性的缺陷。正确的规格书指的是文档化的需求是否精确地反映了利益相关者(即与***有关的任何人，例如用户、测试者、开发小组、管理人员等)的需求。完整的规格书能够清楚地确定出其范围并且完整地指定该范围内的所有需求，不会有遗漏信息。

当规格书中没有哪个部分与其他部分相抵触并且规格书与所有授权的外部文件完全一致时，规格书是一致的。换句话说，规格书中的逻辑不一致性可能关于一个条件限定两个动作，其中这两个动作自身是不一致的。例如，在汽车***中，一个需求可指定条件A导致动作X，其中动作X是制动功能，而另一个需求可指定条件A导致动作Y，而动作Y是加速功能。由于汽车不可能在制动的时候加速，因此这两个需求在逻辑上是不一致的。

关于规格书没有歧义，是指其应当是精确的并且不会给不同的人留下多种解释的空间。需求应当被简明地陈述而不依靠技术行话、未定义的缩略语或者其他内行专用的措辞。规格书应当表达客观事实并且只应有一种解释。应避免模糊的主语、形容词、介词、动词、主语短语、否定陈述以及复合陈述。总之，形式限定的语言和数学是确定的并且无歧义的。

在提供了分析结果后，软件开发工具12使得用户16能够“聚焦”在规格书中已被识别出缺陷的特定部分上。通过聚焦在规格书中的缺陷部分上，用户16能够隔离该缺陷，并且分析该缺陷的根源原因。然后，用户16可生成改正了该缺陷的替代性模型。该模型本质上修改了与需求关联的条件，并且可被并回到规格书中，以及被重新分析以检查任何其它缺陷。

图2示出了用于开发需求的示例性方法。在步骤200，用户16将需求输入到软件开发工具12中。需求可以是任意合适的设计语言的形式，包括但不限于，转换***、事件顺序图表、以及结构化的英语编程。在步骤202，分析引擎20利用形式分析来对利用形式模型所表达的需求进行仿真。在步骤204，形式分析应用多个算法以确定需求14是否满足一组预定准则，在至少一个实施例中，该组预定准则包括检查需求14以确定它们是否正确、一致、完整并且无歧义。在步骤206，产生形式分析的总结并且将其提供给用户16。在步骤208，可根据通过审查分析结果所识别出的任何缺陷来改正分析结果。然后在步骤210，将这些改正的分析结果并入规格书中。可注意到，改正分析结果并且将其并入规格书与直接改正规格书是截然不同的。在测试软件的同时进行适当的类推将会发现错误。假设程序P给出了不正确的输出O2而不是正确的输出O1。一旦发现了该缺陷，则可以改变P的代码来修正该缺陷(这类似于改正规格书)，或者可以仅仅“声明”P应当产生输出O1(这类似于改正分析结果)。正如可以看出的，通过“声明”分析结果为“预期”分析结果从而来改正分析结果并且将其并入规格书中是比改正规格书要强大得多的操作。

下面是利用状态机开发需求规格书的过程的特定示例。利用结构化转换***(STS)形式体系来开发规格书，下面通过示例介绍该结构化转换***(STS)形式体系。所提出的方法处理用于上述需求的每个准则。由于具有用于规格书的形式限定的语言，所以精确和非歧义的特性已经得到满足。该方法使用分析算法以便自动检测规格书中的不一致性和不完整性。

下面说明了使用嵌入式控制器的需求片段的方法。该片段聚焦在控制器的失效和恢复行为上。高层次的需求被总结如下。该特征具有两种操作模式：a)手动模式和b)自动模式。该特征具有下述操作状态：a)停用；b)关闭；c)接合；以及d)失效。该特征初始处于关闭的操作状态，并且通知用户该特征中的故障。一旦发生故障，则该特征必须被重置以恢复并回到正常操作。重置事件将使该特征重新初始化到其初始状态。

上面的模式和操作状态代表了在一些汽车应用中所遇到的一类需求规格书。该方法开始时首先确定规格书中的事件并且将它们分类为输入事件或输出事件。在上述情况下，可确定出下面的事件：1)失效，其为输入事件；2)重置，其为输出事件；以及3)通知，其为输出事件。作为该示例的一部分，添加了输出事件∈以指示该特征无需采取任何动作。

方法中的下一个步骤是识别规格书中所有的有效状态。在该示例中，仅对该特征的操作模式和操作状态感兴趣。在该规格书中，模式和状态值的每种组合均是允许的。因此，对于该规格书存在4×2＝8种有效状态，如下所示：

在该示例中，将状态变量值的特定估值称为状态，并且将这些状态表示为值的元组(tuple)，讨论中的这些状态变量从上下文看是清楚的。例如，元组<手动，停用>代表状态变量“模式”的值为“手动”而状态变量“状态”的值为“停用”。

STS语言提供了多种语言结构来指定状态转换行为。这些结构可用于表达文本特征的需求。这些需求中的一个可被表达为在发生失效事件时转换到“失效”状态。一旦处于“失效”状态，则在失效时的转换应当保持在“失效”状态中。如下所示，这可使用关于简单转换的STS结构来表达。

In any state the event″fail″will transition to a state wherethe predicate″fail″holds and outputs the action″notify(在任何状态下，事件“失效”将转换到这样的状态，其中，保持谓语“失效”并且输出动作“通知”)使用符号

来表示上述规格书，其中谓语“失效”确定了“状态”变量估值为“失效”的所有状态。

初始处于“关闭”状态的特征由STS的初始化结构表达。

Initialize feature to″off″

(将特征初始化到“关闭”)

其中，“关闭”被定义为取值为“关闭”的“状态”变量。

一旦发生失效，则该特征必须被重置以恢复并回到正常操作。重置事件将该特征重新初始化到其初始状态。利用简单的转换来模型化重置事件的这个行为：

In any state the event″reset″will transition to a statewhere the predicate″off″holds and will output theempty action(在任何状态下，事件“重置”将转换到这样的状态，其中，保持谓语“关闭”并且将输出空的动作)使用记号

来表示上述规格书。在该状态下，已经使用STS语言的结构将文本规格书中给定的所有需求都形式化。

许多不同的分析可在规格书上执行，其中最重要的一个分析是检查一致性和完整性。这些分析算法已经在软件开发工具中得以实施，从而随着规格书的开发，给用户提供交互的反馈。

首先检查一致性，发现规格书在目前情况下是一致的。然而，在检查不完整性时，该分析报告说在状态<手动，接合>中，失效事件可导致转换到<手动，失效>或者<自动，失效>。

该不完整性分析已经揭示出，当指定失效事件时的转换时，规格书关于“模式”状态变量的变化是不完整的。实际上，该信息在早先给出的非形式的规格书中是缺失的。

此时，可通过聚焦在状态变量“模型”上来分析规格书。该聚焦操作的结果是“总结”状态机，该状态机的状态仅是“模型”状态变量的不同估值，并且该状态机的转换指定了仅相对于“模式”状态变量的行为，换句话说，其是规格书的谓语-抽象(predicate-abstraction)。图3中示出了聚焦在“模式”上的结果。

然而，更合理的行为是要求由失效导致的转换不应当改变“模式”状态变量。换句话说，聚焦在“模式”上的结果被预期为是图4的状态机，其中，关于失效事件在“手动”和“自动”之间不存在转换。

STS语言允许用户通过将图4中所示状态机作为子句导入从而将其作为规格书的一部分而指定。该子句指定了该状态机，其中该状态机是使用了聚焦操作对规格书进行分析的结果。

此时，一致性和完整性分析评估报告了规格书是一致且完整的。然而，此时规格书可能是不正确的，用户可能勉强地指定了错误的行为。没有通用的算法用于检测规格书中的不正确性，这是因为不存在规格书可以与之比较的其他形式模型，只有用户对非形式书面的规格书的的智力模型。所以，最好的可能性是分析规格书并将其从不同方面可视化，并且确保各个方面均与用户期望获得的行为匹配。

在示例中，将对规格书进行仿真，并且尝试各种方案以确保规格书的正确性。所预期的几种方案是：

从初始状态起，顺序“<失效，失效，重置>”应当导致满足初始的目标状态。从“自动”状态起，关于规格书的任何顺序，也有可能指定对应的仿真轨迹作为规格书中的仿真子句。在目前的规格书上可仿真的更加可疑的方案如下：从“停用”状态开始，顺序<失效，重置>将导致状态被初始化。

在很多领域中，“停用”状态意味着该部件不应当操作，并且需要特殊事件来使其可操作。特别地，如果部件停用的话，则不应当允许诸如失效和重置的事件来改变该状态分量。因此，上述方案是对立方案(anti-scenario)。

STS语言允许这种对立方案的规格书，并且有可能执行上述仿真并且将该仿真轨迹标记为对立方案。在该情况中，当执行该步骤时，算法立即指出规格书中的不一致性。这是因为在规格书的前面已经指定了下述子句：

其指定了“失效”和“重置”事件从所有状态的转换。为了与对立方案一致，这些子句必须变成：

而且，子句必须被添加以指定“停用”状态中的行为，以便使规格书完整：

在此阶段，规格书是一致的、完整的并且推定为正确的。使用树来代表文本STS规格书的分级本质，其中，规格书的非叶节点是包含了子规格书的变焦或聚焦子句。原型工具支持本文所描述的所有分析。可在规格书的顶层次执行每项分析，或者关于与变焦或聚焦子句对应的特定子规格书执行每项分析。

应当理解的是，上面的描述旨在是示例性的而非限制性的。本领域技术人员在阅读上面的描述后将会明白不同于所提供示例的很多替代性方式或应用。本发明的范围不应当参考上面的描述而被确定，而是应当参考所附权利要求以及这些权利要求等同物的全部范围而被确定。已经预见到，在本文讨论的领域将会出现进一步的发展，并且所公开的***和方法将被并入这些进一步示例中。总之，应当理解的是，本发明能够进行修改和变化并且仅受权利要求的限制。

已经特别示出和描述了当前的实施例，这些实施例仅仅是最佳模式的示例。本领域技术人员应当理解的是，在不偏离本发明精神和范围的情况下，实施权利要求时可采用本文描述实施例的各种替代物，并且这些权利要求及其等同物范围内的方法和***也由此被覆盖。该描述应当被理解为包括本文描述的元件的所有新颖且非显而易见的组合，并且可在本申请或后续申请中给出对这些元件的任何新颖且非显而易见的组合的权利要求。而且，前面的实施例是示例性的，并且没有单一的特征或元件对于本申请或后续申请中所请求保护的所有可能的组合而言是必要的。

如本领域技术人员所理解的，权利要求中使用的所有术语意图被赋予其最广义的合理解释以及它们的普通意义，除非本文中作出明确的相反指示。特别地，诸如“一”、“一个”、“该”、“所述”等措词的使用应当被解读为指的是所指元件的一个或多个，除非权利要求记载了明确的相反限制。

Claims (10)

1.一种用于开发规格书的方法，所述方法包括如下步骤：

接收限定了所述规格书功能的多个需求，其中，使用形式模型来表达所述多个需求；

使用形式分析来对所述多个需求进行仿真；

确定所述多个需求是否满足一组预定准则；

产生所述形式分析的总结；以及

如果所述一组预定准则中的至少一个准则未被满足，则修改所述多个需求中的至少一个需求。

2.如权利要求1所述的方法，其特征在于，进一步包括修改所述产生的总结，并且使用所述被修改的总结作为规格书条目，由此改进所述规格书。

3.如权利要求2所述的方法，其特征在于，进一步包括使用由所述形式分析提供的反馈来迭代地改进所述规格书。

4.如权利要求3所述的方法，其特征在于，利用所述被修改的总结来重复下述步骤：对所述多个需求进行仿真、确定所述需求是否满足所述一组准则、以及产生总结。

5.如权利要求1所述的方法，其特征在于，所述形式分析的总结指示了所述多个需求是否满足所述一组预定准则。

6.如权利要求1所述的方法，其特征在于，使用形式分析来对所述多个需求进行仿真包括使用至少一个算法来分析所述需求。

7.如权利要求1所述的方法，其特征在于，确定所述多个需求是否满足一组预定准则包括确定所述需求是否具备下列中的至少一个：完整、正确、一致、以及无歧义。

8.如权利要求1所述的方法，其特征在于，进一步包括修改所述需求中不满足所述一组预定准则的部分。

9.一种方法，包括如下步骤：

接收限定了规格书的功能的多个需求，其中，使用形式模型来表达所述多个需求；

使用形式分析来检测所述多个需求的缺陷；

产生包括了所述形式分析的结果的总结；以及

通过将所述形式分析的结果作为规格书条目并入所述规格书中来改进所述多个需求。

10.一种用于开发规格书的***，所述***包括：

构造成接收多个需求的数据库；以及

构造成使用形式分析来对所述多个需求进行仿真的分析引擎，其中，所述形式分析识别出所述需求中的缺陷；

其中，所述需求被改进以改正所述缺陷，并且所述被改进的需求被并入所述规格书中。

Images