CN112783475A - 一种嵌入式软件需求分析方法 - Google Patents

Abstract

本发明公布了一种嵌入式软件需求分析方法。该方法按系统(System)、流程(Process)、数据(Data)进行分组并建立形式化、可视化的需求分析模型(简称SPD方法)，从不同视角组织软件的静态和动态需求。系统组模型包括系统生态图、系统特性树、组织结构图、组织界面表；过程组包括泳道过程流、界面流和关键绩效指标；数据组包括数据流、数据字典、状态表和状态图。从不同视角对同一系统和软件的需求信息进行分析、组织和展示，为需求分析人员和项目干系人提供需求信息的多维度视觉呈现，通过不同维度需求之间的相互确认和验证，实现嵌入式系统软件需求分析的正确性、一致性和完整性。

Description

一种嵌入式软件需求分析方法

技术领域

本发明涉及软件需求工程领域，尤其是一种嵌入式软件需求分析方法。

背景技术

现有软件需求工程包括需求开发和需求管理两大部分，需求开发的目的是产生并分析顾客、产品和产品部件的需求。需求管理的目的则是管理开发出的项目需求，并跟踪这些需求与项目计划和工作产品之间的一致性。上述两个过程中的需求涉及各利益相关方的需要，包括且不限于顾客需求、产品需求、环境需求、产品属性(例如，安全性、可靠性、可维护性等)有关需求及设计解决方案引起的限制等。

现有软件需求分析方法多采用技术协议、客户访谈、组织利益相关方讨论等方式来获取需求，形成冗长的需求文字描述，形如：“系统应该...”。随着软件规模和复杂度的增加，需求规模逐渐变大，相互之间错综复杂，受限于人类基本认知特征，缺乏信息组织结构的冗长需求清单列表无法支撑项目干系人及时发现需求的缺失、错误、不完整或不明确，进而导致项目的失败。

现有软件需求分析方法一般通过业务流程分析和数据流分析来说明系统需完成的功能。而嵌入式系统大多不涉及业务流程，而其具有的软、硬件强依赖性、强实时性、系统透明性、系统资源限制性等特点相关的非功能性需求，现有软件需求分析方法又不支持预先进行分析定义，通常由需求分析人员依经验确定，存在精确的、技术上的不严谨，这将导致不同项目干系人有意无意地带有个人的不同理解而自行其是，进一步增加了项目失败的风险。

发明内容

本嵌入式软件需求分析方法针对现有软件需求分析方法的缺陷和问题，提出一种基于模型的嵌入式软件需求分析方法，通过结构化组织和展示嵌入式软件需求，从而达到避免软件需求缺失、错误、不完整的目的。

为实现上述目的，本发明提供如下技术方案：

一种嵌入式软件需求分析方法，包括以下步骤：

步骤1：创建系统生态图

对于待进行需求分析的嵌入式软件所在系统，确认与其直接相连的所有可能系统，并确认系统间接口，按前文所述系统生态图模型创建系统生态图。在此过程中，可询问以下问题不断完善系统生态图。

a)所有可能与被分析系统连接的系统都被考虑到了吗？

b)系统间的接口方式已经确定了吗？

c)系统间的接口文件(ICD)或交互信息定义文件明确获取途径了吗？

d)系统间的接口有其他更高级别的约束吗？

步骤2：创建系统特性树

以待进行需求分析的嵌入式软件系统作为产品概念，建立鱼骨图，围绕产品概念，逐项添加1级特性，建议采用(名词+动词形式)，例如：参数设置；随后，对1级特性分别添加子特性，直至将全部共同的子功能连接在相同父特性上。同一颗系统特性树最好不超过3级特性，对于较大的嵌入式系统，确需建立多于3级的特性树时，可建立子特性树。在此过程中，可询问以下问题不断完善系统特性树。

a)该特性是某一类用户提出的吗？

b)该特性是为满足用户特性而要求系统必须具备的吗？

c)该特性涉及系统到系统的相互作用吗？

d)该特性存在多个父特性吗？

e)该特性的子特性完整吗？

f)特性树特性等级划分程度一致吗？

g)以划分完的特性可以合并吗？

h)该特性相关的特性都添加了吗？

步骤3：绘制组织结构图和组织界面表

组织结构图和组织界面表表述的是待分析嵌入式软件系统内部架构。首先，尽可能完整的定位系统现有(计划)的各软/硬件模块和分机组织；然后，确定各模块/分机的架构层级，如果模块与模块的组合存在现实意义，可以使用小组方框将其组织在一起；最后，按照前文所述组织结构图模型完成嵌入式系统组织结构图绘制。

参照步骤1创建的系统生态图和步骤3绘制的组织结构图，确定待分析嵌入式软件系统外部和内部界面(接口)，按照前文所述组织界面表模型，依次确定组织界面(接口)中传输的业务数据对象和字段、传输频度、数据流量、异常处理要求、安全约束等，完成组织界面表的创建。并非所有的界面(接口)都需要创建组织界面表，对于内容少、需求简单清晰的界面(接口)，不需要单独创建组织界面表。

步骤4：创建泳道过程流

针对步骤2中创建的系统特性树上的每个特性，分别创建过程流，因此，与特性等级相关，过程流也呈现不同等级。针对任一特性，按照步骤3绘制的组织结构图，将所有可能参与该特性的各模块/分机分别放置在过程流图的不同泳道上，泳道确认完成后，添加实现该特性的系统过程/步骤，并放置在执行该步骤的泳道上。在此过程中，可询问以下问题不断完善过程流。

a)什么事件触发步骤？

b)在这个步骤上可能发生什么错误情况，应该如何处理？

c)这个步骤需要进行什么计算吗？

d)出现了什么数据操作？

e)系统需要多快对事件作出响应？

f)事件预期出现的频度是多少？

g)是否允许失败，什么样的失败率可以接受？

h)允许占用的系统资源有限制吗？

步骤5：创建界面流

对于没有用户界面或只有非常少屏幕界面的嵌入式系统，不需要创建界面流。

若用户与系统交互跨多个屏幕流程，则可以创建界面流。首先可通过访谈、行业惯例等渠道尽可能多的获取用户对屏幕需求的描述，按前文所述界面流模型确定屏幕范围、屏幕构成，创建屏幕跳转，最后标注触发，初始界面流创建完成。随后向用户和项目干系人展示界面流模型，确认和验证导航，优化系统可用性。

步骤6：创建数据流

创建数据流时需要考虑所有的业务数据对象，以及系统针对这些业务数据对象可能采取的行动。当数据对象确定以后，使用步骤4创建的过程流和步骤5创建的界面流来识别可能与业务数据对象有关的流程，可以与不同项目干系人交流，了解各模块/分机、用户界面是如何产生数据、使用数据和输出数据的。在此过程中，可询问以下问题不断完善数据流。

a)这些是该流程所有的输入/输出吗？

b)什么数据被储存了？

c)系统需要多快完成数据处理？

d)是否允许失败，什么样的失败率可以接受？

e)这个数据流转可能发生什么错误情况，应该如何处理？

f)数据预期输入的频度是多少？

g)预期最大数据量是多少？

步骤7：创建状态表和状态图

首先确定需要分析的业务数据对象，接下来确定它们的状态，按照前文所述状态表模型，将状态分别填入行和列，最后分析状态之间的转变，以确定转变是否允许，如果允许，需要什么样的条件或事件触发这一转变，填入对应单元格。

在此过程中，可询问以下问题不断完善状态表。

a)发生转变需要具备哪些条件？

b)什么事件触发了转变？

c)转变会输出什么？

d)状态转变的结果会发生哪些过程、界面和数据的转变？

状态表创建完成后，若需要显示对象状态之间的转变顺序和方向，可以对有效的转变绘制状态图。

步骤8：创建数据字典

按前文所述数据字典模型结构格式创建数据字典，字段作为行，属性作为列，填充数据前，应先确定哪些属性是必须的。大多数嵌入式项目中，大部分数据字典以接口协议文件的形式给出，也可采用项目惯用格式。

步骤9：添加关键绩效指标

在上述8个步骤创建的不同视角的软件需求模型中，对过程流、界面流、数据流和状态表模型添加关键绩效指标，这些关键指标内容就是模型创建过程中通过提问获得的答案。

a)可能发生什么错误情况，应该如何处理？

b)系统需要多快对事件作出响应？

c)事件预期出现的频度是多少？

d)是否允许失败，什么样的失败率可以接受？

e)允许占用的系统资源有限制吗？

f)系统需要多快完成数据处理？

g)数据预期输入的频度是多少？

h)数据输出频度是多少？

i)预期最大数据量是多少？

j)允许最大等待时间是多少？

步骤10：迭代

使用本方法为一个嵌入式系统软件选择和创建模型后，将各模型进行相互验证，确保任一模型中定义的需求在其他相关模型中被同步定义并且未产生不一致性。通过不断迭代，相互验证，修订完善系统需求，综合提升嵌入式软件系统需求分析的正确性、一致性和完整性。

本发明的技术效果和优点：

1.实现了嵌入式软件可视化、形式化需求分析，解决了缺乏信息组织结构的冗长需求清单列表无法支撑项目干系人及时发现需求的缺失、错误、不完整或不明确的问题；

2.通过在过程流、界面流、数据流和状态表模型中添加关键指标模型，实现了嵌入式软件非功能性需求的分析定义，解决了非功能性需求不精确的问题；

3.通过建立系统、过程和数据三个维度的动态、静态形式化模型，互为补充和验证，提高了需求分析的完整性和一致性；

4.使用泳道来划分处理流程，将原不可见的嵌入式系统处理流程可视化，对项目全生命周期系统要执行的活动、执行顺序和执行逻辑，在全项目干系人中保持一致性和正确性；

5.将嵌入式软件需求分析与软件架构和设计分离，支持形式化方式确认和验证用户需求，在项目早期提高了需求稳定度；

6.与列表条目化的需求清单相比，图表形式化的需求分析结果更好的支持需求迭代，在发生需求增、删、改时，便于实施全局化的影响域分析。

附图说明

图1为本方法需求模型应用架构；

图2为系统生态图模型；

图3为系统特性图模型；

图4为组织结构图模型；

图5为泳道过程流模型；

图6为界面流模型；

图7为添加了KPI的泳道过程流模型；

图8为添加了KPI的界面流模型；

图9为数据流图模型；

图10为状态图模型。

具体实施方式

下面将对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本嵌入式软件需求分析方法将软件需求按系统(System)、流程(Process)、数据(Data)进行分组并建立综合模型(以下简称SPD方法)，从不同视角组织软件的静态和动态需求。下表展示了SPD方法组织方式。

一、系统模型

系统模型用来描述系统本身的静态需求，包括系统的组成、范围，它们与用户或其他系统之间的交互。包括系统生态图、系统特性树、组织结构图和组织界面表。

1、系统生态图

系统生态图用于显示系统与其所处环境之间的交互作用和它们之间关系的性质。使用方框表示系统，方框之间的连线代表系统之间的接口，接口上的箭头代表系统间数据流的方向，对于组成较复杂的系统，可通过虚线将系统的任何组成部分框在一起表示系统子集或子系统，另外，为便于项目干系人阅读系统生态图，可添加必要的系统标注予以说明。其模板如图2所示。

图2所示的系统生态图可帮助项目干系人轻松完整地识别连接到系统上的所有系统的正确性和完整性，通过建立系统生态图，完整、清晰的界定了系统的边界范围和外部交互接口，并确保在项目全生命周期内，系统定义范围始终清晰合理，并在项目干系人中理解一致。

2、系统特性树

系统特性树用于表达和组织系统逻辑特性，在单一页面上展示系统解决方案的全部范围。系统特性树采用鱼骨结构，用线连接的特性作为基本构建模块，第一级别的特性串接在产品概念线上，任何特性都有其子特性，这些子特性串接在父特性线上，以此类推，将全部特性从上到下串在一起，最终形成“鱼骨”形的系统特性树。系统特性图模型如图3所示。

系统特性树以层级方式将相关特性和需求连接在一起，提供单一特性解决方案的功能深度和全部特性解决方案的功能广度；此外，该模型的特性组织方式使得识别缺失特性和冗余特性变得更容易；最后，系统特性树提供了系统解决方案的功能分解和关系视图，用于整个项目的所有阶段，确保项目干系人在全生命周期中对工作范围保持共识。

3、组织结构图

通常意义上的组织结构图是指企业组织各组成部分及各部分之间可能存在的各种干系。在嵌入式软件需求分析中建立的组织结构图，其基本构建模块并非组织机构或人员，而是构成嵌入式系统的各软/硬件模块和分机组织，用于确认和显示系统内部各模块、部件是如何组织和协调工作的。组织结构图示一个分层结构由线连接的方框集合。每个方框包含模块、部件或者电路的名称，方框之间的线显示该系统内部模块的层级关系，通常，在一个组织结构图的同级方框包含相同级别的信息。组织结构图模型如图4所示：

组织结构图用来识别参与解决方案的系统内部各模块/分机，这对于嵌入式软件需求分析而言至关重要，嵌入式软件实际上就是通过控制各模块/分机之间的协作从而实现系统目标，建立这些可视化结构图不但能够凸显所有干系模块及其相关关系，在项目早期避免需求遗漏。并且对于组织结构图中的每个块，可通过但不限于以下方式的提问来完成过程模型的建立：

这个模块是不是与软件有关联？

这个模块对软件是否有任何需求？

这个模块是否会受到软件的影响或控制？

它们参与了过程的哪一部分？

4、系统界面表

组织界面表详细介绍系统之间、系统内部组织之间的通信。完成系统生态图和组织结构图后，建立系统界面表，从业务角度显示两个系统、组织之间的交互细节，说明传输的是什么信息、频率以及信息量，使得技术团队能够理解界面(接口)需求对设计决策的限制。系统界面表包含系统、组织间界面(接口)需求的元数据，但不包括技术协议或信息流的具体内容，如下表模板所示：

系统界面表模型

系统界面表可以确保完全获得系统界面(接口)的需求，通过结构化的字段，完整描述两个系统、组织之间的交互细节，说明各个界面(接口)之间传输的信息及要求，确保了内、外部接口需求的完整性和一致性。

二、过程模型

1、泳道过程流

过程流描述了系统要执行的活动、执行顺序和执行逻辑。使用泳道来划分处理流程非常有用，将全过程分解为几个段，考虑不同模块/分机执行自己的专门流程步骤，选取组织结构图中识别出的参与当前特性解决方案的模块/分机建立泳道。由一个模块或分机所执行的所有处理步骤会进入分配给它的泳道。如图5所示显示了带有泳道的过程流模型：

对系统特性树模型中标识出的系统特性分别建立过程流，因此，与特性等级相关，过程流也表现为不同等级。

2、界面流

界面流为可选模型，其适用于需用户跨屏幕交互执行任务的系统，用于描述用户界面需求、验证导航路径和优化系统可用性。界面流模型由三个基本元素组成：屏幕、标识流转方向的箭头和决策符号。当屏幕数量较大不利于分析时，可采用虚线框将相关的屏幕组织在一起以提高可读性，如图5所示，显示了界面流模型：

在用户需求开发、与技术团队沟通用户如何使用系统方面，界面流模型非常有效，在创建系统界面流的过程中确认和验证屏幕间的导航路径，发现并优化额外路径。创建的任意界面流，检查泳道过程流，应包括用户走过该界面时系统执行的任务，从而确保在需求分析阶段，全部用户场景和界面流对应过程流无错误或遗漏。

3、关键绩效指标

关键绩效指标(KPI)是企业管理工具，是通过对组织内部流程的输入端、输出端的关键参数进行设置、取样、技术、分析，衡量流程绩效的一种目标式量化管理指标。本方法在嵌入式系统软件需求分析领域借鉴这一概念，在上述创建的泳道过程流和界面流模型基础上，创建嵌入式系统软件关键绩效指标以衡量嵌入式系统过程成功与否，使用KPI叠加在已建立的过程流和界面流模型上，完成嵌入式系统性能指标分解，并为映射到过程流上的需求设定优先级。如图7和图8所示，显示了关键绩效指标模板。

通常没有必要为每个过程流和界面流都创建KPI。如果某个具体步骤是嵌入式系统测量的关键，那么需要进一步确定该步骤的一个或多个KPI。嵌入式系统KPI需求通常包括：完成所需时间、典型数据量、最大数据量、多少错误可接受、多严重的错误可接收、需要纠错的频率、任务占用最大资源量、任务占用典型资源量等。

将KPI标注在过程流和界面流上，更易于项目干系人确认系统累加性能指标是否能够满足需求，通过与多个KPI关联的关键步骤/过程，可帮助识别和确认关键需求，从而为需求设定优先级，避免团队做出过多无助于提升系统整体性能的局部优化。

三、数据模型

1、数据流图

数据流图(DFD)来源于结构化分析技术，软件开发人员从上下文创建DFD，然后分解DFD来创建该解决方案的功能模块。本方法在嵌入式系统软件需求分析领域使用DFD，用来收集需求而不是设计技术结构，通过图形视图展示数据是如何在流程之间流过并被流程改变。本质而言，嵌入式软件就是接收输入数据、处理数据和输出数据，数据流图模型可以帮助项目干系人建立数据移动的系统视图，在项目全生命周期中，全面、动态的识别并管理数据影响域。如图9所示，显示了数据流图模板。

2、数据字典

上述数据流图(DFD)显示了数据在系统中的移动路径，数据字典则用于定义数据对象的内容、属性，数据字典不描述嵌入式软件处理和传递的真实数据，而是重点关注系统界面(接口)间如何组织字段以形成数据对象。如下表所示显示了数据字典模板：

ID

数据对象

字段

属性1

属性2

属性3

...

数据字典模型

数据对象：嵌入式系统在完成任务、功能特性时遇到的具有实际意义的对象代表。例如：导航信息、校准信息等系统将处理的任何现实信息。

字段：描述或定义了数据对象的一个或多个特征、属性。例如：导航信息可能包括当前经度、当前纬度、地图信息、目标经度、目标纬度等字段。

属性：一个字段具有多个属性，定义和控制字段的规则。

在数据字典中捕捉上述信息，使得项目干系人能够以一种全局的、相关的和结构化的方式，查阅和管理系统中所有数据的属性。

本方法在需求分析阶段建立数据字典，以表格结构全面定义项目数据和控制数据的规则。使得全体项目干系人以同一种结构化的方法来审查和使用数据信息。

3、状态表

状态表用于识别一个特定的或多个数据对象的所有状态以及状态之间的所有可能的过渡。本方法中所述状态是指数据对象的生命周期阶段在系统中的映射，通常取决于对象一个字段或者字段集的唯一组合。系统状态必须是互斥的、唯一的。状态表用来识别系统状态、转变和触发转变的事件/条件。如下表所示显示了状态表模板：

状态表模型

如果状态转变有效，单元格中填写“是”或触发转变的事件/条件，如果转变无效，则填写“无”。如果状态转变需求具有顺序限制，则更适宜通过状态图来表示。

状态表是在视觉上传达哪些转变是允许的，以确保识别所有可能的状态转变，该模型可以快速地确定项目干系人对系统状态的理解是否正确、一致，对于存在大量状态转换的嵌入式系统而言，状态表的结构设置使得其可读性远远优于文本列表，有效避免了状态的遗漏，并帮助项目干系人直观显示状态转换设置中存在的冲突、错误和冗余需求。

4、状态图

通常情况下，状态图可作为已建立的状态表的补充模型，用于显示对象状态之间的转变顺序和方向。状态图只显示有效的转变、触发转变的事件/条件以及这些转变的视觉流程。状态图在状态转变的视觉呈现方面优于状态表，而状态表在确定评估每一个可能的转变方面更好，所以建议这两种模型配合使用，利用状态表进行需求开发，尽量完整获取转换的可能性，避免遗漏，在此基础上，对有效转变绘制状态图，直观呈现转变流程。如图10所示，显示了状态表模板。

状态图直观地展现了解决方案复杂的状态转变需求，完整的显示了一个对象的整个生命周期。其最重要的价值在于展示了状态转变的顺序流程，补充了状态表无法体现顺序的缺陷。初始需求分析完成后，利用状态图，可更直观有效的确认和验证用户需求，尽早发现缺失的系统状态或错误的转变触发，有效避免需求错误。

四、模型的综合应用

通过创建上述模型完成嵌入式系统初始需求分析后，下一步就是利用这些模型互相改善，这是本方法的真正关键步骤。单个模型只能表述系统需求信息的某个特定类型或某个角度的投影，因此需要多个模型从不同角度定义需求。

本方法采用最简单的术语和形式化的图表格式，专门用于嵌入式系统软件需求分析。使用多个互补模型提供的互补信息，使得项目干系人可以更深入、更全面的了解项目需求，从而发现单个模型中缺失或错误的需求信息。

本方法涉及的需求分析模型作为嵌入式系统软件需求信息的组织结构，使项目干系人对如何创建需求以便所有需求保持一致性和完整性具有共同的理解。本方法需求模型应用架构见图1。

最后应说明的几点是：首先，在本申请的描述中,需要说明的是,除非另有规定和限定,术语“安装”、“相连”、“连接”应做广义理解,可以是机械连接或电连接,也可以是两个元件内部的连通,可以是直接相连,“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变，则相对位置关系可能发生改变；

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种嵌入式软件需求分析方法，其特征在于，包括以下步骤：

步骤1：创建系统生态图

对于待进行需求分析的嵌入式软件所在系统，确认与其直接相连的所有可能系统，并确认系统间接口，创建系统生态图，在此过程中，可询问特定问题不断完善系统生态图；

步骤2：创建系统特性树

以待进行需求分析的嵌入式软件系统作为产品概念，建立系统特性树模型，围绕产品概念，逐项添加1级特性；随后，对1级特性分别添加子特性，直至将全部共同的子功能连接在相同父特性上；同一颗系统特性树优选的不超过3级特性，对于较大的嵌入式系统，确需建立多于3级的特性树时，可建立子特性树；在此过程中，可询问特定问题不断完善系统特性树；

步骤3：绘制组织结构图和组织界面表

组织结构图和组织界面表表述的是待分析嵌入式软件系统内部架构；首先，尽可能完整的定位系统现有或计划的各软/硬件模块和分机组织；然后，确定各模块/分机的架构层级，如果模块与模块的组合存在现实意义，可以使用小组方框将其组织在一起；最后，根据组织结构图模型，按照各模块/分机之间的逻辑关系完成嵌入式系统组织结构图绘制；

参照步骤1创建的系统生态图和步骤3绘制的组织结构图，确定待分析嵌入式软件系统外部和内部界面或接口，按照前文所述组织界面表模型，依次确定组织界面或接口中传输的业务数据对象和字段、传输频度、数据流量、异常处理要求、安全约束等，完成组织界面表的创建。并非所有的界面或接口都需要创建组织界面表，对于内容少、需求简单清晰的界面或接口，不需要单独创建组织界面表；

步骤4：创建泳道过程流

针对步骤2中创建的系统特性树上的每个特性，分别创建过程流，因此，与特性等级相关，过程流也呈现不同等级；针对任一特性，按照步骤3绘制的组织结构图，将所有可能参与该特性的各模块/分机分别放置在过程流图的不同泳道上，泳道确认完成后，添加实现该特性的系统过程/步骤，并放置在执行该步骤的泳道上；

步骤5：创建界面流

对于没有用户界面或只有非常少屏幕界面的嵌入式系统，不需要创建界面流；

若用户与系统交互跨多个屏幕流程，则可以创建界面流；首先可通过访谈、行业惯例等渠道尽可能多的获取用户对屏幕需求的描述，按前文所述界面流模型确定屏幕范围、屏幕构成，创建屏幕跳转，最后标注触发，初始界面流创建完成；随后向用户和项目干系人展示界面流模型，确认和验证导航，优化系统可用性；

步骤6：创建数据流

创建数据流时需要考虑所有的业务数据对象，以及系统针对这些业务数据对象可能采取的行动；当数据对象确定以后，使用步骤4创建的过程流和步骤5创建的界面流来识别可能与业务数据对象有关的流程，可以与不同项目干系人交流，了解各模块/分机、用户界面是如何产生数据、使用数据和输出数据的；

步骤7：创建状态表和状态图

首先确定需要分析的业务数据对象，接下来确定它们的状态，按照状态表模型，将状态分别填入行和列，最后分析状态之间的转变，以确定转变是否允许，如果允许，需要什么样的条件或事件触发这一转变，填入对应单元格；

状态表创建完成后，若需要显示对象状态之间的转变顺序和方向，可以对有效的转变绘制状态图；

步骤8：创建数据字典

按数据字典模型结构格式创建数据字典，字段作为行，属性作为列，填充数据前，应先确定哪些属性是必须的；大多数嵌入式项目中，大部分数据字典以接口协议文件的形式给出，也可采用项目惯用格式；

步骤9：添加关键绩效指标

在上述8个步骤创建的不同视角的软件需求模型中，对过程流、界面流、数据流和状态表模型添加关键绩效指标，这些关键指标内容就是模型创建过程中通过提问获得的答案；

步骤10：迭代

使用本方法为一个嵌入式系统软件选择和创建模型后，将各模型进行相互验证，确保任一模型中定义的需求在其他相关模型中被同步定义并且未产生不一致性；通过不断迭代，相互验证，修订完善系统需求，综合提升嵌入式软件系统需求分析的正确性、一致性和完整性。

2.根据权利要求1所述的一种嵌入式软件需求分析方法，其特征在于，所述步骤1中的特定问题包括但不限于：

a)所有可能与被分析系统连接的系统都被考虑到了吗？

b)系统间的接口方式已经确定了吗？

c)系统间的接口文件(ICD)或交互信息定义文件明确获取途径了吗？

d)系统间的接口有其他更高级别的约束吗？。

3.根据权利要求1所述的一种嵌入式软件需求分析方法，其特征在于，所述步骤二中的特定问题包括但不限于：

a)该特性是某一类用户提出的吗？

b)该特性是为满足用户特性而要求系统必须具备的吗？

c)该特性涉及系统到系统的相互作用吗？

d)该特性存在多个父特性吗？

e)该特性的子特性完整吗？

f)特性树特性等级划分程度一致吗？

g)以划分完的特性可以合并吗？

h)该特性相关的特性都添加了吗。

4.根据权利要求1所述的一种嵌入式软件需求分析方法，其特征在于，在步骤4中创建泳道过程流的过程中，可询问以下问题不断完善过程流：

a)什么事件触发步骤？

b)在这个步骤上可能发生什么错误情况，应该如何处理？

c)这个步骤需要进行什么计算吗？

d)出现了什么数据操作？

e)系统需要多快对事件作出响应？

f)事件预期出现的频度是多少？

g)是否允许失败，什么样的失败率可以接受？

h)允许占用的系统资源有限制吗。

5.根据权利要求1所述的一种嵌入式软件需求分析方法，其特征在于，在步骤6创建数据流过程中，可询问以下问题不断完善数据流：

a)这些是该流程所有的输入/输出吗？

b)什么数据被储存了？

c)系统需要多快完成数据处理？

d)是否允许失败，什么样的失败率可以接受？

e)这个数据流转可能发生什么错误情况，应该如何处理？

f)数据预期输入的频度是多少？

g)预期最大数据量是多少。

6.根据权利要求1所述的一种嵌入式软件需求分析方法，其特征在于，在步骤7创建状态表和状态图的过程中，可询问以下问题不断完善状态表。

a)发生转变需要具备哪些条件？

b)什么事件触发了转变？

c)转变会输出什么？

d)状态转变的结果会发生哪些过程、界面和数据的转变。

7.根据权利要求1所述的一种嵌入式软件需求分析方法，其特征在于，所述步骤9中，模型创建过程中提问包括但不限于：

a)可能发生什么错误情况，应该如何处理？

b)系统需要多快对事件作出响应？

c)事件预期出现的频度是多少？

d)是否允许失败，什么样的失败率可以接受？

e)允许占用的系统资源有限制吗？

f)系统需要多快完成数据处理？

g)数据预期输入的频度是多少？

h)数据输出频度是多少？

i)预期最大数据量是多少？

j)允许最大等待时间是多少。

Images