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

06-需求分析方法

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.1.1. 外部实体

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

3.4.1.2. 过程 Process

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

3.4.1.3. 数据流 Data Flow

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

3.4.2. 数据流图的语法规则

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

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

3.4.3. 数据流图的分层结构

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

3.4.3.2. 0层图

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

3.4.3.4. N层图

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

3.4.4. 数据流图的分层

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

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 ?oor
   7. structures:employee record

3.5.2. Data Objects and Attributes 属性

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

3.5.3. Relationship 关系

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

3.5.4.2. 键(Key)

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

3.5.5. 实体关系图实例

4.2. 需求与用例

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

4.3. 用例(重要)

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

4.3.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. 关系

4.4.2.3. 细化用例

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

4.4.2.4. 常见错误

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

4.4.2.5. 完整实例

4.4.3. 用例文档模板

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

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

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. 如果类之间存在关联，则类的实例之间存在链接(依赖项)

4. 使用空心箭头

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

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

4.5.6. 候选类识别

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

4.5.8. 识别关联

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

4.5.9. 识别重要属性

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

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

4.7. 顺序图(交互图)

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

4.7.1. 顺序图的图例

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

4.7.2. 系统顺序图

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

4.8. 状态图

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

4.8.3. 创建状态图的步骤

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

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

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

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

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

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

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

5.2. 概念类图有助于发现

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

5.4. 建?系统需求

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

5.4.1. by mode 功能需求分类