软件需求的获取和分析是软件系统开发中的一项重要任务，正确获取软件需求是软件技术人员必须掌握的基本技能。本课程从软件需求工程的角度出发，以需求开发过程为主线，完整描述了需求获取、需求分析、需求验证、需求规格说明和需求管理等需求工程活动。本书站在开发者的立场，侧重于实践者的技术与方法，系统全面地介绍了软件需求工程的各项进展，努力促进需求工程领域理论、方法和技术的全面融合应用，以指导需求工程各阶段的系统化实践。

1. Diragram

1.1 Context Diagram(范围图)

范围图以图形方式标识系统。外部因素及其之间的关系。这是系统的高级视图。范围图广泛用于软件工程和系统工程中，以设计处理信息的系统。

使用用于ConceptDraw DIAGRAM的框图解决方案中的现成可用的预先设计的对象，模板和示例，您可以轻松快捷地创建自己的专业外观框图和上下文关系图。

1.2 Sequence Diagram（序列图）

顺序图主要用于显示对象之间的交互，顺序是这些交互发生的顺序。与类图非常相似，开发人员通常认为序列图是专门为它们设计的。但是，组织的业务人员可以通过显示各种业务对象之间的交互方式，来找到有用的顺序图，以交流当前业务的工作方式。除了记录组织的当前事务之外，业务级序列图还可以用作需求文档，以传达未来系统实现的需求。在项目的需求阶段，分析人员可以通过提供更正式的改进级别，将用例提高到一个新的水平。当发生这种情况时，用例通常会被精简为一个或多个序列图。

具有同步消息模式的基本序列图创建元素和序列图：

该图描述了一个参与者和两个组件之间的交互，显示了消息的时间顺序调用。消息交换是同步的，这意味着调用者将等待接收到应答。

显示了一个序列图，一个参与者和两个组件的交互以及它们交换的消息。

使元素之间的相互作用可视化。设计人员和实现团队通常创建序列图，作为设计工具或用于文档目的。该模式允许建模者展示如何创建资源，例如类，一旦它们在交互中达到了目的，就可以销毁它们。消息序列通常可以通知设计决策或使操作系统中发现的问题变得清晰。

该模式通常在设计或实现阶段使用，但也可以在计划完成并需要文档记录时使用。它可用于对调用对象在继续进行进一步处理之前必须等待消息得到答复的情况进行建模。

1.3 Dataflow Diagram（数据流图）

数据流模型模式创建元素和许多图表，这些图显示了系统以及流入和流出外部实体的数据，允许向下钻取（单击）到两个较低级别的图表。

此图为最底层的图标，该模式的目的是允许业务分析员、数据分析员、信息架构师或其他涉众创建数据在被观察系统和外部实体之间流动的方式的表示（上下文或0级图）。

模式通常在信息分析期间使用。上下文（0级）图通常在早期创建，以了解系统和外部实体之间交换的信息（数据），包括行程方向和其他对分析非常重要的细节，如传输的类型、格式、大小和频率。

1.4 Component Diagram（组件图）

向通过组装连接器连接的组件显示，这两个组件通过接口共享信息。组件添加了描述元素的注释，这些注释在图表上是可见的。目的是允许设计师、架构师和其他涉众创建或查看架构或设计的逻辑部分以及它们通过接口进行通信的方式。

组件图经常是一个架构师在项目的初期就建立的非常重要的图。然而，组件图的有用性跨越了系统的寿命。组件图是无价的，因为它们模型化和文档化了一个系统的架构。因为组件图文档化了系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统。

组件图的主要目的是显示系统组件间的结构关系。在UML 2中，组件被认为是独立的，在一个系统或子系统中的封装单位，提供一个或多个接口。虽然 UML 2 规范没有严格地声明它，但是组件是呈现事物的更大的设计单元，这些事物一般将使用可更换的组件来实现。主要思想是，你能容易地在你的设计中重用及/或替换一个不同的组件实现，因为一个组件封装了行为，实现了特定接口。

在以组件为基础的开发中，组件图为架构师提供一个开始为解决方案建模的自然形式。组件图允许一个架构师验证系统的必需功能是由组件实现的，这样确保了最终系统将会被接受。

除此之外，组件图对于不同的小组是有用的交流工具。图可以呈现给关键项目发起人及实现人员。通常，当组件图将系统的实现人员连接起来的时候，组件图通常可以使项目发起人感到轻松，因为图展示了对将要被建立的整个系统的早期理解。

开发者发现组件图是有用的，因为组件图给他们提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。系统管理员发现组件图是有用的，因为他们可以获得将运行于他们系统上的逻辑软件组件的早期视图。虽然系统管理员将无法从图上确定物理设备或物理的可执行程序，但是，他们仍然欢迎组件图，因为它较早地提供了关于组件及其关系的信息（这允许系统管理员轻松地计划后面的工作）。

应用：

构件图由构件、接口和构件之间的联系组成，其中，构件可以是源代码、二进制码或可执行程序等。

构件图用于下列事物建立模型：系统的源代码、系统的发布版本、物理数据库等。

一个大型复杂的软件系统，其运行系统往往由多个可执行程序和相关的对象库构成，可以使用构件图对它建立模型，以便可视化和说明系统的构成，有利于作出开发决策。

建立一个可执行的构件图可按以下步骤进行：

1.确定构件。首先要分解系统，考虑有关系统的组成管理、软件的重用和物理节点的配置等因素，把关系密切的可执行程序和对象库分别归入构件，找出相应的对象类、接口等模型元素。

2.对构件加上必要的构造型。可以使用UML的标准构造型<<executable>>、<<library>>、<<table>>、<<file>>、<<document>>等，或自定义新的构造型，说明构件性质。

3.确定构件之间的联系。最常见的构件之间联系是通过接口的依赖。一个构件使用某个接口，另一个构件实现该接口。

4.必要时把构件组织成包。

5.绘制构件图。

1.5 Interaction Diagram（交互图）

其中包含交互图以及由控制流和控制流结构连接的多个交互事件。

目的是从一个高层次描述交互。该图的语法类似于更常用的活动图，包括所有的控制结构，如决策、合并、分叉和联接，但在活动的地方，控制流之间可以包含交互和交互事件。

它通常在分析阶段用于创建从高层描述交互的图表。因为它包含了显示现有图表的元素，不管是内联的还是通过引用的，在创建其他图表之前，不能定义交互概述图。

1.6 Statechart Diagram(状态转换关系图)

状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的，状态描绘了对象的动态生命周期。在对象的整个生命周期中，它的状态是会发射功能变化的，而状态机就是用来表示一个对象在它的生命周期中响应事件所发生的状态变化以及对事件的响应。主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（ Event ），以及因状态转移而伴随的动作（ Action ）。一般可以用状态机对一个对象的生命周期建模，状态图用于显示状态机（ State Mac hine Diagram ），重点在与描述状态图的控制流。

1.7 Use Case Diagram(用例图)

Actors（演员）：

用例图显示了系统与系统外部实体之间的交互。这些外部实体称为参与者。角色代表的角色可能包括人类用户，外部硬件或其他系统。通常将演员绘制为命名的简笔画，或者使用«actor»关键字绘制为类矩形。

Use Cases（用例）：

用例是有意义的工作的单个单元。它提供了系统外部某人或某物可观察到的行为的高级视图。用例的表示法是椭圆。

用例的用语是一条带有可选箭头的连接线，该箭头显示了控制方向。

Use Case Definition（用例定义）：

用例通常包括：名称和说明，要求，约束条件，情境，方案图，附加信息。

Name and Description（名称和说明）：

用例通常被称为动词短语，并给出简短的非正式文本描述。

Requirements（要求）：

需求定义了用例必须提供给最终用户的正式功能需求。它们对应于结构化方法中的功能规范。需求是用例将执行操作或为系统提供某些价值的合同或承诺。

Constraints（约束条件）：

约束是用例在以下条件下运行的条件或约束，包括使用前，后和不变条件。前提条件指定了用例可以继续进行之前需要满足的条件。后置条件用于记录用例执行后必须为真的条件更改。不变条件指定在整个用例执行过程中正确的条件。

Scenarios（情境）：

场景是对用例实例执行期间发生的事件流的正式描述。它定义了系统与外部参与者之间事件的特定顺序。它通常以文本形式描述，并且与顺序图的文本表示相对应。

Including Use Cases（包括用例）：

用例可能包含其他用例的功能，作为其正常处理的一部分。通常，假设每次运行基本路径时都会调用任何包含的用例。这方面的一个示例是执行用例<Card Identification>作为用例<Withdraw>的一部分运行。

一个或多个用例可能包含用例，通过将常见行为分解为可重复使用的用例来帮助降低功能的重复程度。

Extending Use Cases（扩展用例）：

一个用例可以用来扩展另一个用例的行为。这通常在特殊情况下使用。例如，如果在修改特定类型的客户订单之前，用户必须获得更高权限的批准，则<Get Approval>用例可以选择扩展常规的<Modify Order>用例。

Extension Points（延伸点）：

可以通过扩展点定义添加扩展用例的时间点。

System Boundary（系统边界）：

通常将用例显示在系统内部，将参与者显示在系统外部。

Basic Use Case Model：

基本用例模型：

基本用例模型模式创建元素和用例图，描述用户角色希望从系统中实现的目标。用例都包含在系统边界内，参与者都在边界之外。其中包含参与者和系统边界中包含的多个用例。一个参与者表示一个系统，并使用矩形表示法。

其目的是允许业务分析师和其他涉众描述参与者（用户扮演的角色）在与系统交互时想要实现的价值。

该模式通常用于计划的分析阶段，可用于实现任意数量的需求，并作为为实现团队提供规范的一种方式

1.8 Activity Diagram(活动图)

Exception Handlers（异常处理程序）：

异常处理程序可以在活动图上建模，如下例所示。

Interruptible Activity Region（中断活动区域）：

一个可中断的活动区域围绕着一组可以被中断的动作。在下面的非常简单的示例中，“流程订单”动作将执行到完成为止，直到将控制权传递给“关闭订单”动作，除非收到“取消请求”中断，该中断会将控制权传递给“取消订单”动作。

Starter Activity Diagram：

启动机活动图模式：

创建元素和一个活动图，其中包含一系列动作和控制节点（初始、最终、决策等），这些节点由控制流连接，这些控制流指示触发动作的顺序。

显示活动包含由控制流连接的多个操作和控制节点（初始、最终、决策）的图表。

其目的是允许业务分析人员和其他涉众通过定义一系列操作来创建活动如何执行其工作的可视化表示。顺序由控制流关系显示。

它通常在计划的分析阶段使用，以显示活动所描述的工作是如何由一系列动作执行的。图表通常不会为每一项活动而创建，而是为一小部分活动而创建，在这些活动中，明确说明工作是如何进行的很重要。

1.9 State Machine Diagram(状态机图)

状态机图为单个对象的行为建模，指定对象在其生命周期中响应事件而经历的事件顺序。

Concurrent Regions（并发区域）：

可以将状态划分为包含子状态的区域，这些子状态同时存在并执行。下面的示例显示，在“正在应用制动”状态下，前后制动器将同时且独立运行。注意使用fork和join伪状态，而不是选择和合并伪状态。这些符号用于同步并发线程。

Starter State Machine：

Initial and Final States（初始状态和最终状态）：

初始状态用黑色实心圆圈表示，并可以用名称标记。最终状态由内部带有圆点的圆圈表示，也可以标记名称。

Basic State Machine with Triggers：

Basic State Machine with Triggers and Guards：

Basic State Machine with Triggers Guards and Effects：

Transitions（转场）：

从一个状态到下一个状态的过渡用带箭头的线表示。过渡可能具有触发，防护和效果，如下所示。

提供一种机制来表示系统工程师或其他涉众认为在类或其他元素的生命周期中很重要的条件（状态）。它描述了状态相关的行为，显示了元素如何从一个状态转换到另一个状态。

当软件工程师想要定义或描述类或其他元素可能显示的一组离散状态时，可以使用该模式。它们通常用于分析系统某些部分的行为，通常是因为难以理解或其行为复杂。

Basic State Machine with Entry Actions：

具有入口操作的基本状态机：

带有入口操作模式的基本状态机从其显示的重要状态的角度描述了一个实体（例如，类、参与者、用例或测试用例）。条目是一种可选行为，无论到达状态所需的转换是什么，只要输入一个tate就执行它。

提供一种机制来表示系统工程师或其他涉众认为在类或其他元素的生命周期中很重要的条件（状态）。它描述了状态相关的行为，显示了元素如何从一个状态转换到另一个状态。转换上的注释有助于限定状态更改。

Complete Nested States：

嵌套的状态：

嵌套状态模式描述了一个类或其他元素，该类或元素具有多个状态，其中一个或多个状态本身具有状态（子状态）。模式允许这些状态显示在同一个图表上。

其目的是允许软件工程师和其他涉众在一个图表上创建两个（或更多）状态转换级别的可视化表示。

当执行转换的遍历以了解所属元素的行为时，或者当将嵌套状态放置在同一个图上时，这种表示通常很有用，无需单击组合图就可以更容易地理解状态之间的转换。

Simple State Machine：

简单状态机：

简单状态机模式从实体显示的重要状态的角度描述了一个实体（例如块、参与者、用例或测试用例）。当进入一个状态时，一个进入动作可以被触发，而在这个状态下一个执行动作可以被触发，离开状态时可以触发一个退出动作。

描述了状态相关的行为，显示了元素如何从一个状态转换到另一个状态，以及在元素处于该状态期间调用了哪些活动。它们通常用于分析系统某些部分的行为，通常是因为难以理解或其行为复杂。

1.10 Class Diagram(类图)

类图显示了任何面向对象系统的构建块。类图描绘了模型或模型一部分的静态视图，描述了模型具有的属性和行为，而不是详细描述了实现操作的方法。类图在说明类和接口之间的关系时最有用。概括，集合和关联对于分别反映继承，组成或用法以及连接都很有价值。

Basic Class Diagram with Operations：

带操作的基本类图：

基本类图with Operations模式创建元素和描述两个类如何相互关联的类图。这些关联显示了类之间的语义或结构关系。操作已添加到类中，这些操作是类的功能。它们与属性一起赋予分类器本质特征。操作描述了分类器可以执行的工作。它们是类行为的重要表达式，并赋予类（连同属性）的本质特征。

其目的是让分析员和其他利益相关者能够创建和查看表示感兴趣领域中重要“事物”的元素以及它们之间的结构或语义方式。操作有助于对类将要执行的行为或工作（包括它所交付的服务）进行建模。

它通常在计划的早期用于描述域中的重要元素。模式对于分析很有用，但是操作和接收通常是由实现团队添加的。

Domain Model：

领域模型:

1.在类图上创建类，这些类描述讨论中的域中的重要概念或“事物”。类可以命名，也可以有详细的注释。连接词用来描述元素之间的关系，就像自然语言中动词用来描述名词如何相互作用一样。

2.显示一个类图，其中包含表示域中概念的多个类。类被连接以显示它们的关系，而多重性用于描述关系的基数。该图以手绘方式呈现，以使其更直观，更吸引非技术观众。

3.其目的是创建一个域中重要概念的模型，该模型可以用作通信工具，以确保所有涉众对概念有一个共同和一致的理解。

4.通常是在计划中创建的首批模型之一，它构成了开发存储库其他部分的基础。它可以像使用词典一样作为一种交流工具。

1.11 Package Diagram(包图)

包图用于反映包及其元素的组织。当用于表示类元素时，包图提供名称空间的可视化。封装图最常见的用途是组织用例图和类图，尽管封装图的使用不限于这些UML元素。

包中包含的元素共享相同的名称空间。因此，特定名称空间中包含的元素必须具有唯一的名称。

可以构建包来表示物理或逻辑关系。选择在特定包中包含类时，将具有相同继承层次结构的类分配给同一包很有用。还有一个很强的论点，就是将通过组合相关联的类以及与它们协作的类包含在同一包中。

Nested Package Hierarchy：

嵌套连接器：

目标软件包和源软件包之间的嵌套连接器显示源软件包已完全包含在目标软件包中。

嵌套包层次结构：

嵌套包层次结构模式创建了许多包和一个包关系图，该图将包表示为嵌套层次结构，包可视地包含在其父包中。颜色被用来使图表更吸引人。

其目的是提供包结构的可视化表示，对于不使用项目浏览器查看模型的人来说，这可能并不明显。可视化包含显示父包所拥有的子包，并通过将包嵌套在彼此内部来呈现。

它通常用于计划的早期阶段，当重要的是显示包的内容及其组成的包时。提供包结构的可视化表示非常有用，对于不使用项目浏览器查看模型的用户来说，这可能不太明显。

1.12 Communication Diagram(通讯图)

通信图是一种交互图，它显示与序列图相似的信息，但其主要重点是对象关系。在通信图上，显示了对象以及它们之间的关联连接器。消息将添加到关联中，并显示为指向消息流方向的短箭头。消息的顺序通过编号方案显示。

Starter Communication Diagram：

该图显示了如何在对象之间交换消息。这些消息被编号，表明它们被调用的顺序。目的是允许设计人员和架构师描述对象通过消息调用序列进行通信的方式。消息可以叠加在类图或组件图上，以显示元素如何通信。

以下两个图显示了通信图和显示相同信息的顺序图。尽管可以从编号方案中得出通信图中消息的顺序，但是它并不是立即可见的。尽管通信图确实非常清楚地显示了在相邻对象之间传递的全套消息。

1.13 Deployment Diagram(部署图)

部署图对系统的运行时体系结构进行建模。它显示了硬件元素（节点）的配置，并显示了软件元素和工件如何映射到那些节点上。

Node Stereotypes（节点刻板印象）：

为节点提供了许多标准构造型，即“ cdrom”，“ cd-rom”，“计算机”，“磁盘阵列”，“ pc”，“ pc客户端”，“ pc服务器”，“安全”，“服务器” »，“存储”，“ unix服务器”，“用户PC”。这些将在节点符号的右上角显示一个适当的图标

Starter Deployment Diagram：

部署图是结构图的一种，它展示了系统的架构。例如：一个软件系统的众多实体（Artifacts）是如何构成部署目标（Node，节点）的。

实体（Artifact）表示在现实世界中具体的元素。实体通常是开发过程的结果，例如：可执行文件、库、存档、数据库schema、配置文件等等。

部署目标（Deployment target）：通常用节点（Node）来表示，代表一个硬件设备或某些软件运行环境。节点可以通过communication paths构成任意复杂度的、网络连接的系统。

注意：在UML1.x部署图规范中，组件可以直接部署到节点中。但是在UML2.x规范中，实体可以部署到节点，实体也可以实现组件。组件则可以通过实体间接部署到节点。

部署图可以用于描述规范级别的架构，也可以描述实例级别的架构。这与类图和对象图有点类似。

规范级别：展示从实体到节点的部署情况。不涉及具体的实体实例或节点实例。

实例级别：展示实体实例到具体的节点实例的部署情况。它可以用于展示不同部署之间的差异。例如，开发和生产环境的部署可以通过具体的名字或ID（这里指的是具体的构建、部署服务器、或设备）加以区分。

1.14 Composite Stucture Diagram(复合结构图)

复合结构图是显示分类器的内部结构的图，包括其与系统其他部分的交互点。它显示了零件的配置和关系，一起执行了包含分类器的行为。

Port（端口）：

端口是有类型的元素，代表包含的分类器实例的外部可见部分。端口定义了分类器与其环境之间的交互。端口可以出现在包含零件，类或复合结构的边界上。端口可以指定分类器提供的服务以及其环境所需的服务。端口在其所属分类器的边界边缘上显示为命名矩形。

Starter Composite Structure Diagram：

通过使用表示组成组件的组件的部件来描述组件的内部结构。端口和接口通过委派连接器和信息流连接，它们显示信息项如何通过指定的接口从组件流向组件。

目的是允许设计师和架构师描述组件的组成，以及这些组件（其他组件）如何“连接”在一起以执行组件的工作。信息流充当管道，携带信息项连接显示信息的接口，其他有效载荷从一个组件移动到另一个组件。

Composite Structure Diagram with Collaboration：

具有协作模式的复合结构图通过使用零件（代表组成零件的零件）来描述零件的内部结构。端口和接口与委托连接器和信息流连接，这些连接器和信息流显示了信息项如何通过指定的接口从组件流向组件。

上图显示代表组成组件的组件的零件以及流经连接组件零件的接口和端口的信息项。该模式的目的是允许设计人员和架构师描述组件的组成以及如何将零件（其他组件）“连接”在一起以执行组件的工作。充当管道的信息流携带信息项，这些信息项连接显示信息和其他有效负载从组件到组件移动的接口。该模式通常用于设计或实现阶段，以通过描述组件或其他组件（其他组件）的交互来显示复合或复杂组件如何交付价值。它可以用来分解组件的层次结构，以显示系统逻辑部分如何产生和使用信息。

1.15 Object Diagram(对象图)

Complete Object Diagram：

完整对象图：

完整的对象图模式创建一个对象图，其中包含通过链接（关联实例）连接的对象（实例规范）。对象包含允许为类中定义的属性指定值的插槽。角色名称（包括数字）用于标识实例及其相对于关联的类或链接对象所扮演的角色。

目的是允许业务分析师、测试人员和实现团队的成员定义信息模型的范例。

可用于任何需要类模型示例的情况。它们可用于多种情况，包括：

1.定义可以用作测试用例输入的测试数据，或者在开发使用或生成部分信息模型的模块或组件时为程序员提供有用的范例。

2.创建范例，分析员可以使用这些范例向那些发现更抽象的信息模型难以理解或概念化的涉众解释困难的场景。

1.16 Timing Diagram(时序图)

State Lifeline（状态生命线）：

状态生命线显示了项目状态随时间的变化。X轴以选择的任何单位显示经过的时间，而Y轴标有给定的状态列表。状态生命线如下所示。

Value Lifeline（价值生命线）：

价值生命线显示了项目价值随时间的变化。X轴以所选择的任何单位显示经过的时间，与状态生命线相同。该值显示在每条值变化时交叉的一对水平线之间。价值生命线如下所示。

Putting it all Together（全部放在一起）：

状态和价值生命线可以任意组合堆叠在一起。它们必须具有相同的X轴。消息可以从一条生命线传递到另一条生命线。每个状态或值转换可以具有一个已定义的事件，一个指示何时必须发生一个事件的时间约束以及一个指示一个状态或值必须生效多长时间的持续时间约束。一旦应用了所有这些，时序图可能如下所示。

1.17 Interaction Overview Diagram(交互概览图)

交互概述图是活动图的一种形式，其中节点表示交互图。交互图可以包括顺序图，通信图，交互图和时序图。交互概述图的大多数表示法与活动图相同。例如，初始，最终，决策，合并，派生和联接节点都相同。但是，交互概述图引入了两个新元素：交互发生和交互元素。

Interaction Occurrence（交互发生）：

交互事件是对现有交互图的引用。交互事件显示为参考框架；也就是说，在左上角带有“ ref”的框架。所引用的图的名称显示在框架的*。

Interaction Element交互元素：

交互元素类似于交互事件，因为它们显示矩形框架内现有交互图的表示。它们的不同之处在于它们以内联方式显示参考图的内容。

Putting it all Together（全部放在一起）：

活动图上所有相同的控件（分支，联接，合并等）都可以用于交互概览图上，从而将控制逻辑置于较低级别的图上。以下示例描述了一个示例销售过程，其中子过程在交互事件中被抽象化。

1.18 Entity-relationship Diagram(实体关系图)

实体关系图（ERD）显示了存储在数据库中的实体集的关系。在这种情况下，实体是对象，是数据的组成部分。实体集是相似实体的集合。这些实体可以具有定义其属性的属性。

1.19 Basic Business Process(业务流程图)

房屋出租业务流程:

1、基本业务流程模式使用埃里克森-彭克语言创建元素和图表来表示业务流程和交互。

该语言提供了一种对业务流程建模的内聚方式，它允许建模者在一个综合的、有表现力的图中表示目标、触发流程的事件以及流程的输入和输出。

2、该模式的目的是允许业务分析师、架构师和其他涉众创建和查看一个简单但富于表现力的图表，该图表在一个视图中捕获流程的所有方面。

3、该模式可在计划期间的任何时间使用，但通常在分析期间用于描述基线(当前)和目标(未来)流程。

Business Process Diagram with Lanes(带通道的业务流程图)

带有通道模式的业务流程图在池中包含的三个通道中创建流对象，包括活动和开始和结束事件。车道用于组织和分类车道中的元素。
车道的目的是组织和分类流动对象，通常用于指示谁执行或负责车道中包含的活动。这些通道可用于其他目的，例如指示正在执行活动的位置或谁管理一组活动。

模式可以在计划的任何时候使用，但通常在绘制基线（当前状态）过程或定义目标（未来状态）过程的早期使用。对于一个组织来说，在一个企业或业务单元级别开始详细描述所有基线（当前状态）过程是非常常见的，这样这些过程是可用的，并且可以被多个项目重用。

1.20 Organization Chart Diagram(组织结构图)

组织结构模式创建元素和图表，为组织的角色、职责和报告线建模。各种各样的线条样式和颜色被用来帮助布局和吸引人的图表。
模式的目的是允许业务分析师、业务架构师或其他涉众创建一个组织图，以表示特定时间点的组织结构。组织部门、角色或指定人员可以作为图表的一部分。

它通常在定义企业或业务体系结构时使用，并允许将角色包含在存储库的其他部分中，例如，表示哪个角色、职务或人员负责给定的业务流程、功能或支持服务。

1.21 Composite Requirement Hierarchy : SysML Requirements diagram(需求图)

可追踪性：
显示需求和模型中其他元素之间的关系，包含一个需求层次结构，该层次结构包含许多其他元素，包括：涉众、块和测试用例。
其目的是允许系统工程师创建一个图表，其中模型元素和它们相关的需求之间的关系可以可视化，包括其他需求。通常在开发模型和定义诸如块、用例和测试用例等元素并与其满足的需求相关时使用。然而，图的形式可以在模型演化的任何阶段使用。

1.22 Internal Block Diagram : SysML Internal Block diagram(内部框图)

定义：
块：块（表示法：带有关键字=“块”的矩形）代表一个系统组件，是一个模块化的结构单元，封装了其内容（属性，行为，约束）并支持一流的（即可以在其中绘制和直接操作）模型存储库）接口。块封装的行为包括：操作，信号和状态机。用于连接和连接（“布线”）模块接口的唯一交互点称为端口。

块可以指定软件，硬件，机械和湿件（人员，组织，设施）组件。
块同时支持信息和物理流的提供（实现或实现）和必需（使用）接口。
块可以递归分解为零件，其中每个零件也必须由一个块定义。（请参阅下面的使用说明。）
内部方框图（ibd）：内部方框图是特定方框所拥有的静态结构图，它显示其封装的结构内容：零件，属性，连接器，端口和接口。换句话说，IBD是封装的（“黑盒子”）块的“白盒子”透视图。

可以通过在块定义图（BDD）定义和内部块图（IBD）用法之间交替来将块递归分解（嵌套）为零件（请参见下面的用法说明）。
行为可以由块（例如，操作，信号和状态机）封装，也可以直接（或通过接口）间接（通过“ allocate”依赖）分配给块（例如，活动/动作）。
可以通过约束块对块进行数学约束，以生成数学上可模拟的参数图。
比较和对比：UML 2类和组件图；SA / SD系统上下文和结构图图; IDEF IDEF1X图表。
目的
内部框图（IBD）的目的是显示模块的封装结构内容（零件，属性，连接器，端口，接口），以便可以使用基于接口的设计技术对其进行递归分解和“连线”。如果使用得当，BDD + IBD可以递归扩展，并且可以在数学上（参数上）模拟。

1.23 Block with Properties : SysML Block Definition diagram(模块定义图)

SysML中的模块定义图，英文为 “Block Definition Diagram”，简称BDD，是系统建模过程中最为常见的图之一，BDD是一种结构图，它主要对系统的结构组成以及组成元素间的关系进行描述。

BDD中可以包含包、模型、模型库、视图、模块和约束模块。其中最为重要和常见的是模块和约束模块。约束模块是SysML中的一种定义元素，常见情况下在约束模块中定义约束表达式。约束模块一般用于搭配参数图构建系统的数学模型。

模块时SysML中的基本单元，其对应于系统中的任意实体，我们可以使用模块对系统中的实体进行建模。通过带有<>标识的矩形框表示，其后带有模块的名称（用户自定义），另外，还可以通过可选的其他分隔框，用来标识模块的其他组成。
BDD属性包含行为属性和结构属性。顾名思义，结构属性表达了实体的结构组成该部分，而行为属性则表达了实体所具有的行为特征。结构特性包含值属性、组成属性、引用属性、约束属性、端口共 5 种类型。行为属性是对系统或结构的行为的表达，在SysML中包括操作（operations ）和接收（receptions）。操作表示一种调用后执行的行为，也就说operations是基于调用事件触发的。一般情况下，operations代表一种同步行为，但SysML并没有对其做严格限制，设计者可以把任何行为定义为操作。

2. System

2.1 System Boundary（系统边界）

系统边界一般在用例图中显示，如下：

通常将用例显示在系统内部，将参与者显示在系统外部。

每个系统角色与角色之间都应设有边界。

2.2 System Requirement(系统需求)

说明系统是一个什么游的系统，用市场上现有的系统来类比，用客户（或是我们自己）需要一个什么样的系统，力求完整。并对系统的发展可扩充性进行描述（现在没有哪个系统是一次OK的吧）。说明与现在已有的系统有什么共同点和不同点，说明未来系统的发展方面以及可移植性等能预见的事情。

系统需求分析包括了项目总述，项目范围，项目进度和限制条件，系统角色与边界，业务流程，性能需求，系统功能需求和非功能需求之类。

2.2 Submachine State(子机状态)

含有子状态的状态被称为组合或嵌套状态

组合状态可以使用“与”关系分解为并发子状态，或者通过“或”关系分解为互相排斥的顺序子状态。

2.3 Internal Transition (内部转换)

转换是两个状态间的一种关系，表示对象将在当前状态中执行动作，并在某个特定事件发生或某个特定的条件满足时进入后继状态。每个转换只允许有一个事件触发，一个事件只允许有一个动作。

转换的五要素：源状态、目标状态、触发事件、监护条件和动作。（触发事件：如果箭头上不带任何事件名，表示是一个自动转换，当与源状态相关的活动完成时就会自动触发）。格式：触发事件（参数）[条件]/动作。

转换的类型

外部转换：对事件做出响应，引起状态变化或自身转换，同时引发一个特定动作，如果离开或进入状态将引发进入转换、离开转换。

内部转换：对事件做出响应，并执行一个特定的活动，但并不引起状态变化或进入转换、离开转换。

进入转换：当进入某一状态时，执行相应活动。

退出转换：当离开某一状态时，执行相应活动。

2.4 Concurrency(并发)

一个并发程序是指能同时执行通常不相关的各种任务。以一个游戏服务器为例子：它通常是有各种组件组成，每种组件都跟外部世界进行着复杂的信息交互。一个组件有可能要处理多个用户聊聊；另外一些可能要处理用户的输入，并把最新状态反馈给用户；其它的用来进行物理计算。这些都是并发处理。

并发程序并不需要多核处理器。

相比之下，并行程序是用来解决一个单一任务的。以一个试图预估某支股票价格在下一分钟波动情况的金融组件为例，如果想最快速度的知道标普500中哪知股票应该卖出还是买进，你不能一个一个的计算，而是将这些所有的股票同时计算。这是并行。

2.5 View(视图)

图是模型元素集的图形表示，通常是由弧（关系）和顶点（其他模型元素）相互连接构成的。而视图是表达系统的某一方面的特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。

视图的分类：

UML是用来描述模型的，用模型来描述系统的机构或静态特征，以及行为或动态特征。从不同的视角为系统构架建模，形成系统的不同视图。

(1) 用例视图(Use Case View)，强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。

(2) 逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也称为结构模型视图(Structural Model View)或静态视图(Static View)。

(3) 并发视图(Concurrent View)，体现了系统的动态或行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。

(4) 组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。

(5) 配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也称为环境模型视图(Environment Model View)或物理视图(Physical View)。

根据图在不同架构视图的应用，可以把9种图分成：

(1) 用户模型视图：用例图；

(2) 结构模型视图：类图和对象；

(3) 行为模型视图：状态图、时序图、协作图和活动图（动态图）；

(4) 实现模型视图：组件图；

(5) 环境模型视图：配置图。

用户模型视图由专门描述最终用户、分析人员和测试人员看到的系统行为的用案组成，它实际上是从用户角度来描述系统应该具有的功能。用户模型视图所描述的系统功能依靠外部用户或者另外一个系统来激活，为用户或者另一系统提供服务，从而实现用户或另一系统与系统的交互。系统实现的最终目标是提供用户模型视图中所描述的功能。在UML中，用户模型视图是由用案图组成。

结构模型视图描述组成系统的类、对象以及它们之间的关系等静态结构，用来支持系统的功能需求，即描述系统内部功能是如何设计的。结构模型视图由类图和对象图构成，主要供设计人员和开发人员使用。

行为模型视图主要用来描述形成系统并发与同步机制的线程和进程，其关注的重点是系统的性能、易伸缩性和系统的吞吐量等非功能性需求。行为模型视图利用并发来描述资源的高效使用、并行执行和处理异步事件。除了讲系统划分为并发执行的控制线程之外，行为模型还必须处理通信和这些线程及进程之间的同步问题。行为模型视图主要供系统开发人员和系统集成人员使用，它由序列图、协作图、状态图和活动图组成。

实现模型视图用来描述系统的实现模块它们之间的依赖关系以及资源分配情况。这种视图主要用于系统的配置管理，它是由一些独立的构件组成的。实现模型视图由构件图组成。其中构件是代码模块，不同类型的代码模块形成不同的构件。实现模型视图主要供开发人员使用。

环境模型视图用来描述物理系统的硬件拓扑结构。例如，系统中的计算机和设备的分布情况以及它们之间的连接方式，其中计算机和设备统称为节点。在UML中环境模型视图是由部署图来表示的。系统部署图描述了系统构件在节点上的分布情况，即用来描述软件构件到物理节点的映射。部署图主要供开发人员、系统集成人员和测试人员使用。

上面每一种视图反映了系统的一个特定方面，不同人员可以单独的使用其中每一种视图，从而可以关注特定的体系结构问题。但在通常情况下，由于系统的最终目标是提供用户模型视图中描述的功能以及其它一些非功能性需求，因此，用户模型视图是其它视图的核心基础，其它视图的构造都依赖与用户模型视图中所描述的类容。

2.6 Containment Hierarchy（包容层次结构）

该任务采用每个系统级用例，然后将其分解为一组子系统级用例。这是在为此目的定义的（新）用例图上完成的。关键关系是用例之间的“包含”关系。你可能还记得从第4章开始，“包含”关系是代表包容性的依赖的刻板印象。也就是说，较大的用例包含了包含的用例。

在用例建模中，仅在以下几种情况下使用«include»关系：

1。为大型系统创建用例抽象/包含层次结构（系统复杂性管理）

2。将大型复杂用例分解为更小巧，更易于使用的用例（用例复杂性管理）

3。提取较小的功能，以供不同用例重用（重用）

4。将系统级用例的一部分分配给子系统（分配）。

在这种情况下，我们专注于最后一个-将系统用例分解为一组子系统用例，以便将所有系统用例需求分配给子系统。

2.7 Requirements Analysis(需求分析)

在软件生命周期中，需求分析（Requirements Analysis）是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量分析软件需求对软件开发往往起到事半功倍的效果，这就是所谓的“磨刀不误砍柴功”。

软件需求分析任务：

即借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。

软件需求分析原则：

软件需求分析过程：

在这一阶段形成的文档包括：

软件需求说明书

数据要求说明书

初步的用户手册

修改、完善与确定软件开发实施计划

软件需求分析方法：

1）结构化分析方法：

用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可

实现的软件为止。

2）Jakson方法：

用来描述数据结构中的顺序，选择和重复。

实现步骤：

3）面向对象开发方法：

三阶段：面向对象分析、面向对象设计、面向对象开发

因为用户的需求在不断变化，所以我们在做需求分析时既要满足当前用户的需求，也要预防用户可能在以后需要到的功能。另外在做需求分析时也要注重用户的参与。

2.8 Requirements Management(需求管理)

需求管理是收集，分析，完善和确定产品需求的优先级，然后计划交付的过程。需求管理的目的是确保组织验证并满足其客户以及外部和内部利益相关者的需求。

需求管理涉及项目团队成员与利益相关者之间的沟通，以及在整个项目过程中对需求变更的调整。为了防止一类需求超越另一个需求，开发团队成员之间的持续沟通至关重要。

需求管理不随产品发布而结束。从那时起，收集有关应用程序可接受性的数据，并将其输入到下一代或发行版的调查阶段。因此，该过程再次开始。

需求是某些工作（在这种情况下为软件开发）的结果应满足的已定义能力。它是产品整个生命周期中的一个连续过程，许多利益相关者都可以产生需求，包括：客户，合作伙伴，销售，支持，管理，工程，运营，当然还有产品管理。当正确地制定和管理需求时，产品团队与工程成员之间将保持清晰，一致的沟通，任何需要的变更都将与所有利益相关者广泛共享。

2.9 Requirements Model(需求模型)

需求模型(RQM) 是一种文档式模型，它通过准确恰当地列出，解释开发过程程中需要实现的功能行为来描述待开发项目。你可以为开发过程中需要使用到的各种结构化技术文档（功能或技术规格说明书，测试计划）而使用需求模型。

2.10 Requirements Specification(需求规格说明)

软件需求规格说明（SRS）是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。 SRS可由来自供方、顾客或双方的一个或多个人员来编写，推荐双方人员联合编写。

SRS编写人员应该关注以下基本点：

功能 - 软件将执行什么功能？

外部接口 - 软件如何与人、系统的硬件及其他硬件和其他软件进行交互？

性能 - 各种软件功能的速度、响应时间、恢复时间等是多少？

属性 - 软件的可用性、可靠性、可移植性、正确性、可维护性、安全性如何？

影响产品实现的设计方案 - 是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？

编写人员宜避免把设计或项目需求写入SRS中。

好的SRS会由这些特征：

SRS宜是，正确，无歧义，完备，一致，重要性和/或稳定性分级，可验证性，可修改，可追踪；
2.当且仅当SRS中的每一项需求都是软件应满足的需求， SRS才是正确的。
3.当且仅当SRS中的每一项需求都只有一种解释，SRS才是无歧义的。
4.当且仅当SRS包含以下元素，SRS才是完备的。所有重要的需求，不论是否与功能、性能、设计约束、属性或者外部接口有关。尤其是由系统规格说明所施加的任何外部需求都应当得到确认和处理。
软件响应的定义。
5.SRS中所有图表的全面标记和索引，以及所有术语和度量单位的定义。
6.任何含有“待定”词语的SRS是不完备的。

2.11 Requirements Source(需求来源)

需求来源主要分为两类，按照房屋出租系统来讲，除了房客对租房由需求之外，还有闲置房屋对自身的有效利用需求，必须要看到需求来源，才能有效的进行需求分析。

2.12 Asynchronous Action(异步动作)

如何使用异步动作：

在工作流程执行期间，Mistral最终会运行操作。动作是与工作流任务相关联的特定功能（或一项工作）。

动作可以是同步的也可以是异步的。

同步动作是在没有第三方的情况下完成的动作，即由Mistral本身完成的动作。当Mistral引擎计划运行同步操作时，它将其定义和参数发送给Mistral执行器，然后执行器运行它，并在完成后将操作结果发送回Mistral引擎。

对于异步操作，执行程序不会将结果发送回Mistral。实际上，异步操作的概念假定执行程序运行它时，结果将不会为人所知。而是假设该操作只会将实际工作委托给第三方，该第三方可以是人为系统或计算机系统（例如Web服务）。因此，异步操作的run（）方法应该只是向能够执行所需工作的对象发送信号。

一旦第三方完成工作，它就有责任通过Mistral API将操作结果发送回Mistral。实际上，第三方只需要更新相应动作执行对象的状态即可。为了使其成为可能，它必须知道相应的动作执行ID。

值得注意的是，从Mistral引擎的角度来看，在同步和异步操作的情况下，架构本质上是相同的。如果动作是同步的，则执行器在动作完成后立即使用RPC机制（通常是消息队列作为传输）将结果发送回Mistral引擎。但是引擎本身并没有主动等待任何东西，它的架构完全基于异步消息。因此，在异步操作的情况下，唯一的变化是执行者不负责发送操作结果，其他事务接管了执行者。

让我们看看使用异步操作时需要记住的内容。

2.13 Structured Analysis(结构化分析)

结构化概念在结构化分析方法中达到了顶峰，该方法目前以多种形式存在。在结构化分析方法中，当前的应用程序系统被捕获在“数据流程图”中。该技术本身主张将逻辑设计和物理实现分开。为此，现有的数据存储被视为旧的物理模型，并从中得出了新的逻辑模型。如果没有以前的系统，则将手动过程视为一个系统进行分析并记录下来。然后，这种新的逻辑设计将重点放在完成了什么而不是如何完成上。

然后可以将更改应用于包含客户所需更改的逻辑模型。更改后的模型将成为甚至更“新”的新模型，并转换为新的物理模型以供实施。由于这种方法对业务问题和程序解决方案之间的关系的演变产生了影响，因此改进了模块化的概念。这种改进使程序模块的结构，模块之间的接口和通信限制以及质量测量变得统一。后来，这段时间中的一些重要发现对于形成面向对象设计的概念根源很有用，我们将在其他地方更详细地介绍这些概念。

2.14 Decision Table(决策表)

一个决策表是各种条件及其相应的行动表。决策树是一个二维矩阵。它分为四个部分，条件存根，操作存根，条件条目和操作条目。请参阅下面列出的第一个图。条件存根显示了各种可能的条件。

决策表-折扣政策

条件条目用于指定要分析的条件。动作存根显示针对不同条件采取的各种动作。

动作条目用于找出对应于一组特定条件采取的动作。

操作语句列出了针对某种可能情况要采取的步骤。动作条目显示在选定条件或条件组合为真时要执行的特定动作。有时会在表下方添加注释，以指示何时使用该表或将其与其他决策表区分开。

该表的右侧列链接条件和动作，并形成决策规则，因此它们陈述了要采取的一组特定动作必须满足的条件。在决策树中，遵循固定的有序序列，在其中检查条件。但是这里不是这种情况，因为决策规则包含所有必需条件，必须为真。

2.15 Software architecture design(软件架构设计)

软件体系结构通常是指软件系统的更大结构，它涉及多个软件流程如何协作执行任务。软件设计是指较小的结构，它处理单个软件过程的内部设计。在本教程结束时，读者将对软件体系结构和设计概念有深入的了解，并可以为给定的软件项目选择和遵循正确的模型。

系统的体系结构描述了其主要组件，它们之间的关系（结构）以及它们之间如何交互。软件体系结构和设计包括几个促成因素，例如业务战略，质量属性，人员动态，设计和IT环境。

体系结构是系统的蓝图。它提供了一种抽象方法来管理系统复杂性，并在组件之间建立通信和协调机制。

它定义了一种结构化的解决方案，可以满足所有技术和运营要求，同时优化性能和安全性等通用质量属性。

此外，它涉及与软件开发有关的一组与组织有关的重要决策，并且这些决策中的每一个都会对最终产品的质量，可维护性，性能和整体成功产生重大影响。这些决定包括：

1.选择组成系统的结构元素及其界面。

2.在这些元素之间的协作中指定的行为。

3.将这些结构和行为元素组成大型子系统。

4.体系结构决策符合业务目标。

5.建筑风格指导组织。

软件设计提供了一个设计计划，该计划描述了系统的元素，它们如何适合以及如何共同满足系统的需求。制定设计计划的目标如下-

1.与系统需求进行谈判，并与客户，市场营销和管理人员建立期望。

2.在开发过程中充当蓝图。

3.指导实施任务，包括详细的设计，编码，集成和测试。

在详细设计，编码，集成和测试之前，在领域分析，需求分析和风险分析之后。

该体系结构的主要目标是确定影响应用程序结构的需求。布局合理的体系结构可减少与构建技术解决方案相关的业务风险，并在业务和技术要求之间架起一座桥梁。

2.16 Architectural design processes(架构设计程序)

架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构设计是软件设计过程的早期阶段，它把需求分析和设计流程连接在一起。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。

所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。

在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。

3. Explanation of terms

3.1 Risk(风险)

风险是指在某一特定环境下，在某一特定时间段内，某种损失发生的可能性。风险是由风险因素、风险事故和风险损失等要素组成。换句话，是在某一个特定时间段里，人们所期望达到的目标与实际出现的结果之间产生的距离称之为风险。

风险由两种定义：

一种定义强调了表现为不确定性；

而另一种定义则强调风险为不确定性。

若风险表现为不确定性，说明产生的结果可能带来损失、获利或是无损失也无获利，属于广义风险，金融风险属于此类。而风险表现为损失的不确定性，说明风险只能表现出损失，没有从风险中获利的可能性，属于狭义风险。

需求分析里也存在着各种各样的风险，例如我们这个房屋出租系统，风险主要是针对自己的投资风险，用户的安全险，房屋的意外险。

3.2 State Machine(状态机)

由于某些动作将其状态从一个改变为另一个的任何设备都被定义为状态机。例如，ATM机，交通信号灯，遥控器，胡算计本身等。大多数应用程序还以来状态并根据状态进行操作。有两种类型的状态机。

1.有限状态机–拥有一组定义的状态的状态机，它们在其中工作。

2.无限状态机–这里的状态可以是很多，并且不能预定义。

最常见的状态机是有限状态机

以下内容共同构成了有效的有限状态机。

State（状态）：

一组定义的状态。在任何时间点，状态机都将处于定义的任何状态。例如，交通信号系统中的红色，绿色和黄色。

State Transition（状态转换）：

将状态机从一个状态更改为另一个状态机称为状态转换。通常，将建立一个状态转换表，其中包含状态序列以及元数据，该元数据说明哪个事件将导致哪个状态转换。

Triggers（触发条件）：

触发器是在状态机中引起状态转换的点。

Events or Actions（事件或动作）：

当达到和退出特定状态时，状态机将执行操作。每个状态都有进入和退出操作。

Guard Condition（守卫条件）：

这是验证过渡并确保不执行无效状态更改的组件。

State Transition（状态转换）：

3.3 Specification(规范)

规范分析：

是指根据一定的价值判断为基础，提出某些分析处理经济问题的标准，树立经济理论的前提，作为制定经济政策的依据，并研究如何才能符合这些标准。它要回答的是“应该是什么”的问题。

特点：

回答“应该是什么”的问题；

分析问题的依据是一定的价值观念；

得出的结论无法通过经济事实进行验证；

3.4 Application Domain(应用程序域)

介绍：

.NET引入了应用程序域或应用程序域的概念。像过程一样，应用程序域既是容器又是边界。.NET运行时将应用程序域用作代码和数据的容器，就像操作系统将进程用作代码和数据的容器一样。由于操作系统使用进程来隔离行为异常的代码，因此.NET运行时使用应用程序域来隔离安全边界内的代码。

一个应用程序域仅属于一个进程，但是一个进程可以容纳多个应用程序域。与过程相比，应用程序域的创建成本相对较低（与流程相比），并且维护开销相对较小。由于这些原因，对于托管数百个应用程序的ISP来说，应用程序域是一个很好的解决方案。每个应用程序都可以存在于隔离的应用程序域中，并且许多应用程序域可以存在于单个进程中节省了成本。

3.5 Quality(质量)

ISO9001:2008 定义：质量为一组固有特性满足要求的程度。

（1）特性：可区分的特征

（2）要求：明示的、通常隐含的或必须履行的需求或期望

质量具有经济性、广义性、时效性、相对性。

产品：

ISO9000:2008 解释：产品是过程的结果。

产品可以分为 4 种类别：硬件、流程性材料、软件、服务或者它们的组合。

影响质量的因素：人、机（设备）、物（材料）、方法、环境

质量目标：在质量方面所追求的目的，是产品和工程质量在一定时间内可达到的水平。

质量成本：将产品质量保持在规定的质量水平上所需的有关费用。

（1）运行时质量成本：保证和提高产品质量支付的费用 + 因质量故障造成的损失费用

（2）外部质量保证成本：为用户提供所要求的客观证据所支付的费用。

质量管理：从技术层面和质量管理的角度去思考产品质量。

3.6 Association Class(关联类)

一个关联类是UML构建体，它使协会具有属性和操作（功能）。这导致具有关联和类别特征的混合关系。

添加关联类连接时，Enterprise Architect还将创建一个自动连接到关联的类。当您隐藏或删除关联时，该类也会被隐藏或删除。

要将关联类添加到类或部署图中，请单击工具箱中的关联类图标。在将线拖动到目标元素的同时，单击并按住图中的源对象，然后释放鼠标按钮。Enterprise Architect绘制连接器并添加类，然后提示您添加类名称。请注意，类和连接器的名称相同。您还可以将新的班级连接到现有的协会。

通过选择关联连接器上的“查找关联类”上下文菜单选项，可以在项目浏览器中突出显示关联类的“类”部分。

如果要将带有Shape Script的构造型应用于关联类，请注意，Shape Script同时应用于Class部分和Association部分。因此，您可能必须在形状主体中包含用于测试元素类型的逻辑，以便可以为类和关联提供单独的绘制指令

• 在以下情况中，不需要这样的逻辑：

• 形状源或形状目标，这些类别或类会忽略它们

• 装饰形状，被关联连接器忽略

• 如果将“类”与“关联”连接器分离，则两个部分都将保持其形状脚本，直到移除构造型为止。

3.7 Association End(关联结束)

一个关联端标识实体类型上的一个端部的关联，并且可以在关联的端部存在实体类型的实例的数目。关联结束定义为关联的一部分；一个关联必须恰好有两个关联结束。导航属性允许从一个关联端导航到另一关联端。

下图显示了具有两个关联的概念模型：PublishedBy和WrittenBy。关联的关联结束PublishedBy是Book和Publisher实体类型。Publisher末端的多重性是一（1），Book末端的多重性是许多（*），表示出版者出版了许多书籍，而一本书由一个出版者出版。

ADO.NET实体框架使用称为概念架构定义语言（CSDL）的领域特定语言（DSL ）来定义概念模型。下面的CSDL定义了PublishedBy上图中所示的关联。注意，类型，名称和每个关联端的多重性是由XML属性（指定的Type，Role和Multiplicity属性，分别地）。有关在一端执行的操作的可选信息在XML元素（OnDelete元素）中指定。在这种情况下，如果删除了出版商，则所有关联的书也将删除。

3.8 Scenario(场景)

场景分析是经常使用的一种反映和评价项目风险的分析方法。场景分析的方法类似于敏感性分析，只是包含了各种变量在某种场景下的综合影响。场景分析一般设定三种情况，即乐观的、正常的及悲观的情景。在不同的场景下，各变量的预期值随着场景的变化而变化。如在悲观的场景下，各变量的预期值都是最悲观的估计，由此得到的净现值和内涵报酬率也是三种情景下最低的。

3.9 Project Change Request(项目变更请求)

概述：

所谓项目变更请求是指项目在执行过程中，对项目计划提出的各种改动要求，比如范围变化、项目预算变更或者进度估算变化等，都需要提出变更申请。

变更请求应该详细说明变更的性质和对项目的影响。记录变更情况和批准变更的主体情况是重要的，以防未来一件分歧。变更请求应输入总体变更控制系统。

变更请求用于追踪所以的涉众请求（包括新特性、扩展请求、缺陷、已变更的需求等）以及整个项目生命周期中的相关状态信息。将用变更请求来保留整个变更历史，包括所有的状态变更以及变更的日期和原因。进行重复审和结束项目时都可使用此信息。

形式：

变更请求的提出可以是书面形式的或口头形式的，也可以直接方式的或间接方式的。变更请求的提出可以是来自外部的，也可以是来自内部的，可以是自愿的也可以是*的，变更的内容可以是延长工期的，也可以是缩短工期的。

3.10 Maintainability(可维护性)

软件可维护性的五个子特性：

(1)易分析性：软件产品诊断软件中的缺陌或失效原因或识别待修改部分的能力。

(2)易改变性：软件产品使指定的修改可以被实现的能力，实现包活编码、设计和文档的更改，如果软件由最终用户修改，那么易改变性可能会影响易操作性。

(3)稳定性：软件产品避免由于软件修改而造成意外结果的能力。

(4)易测试性：软件产品使已修改软件能被确认的能力

(5)维护性的依从性：软件产品遭循与维护性相关的标佳或约定的能力。

3.11 Constraint(约束)

在Oracle中，可以通过设置约束来防止无效数据进入表中。Oracle一共有5种约束：主键约束（primary key）、外键约束（foreign key）、唯一性约束（unique）、非空约束（not null）、检查约束（check）。

（1）主键约束

主键约束可以定义在一列或多列上，值具有唯一性、非空性；

在一个表上只能定义一个主键约束；

Oracle会自定在主键约束的列上创建唯一性索引，可以指定唯一性索引的位置及存储参数。

（2）外键约束

外键约束列的取值来源于参照表（父表）的参照列的值，或者空值；

定义外键约束的列只能参照父表的主键约束列和唯一性约束列；

父表与子表必须在同一个数据库中。

（3）唯一性约束

可定义在一列或多列上，列的取值必须唯一；

如果在某些列上定义了唯一性约束，而没有定义非空约束，那么在这些列上可以出现多个空值；

Oracle会自定在主键约束的列上创建唯一性索引，可以指定唯一性索引的位置及存储参数。

（4）非空约束

只能定义在列上；

在同一个表中可定义多个非空约束。

（5）检查约束

检查约束用来限制列的取值范围，其表达式必须引用相应列，表达式的计算结果是一个布尔值；

一个列可以定义多个检查约束。

3.12 Interface specification(接口规格)

标准接口在系统设计过程中发挥着重要的作用，可为设计实现互操作性与低成本，并减少设计所需的时间，但对需要实现产品差异化的设计团队而言，其实用性仍然很用限。设计人员还应依赖芯片厂商为其提供各种多组合标准接口。对芯片厂商而言，可帮助高效实施接口的高质量软件是实现差异化的其它因素。提供更高级别的灵活性也非常有帮助，能够通过TIPRU与UPP等可配置接口获得。系统设计人员利用其工具套件中的这些选项，即可发挥创造性，同时又能保持组件的低成本。

4. Model

4.1 Logical Model(逻辑模型)

逻辑模型是构成设计/分析空间的对象和类的静态视图。通常，域模型是业务对象和实体的较宽松的高级视图，而类模型是更严格且注重设计的模型。该讨论主要涉及类模型。

The Class Model类模型：

类是一种标准的UML构造，用于详细说明在运行时将根据其生成对象的模式。类是一种规范-对象是类的实例。类可以从其他类继承（即，它们继承其父类的所有行为和状态并添加自己的新功能），具有其他类作为属性，将职责委派给其他类并实现抽象接口。

类模型是面向对象的开发和设计的核心-它表示系统的持久状态和系统的行为。类封装状态（属性）并提供服务以操纵该状态（行为）。良好的面向对象设计限制了对类属性的直接访问，并提供了代表调用者操纵属性的服务。数据的这种隐藏和服务的公开确保了仅在一个地方并根据特定规则进行数据更新-对于大型系统，在许多地方可以直接访问数据元素的代码的维护负担非常高。

该类表示如下：

该类具有三个不同的区域：

1.类名（和原型（如果有的话））

2.类属性区域（即内部数据元素）

3.行为-私人和公共

属性和方法可以标记为：

1.不公开，表示班外的呼叫者看不到它们

2.受保护，它们仅对班级的孩子可见

3.公开，所有人都看得到

Inheritance遗产：

类继承如下所示：在这种情况下，抽象类是两个子代的父代，每个子代都继承基类的功能并以自己的行为对其进行扩展。

可以将类模型收集到相关行为和状态的程序包中。下图说明了这一点。

4.2 Dynamic Model(动态模型)

动态模型用于表达和建模系统随时间的行为。它包括对活动图，状态图，序列图和扩展

Sequence Diagrams（顺序图）：

顺序图用于显示系统内用户，屏幕，对象和实体之间的交互。它提供了对象之间随时间传递的消息的顺序映射。通常，这些图放置在模型中的用例下，以说明用例场景-用户将如何与系统交互以及内部将发生什么事情以完成工作。通常，对象使用特殊的构造型图标表示，如以下示例所示。使用用户界面图标显示标记为登录屏幕的对象。标有SecurityManager的对象使用Controller图标显示。使用实体图标显示标记为用户的对象。

Activity Diagrams（活动图）：

活动图用于显示系统中不同工作流的构建方式，如何开始工作以及可能从头到尾采取的许多决策路径。它们还可以说明在执行某些活动时并行处理可能发生的位置。

State Charts（状态图）：

状态图用于详细说明对象在系统中可以通过的状态的转换或更改。它们显示了对象如何从一种状态移动到另一种状态，以及控制该变化的规则。状态图通常具有开始和结束条件。

Process Model（过程模型）：

过程模型是活动图的UML扩展，用于对业务流程进行建模-该图显示了流程的目标，流程中涉及的输入，输出，事件和信息。

4.3 Component Model(组件模型)

组件模型说明了将用于构建系统的软件组件。这些可以从类模型构建，并从头开始为新系统编写，也可以从其他项目和第三方供应商处引入。组件是较小的软件片段的高级集合，并为软件构建提供了“黑匣子”构建块方法。

Component Notation（组件符号）：

组件可能类似于ActiveX控件-用户界面控件或业务规则服务器。组件绘制如下图所示：

The Component Diagram（组件图）：

组件图显示了软件组件之间的关系，它们的依赖关系，通信，位置和其他条件。

Interfaces（接口）：

组件也可能公开接口。这些是组件正在宣传的可见入口点或服务，并可供其他软件组件和类使用。通常，组件由许多内部类和类包组成。它甚至可以由一组较小的组件组装而成。

Components and Nodes（组件和节点）：

部署图说明了系统在生产（或测试）环境中的物理部署。它显示组件将位于何处，在什么服务器，机器或硬件上。它可能会说明网络链接，LAN带宽等。

Requirements（需求）：

组件可能附带要求以表明其合同义务，他们将在模型中提供什么服务。需求帮助记录软件元素的功能行为。

Constraints（约束条件）：

组件可能附带约束，这些约束指示组件在其中运行的环境。前提条件指定在组件可以执行某些功能之前必须满足的条件；后置条件指示在组件完成某些工作后将是什么，不变式指定在组件生命周期内必须保持为真的情况。

Scenarios（场景）：

场景是随着时间的推移对象的动作的文本/过程描述，并描述了组件的工作方式。可能会创建多个场景来描述基本路径（完美运行）以及异常，错误和其他情况。

Traceability（可追溯性）：

您可以通过实现链接指示可追溯性。组件可以实现另一个模型元素（例如，用例），或者组件可以由另一个元素（例如，类的包）来实现。通过提供与组件之间的实现链接，您可以映射模型元素之间的依赖关系以及从初始需求到最终实现的可追溯性。

Security Components（安全组件）：

安全组件图显示了诸如证书颁发机构，浏览器，Web服务器和其他模型元素之类的安全软件如何协同工作，以确保所提议系统中的安全性规定。

4.4 Business Process Model(业务流程模型)

传统上，UML与软件工程和系统设计的关联多于与业务流程的分析和建模的关联。但是，标准的UML 2.x提供了丰富的行为模型集，这些模型对于建模对每个业务至关重要的流程，活动，人员和信息非常有用。

除了标准的UML表示法以外，还存在两个受人尊敬且经过验证的UML“扩展”，它们进一步增强了对业务流程和相关结构的捕获。第一个是业务流程建模表示法（BPMN），它已经获得了极大的普及，并且正迅速成为用于建模和设计业务流程的新标准。第二个是爱立信-彭克（Ericsson-Penker）配置文件，该配置文件不那么受欢迎，但是仍然提供了一种独特而强大的方法来可视化和交流业务流程以及组织内必要的信息流。

Business Process Modeling Notation (BPMN)（业务流程建模符号

）：

BPMN定义了业务流程图（BPD），该流程图基于为创建业务流程操作的图形模型而量身定制的流程图技术。从创建流程初稿的业务分析人员到负责实施将执行这些流程的技术的技术开发人员，再到将要执行此流程的技术人员，所有业务用户都可以轻松理解该符号。管理和监视这些过程。

BPMN模型由带有少量图形元素的简单图组成。

上图显示了一个事件正在启动的过程-在这种情况下，是一个消息触发的开始事件，该事件通知该过程工作组处于活动状态。该图还显示了一个由计时器事件控制的循环，并显示了一个控制网关（在这种情况下为XOR决策网关），该循环控制何时终止循环。

此图说明了使用池显示交互过程以及使用消息流连接器在池之间传递消息的方式。

流程模型：

业务流程是旨在为特定客户或市场产生特定输出的活动的集合。与产品对流程是什么的关注相反，这意味着要特别强调组织内部工作的完成方式。因此，跨时间和地点的工作活动的特定顺序，包括开始，结束以及明确定义的输入，输出和操作结构。

来自对象信息的供应链接。供应链接指示链接到流程的信息或对象在处理阶段没有用完。例如，可以反复使用订单模板来提供某种样式的新订单-模板不会作为此活动的一部分被更改或用尽。

来自对象Resource的输入链接。输入链接指示在处理过程中消耗了附加的对象或资源。例如，在处理客户订单时，它们会完成并签署，并且通常每个唯一资源（订单）仅使用一次。

目标链接到目标Goal。目标链接指示业务流程的附加对象描述了流程的目标。目标是执行活动的业务理由。

对象流链接到对象输出

事件Event的对象流链接。对象流链接指示某个对象已传递到业务流程中。它捕获控制权到另一个实体或过程的传递，以及状态或信息从活动到活动的隐含传递。

4.5 Physical Model(物理模型)

物理或部署模型提供了跨系统基础架构部署组件的详细模型。它详细介绍了网络功能，服务器规格，硬件要求以及与部署建议的系统有关的其他信息。

Deployment View（部署视图）：

Physical Model（物理模型）：

物理模型显示了在何处以及如何部署系统组件。它是系统物理布局的特定图。部署图说明了系统在生产（或测试）环境中的物理部署。它显示组件将位于何处，在什么服务器，机器或硬件上。它可能会说明网络链接，LAN带宽等。

节点用于描述用于将组件部署到生产环境中的任何服务器，工作站或其他主机硬件。您还可以指定节点之间的链接，并为它们分配构造型（例如TCP / IP）和要求。节点可能还具有记录的性能特征，最低硬件标准，操作系统级别等。下面的屏幕说明了可以为节点设置的常见属性。

4.6 Context Model(上下文模型)

对于某一类错误，模型学习目标词上下文的向量表示，然后通过上下文的向量预测该目标词。如果预测结果不同于原始目标词，原词被标记为错误，预测结果用作校正。我们的深层上下文模型使用双向GRU，它是基于context2vec的体系结构。句子的上下文表示可以是从句子的开头到目标词，也可以从句子结尾到目标字，也可以是固定窗口大小的上下文

4.7 Entity-relationship Model(实体关系模型)

用来描述现实世界的概念模型。E-R方法是“实体-联系方法”（Entity-Relationship Approach）的简称。它是描述现实世界概念结构模型的有效方法。

实体联系模型，实体关系模型或实体联系模式图(ERD)是由美籍华裔计算机科学家陈品山(Peter Chen)发明，是概念数据模型的高层描述所使用的数据模型或模式图，它为表述这种实体联系模式图形式的数据模型提供了图形符号。这种数据模型典型的用在信息系统设计的第一阶段；比如它们在需求分析阶段用来描述信息需求和/或要存储在数据库中的信息的类型。但是数据建模技术可以用来描述特定论域（感兴趣的区域）的任何本体（对使用的术语和它们的联系的概述和分类）。在基于数据库的信息系统设计的情况下，在后面的阶段（通常叫做逻辑设计），概念模型要映射到逻辑模型如关系模型上；它依次要在物理设计期间映射到物理模型上。注意，有时这两个阶段被一起称为"物理设计"。

基本要素：

通常，使用实体-联系图(entity-relationship diagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。ER图中包含了实体(即数据对象)、关系和属性等3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。例如，图1是某学校教学管理的ER图。

人们通常就是用实体、联系和属性这3个概念来理解现实问题的，因此，ER模型比较接近人的习惯思维方式。此外，ER模型使用简单的图形符号表达系统分析员对问题域的理解，不熟悉计算机技术的用户也能理解它，因此，ER模型可以作为用户与分析员之间有效的交流工具。

实体型(Entity)：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体;在E-R图中用矩形表示，矩形框内写明实体名；比如学生张三丰、学生李寻欢都是实体。如果是弱实体的话，在矩形外面再套实线矩形。

属性(Attribute)：实体所具有的某一特性，一个实体可由若干个属性来刻画。在E-R图中用椭圆形表示，并用无向边将其与相应的实体连接起来；比如学生的姓名、学号、性别、都是属性。如果是多值属性的话，再椭圆形外面再套实线椭圆。如果是派生属性则用虚线椭圆表示。

联系(Relationship)：数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下 3 种类型：

(1) 一对一联系 (1 ∶ 1)

例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

(2) 一对多联系 (1 ∶ N)

例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教【见图1】。

(3) 多对多联系 (M ∶ N)

例如，图1表示学生与课程间的联系(“ 学 ”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。联系也可能有属性。例如，学生 “ 学 ” 某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于 “ 成绩 ” 既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系 “ 学 ”的属性.

4.8 Static model(静态模型)

OOA和OOD活动都使用静态模型。下图中显示了另一个静态视图，用于说明对象分解，并提供了有关ATM Machine对象的更详细的视图。描述了ATM机与客户显示，交易和打印机组件之间的整体关系的汇总。继承与现金提取和支票存款一起显示为父交易的派生对象。

静态模型的另一种形式是如下图所示的模块架构图。这用于OOD阶段，并说明静态体系结构实体及其接口。每个设计图标都描述了用于与封装在图标边界内的对象之间收发消息的接口。可以通过连接对象的线上的箭头方向指示消息流。

4.9 状态机模型(State machine model)

状态机模型：要求设计者要考虑所有可能的状态，以及所有可能输入条件下可能进行的所有状态转移。

时序程序模型：它是通过一系列可重复执行或有条件执行的指令来变换数据的。状态机模型在许多场合中用来描述效果更好。因为用状态机来进行描述提供了更自然的计算方法。

5. Know Of Requirement

5.1 What is the requirement?

1.用户为了解决问题或达到某些目标所需要的条件或能力。

2.系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的的要求而需要具备的条件或能力。

3.对（1）或（2）中的条件或能力的一种文档化表述。

5.2 Meet requirements is solving problems

1.问题与需求

人们开发软件系统的目的就是希望用它作为解决方案来解决问题,使得现实改善到期望的状况。解决问题、改善现实、满足用户期望的条件与能力就是需求。

2.问题域：要解决问题，就需要改变现实中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。这些实体和状态构成了问题解决的基本范围，称为该问题的问题域。

3. 解系统：软件系统通过影响问题域帮助人们解决问题，称为解系统。

4. 共享现象：软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。问题域中的某些信息能够和模型中的信息建立映射关系，这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象。

5. 需求规格说明：解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。

6. 约束：问题域中有些特性完全不受共享现象（解系统）的影响，同时却可能很大程度上影响共享现象、解系统，甚至关乎解系统的成败。这些特性被认为是解系统对环境的依赖特性。特性非常明确时，称为约束；特性不明确时，称为假设。

图：问题域、需求、解系统、需求规格说明关系示意图

5.3 Requirements and problems are hierarchical

图：需求的层次性

1.业务需求：是抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标。它描述了组织为什么要开发系统。

2.用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。

3.系统级需求：用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求。系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。

正确处理用户需求和系统级需求，明确其不同点：用户需求——任务；系统级需求——交互文本方式描述系统级需求，图像方式描述用户需求。可以说，系统级需求是专业人员对用户需求的一种功能性细分，以更具条理性的文本描述了如何实现用户需求。

图：不同抽象层次需求之间的联系

5.4 Classification and expression of requirements

1. 需求可以分为：项目需求、过程需求、硬件需求、人力需求（其他）。

2. 功能需求：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。

3. 性能需求：速度、容量、吞吐率、负载、实时性

速度：系统的响应时间。PR1：所有的用户查询都必须在10秒内完成。

容量：系统所能存储的数据量。PR2：系统应该能够存储至少10万条销售记录。

吞吐量：系统在连续的时间内完成的事务数量。PR3：解释器每分钟应该至少解析5000条没有错误的语句。

负载：系统可以承载的并发工作量。PR4：系统应该允许200个用户同时进行正常的工作。

实时性：严格的实时要求。PR5：监测到病人异常后，监控器必须在0.5秒内发出警报。

4. 质量属性：可靠性、可用性、可维护性、可移植性、安全性、易用性

可靠性（Reliability）：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力。

可用性（Availability）：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率。

易用性（Usability）：与用户使用软件所花费的努力及其对使用的评价相关的特性。

5. 对外接口：解系统和其他系统之间的软硬件接口。

6. 约束：系统开发运行环境、问题的相关标准（法律法规、行业规定、企业规章等）、商业规则。

7. 其他：安装需求、数据需求等。

5.5 Characteristic

1．完备性：优秀的需求是完备的，它不需要做更多的扩展就可以充分说明用户需要的系统功能。完备性的判断标准是：需求是否描述了开发人员设计和实现这项功能所需的所有信息。只有完备的需求在开发中才可能被独立出来，单独对待。在需求开发过程中，对于不清晰的信息可以标记为TBD( To Be Determined，待确定)，但在需求开发结束之前，所有的TBD都必须被解决。

2．正确性：每一项需求都必须正确描述所需要的系统功能要真实反映用户的意图，所以需求的正确性又常被称为真实性。需求的正确性只有提出需求的人才能加以判断，所以需求在传递给开发人员之前，必须请需求的提出者予以确认。

需求正确性难以达到的主要原因有以下两方面。

①用户在表达自己的需要时，可能会在潜意识下进行一定的加工。常见的情况是：用户的问题是A，但用户认为如果提供了方法B，则问题A自然可以得到解决，为此用户向需求工程师反映的便是B，而不是真实的A。所以为了发现用户的真实需求，需求工程师一定要进行问题分析，尽力发现问题背后的问题

②在人际交流中，信息会发生自然衰减，甚至扭曲，导致需求工程师理解的并非是用户所表达的。对此情况的解决方法是在需求传递给开发人员之前，请提出需求的用户进行仔细检查和确认。

3．可行性：需求必须能够在系统及其运行环境的已知条件和约束下实现。用户无法判断需求的技术可行性，所以需求的可行性是由开发人员进行检查的。在检查的过程中，开发人员可能需要进行定的分析和研究，而不是单纯地凭借经验和直觉。对于难以判断的需求，必要时要通过开发原型来加以验证。

不可行的需求又被称为不切实际的期望( unrealistic expectations)，是实践中常见的需求定义问题，而且它在很大程度上影响着项目的成败。

因为用户并不掌握关于软件系统构建的相关技术知识，所以用户可能会提出一些已有软件

技术无法实现的期望，或者在限定的项目环境下固执地要求不可能同时满足的多项要求，这通常是不切实际的期望的来源。面对不切实际的期望，要求软件开发者提供可行性、成本等足够的技术参考信息，帮助用户对其进行取舍和调整。

4．必要性：每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的资源。

不必要的需求也是实践中常见的一个问题，可能因为多种原因而出现：

①用户将之作为和开发人员谈判的筹码，然后通过自己对不必要需求的进退取舍而在和开

发人员的谈判中取得真正想要的利益，如金钱。对此问题，唯一需要的就是开发人员代表的谈判技巧。

②用户在交流中总是害怕信息有所遗漏，并因而产生不利后果，因此用户总是倾向于表达

各种各样的需要。要解决这个问题，就需要开发人员在进行用户需求的获取之前先定义明确的业务需求，然后根据业务需求进行用户需求的过滤和选择。

③需求开发人员“画蛇添足”，添加“用户肯定会喜欢”的功能，该类功能既会造成项目额外的耗费，又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用户为中心。开发人员尤其需要注意该事项。

5.无歧义：需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有而且只能有一种解释，即需求无歧义。为了让需求可理解，一般倾向于以用户的语言描述需求，而用户的语言往往含有大量容易导致歧义的因素，因此在保证需求描述的无歧义时要格外注意需求描述中的词汇选择，通常在需求开发中要定义一个可以共同理解的词汇表( glossary)，然后再在其基础上进行需求的描述。

模糊和歧义也是实践中常见的需求错误类型，它多数是被无意写出的，少数情况下也可能被有意写出。

无意中写出模糊和歧义的需求定义往往是因为选词造句不当，导致不同的人对同一项需求产生了不同的理解。[ Wiegers2003建议在描述需求时避免使用表2-5内的词汇，以防止需求描述出现歧义。

5.6 Content and work of requirement analysis stage

需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。具体分为功能性需求、非功能性需求与设计约束三个方面：1．功能性需求，功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。2．非功能性需求，作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。3．设计约束，一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。

需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。制订规格说明书：即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。评审：对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。

6. Summary and experience

需求分析的唯一角度是用户，而不是其他；
需求分析的所有工作是围绕着得出一个合理的系统需求而展开的；
需求分析的三部曲是：需求获取、需求分析、需求建模。获取中有分析，分析时需建模，需求不完整是再获取；
需求分析的工作方式应是：边调查，边记录，边分析，边画图，边描述，边审核；
需求是从用户的业务中捕获的，其目的是尽可能全面、深入地了解用户对系统的要求；
应正确的划分系统的范围，范围之内为系统，范围之外为系统的环境；
确定系统外部与系统联系的业务角色，业务角色可以使人，也可以是外部其他系统，业务角色用小人表示
应根据业务的相关性把整体系统划分成为多个职能域，已确定系统需求的结构框架，用包图来描述需求结构；
功能分析是需求分析的重点，用例图表示职能域中一组相关的功能。复杂的功能可以分解为子功能，用例分解不宜太细。每一个用例应该给予说明；
用户界面对确定需求有帮助，可以确定界面信息的要素，界面风格和格式的设计可以留到设计阶段；
在描述需求时，应该捕捉业务对象。业务对象如果有复杂的状态，可以用状态图来描述；
需求需要进行评审，评审应作为质量活动贯穿在需求分析的过程中，所有需求均应进行评审；
需求是一种创新。需求来自客观实际，但一定高于实际；
很多需求是启发出来的，因此不要期望在一个有限的时段，会把所有需求完全搞清楚，在系统开发的各个阶段，变更需求是正常的；
需要高度重视需求分析工作，并要求在需求分析阶段把系统的核心的、关键的、大量的需求确定了；
需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
确定问题难。主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。
需求难以进行深入的分析与完善。需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。