2020-软件工程与计算II-06-需求分析方法

06-需求分析方法

重要：注意完成课本习题

1. 用例文档的格式情况

2. 需求分析基础

2.1. 为什么要需求分析

1. 需求不是属于用户的，是应该是需求人员提出来的

2.2. 需求分析的任务

1. 建⽴分析模型，达成开发者和用户对需求信息的共同理解:分析将复杂的系统分解为简单的部分以及它们之间的联系，确定本质特征，抛弃次要特征。
2. 依据共同的理解，发挥创造性，创建软件系统解决方案:分析可以将一个问题分解为独立的、更简单的和易于管理的子问题来帮助寻找解决方案

2.3. 需求分析的模型与建模

2.3.1. 模型

1. “模型是对事物的抽象，帮助⼈们在创建一个事物之前可以有更好的理解”[Blaha2005]
2. 为了更好地理解需求获取所得到的复杂信息，需要集中关注问题的计算特性(数据、功能、规则等)，建立相关的软件模型

2.3.2. 建模

1. 建立模型的过程被称为建模。“它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，这个表示以精确⼀致的方式描述系统，使得系统的使用更加容易”[Fishwick1994]。
2. UML的规范，每一个细节，含义也需要遵从规范的，箭头，实线虚线。
3. 抽象(Abstraction)和分解(Decomposition / Partitioning)是建模最为常用的两种手段

2.3.3. 需求分析模型的特点及常见的需求分析模型

• 需求分析模型是专门用来描述软件解决方案的模型技术。因为软件解决方案介于用户描述与软件内部构造之间，所以需求分析模型也是介于用户概念和软件内部实体之间的模型形式。

• 常见的需求分析模型

3. 结构化分析

3.1. 结构化方法的历史

1. 结构化⽅法是针对1960’s到1980’s软件开发界所⾯临的问题提出⼀系列分析、设计和编码的技术⽅法。那个时代：
   • 大多数商业编程都在Cobol和Fortran中完成，然后在C和BASIC中完成
   • 关于"好的"设计和编程技术的指导很少
   • 没有记录需求和设计的标准技术
2. 关键是软件的复杂度的急剧上升

3.2. Multiple Structured Methods emerged 多种结构化分析方法的出现

1. 结构化编程：in circa 1967 with Edsger W.Dijkstra
2. 结构化设计：around 1975 with Larry Constantine and Ed Yourdon
3. 结构化分析：in circa 1978 with Tom DeMarco, Yourdon, Gane & Sarson, McMenamin & Palmer
4. 信息专家：in circa 1990 with James Martin

3.3. 结构化分析思想

1. 自顶向下分解
2. 各种图
   • 数据流图
   • 实体关系图
   • 状态转移图

3.4. 数据流图 (Flow Oriented Model)

1. 数据流图将系统看做是过程的集合，其中一些由人来执行，另一些由软件系统来执行。
2. 过程的执行就是对数据的处理：它接收输⼊，进⾏数据转换，输出结果。
3. 数据流图主要是展示了数据在通过系统如何进行了变化。
4. 可能需要和软件系统外的实体尤其是人进行交互
5. 数据的变化包括：
   • 被转换、被存储、或者被分布

3.4.1. Flow Modeling Notation(数据流图基本元素)

3.4.1.1. 外部实体

1. 数据的产生或者消耗者
   • 示例：一个人，一个设备，一个传感器
   • 另一个例子：基于计算机的系统
2. 数据必须是从一个地方来到另一个地方去
3. 外部实体是待构建软件系统之外的人、组织、设备或者其他软件系统，它们不受系统控制，开发者不能以任何方式操纵它们。

3.4.1.2. 过程 Process

1. 将数据从输入转换到输出：示例：计算税金，确定面积，格式报告，显示图形必须始终以某种方式处理数据以实现系统功能
2. 过程是指施加于数据的动作或者行为，它使得数据发生变化，包括被转换、被存储或者被分布。

3.4.1.3. 数据流 Data Flow

1. 数据在整个系统流动，从输入流动到输出
2. 数据流是数据的运动，它是系统与其环境之间或者系统内两个过程之间的通信形式。

3.4.1.4. 数据存储 Data Stores

1. 数据经常被存储起来等之后使用
2. 数据存储是软件系统需要在内部手机、保存，以供日后使用的数据集合。

3.4.2. 数据流图的语法规则

1. 过程是对数据的处理，必须有输⼊，也必须有输出，输⼊数据集应该和输出数据集存在差异

2. 数据流是必须和过程产⽣关联的，它要么是过程的数据输⼊，要么是过程的数据输出

3. 所有的对象都应该有⼀个可以唯⼀标识自己的名称。过程使用动词，外部实体、数据流、数据存储使用名词

3.4.3. 数据流图的分层结构

1. 数据流图分为如上三种图:上下文图、0层图和N层图

3.4.3.1. 上下文图

1. 上下文图是DFD的最高层次的图，是系统功能的最高抽象。上下文将整个系统看做一个过程，这个过程实现系统的所有功能。
2. 因此，上下文图往往也脱离DFD的层次结构单独使用，用来描述系统的上下文环境和定义系统边界。

3.4.3.2. 0层图

1. 回顾描述并使用语法分析来确定"操作"
2. 确定外部实体(数据的生产者和消费者)
3. 0层图通常被用作整个系统的功能概图。
   1. 为了概述整个系统的功能，建立0层图时需要分析需求获取的信息，归纳出系统的主要功能
   2. 将系统的主要功能描述为几个比较高层的抽象过程，并在0层图中加以标书
   3. 有部分重要的数据存储会在0层图中得到表述
4. 0层图示例

3.4.3.3. 1层图

1. 写一篇叙述性文章来描述这个转变(数据的转变)
2. 分析以确定下一级转换
3. "平衡"流量以保持数据流量的连续性
4. 1层图实例

3.4.3.4. N层图

1. 父过程:被分解的过程
2. 子图:分解后产生的揭示更多细节的图
3. 原始DFD图:所有过程无法再次分解的图。
4. 子图的接口流:父过程的输入输出，往往从空白的区域引出。
5. 子图中过程的编号需要用父过程中的编号作为前缀。
6. 注意:低于0层图的子图上通常不显示外部实体

3.4.4. 数据流图的分层

1. 输⼊、处理、输出
2. 分层将细节逐步细化

3.4.5. 过程分解的平衡原则

3.5. 实体关系图(ERD) - 数据的建模

1. 独立于处理检查数据对象
2. 关注数据域(数据说明)
3. 指示数据对象如何相互关联
4. 能够弥补过程建模在数据说明方面的缺陷，是描述数据的定义、结构和关系等特性的技术。

3.5.1. 实体关系图的组成元素

3.5.1.1. 传统实体(Typical Objects)

实体是需要在系统中收集和存储的现实世界事物的类别描述。

1. 实体并不是孤立存在的，相互交互相互影响
2. 参与关系的每个实体都针对关系拥有最大基数和最小基数
3. 最大基数:对关系中任意的其他实体实例，该实体可能参与关系的最大数量。最大基数为1，表示为One，否则为Many
4. 最小基数:对关系中任意的其他实体实例，该实体可能参与关系的最小数量。实体在关系中的最小基数被标记为Optional,最小基数为1时，实体在关系中的最小基数被标记为mandatory
5. 实体的例子
   1. external entities:printer, user, sensor
   2. things:reports, displays, signals
   3. occurrences or events:interrupt, alarm
   4. roles:manager, engineer, salesperson
   5. organizational units:devision, team
   6. places:manufacturing floor
   7. structures:employee record

3.5.2. Data Objects and Attributes 属性

1. 数据对象包含一组作为对象的方面、质量、特征或描述符的属性
2. 属性可以对尸体进行描述的特征。

3.5.3. Relationship 关系

1. 连通性
   • 系统必须记住的事实，不能或不能计算或推导出来
   • 关系的几个实例可以存在
   • 实体可以以多种方式关联

3.5.4. 建立实体关系图的步骤

1. 第1级-对所有数据对象(实体)及其相互之间的"连接"建模
2. 第2级-对所有实体和关系建模
3. 第3级-对所有实体、关系和属性建模，以提供进一步的深度

3.5.4.1. ERD的图形表示

3.5.4.2. 键(Key)

1. 实体的⼀个或者多个属性能够唯⼀确定和标示每个实例，这些属性或者属性 组合就被称为实体的标示符，或者键(Key)

3.5.5. 实体关系图实例

4. 面向对象分析

4.1. 面向对象分析的简单过程

4.2. 需求与用例

1. 传统上，这些要求是在客户和开发人员之间的合同文件中规定的：很难满足所有的需求。
2. 1992年，Jacobson提出了用例方法：它们来自于传统的开发方法，并适应OOAD。

4.3. 用例(重要)

1. 用例最初由[Jacobson1992] 在 Objectory 方法中提出的,它将⽤例定义为"在系统(或者子系统或者类)和外部对象的交互当中所执行的行为序列的描述,包括各种不同的序列和错误的序列,它们能够联合提供⼀种有价值的服务"[Rumbaugh2004]。
2. [Cockburn2001]认为用例描述了在不同条件下系统对某⼀⽤户的请求的响应。根据用户的请求和请求时的系统条件,系统将执⾏不同的行为序列, 每⼀个行为序列被称为⼀个场景。⼀个用例是多个场景的集合。

4.3.1. 目标、交互与行为序列

4.3.2. 案例

1. 连锁超市管理系统的收银员为了完成⼀次销售任务,会使⽤软件系统处理销售过程,那么就可以建立⼀个⽤例"销售处理"。考虑实际销售时的不同条件,会发⽣不同的⾏为:
   • 在⼀切顺利时是⼀种正常⾏为流程;
   • 购买多个同样商品时可以逐⼀输⼊每个商品,也可以分别输⼊商品号与数量;
   • 销售过程中可能会发现某个商品无法识别;
   • 有可能⼀个商品被纳⼊销售清单后用户⼜提出退回…
2. 上述的每⼀个⾏为都是⼀个场景。所有的行为联合起来就构成了场景的集合——⽤例,它的目标与价值是完成销售任务。
3. 除了上述基本操作以外，还应该考虑用户大量的操作。
4. 用例是需求的一种组织，一种表达。

4.4. 用例图

1. ⽤例:椭圆
2. 参与者:小人
3. 关系:简单的就是一条直线
4. 系统边界:是一个框

4.4.1. 用例图组成成分

4.4.1.1. 参与者

1. 参与者是用户或其他系统对要开发的系统所扮演的角色。
2. 用例图中的单个参与者可以表示多个用户(或系统)。
3. 单个用户(或系统)也可以扮演多个角色。
4. 参与者不需要是人，例如，需要来自当前系统的某些信息的外部系统也是参与者。

4.4.1.2. 用例(需要语境)

1. 以用例的形式表达需求。
2. 用例表示有助于构建、关联和理解基本需求的典型场景集。
3. 场景是对系统在实践中如何使用的描述：用户与计算机系统之间的典型交互
4. 一般会用动宾短语，加上actor作为主语就是句子了。

4.4.1.3. 系统边界

1. 强调重点是什么是要详细的，什么不是。
2. 系统边界隐式存在于没有显式表示的系统边界的图中
3. 参与者总是在边界之外，用例总是在边界之内。
4. 系统边界是指一个系统所包含的系统成分与系统外事务的分界线。

4.4.1.4. 关系

1. 有关
2. 泛化关系，指向的是被泛化的。
3. 包含关系
4. 继承关系
5. 如果能清晰include和extends可以画，不明白可以直接连线和不画。
6. multiplicity:多样性。

4.4.2. 用例图的建立的步骤

1. 目标分析与解决方向的确定
2. 寻找参与者
3. 寻找用例
4. 细化用例

4.4.2.1. 目标分析

1. 问题目标的解决方案
2. ×××连锁商店是一家刚刚发展起来的⼩型连锁商店，其前身是⼀家独立的小百货门面店。
   • ⾸先是随着商店规模的扩⼤，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。
   • 其次是商店的商品品种增多，⽆法准确掌握库存，商品积压、缺货和报废的现象上升 明显。
   • 再次是商店⾯临的竞争⽐以前更⼤，希望在降低成本，吸引顾客，增强竞争⼒的同时，保持盈利⽔平。
3. 业务需求
   1. BR1：在系统使⽤6个⽉后，商品积压、缺货和报废的现象要减少50%
   2. BR2：在系统使⽤3个⽉后，销售⼈员⼯作效率提⾼50%
   3. BR3：在系统使⽤6个⽉后，运营成本要降低15%
      • 范围：⼈⼒成本和库存成本
      • 度量：检查平均员工数量和平均每10,000元销售额的库存成本
   4. BR4：在系统使⽤6个⽉后，销售额度要提⾼20%
      • 最好情况：40%
      • 最可能情况：20%
      • 最坏情况：10%
4. 系统功能
   1. SF1：分析商品库存，发现可能的商品积压、缺货和报废现象
   2. SF2：根据市场变化调整销售的商品
   3. SF3：制定促销⼿段，处理积压商品
   4. SF4：与生产厂家联合进⾏商品促销
   5. SF5：制定促销手段进行销售竞争
   6. SF6：掌握员工变动和授权情况
   7. SF7：处理商品⼊库与出库
   8. SF8：发展会员，提高顾客回头率
   9. SF9：允许积分兑换商品和赠送吸引会员的礼品，提⾼会员满意度
   10. SF10：帮助收银员处理销售与退货任务

4.4.2.2. 寻找参与者与用例

1. 每个用户的任务(⽬标)都是⼀个独⽴用例
2. 案例中的参与者的目标
   1. 总经理的目标有：
      • 产品调整(增删改产品信息)
      • 特价策略制定(增删改特价策略)
      • 赠送策略制定(增删改赠送策略)
      • 库存分析；(分析可能的商品积压)
   2. 客户经理的目标有：
      • 会员管理；(会员发展、礼品赠送)
      • 库存管理；(商品入库、出库和库存分析)
   3. 收银员的目标有：
      • 销售处理(销售)
      • 退货；(退货)
   4. 管理员的目标有：
      • ⽤户管理(增删改⽤户信息)

4.4.2.3. 细化用例

1. 如果用例的粒度不合适就需要进⾏细化和调整。
   • 判断标准是：⽤例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务。
2. 产品具体的细化
   1. 特价策略制定、赠送策略制定两个用例的业务目的、发起源和过程基本相同，仅仅是业务数据不同，所以可以合并为⼀个⽤例销售策略制定。
   2. 会员管理用例有两个明显不同的业务事件，可以被细化为发展会员和礼品赠送2个更细粒度的用例。
   3. 客户经理的库存管理用例也有三个不同的业务⽬标：出库、⼊库和库存分析，所以也应该细化为三个用例商品出库、商品⼊库和库存分析，其中库存分析⽤例与总经理的库存分析⽤例相同。

4.4.2.4. 常见错误

1. 不要将用例细化为没有独立业务价值的单个操作
   • 例如,不要将用户管理细化为增加、修改和删除三个更⼩的用例,因为它们要联合起来才能体现出业务价值。
2. 不要将同⼀个业务目标细化为不同用例
   • 例如特价策略制定和赠送策略制定。
3. 不要将没有业务价值(而是技术实现需要)的内容作为用例
   • 常见的错误有登录(应该描述为安全性质量需求)、“数据验证/输入/输出数据检查”(应该描述为数据需求或者业务规则)、“连接数据库”(属性软件内部实现⽽不是需求)、网络传输等。
4. 不要将单个步骤细化为用例
5. 不要将片面的一个方面细化为用例

4.4.2.5. 完整实例

[实例一]
×××连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门面店。
首先是随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。其次是商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废的现象上升明显。再次是商店面临的竞争比以前更大，希望在降低成本，吸引顾客，增强竞争力的同时，保持盈利水平。

BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%
BR2：在系统使用3个月后，销售人员工作效率提高50%
BR3：在系统使用6个月后，运营成本要降低15%
范围：人力成本和库存成本，度量：检查平均员工数量和平均每10,000元销售额的库存成本
BR4：在系统使用6个月后，销售额度要提高20%，最好情况：40%，最可能情况：20%，最坏情况：10%

SF1：分析商品库存，发现可能的商品积压、缺货和报废现象
SF2：根据市场变化调整销售的商品
SF3：制定促销手段，处理积压商品
SF4：与生产厂家联合进行商品促销
SF5：制定促销手段进行销售竞争
SF6：掌握员工变动和授权情况
SF7：处理商品入库与出库
SF8：发展会员，提高顾客回头率
SF9：允许积分兑换商品和赠送吸引会员的礼品，提高会员满意度
SF10：帮助收银员处理销售与退货任务

从上述特性可以发现涉及的用户类别：总经理，客户经理，收银员，管理员
总经理的目标有：
    1. 产品调整(增删改产品信息)
    2. 特价策略制定(增删改特价策略)
    3. 赠送策略制定(增删改赠送策略)
    4. 库存分析；(分析可能的商品积压)
客户经理的目标有：
    1. 会员管理；(会员发展、礼品赠送)
    2. 库存管理；(商品入库、出库和库存分析)
收银员的目标有：销售处理(销售)，退货；(退货)
管理员的目标有：用户管理(增删改用户信息)

【示例2】
网上书店系统(OBS)是一个基于web的应用程序，允许用户浏览和购买网上产品。该应用程序支持网上购物车的概念，类似于其他网上零售商，如Amazon.com,。该系统的结账功能将集成信用卡交易处理以及内部计费系统。该系统还提供管理员视图，允许授权的员工查看和管理产品、用户和订单。
用户：购买、浏览
员工：查看用户、订单、产品管理
管理员：授权
信用卡：结账
内部计费：结账
注意：内部计费指的是单位内部，而不是系统内部

4.4.3. 用例文档模板

1. 用例标识:至少在本文档中标识应当是唯一，最好是在整个项目中的文档标识是唯一的
2. 触发事件:
3. 前置条件:系统应该满足的条件，但是不是达到这个条件就除法
4. 后置条件:用例处理完的状态
5. 扩展流程:不按照我们预估的顺序走，不是错误的。
   • 也包含一些异常说明

4.4.4. 用例模板实例

1. UC1是ID，前置条件是应该被完成的

2. 流程是被标识数字，并且数字应该是唯一的。

3. 上面的8和9合并(无和系统的交互)
   

4. 2a:非法输入一定要明确的提示(a标识扩展，然后之后写出扩展流程的具体流程)

1. 特殊需求应当保证确定有需求才写，符合规格要求

4.4.5. 用例文档的部分问题

1. 顾客为什么不是参与者:顾客没有直接和我们交互，因为是通过收银员进行交互
2. 上传下载为什么不是⽤例:是系统之间的交互，并不是系统和系统外的交互
3. 系统可不可以分为服务器和客户端两个系统:
   1. 表达用例的时候还是在表达需求，这时是没有服务器端和客户端的概念的，这时我们的实现细节

4.4.6. UML中用例图的作用

1. 用例图在整个UML中是有很重要的作用，是其他用例的基础

4.5. 概念类图(Conceptual Class Diagram)

1. 概念类图又被称为"领域模型"(Domain Model)
2. 类图是面向对象分析方法的核心:类图描述类(对象)和这些类(对象)之间的关系
3. 概念类图和设计类图的不同点:关注系统与外界的交互，⽽不是软件系统的内部构造机制
4. 类型、方法、可见性等复杂的软件构造细节不会在概念类图中
5. 类图只有类和类名，没有包含方法。
6. 用例不是概念类，同一个用例可能产生多个概念类

4.5.1. 概念类图的注意事项

1. 注意：与设计类图有所不同，分析类图关注现实世界问题域，而不是软件系统的内部构造机制；
2. 类型、方法、可见性等复杂的软件构造细节不会在概念类图中，不允许出现与现实无关的内容

4.5.2. 概念类图基本元素

1. 对象
   • 标识符:对象自治、对象请求写作
   • 状态:存储数据，如密码、名称
   • 行为:利用数据做什么
2. 类:对象集合的抽象
3. 链接(link)(dependency)
   • 对象之间的互相协作的关系
   • 描述了对象之间的物理或业务联系
4. 关联
   • 对象之间链接的抽象
   • 聚合与组合
5. 继承:泛化关系

4.5.3. 关联与依赖

1. 两个分析类通常以某种方式相互关联
   • 在UML中，这些关系称为关联
   • 关联可以通过指示多样性来重新定义(数据建模中使用术语基数)
2. 如果类之间存在关联，则类的实例之间存在链接(依赖项)

3. 上图中注意基数和箭头的形状
4. 会使用到的四种关系线:
   1. 聚合关系不必可以使用，但是组合关系要适当的使用
   2. 继承关系、组合关系、聚合关系、普通关联

4.5.4. 继承

1. 将域对象类组织到层次结构中
2. 层次结构顶部的类反映了所有类的公共特性
3. 对象类从一个或多个超级类继承其属性和服务。必要时可将其专门化

4. 使用空心箭头

4.5.5. 建立概念类图的步骤(重要)

1. 对每个用例文本描述，尤其是场景描述，建⽴局部的概念类图
   • 根据用例的⽂本描述，识别候选类
   • 筛选候选类，确定概念类
   • 识别关联
   • 识别重要属性
2. 将所有用例产⽣的局部概念类图进⾏合并，建⽴软件系统的整体概念类图
3. 自己注:先画关联关系，再添加类的属性

4.5.6. 候选类识别

1. 发现软件系统与外界交互时可能涉及的对象与类，它们就是候选类。
2. 行为分析、名词分析、CRC等很多种⽅法都可以⽤来分析⽤例⽂本描述
3. 名词分析:提取出用例描述中的名词作为候选类

4.5.7. 筛选候选类，确定概念类

1. 确定概念类的准则：该对象的状态与行为是否全部必要
   1. 依据系统的需求
   2. 该类的对象实例的状态与⾏为是否完全必要
   3. 如果是只允许打印两次，则要为何打印的状态。
2. 候选类向概念类的转换：如果候选类的对象实例
   1. (状态+行为)既需要维持⼀定的状态，⼜需要依据状态表现⼀定的行为
      • 确定为⼀个概念类
   2. (仅状态)如只需要维护状态，不需要表现行为
      • 确定是不是其他概念类的属性
   3. (仅行为)不需要维护状态，却需要表现⾏为
      • ⾸先要重新审视需求是否有遗漏，因为没有状态⽀持的对象无法表现⾏为
      • 如果确定没有需求的遗漏，就需要剔除该候选类，并将⾏为转交给具备状态⽀持能⼒的其他概念类
   4. (无状态行为)既不需要维护状态，⼜不需要表现行为:废弃

4.5.8. 识别关联

1. 分析用例文本描述，发现概念类之间的协作，需要协作的类之间需要建立关联。

2. 分析和补充问题域内的关系，例如概念类之间的整体部分关系和明显的语义联系：对问题域关系的补充要适可⽽⽌，不要把关系搞得过度复杂化。
3. 去除冗余关联和导出关联。

4.5.9. 识别重要属性

1. 这些属性往往是实现类协作时必要的信息，是协作的条件、输⼊、结果或者过程记录。
2. 通过分析用例的描述，并与用户交流，补充问题域信息，可以发现重要的属性信息。
3. 在分析每个单独的用例(场景)描述时，为各个概念类发现的重要属性可能不多，甚⾄有些概念类没有任何重要属性。但是，系统通常有多个⽤例和很多场景，会建立多个局部的概念类图，只有在合并所有局部概念类图之后， 各个概念类的重要属性才能得到全⾯的体现。

4.5.10. 概念类图生成的步骤(总结)

1. 识别候选类(名词分析法)
2. 确定概念类 (看是否满足既有状态又有行为)
   1. 既需要维持一定的状态，又需要依据状态表现一定的行为：确定为一个概念类
   2. 如只需要维护状态，不需要表现行为：其他概念类的属性
   3. 不需要维护状态，却需要表现行为：首先重新审视需求是否有遗漏，因为没有状态支持的对象无法表现行为；如果确定没有需求的遗漏，就需要剔除该候选类，并将行为转交给具备状态支持能力的其他概念类
   4. 既不需要维护状态，又不需要表现行为：应该被完全剔除
3. 识别关联(文本中提取出"名词＋动词＋名词"的结构)：第一标准是满足需求的要求，第二标准是现实状况
4. 识别重要属性：协作的必要信息，通过分析用例的描述，补充问题域信息发现。

4.5.11. 实例

【示例1】
1、如果是会员，收银员输入客户编号(属性、无行为)
2、系统显示会员信息(就是会员)，包括姓名(属性、无行为)与积分(属性、无行为)
3、收银员输入商品标识(商品属性、无行为)
4、系统记录并显示商品信息(有状态、有行为)，商品信息包括商品标识、描述、数量、价格、特价(如果有商品特价策略的话)和本项商品总价(商品属性)
5、系统显示已购入的商品清单(有状态、有行为)，商品清单包括商品标识、描述、数量、价格、特价、各项商品总价和所有品总价(商品属性)
收银员重复3-5步，直到完成所有商品的输入
6、收银员结束输入，系统计算并显示总价(存储在账单中，有行为)，计算根据总额特价策略(有状态、有行为)进行
7、系统根据商品赠送策略和总额赠送策略计算并显示赠品清单(要)，赠品清单包括各项赠品的标识、描述与数量(不要)
8、收银员请顾客(就是会员)支付账单(有状态、有行为)
9、顾客支付，收银员输入收取的现金数额(有属性、无行为、不要)
10、系统给出应找的余额(有属性、无行为、不要)，收银员找零
11、收银员结束销售，系统记录销售信息(有状态、有行为)、商品清单、赠品清单和账单信息，并更新库存(有状态、有行为)
12、系统打印收据(根据需求，如果是一次性就无状态无行为，如果是丢了还可以打印就有状态有行为)
注意：一切看需求。

(1)若商品ID必须符合标准，则ID有状态、有行为
(2)若商品数量单位不同，则单位换算的职责交给数量，有状态、有行为
(3)若商品价格按照国际汇率有不同定位，则价格有状态、有行为

【示例2】
ATM系统通过显示屏，输入键盘(有数字和特殊输入按键)，银行卡读卡器，存款插槽，收据打印机等与用户交互。客户使用ATM机存款，取款，余额查询，对账户的更新交由账户系统的一个接口来处理。安全系统将为每个客户分配一个PIN码和安全级别。每次事物执行之前都需要验证PIN码。将来，银行计划使用ATM机支持一些常规操作，例如使用地址和电话号码修改。

分析：显示器、按键、读卡器、存款插槽、收据打印机 不属于现实世界
客户：属性：PIN、地址、电话号码、安全级别
账户：余额
交易

【示例3】
1. 顾客向系统提起查询请求
2. 系统根据请求为顾客提供一个CD的推荐列表
3.顾客在推荐列表中选定一个CD，然后要求查看更详细的信息
4. 系统为顾客提供选定CD的详细信息
5. 顾客购买选定CD.
6. 顾客离开

分析：
查询请求：有状态、有行为
顾客和CD：看戏球，不确定是否存储详细信息
推荐列表：有状态、有行为(增删改)

4.6. 用例模型和对象模型之间的鸿沟

1. 用例模型和对象模型之间是存在比较大的差距的。

4.7. 顺序图(交互图)

1. 行为模型显示了对象之间的交互，以产生一些特定的系统行为，这些行为被指定为一个用例
2. UML中的序列图(或协作图)用于建模对象之间的交互
3. 分析阶段，主要是利⽤系统顺序图，表达系统和外部参与者之间的交互⾏为：务必要严格谨慎的界定系统

4.7.1. 顺序图的图例

1. 下划线表示对象，没有下划线表示类(上图中的名字)

2. 区分不同的箭头： 箭头们无论是从系统到外部还是从外部到系统都是一样的

4.7.2. 系统顺序图

1. 画外部和内部之间的交互应当仔细辨别系统和系统(也就是系统边界)
2. 不同框的含义:
   1. alt一定要选(多选一):注意，每一种可选分支之间要用虚线分割，而且在表示执行态的圆柱上面要写监护条件，放在[]里面。
   2. opt一定要选(选择0或者1)
   3. loop:表示循环，在旁边使用[]书写循环条件
3. 步骤:
   1. 确定上下文环境
   2. 根据用例描述找到交互对象
   3. 按照用例描述中的流程顺序逐步添加消息

4.8. 状态图

4.8.1. 状态图的基本概念

1. 状态：一组可观察的情况，描述了一个系统在给定时间的行为
2. 状态转换：从一个状态到另一个状态的转换
3. 事件：使系统表现出某种可预测的行为形式的事件
4. 行为：由于过渡而发生的过程

4.8.2. 状态图的示例

• 上图非常重要，请务必认真确定

4.8.3. 创建状态图的步骤

1. 确定上下文环境
   • 状态图是立足于状态快照进⾏⾏为描述的，因此建⽴状态图时首先要搞清楚状态的主体，确定状态的上下⽂环境。常⻅的状态主体有：类、用例、多个⽤例和整个系统。
   • 状态应该是相对较多，比较复杂的。
2. 识别状态
   • 状态主体会表现出⼀些稳定的状态，它们需要被识别出来，并且标记出其中的初始状态和结束状态集。在有些情况下，可能会不存在确定的初始状态和结束状态。
3. 建⽴状态转换
   • 根据需求所描述的系统⾏为，建⽴各个稳定状态之间可能存在的转换。
4. 补充详细信息，完善状态图
   • 添加转换的触发事件、转换⾏为和监护条件等详细信息。

4.8.4. 示例:销售处理用例状态图

1. 明确状态图的主体：⽤例UC1销售处理。
2. 识别⽤例UC1销售处理可能存在的稳定状态：
   • 空闲状态(开始状态)：收银员已经登录和获得授权，但并没有请求开始销售⼯作的状态；
   • 销售开始状态：开始⼀个新销售事务，系统开始执⾏⼀个销售任务的状态；
   • VIP顾客信息显示状态：输⼊了客户编号，系统显示该VIP顾客信息的状态；
   • 商品信息显示状态：刚刚输⼊了⼀个物品项，显示该物品(和赠品)描述信息的状态；
   • 列表显示状态：以列表⽅式显示所有已输⼊物品项(和赠品)信息的状态；
   • 错误提示状态：输⼊信息错误的状态；
   • 账单处理状态：输⼊结束，系统显示账单信息，收银员进⾏结帐处理的状态。
   • 销售结束状态：更新信息，打印收据的状态。

4.8.5. 状态转换表(辅助完成状态图绘制)

1. 用来分析状态之间的关系

4.9. 例题

5. 使用需求方法细化和明确需求

1. 为什么要细化
   • ⽤户需求的描述的模糊性和系统设计所需要的严谨性之间的⽭盾
2. 如何细化
   • 需求分析建模
   • 发现其中的遗漏、冲突、冗余和错误
   • 迭代(获取、分析、获取、分析。。。)

5.1. 系统顺序图有助于发现交互性的缺失

5.2. 概念类图有助于发现

1. 部分信息的使用不准确
   • 例如步骤 2 中输⼊的是商品标识,⽽不是商品,第 5 步显示的已输⼊商品列表信息和总价。
2. 部分信息不明确
   • 例如会员信息、商品信息、商品列表信息、赠品 信息、更新的数据、收据等等各⾃的详细内容并没有描述。
3. 遗漏了重要内容
   • 例如总价的计算需要使⽤商品特价策略和总额特 价策略,赠品的计算需要使⽤商品赠送策略和总额赠送策略。

5.3. 状态图有助于发现页面的跳转

5.4. 建⽴系统需求

1. 8种规格说明
2. 不同的分析⽅法适合不同的规格说明

5.4.1. by mode 功能需求分类

5.4.2. by user class

5.4.3. by object

5.4.4. by feature

5.4.5. by stimulus

1. 根据刺激和不同的相应

5.4.6. by functional hierarchy

5.4.7. multiple organization

6. 其他注意

1. alt是多选一，必选，将两个部分划分开。