第四章 软件需求工程

第四章 软件需求工程

1. 软件需求

需求：系统必须符合的条件或能力

软件需求：用户对目标软件系统在功能、行为、性能、设计约束等方面的期望

软件需求的内容 FURPS+：

• Functionality 功能性：特性、功能和信息安全性
• Usability 易用性：用户学习和操作软件的容易程度
• Reliability 可靠性：软件在规定时间/条件下无错运行的概率
• Performance 性能：软件运行的速度、效率
• Supportability 可支持性：软件易于修改和维护的能力
• “+” 补充需求：
  • 设计约束：规定或约束了系统的设计的需求
  • 实现需求 ：规定或约束了系统的编码或构建，如技术标准、编程语言、数据库完整性策略、资源限制和操作环境
  • 接口需求：规定了系统必须与之交互操作的外部软件或硬件，以及对这种交互操作所使用的格式、时间或其他因素的约束
  • 物理需求：规定了系统必须具备的物理特征，可用来代表硬件要求，如物理网络配置需求
  • 社会、健康、安全、法律及文化对软件的约束。

以下为包含内容/指标/判断方法

2. 软件需求的层次

软件需求包括两个层次：

1. 软件概要需求：记录在前景文档（需求获取阶段）中，用于刻画关键的用户需要和系统特性。
2. 软件详细需求：记录在软件需求规约文档（需求定义阶段）中，用于描述详细的功能需求、非功能需求和约束条件。
   

&优秀的需求具有的特性（了解）

需求无二义性它只有一个解释

需求可验证性可以用人工或机器方式检查产品是否满足需求

3. 软件需求工程的5个阶段

3.1 需求获取

• 分析业务问题，确定软件系统边界。
• 通过与干系人交流、已有系统参考等获取干系人需求。
• 通过软件高层特征分析形成前景文档，明确概要需求。
• 制定项目术语表。

需求获取阶段的主要成果为前景文档、术语表和一组详细的干系人需求。

3.2 需求分析（关注What ，Not How）

对需求进行分析，并进行可视化建模，形成分析模型（平台无关模型PIM）

分析模型达到的三个主要目标：

1. 描述客户的需要。
2. 建立创建软件设计的基础。
3. 定义在软件完成后可以被确认的一组需求。

分析建模方法

1. 面向对象分析
2. 结构化分析
3. ……

需求分析阶段的主要成果为分析模型。

3.3 需求定义

撰写详细的软件需求规约，开发用户界面原型。

3.3.1 软件需求规约

在概要需求（即前景文档）和分析模型的基础上，对需求调查得到的大量项目干系人需求进行分析，我们可以定义出详细的软件需求规约（SRS）。

软件需求规约 (SRS) 定义了系统的外在行为和属性。

• 细化功能需求 F
• 细化非功能需求 URPS
• 细化约束条件 +
• 设计用户界面和接口

3.3.2 用户界面原型

界面原型为静态的，包括主要界面和界面上的主要元素。

可以通过图纸手绘，绘图工具或可执行代码（直接HTML编程，不要关注太多的界面设计细节）。

用户界面原型是一种有效的需求工具，它可以用来明确并完善需求，发现和解决需求中的二义性，消除在需求理解上的差异。

需求定义阶段的主要成果为软件需求规约。

3.4 需求验证

需求（包括前景文档、分析模型和软件需求规约等）是否如实反映了客户的真正需要必须反复验证，在需求工程中常用的需求验证手段有需求评审和原型确认两种。

• 需求评审：

  • 评审需求文档（Vision和SRS等），及时发现缺陷，寻找改进的契机，同时从评审反馈中获得知识，补充了正规的交流和培训机制，帮助团队建立对产品的共同理解。
  • 按照四个阶段进行
    • 计划阶段
    • 实施阶段
    • 改进阶段
    • 结束阶段

  

• 原型确认（按照用途分）

  • 抛弃型原型确认：用来一次性地确认用户需求，原型的代码不再包含在最终产品中。
  • 演进型原型确认：是以迭代的方式快速实现部分界面或功能并对需求不确定部分加以检验。不会被抛弃，而是会不断被精化直至融入最终产品。

需求验证阶段的主要成果为软件需求基线。

3.5 需求管理（贯穿项目始终）

需求管理是指建立并维护在软件工程中与客户达成的契约。这种契约包含在编写的需求规约文档与分析模型中。

主要活动包括：

1. 定义需求基线，明确本项目实现哪些功能或非功能需求。

根据项目资源，按照优先级选定需求，形成书面的需求文档。通过评审，达成共识，形成需求基线。

2. 需求变更控制和版本控制（建立新的需求基线）。

每次需求变更后，生成新的版本。经过审核，形成新的基线。这些版本应采用版本控制工具。将变更通知到每个涉及到人员。保证项目组成员拿到正确的需求版本。

3. 需求跟踪。软件开发过程中进行需求跟踪，保持项目计划与需求一致，并了解需求的状态。

4. UML图

从前慢-UML CSDN博客

UML 统一建模语言 Unified Modeling Language，是第三代面向对象的开发方法，是一种基于面向对象的可视化的通用建模语言。

UML的特点：

1. 面向对象
2. 可视化，表示能力强
3. 独立于过程
4. 独立于程序设计语言
5. 易于掌握和使用
6. 统一标准

UML基本模型元素：

需求阶段涉及用例图、活动图、类图、时序图、通信图和包图。

设计阶段涉及类图、时序图、通信图、状态机图、构件图、部署图和包图。

4.1 用例图

用例图是一种用于描述系统功能需求，展示系统与外部用户（或其它系统）之间的交互。

用例图主要包括一组执行者（actor）、一组用例（use case）以及它们之间的关系。

4.1.1 执行者

执行者通常称为用户或者角色，执行者不一定是一个人，执行者表示的是和系统进行交互的所有外部系统，包括人、其他软件系统和设备等。执行者位于系统外，在UML中通常以一个稻草人图符来表示。

4.1.2 用例

用例是用户与计算机之间的一次典型交互作用，描述的是系统提供给用户的一个完整的功能。在UML中用例被定义成系统执行的一系列动作，用椭圆表示用例。

• 基础用例：是相对于扩展用例和包含用例而言的核心概念，描述了系统的主要功能流程或基础业务逻辑。
  • 独立描述系统核心功能的用例，无需依赖其他用例即可完成一个完整的业务操作；
    例：“用户提交订单” 是基础用例，无论是否包含 “支付”（包含用例）或扩展 “订单取消”（扩展用例），其核心流程（选择商品、填写地址、提交）是完整的。
  • 可以被扩展或包含的用例，是扩展关系（<< extend >>）和包含关系（<< include >>）中的 “基础” 对象；在扩展关系中，基础用例是被扩展的对象（扩展用例 → 基础用例）；在包含关系中，基础用例主动包含其他用例（基础用例 → 包含用例）。
  • 通常对应用户的主要目标（如 “用户登录”“创建订单”“查询信息”）。
• 被包含用例（基础用例的必须组成部分）
• 扩展用例（基础用例中添加的额外的功能，是可选的增强功能）

4.1.3 关系

关系：用例图中，执行者和用例、用例和用例之间、执行者和执行者之间的联系。

• 执行者和用例之间的关系只有一种：关联。关联用执行者与用例之间的连线来表示。

  执行者触发了用例之后，与用例进行信息交换，用例在完成相应功能之后，向执行者返回结果。

  

• 用例和用例之间的关系有三种：包含、扩展和泛化。

  • 包含是指其中一个用例（基础用例）的行为包含了另一个用例（被包含用例）的行为。包含关系用一条带箭头的虚线和<< include >>表示，箭头由基础用例指向被包含用例。

    若A包含B，记为A-------<< include >>------->B，A 的执行过程中必然会触发 B 的功能，B 是 A 的一部分，没有 B 则 A 无法完整执行。

    被包含用例是基础用例的必须组成部分。

    包含关系解决的是公共行为复用的问题。

    

  • 扩展是指在一个用例（基础用例/被扩展的用例）中增加一些新的动作然后构成了另一个用例（扩展用例/生成的新的用例）。扩展用一条带箭头的虚线和<< extend >>表示，箭头由扩展用例指向基础用例。

    

  • 泛化即继承关系，用一条带空心三角箭头的实线表示，从子类指向父类。

    

• 执行者与执行者之间的关系只有一种：泛化，同上。

4.2 类图

类是面向对象系统组织结构的核心。

类图（class diagram）是用类和它们之间的关系描述系统的一种图示，是从静态角度表示系统的，因此类图属于一种静态模型。

• 类图的两个基本元素是类以及类之间的关系。
• 定义系统中的类，表示类之间的联系，也包括类的内部结构（类的属性和操作）类图所描述的静态关系，在系统的整个生命周期都是有效的。
• 类图是构建其他图的基础，没有类图，就没有状态图、协作图等其他图，也就无法表示系统的其他各个方面。

类的多重性说明了有多少个实例可以存在，通常情况下，可以有多个（零个或多个，没有明确限制），但在执行过程中一个实例只属于一个类。

4.2.1 类

类定义了一组有着状态和行为的对象。属性和关联用来描述状态。个体行为由操作来描述，方法是操作的实现。

在UML图中，类的表示为一个矩形，由带有类名、属性和操作的分格框组成。

UML定义了四种类型的可见性：

• public（+）
• protected（#）
• private（-）
• package（~）

4.2.2 抽象类

包含抽象操作的类称为抽象类。抽象类一般至少包含一个抽象操作。

抽象操作是指在声明该操作的类中没有该操作的代码实现。

在UML中，抽象类也用矩形框表示，但是类名以及抽象操作都用斜体字表示，非抽象操作不用斜体表示。

4.2.3 继承/泛化

继承关系表示一个类（子类/派生类）是另一个类（父类/基类）的特殊类型，子类继承了父类的属性和方法。继承关系是一种"is-a"关系，即子类是父类的一种特殊情况。

泛化关系表示一个类（子类）是另一个类（父类/接口）的一种特殊形式，子类继承了父类/接口的行为和结构。泛化关系通常用于表示类与接口之间的关系，或者类与抽象类之间的关系。

在UML类图中，继承关系和泛化关系的表示方式是相似的，用一条带空心三角箭头的实线表示，箭头从子类指向父类，但是它们所表示的语义略有不同。继承关系更强调类之间的“是一种”关系，泛化关系更强调类之间的一般化与特殊化的关系。(继承一般是子类继承普通类或抽象类，泛化一般是子类继承抽象类或实现接口)。

4.2.4 关联

两个相对独立的类，当一个类的实例与另外一个类的特定实例存在固定关系时，这两个类之间就存在关联关系。

在UML中，类之间的关联关系用实线箭头来表示。关联的两个连接点叫关联端，关联端可以设置名字（角色名）、可见性和基数等特性（选写）。基数是指连线两端的数字，表明这一端的类可以有几个实例。

根据导航箭头，关联可以分为单向关联和双向关联。

• 单向关联—>，两个类相关，但只有一个类知道这种联系的存在，车—>人 即车有确定的主人，但人不确定车。（一个类中包含另一个类的属性或引用）
• 双向关联—，无箭头实线，但表示双箭头，表示两个类彼此知道对方。（两个类中互相包含对方的属性或引用）

特殊的关联（部分与整体关系的关联）

• 聚合关系，整体与部分生命周期独立，发生聚合关系的两个类独立存在。在 UML中用带有空菱形的实线表示，空菱形与聚合类（整体）相连接，指向部分。

  例：

  1. 车队 -> 车
  2. 图书馆 -> 书
  3. 公司 -> 员工
  4. 整体 ->部分

  以上 车队，图书馆，公司都是聚合关系中的聚合类，当“部分”与“整体”分离时，“部分”不会消亡，车队解散，车还在。

• 组合关系，更强形式的聚合，整体有管理部分的特有的职责，整体消亡时部分随之消亡。在UML中用带有实菱形的实线表示，空菱形与整体相连接，指向部分。

  例：

  1. 图形界面 -> 按钮
  2. 汽车 -> 轮胎
  3. 整体 -> 部分

  当“整体”消亡时，“部分”也会消亡。

4.2.5 依赖

当一个类的行为或实现影响了另一个类时，这两个类之间就存在依赖关系。

依赖关系表示两个模型元素之间存在的一种语义关系，被依赖着的某些变化会要求或只是依赖着随之发生变化。

在UML中，依赖用一个从依赖者指向被依赖者的虚线箭头表示（依赖者------<< … >>------->被依赖者），用一个衍型（stereotype）的关键字来区分它的种类。

依赖关系除了用于类之间，也可用于其他模型元素之间，例如设计模型依赖于分析模型，一个包依赖于另一个包，一个类或构件依赖于一个接口，等等。

依赖和关联的不同：

• 依赖是 临时的非结构型关系
• 关联是 永久（长期）的结构型关系

维度	依赖（Dependency）	关联（Association）
代码实现	方法参数、局部变量、静态方法调用	成员变量（属性）
生命周期	临时（方法调用期间）	长期（对象存在期间）
关系强度	弱（类 A 使用类 B，但不持有 B 的引用）	强（类 A 持有类 B 的引用）
结构性	非结构型（不影响类的基本设计）	结构型（类的设计依赖于关联关系）
UML 符号	虚线箭头（→）	实线（可带箭头或多重性）

4.2.6 接口和实现

接口即一组操作的集合，它是对模块（类、构件、服务、微服务、子系统等）行为的抽象，定义了它们应该提供的服务。

接口是一种特殊的类，包含操作但不包含属性，操作全抽象，操作名不需要斜体。可用类的衍型<< interface >>来表示，也可以使用圆圈表示（又称棒棒糖表示法）。实现关系是一种特殊的依赖关系，表示一个类实现一个接口。

---

UML动态建模通过行为图和交互图定义并描述了系统结构元素的动态特性及行为。交互图包括协作图（通信图）和顺序图（时序图），它以描述系统对象通讯和交互为主。行为图包括状态图和活动图，它以描述系统状态转移为主（关注对象内部行为）。

4.3 交互图

4.3.1 时序图

https://www.bilibili.com/video/BV1YM411f7dr?vd_source=85c17d718a35ff887ddcfa900978cbd6

时序图（sequence diagram），又称为序列图，它通过描述对象之间发送消息的时间顺序 显示多个对象之间的动态协作。

时序图以两维图的方式来刻画对象间的动态交互。垂直维是时间，用于表示对象之间传送消息的时间顺序。水平维是角色，代表参与交互的对象。

组成元素：

1. 对象：代表参与交互的个体（如用户、系统模块、数据库等）。

   • 表示形式：矩形框内标注对象名。
   • 位置：水平排列在时序图顶部。

2. 生命线：代表对象的生命周期。

   • 表示形式：对象下方垂直向下的虚线。
   • 激活：生命线中间的矩形框，表示对象正在执行某个操作或处于激活状态（可以理解为对象正在忙碌）。

3. 消息：

   • 表示形式：对象生命线之间的带箭头线段，箭头方向表示消息传递方向，线上标注消息名称（如“登录“ ”查询订单”）。

   • 类型：

     • 同步消息（实心箭头实线）：发送方发送消息后需等待接收方响应（如函数调用）。
     • 异步消息（空心箭头实线）：发送方无需等待接收方响应，可继续执行后续操作（如事件通知）。
     • 返回消息（实心箭头虚线）：接收方处理完消息后返回结果给发送方。（通常省略）

   • 消息的顺序：消息从发出者指向接收者，次序由垂直位置来表示，第一个消息出现在图的顶部，

     最后一个消息出现在图的底部。（即垂直时间轴）

4. 时间轴：时序图的垂直方向代表时间流逝，对象生命线越向下，时间越晚。消息的上下位置直观反映交互的先后顺序。

序列片段可以用来简化时序图，也可用来表示时序图中的流程控制结构，它主要包括交互使用、循环、条件和并发四种。

1. 交互使用，用于复用另处已定义的一个交互场景，它表现为一个带有ref标签 的框，如图中在对象 order 创建后就执行已定义的“ get existing customer status ”时序图中定义的消息序列。
2. 循环，表现为一个带有loop标签的框，如图中引入了一个循环，由条件[ get next item]来控制执行，依次处理订单中的每一项内容。
3. 条件，可以有两个或多个分支，表现为一个带有alt标签的框，如图中，CarDB 处理汽车预订（reserve）消息，根据库存情况分别返回 accept 或 reject。
4. 并发，可以有两个或多个并发执行的序列片段，表选为一个带有par标签的框。

4.3.2 通信图

【小白也能懂！循序渐进学会UML通信图（协作图）的绘制】https://www.bilibili.com/video/BV1KM4m1f7Va?vd_source=85c17d718a35ff887ddcfa900978cbd6

UML 中用于对象交互建模的另一种图是通信图（communication diagram）。与时序图不同，通信图强调的是发送和接收消息的对象之间的组织结构。

当两个对象对应的类之间存在关联关系时，对象之间则存在一条通信路径，称为链接（link）。一个对象可以通过链接向另一个对象发送消息。一个链接上可以发送多条消息，一条消息必须附在一个链接上。消息的发生顺序用消息编号来说明。

组成元素：

1. 对象：表示参与交互的实体，用矩形框标注名称，名称格式为:名称
2. 链接：表示对象之间的通信路径，用实线（无箭头）表示，线上标注消息名称和参数
3. 消息：表示对象间传递的信息，包含顺序编号（执行顺序）、消息名和参数。

维度	通信图	时序图
核心关注点	对象间的结构关系和消息传递路径	对象间的时间顺序和交互流程
布局方式	自由布局，对象位置灵活	按时间轴垂直排列，对象位置固定
消息编号	必须使用层次化编号表示顺序	可省略编号，通过垂直位置直接体现顺序
适用场景	强调对象协作结构的场景（如架构设计）	强调流程时序的场景（如详细流程分析）

时序图和通信图都用于表示各对象间的交互关系，两者表述的是相似的信息，但表述的方式却不同，可相互转换。时序图用消息的几何排列关系来表达消息的时间顺序，各角色之间的相关关系是隐含的。通信图用各个角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系。

4.4 行为图

4.4.1 状态机图

状态机图（state machine diagram）又称为状态图，用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。

状态机图的基本要素：状态、转移、事件。

• 状态（静止）：指事务在其生命周期中满足某些条件、执行某些操作或等待某些事件而持续的一种稳定状态。
  • 作用：用于对某种形态进行建模，在这种形态下将满足一组不变式条件。
  • 分类：初始状态用实心圆表示；终止状态用被圆圈包围的实心圆表示，其他状态都使用圆角矩形表示，矩形内部显示的是状态名、（状态变量、活动）。
• 状态机（动态）：描述一个事务在其生命周期中，所具有的所有状态以及因事件触发而引起的状态的各种转换。由多个状态（包括初始状态、终止状态）和状态之间的转移关系组成。
• 转移：表示状态之间可能的路径，这些路径表示状态的转移。当产生恰当的事件时，状态就会发生转移，从一种状态进入另一种状态。转移可以通过重定义来求精，但是带有{final}标志的转移不能再被重定义。
• 事件：状态机中事件触发迁移，事件可以用转移上的标号来表示，也可以在状态内表示。
  • 分类：定时事件表示定时触发的事件；调用事件表示在对象上执行同步调用的事件；而信号表示异步调用事件。

状态机图通过有限状态机对系统各个部分的离散行为和使用的协议进行建模。其中行为状态机用来指定各种模型元素的行为，而协议状态机用来表示每一个类可以触发的合法状态转移。

4.4.2 活动图

【UML 活动图】https://www.bilibili.com/video/BV1Zp4y1Z7nV?vd_source=85c17d718a35ff887ddcfa900978cbd6

活动图（Activity Diagram）是状态图的一个变种，状态图显示了一个对象的状态及其转换的过程。而活动图用于描述动作（执行的工作和活动），对象状态改变的结果，突出了活动本身。

活动图的应用非常广泛，它既可用来描述操作(类的方法)的行为，也可以描述用例和对象内部的工作过程。

活动图包括动作、控制流、控制节点和对象节点。

1. 动作是行为的基本单元，一个活动可包含多个动作。用圆角矩形表示。

2. 控制流用来表示从一个动作到另一个动作的流的控制。用一条带箭头的直线表示。

3. 控制节点是用于协调动作的节点，它决定了活动图的流程。

   分类：

   • 初始节点是活动开始的节点，用一个实心圆表示。（一个活动图只有一个初始节点）
   • 终止节点是活动结束的节点，细分为（一个活动图可以有多个终止节点）
     • 活动终止用带十字叉的圆表示
     • 流终止用带边框的实心圆表示。
   • 分叉节点和汇合节点分别表示并发流开始和结束。用同步棒（即一条水平或垂直粗线）来表示。
   • 判断节点和合并节点用菱形符号表示
     • 一个判断节点可以有一个进入流和多个离去流。在每个离去流上放置一个布尔表达式，在进入这个分支时被判断一次。在所有离去流中，其监护条件应该覆盖所有可能性（否则控制流可能会冻结），同时不应该重叠（否则控制流可能有二义性）。
     • 一个合并节点可以有多个进入流和一个离去流。它可以将多个控制路径重新合并。注意，如果一个合并节点接收到多个流，它的离去流指向的动作会被执行多次。

4. 对象节点是动作处理的数据。

带泳道的活动图：

活动图中的元素可以利用分区或泳道来分组。

分组的目的是说明执行具体活动的责任。

泳道可以是一个业务单位、部门、小组、执行者、系统、子系统、对象。每个泳道都可以被命名，表示负责者。

如图是带泳道的整车销售活动图。图中，四个执行者各自负责一个泳道。

活动图与状态图的区别：

• 虽然活动图是由状态图变化而来的，但它们各自用于不同的目的。活动图描述了系统中各种活动（任务）的执行的顺序。刻化一个方法中所要进行的各项活动的执行流程。
• 活动图中一个活动结束后将立即进入下一个活动，而在状态图中状态的变迁通常需要事件的触发。
• 活动图可以描述并发执行的任务，这是包括状态图在内的其他动态模型都无法实现的。

4.5 构件图 部署图 包图（了解）

5. 面向对象分析建模（大致了解）

面向对象分析建模的步骤：

5.1 建立用例模型

通过对项目干系人需求的详细分析，识别出待开发软件系统的执行者和用例，画出用例图，并针对每个用例写出详细的用例规约。

5.1.1 执行者的识别

执行者（actor）是为了完成一个事件而与系统交互的外部事物，位于系统外部，与系统直接交互，用于描述系统的边界。执行者并不仅仅包括系统的用户，还可以是与系统有交互的外部系统和外部设备。

特征：

1. 与系统直接交互
2. 位于系统外部
3. 可能是系统的用户，也可以是外部设备或外部系统

用于识别执行者的四个问题：

• 谁需要在系统的帮助下完成自己的任务？
• 需要谁去执行系统的核心功能？
• 需要谁去完成系统的管理和维护？
• 系统是否需要和外界的硬件或软件系统进行交互？

例：

执行者是一种角色，一个实际用户可能承担着系统的多个执行者角色，同样一个执行者可由多个不同的用户承担，从而代表同一执行者的不同实例。例如 ABC 公司的张凡既是维修员，又从公司买了车，是一名顾客；而维修员除了张凡，还有李强等几十名员工。

5.1.2 用例的识别

用例是系统执行的一个动作序列，这些动作必须对某个特定的执行者产生可观测的、有价值的结果。所以，识别用例最好的方法就是考虑每个执行者需要从系统得到什么（执行者想使用系统去做的事）。

用于识别用例的四个问题：

● 执行者希望系统提供什么功能？

● 执行者是否要创建、存储、删除或读取系统中的数据？

● 执行者是否要告诉系统外界的事件？

● 执行者是否需要告知系统中发生的情况？

在识别用例时，常常存在粒度太小的误区。用例必须给执行者带来可观测的、有价值的结果。一个用力是系统和执行者之间的一次完整“对话”，是一组完整的动作序列。因此要避免功能分解。

5.1.3 用例图的构建

执行者、用例以及它们之间的关系构成用例图。

用例与至少一个执行者交互，一个用例必须向至少一个执行者提供可观测到的价值。

参与某用例的执行者可以有多个，它们各有不同的角色和职责：一些负责接收用例提供的价值，一些则负责向用例提供服务，其他则负责触发或初始化用例。

5.1.4 用例规约的撰写

用例规约（多个）分别对每个用例的行为进行详细说明。

编写用例规约形式：首选简单的文本；时序图、活动图等作为辅助说明。

1. 用例规约的核心内容——事件流

事件流是用例的组成部分，描述了那些在执行者和用例之间的对话期间发生的基本活动，例如行为和交互。

组成：

• 基本事件流包括在执行用例时“通常”（频度高）会发生的事件。（正常情况）
• 备选事件流包括与正常行为相关的可选或异常特征的行为，同时也包括正常行为的各种变形。（异常情况或正常情况的补充变形）

2. 用例规约的可选字段

除了用例名称、描述和事件流这些必填的核心字段外，用例规约还包括以下可选字段：

• 前置条件和后置条件：用于阐明事件流如何开始和结束。前置条件描述用例执行前所必需的系统状态，后置条件描述用例结束后系统可能具备的状态。
• 扩展点：用于扩展用例。
• 业务规则：用于描述事件流中的规则或计算公式。
• 非功能需求

3. 活动图

如果事件流是线性的（含有很少或没有循环和条件逻辑），用文字就足以表示用例信息。

如果事件流中又复杂的逻辑（条件和循环），考虑使用UML活动图或时序图对事件流进行建模。

4. 黑盒用例规约和白盒用例规约

5.1.5 用例模型的优化

三种关系可以用于组织和优化用例：包含（include）、扩展（extend）和泛化（generalization）。

5.2 建立概念模型

面向对象分析建模的第二步是确定拟建系统必须处理的核心概念类，并识别这些类之间的关系，画出类图，建立概念模型。

Liskov Substitution Principle (LSP) 里氏替换原则

子类型应该能替换基类型。（圆是一种有半径的点）

但是子类不能替换超类。

5.3 识别用例实现

即用例之间的各种关系

5.4 识别分析类

三种分析类 Analysis Class

• 边界类：系统和外部环境之间交互的边界（View）

  主要负责内容的翻译和形式的转换，并表达相应的结果。边界类对系统中依赖于环境的那些部分进行建模，具有良好的隔离作用，使系统的其他部分（实体类和控制类）和系统外部环境解耦。

  三种边界类

  • 用户界面类——用来与系统用户进行通信的类，关注的是用户界面的交互内容，如窗口、对话框等。在分析阶段，不要关注界面的美工、排版等具体细节，而只需描述界面的核心字段和构件。可以通过制作用户界面原型的草图来展示边界对象的行为和外观。

  • 系统接口类——用来与其他系统进行通信的类，关注的是系统通信协议，如 ATM和银行会计系统的接口。在此，无论这个协议是现有的，还是新发明的，都只需描述接口的名称和承担的职责，无须关注协议的设计和实现。

  • 设备接口类——用来与外部事件的设备（如传感器）进行通信的类，关注的是硬

    件通信协议，如打印机接口、传感器接口。同样，只需描述其名称和职责，无须关注协

    议的细节。

• 控制类：系统在运行中的控制逻辑（Control）

用于描述一个或几个用例所特有的事件流控制行为，如事务管理器、资源协调器和错误处理器等。控制类相当于协调者，它自己通常不处理具体的任务，相反，它协调其他对象实现用例的功能。

• 实体类：系统要记录和维护的信息（Model）

用于描述必须存储的信息和相关行为。实体类代表拟建系统中的核心概念，如银行系统中实体类的典型示例是账户和客户；在一个网络处理系统中，典型的示例是节点和链接。实体类显示了逻辑数据结构，它们直接对应拟建系统中体现用户核心价值的那部分内容，在系统运行时其实例数据通常需要长期储存。

5.5 建立分析模型

时序图和通信图的构建，类图的构建

6. 敏捷开发中的需求工程（了解）

采用需求卡片而不是正式的需求文档来刻画需求；

需求的粒度不能太大，能在短期迭代内实现与交付；

需求应按照对用户的价值和紧迫性进行优先级排序，从而决定在下一次迭代计划中优先实现哪些需求。

因此，用户故事（user story）常常被用作敏捷迭代中的基本需求单位 A。用户故事是一种从用户视角出发表述的端到端的细粒度功能，是对客户有价值的功能项的简洁描述。

编写用例的目的是让开发团队与客户一起进行讨论并就需求达成一致，而编写用户故事的目的是规划迭代并引导客户提供更多细节。

在基于用户故事的敏捷开发实践中，用户故事写在任务卡片上。

开发团队会在任务板上根据优先级将用户故事排入迭代计划中，由团队成员认领。团队成员在本次迭代周期内完成用户故事的详细设计、实现和测试，保证按时、高质量交付。

需要注意的是，这些用户故事并不一定都是事先一次性定义的，而是可以随着迭代化的开发逐步被提出来，不断完善。