MBSE建模学习之八：需求和需求图

   

需求（Requirement）

需求（Requirement）是一个系统必须或应该满足的能力或条件。当设计一个产品的时候，最初产生的设计概念或要求都是用文字描述和交流的。这些文字化描述的需求最终需要落实到每个设计细节。SysML通过建立文字化的需求元素，以及这些需求元素和系统中其它设计元素（表示功能的行为、表示架构的模块等）的关系，以实现设计过程对中文字化需求的跟踪分析。这种跟踪分析的工作包括需求实现情况的分析（需求覆盖分析）、变动之后对设计的影响分析（需求变更分析）等等。

根据需求说明的对象不同，需求分为“利益相关者需求”和“系统需求”。“利益相关者需求”是反映利益相关者需要的表述，是从用户或其它使用系统的相关人员（包括维护人员、市场人员等）的角度，系统应该向他们提供什么。“系统需求”是系统将要做什么以及必须做到什么程度的表述，是从实现的角度，主要讲给内部设计人员的。需求分析的过程，是先有利益相关者需求，然后经过分析、总结，才产生系统需求。

SysML标准附录中对需求的类型进行了扩展，五种扩展需求的说明如下：

功能需求：代表对系统的功能要求，它将被一个“行为”（如“活动”Activity））满足或改善（Refine，表示更详细的说明）。

性能需求：表示系统或系统中的部件的能力应该达到的定量要求。通常用一个约束来更具体的说明（改善），被一个表示系统或部件能力的值属性来满足。

物理需求：表示系统或部件的物理特征或物理约束，被一个表示具体结构的元素来满足。

接口需求：表示对系统或系统部件的端口的要求，被一个端口、连接器、项目流或约束属性满足。

设计约束：它表示对系统或系统中的部件给出的一个约束，例如“系统中的某类部件必须使用商业货架产品”，被一个具体的模块或部件满足。

      上面所说的关系可以通过下面一个需求图来说明：

 需求关系

如上所述，为了实现需求跟踪和分析，SysML中定义了6种需求关系。

跟踪关系：用于建立一种可追踪的需求路径，可以被后面这几种更具体的需求关系代替（其它需求关系是从跟踪关系继承的）。

复制关系：从需求文本总是和主需求文本相同。这个关系用于同一个需求说明在不同的需求层级被重复使用的情况。从需求不用输入文本，它总是会和主需求的说明保持一致。

导出需求关系：导出的需求来源于被导出需求。一般用于建立“系统需求”和“利益相关者需求”之间的关系（请注意：这个关系应该是从“系统需求”指向“利益相关者需求”，就是箭头端是在后者，它表示“系统需求”是从“利益相关者需求”导出的。一些资料中将“导出需求”关系翻译为“继承”或“派生”都是错误的。“继承”或“派生”都是子类自动具有父类的所有特征，而导出需求关系只是表示导出的需求和来源需求之间有一个“推导”的关系，两者的描述内容可能是差距很大的）。

改善关系：用一种更具体、更详细的方式说明了被改善的需求。例如用一个用例、用例的活动场景来改善一个需求的说明。

满足关系：建立具体的设计元素实现了一个需求的关系。

验证关系：建立测试方法和需求之间的验证关系。测试方法在模型中一般是一个活动或其它的行为，SysML中建立了一种构造型“测试用例”来标记这些专门用于验证需求的行为（测试用例不是“用例”，而是具体的行为）。

下面这个模型图中举出上面所述的各种关系：

需求图

需求图是展示需求元素的图。需求图的代表元素一般是一个包，需求图中顶层的需求元素属于这个包。在需求图中最常见的表示方法是用需求包含关系把各层需求连接成一棵树。包含关系表示需求的分解关系。把一个需求逐步分解为更细、更具体的需求项目，也是需求分析的常规工作。进行需求覆盖分析的时候，如果是按组进行统计，则下层子需求全部满足了，上层需求就认为也满足了；如果是按“独立”的统计方式，则不考虑上下层需求之间的包含关系。在需求图中也可以显示其它元素，然后用其它6种关系把这个元素和需求连起来。但为了更方便的建立需求和其它元素的关系，软件工具中一般用“矩阵”表格的方式建立和显示需求和其它元素的关系。

下图是一个表示需求分解的需求图。

     除了用图，软件工具中也经常提供表格的方式来显示和管理需求。表格一般也展示为一棵树的形式。如下所示上面需求的表格表示方式。

     在需求表格中，还会有需求导入、导出的功能，可以和其它系统进行需求数据的交换。

建模过程中的需求分析工作

在MBSE建模工作中，有多个工作阶段涉及需求。系统建模的开始工作，就是从建立利益相关者需求。经过用例分析、功能分析，进一步总结出系统需求。再经过系统架构分析，最终形成能够作为机械结构或电子电路设计输入的物理需求。

（1）建立利益相关者需求。利益相关者需求可能来源于市场调研、参考已有系统、用户的意见、合同中规定的研制要求、售后产品故障维修记录等。利益相关者需求也可能是在一个专用的需求管理系统中已存在，导入到我们系统工程建模软件中即可。而且，这些需求也未必是一开始就非常全面和完备的。我们进行需求分析的过程，也是不断补充、完善需求的过程。甚至一开始我们连一条需求都没有，通过后面用例分析才抽出来利益相关者需求也是正常的过程。

（2）建立用例。我们通过上一个文章已经了解到，用例是进行需求分析的重要工具。利益相关者需求和用例是“多对一”的关系，就是一个用例可以和多个利益相关者需求建立关系。可以用“跟踪”关系、“改善”关系，或者“分配”关系建立利益相关者需求和用例之间的关系。不建立用例和需求的关系、直接建立用例的行为和需求的关系也可以，这个和使用的方法论有关。

（3）建立用例的活动场景，开展系统功能分析。用活动图建立用例的活动场景，分析功能性的需求必要性和充分性。在这个过程中如果发现新的功能需求，补充到利益相关需求。同时，这个过程又是抽取系统需求的过程，就是分析以满足利益相关者需求为目的，系统应该提供什么功能需求。

（4）建立系统需求。从如何实现、满足利益相关者需求的角度，结合用例的活动场景分析，抽出系统需求条目。系统需求是否是可行的、充分的，也是需要在后面的架构设计过程中不断完善。在整个模型中，需求应该和满足需求的设计要素一一对应。

（5）建立满足系统需求的架构模型。

（6）提取进行机械结构、电子电路、工艺或嵌入式软件设计的物理需求。

从利益相关者需求到建立系统需求、物理需求，整个系统建模过程都是一个需求不断更具体、更细化的过程。通过系统架构的设计分析，系统性能参数的分配和分析，逐步生成子系统的需求，以及开展机械结构设计、电子电路设计的物理需求。

需求跟踪和需求覆盖分析

在整个系统建模过程中，通过建立需求和需求、需求和其它设计元素之间的关系，可以跟踪需求变动对设计的影响，统计建模工作的完成度。

例如利益相关者需求到功能分析的关系，通过一个需求改善关系矩阵，设置用例行为分析中的“活动”对利益相关者需求中“功能需求”改善关系，如下图所示：

利益相关者需求改善关系的覆盖分析，按组统计，结果是 66.66% ，如下所示：

查看没有被改善的需求项，可以看到，是“自主行走”需求没有进行用例及功能分析，没有改善关系。因为是“按组”统计，“总需求”下面如果有一个子需求没有被改善，就认为它也没有被改善。需求数量的统计，是包括最上层的“总需求”，所以总数是6个，2个没有改善，总的改善率是“66.66%”。

文章来源：智睿思维MBSE