文章目录
需求分析基础
为什么要需求分析
- 如图
从对问题的描述（需求获取的结果）到对解决方案的描述之间（需求开发的目标）有一段gap，这段gap就是由需求分析来填充
需求获取：用户的理解、问题的描述；向用户获取他们对问题域的理解、描述
需求开发目标：共同的理解、解决方案的描述；共同理解指需求人员、用户、开发人员的共同理解；需求开发的目标是需求阶段的结果
用户能够描述的是自己的业务，反而他们对如何用计算机技术解决业务问题的理解不深刻
所有需求的结果都不是用户提出来的，都是需求工程师来做的；需求阶段的结果是解决方案；需求开发完毕应该得到对解决方案的描述 - 需求分析的任务
建立分析模型，达成开发者和用户对需求信息的共同理解
分析模型：促进共识；是经整理而得，是一些图；更容易与用户达成共同理解
依据共同的理解，发挥创造性，创建软件系统解决方案
需求分析模型
需求分析模型与建模
- 模型是什么：（一种抽象化的概念，是解决方案的一种表达）
“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解” - 建模：建立模型的过程被称为建模
“他是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易”
建模常用手段
- 抽象(abstraction)：指逻辑层次上更高的抽象
- 分解(decomposition/partitioning)：分解成小任务
注：分解、抽象都是降低复杂度的方法，是更高层、更抽象的概念
需求开发过程中的需求分析模型
如图
- 需求获取信息：直接获取来的、未经整理的信息
- 问题域语言：用问题域语言表示需求
- 软件内部实体：类们
- 分析模型
从文字到类图的中间过程、从问题域语言到软件内部实体
此例中，分析模型为E-R图；表达出来实体、关系、多重性等信息；用E-R图将前面的问题域语言“每本书都至少有一个作者”这个信息表达清楚；有了这样的分析模型，再根据经验，产生软件内部实体（类图）
常见分析模型
| 方法 | 模型 | 描述 |
|---|---|---|
| 结构化方法 | 数据流图(Data Flow Diagram) | 从数据传递和加工的角度，描述了系统从输入到输出的功能处理过程 运用功能分解的方法，用层次结构简化处理复杂的问题 |
| 结构化方法 | 实体关系图(Entity Relationship Diagram) | 描述系统中的数据对象及其关系，定义了系统中使用、处理和产生的所有数据 |
| 面向对象方法 | 用例图(Use-Case Diagram) | 描述用户与系统的交互 从交互的角度说明了系统的边界和功能范围 |
| 面向对象方法 | 类图(Class Diagram) | 描述应用领域当中重要的概念以及概念之间的关系 他捕获了系统的静态结构 |
| 面向对象方法 | 状态图(State Diagram) | 描述系统、用例或者对象在其整个生命期内的状态变化和行为过程 |
| 面向对象方法 | 交互图/顺序图(Interaction/Sequence Diagram) | 描述系统中一次交互的行为过程，说明了在交互当中的对象协作关系 |
面向对象分析
面向对象分析的简单过程
如图所示
- 先绘制系统用例图
系统用例图描述的是系统与外部的交互 - 再绘制用例图，进行用例描述
用例图和用例描述：以系统用例图为根据，细化系统的对外交互；系统用例图细化成文字形式 - 绘制概念类图，创建领域模型
概念类图/领域模型：从用例描述出发，明确用例中的协作对象们，看用例中对象间有哪些协作，得到静态的概念类图/领域模型 - 绘制交互图/顺序图，状态图，对象约束语言
交互图/用例图、状态图、对象约束语言：从用例描述中，明确用例中的协作行为，看看对象如何协作，得到动态的这些图 - 注意：这些图都是建模方式之一，具体应用时根据当前系统的特点与需求来进行选择，选择用哪种方式或哪几种方式
用例图与用例描述
需求与用例
-
传统来讲，需求是一种在客户与开发者之间的契约式文档，但是需求们难以获得、难以以契约形式展现
-
1992年，用例的方法被引入，进行了面向对象的分析设计
-
用例定义
Jacobson：“在系统（或者子系统或类）和外部对象的交互当中所执行的行为序列的描述，包括各种不同的序列和错误的序列，他们能联合提供一种有价值的服务”
Cockburn：“用例描述了在不同条件下系统对某一用户的请求的响应；根据用户的请求和请求时的系统条件，系统将执行不同的行为序列，每一个行为序列被称为一个场景；一个用例是多个场景的集合” -
对用例定义解释
用例侧重于表达交互
用例是用来表达需求的；用例是对需求的组织和表达；需求是获取来的
用户混乱的话经过组织，交给开发人员（开发人员得到的是梳理好的、严格描述的需求）；这个过程需要对需求进行组织和表达——用例就是组织和表达的方法之一；这种组织和表达：利于理解、利于后面的进一步分析 -
目标、交互与行为序列
如图，基础用例
如图，真实用例
最基础时，如Action1: “The Customer identifies themselves”
是一个含糊的需求
而真实用例里，就是一系列具体精确的动作
这样的好处：
抽象角度上有利：一个东西一点一点做细化，同一时刻的注意力就更加集中在当前的整体任务上
增加可修改性：可能以后有新的实现时，在基础阶段的这样的描述（只说验证身份没说具体验证身份方法）可以涵盖新的实现 -
案例
连锁超市管理系统的收银员为了完成一次销售任务，会使用软件系统处理销售过程，那就可以建立一个用例“销售处理”；考虑到实际销售时的不同条件，会发生不同行为：
- 在一切顺利时是一种正常行为流程
- 购买多个同样商品时可以逐一输入每个商品，也可以分别输入商品号与数量
- 销售过程中可能会发现某个商品无法识别
- 有可能一个商品被纳入销售清单后用户又提出退回
上述的每一个行为都是一个场景，所有的行为联合起来就构成了场景的集合——用例，用例的目标与价值是完成销售任务
用例图的基本元素
参与者(Actor)
- 参与者是与本系统有交互的外界角色（可能是人，系统）
- 用例图中的一个参与者角色可以代表实际上的多个人或系统
- 同一种用户（人、系统）在本系统中可能有多重角色
- Again，参与者不一定是人，也可能是系统
用例(Use Case: requirements in context)
- 用例是场景的集合；每个场景是用户与系统的交互行为
- 用例是表达需求的一种形式
- Use cases represent typical sets of scenarios that help to structure, relate and understand the essential requirements
- Scenarios are descriptions of how a system is used in practice; Typical interactions between a user and a computer system
关系(Relationship)
如图例
- 关联关系(Association)：直线表示
- 多重性(Multiplicity)：*表示
- 继承关系(Generalization)：（泛化关系的一种）空心三角实心箭头实线表示
导游也是passenger - 包含关系(Include)：（组合关系的一种）鱼骨箭头虚线表示
整个团队的check-in行为包括每个个体的check-in行为 - Extend：（泛化关系的一种）鱼骨箭头虚线表示
个体的check-in行为之中还涉及行李的check-in - 关系表示中
如果能分辨出来各个关系，就细细地画
如果不能分辨出来，索性就不细画（直接直线连接就好）
系统边界(System Boundary)
- 系统边界界定哪些需求是系统要做的、哪些需求是不做的
- 用例在系统内，参与者在系统外（来交互）
有一些参与者也在系统内部，如ATM机系统中的银行系统就是系统内部的参与者
用例图的建立
目标分析与解决方向的确立
- 目标是问题的解决和期望；通过目标产生业务需求、系统功能
- 以超市销售系统为案例阐释
目标分析：
xxx连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门店
问题一：随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重
问题二：商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废现象上升明显
问题三：商店面临的竞争比以前更大，希望再降低成本，吸引顾客，增加竞争力的同时保持盈利水平
业务需求
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: 帮助收银员处理销售与退货任务
寻找参与者与用例
**每个用户的任务（目标）都是一个独立用例
- 案例的用户的目标
- 总经理的目标有：
– 产品调整（增删改产品信息）
– 特价策略（增删改特价策略）
– 赠送策略制定（增删改赠送策略）
– 库存分析（分析可能的商品积压）- 客户经理的目标有：
– 会员管理（会员发展、礼品赠送）
– 库存管理（商品入库、出库和库存分析）- 收银员的目标有：
– 销售处理（销售）
– 退货（退货）- 管理员的目标有：
– 用户管理（增删改用户信息）
- 超市销售系统用例图（细化之前）
细化用例
- 如果用例的粒度不合适就要进行细化和调整
- 用例的判断标准是：用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务
- 是否是用例可以看4点
是否是交互；是否是一系列行为序列；是否是不同的行为序列；是否体现业务价值 - 细化常见错误
不要将用例细化为单个操作，如用户管理（增删改）不要再细化成增、删、改三个，因为单独的增或删或减不能体现业务价值（增删改合在一起才能体现业务价值——此处是管理）
不要将同一业务目标细化为不同的用例（如特价策略制定和赠送策略制定）
不要将没有业务价值的内容作为用例（如登录——质量需求（安全性）、数据验证——数据需求、连接数据库——软件内部实现而不是需求） - 超市销售系统案例中：
特价策略制定、赠送策略制定两个用例的业务目的、发起源和过程基本相同，仅仅是业务数据不同，所以可以合并为一个用例销售策略制定
会员管理用例有两个明显不同的业务事件，可以被细化为发展会员和礼品赠送两个更细粒度的用例
客户经理的库存管理用例也有三个不同的业务目标：出库、入库和库存分析，所以也应该细化为三个用例商品出库、商品入库、库存分析，其中库存分析与总经理的库存分析用例相同 - 超市销售系统案例的用例图（细化之后）
用例模版
项目与内容
- 用例模版中的项目与内容
| 项目 | 内容描述 |
|---|---|
| ID | 用例的标识 |
| 名称 | 对用例内容的精确描述，体现了用例所描述的任务 |
| 参与者 | 描述系统的参与者和每个参与者的目标 |
| 触发条件 | 标识启动用例的事件，可能是系统外部的事件，也可能是系统内部的事件，还可能是正常流程的第一个步骤 |
| 前置条件 | 用例能够正常启动的系统状态条件 |
| 后置条件 | 用例执行完后的系统状态条件 |
| 正常流程 | 在常见和符合预期的条件下，系统与外界的行为交互序列 |
| 扩展流程 | 用例中可能发生的其他场景 |
| 特殊需求 | 和用例相关的其他特殊需求 |
- 说明
ID具有唯一性：本文档中唯一；甚至整个项目也唯一（这样就可以在其他文档中通过此标识进行引用）
触发条件：该事件一发生，用例就启动
（注意前世条件与触发条件的区别） - 例
后置条件一般涉及一些持久化工作
前后置条件如果没有合适的就不写，不要乱凑
续例
更正：正常流程后半段应该序号从6开始（保持每步骤序号唯一）
编号很重要，不能重复
步骤1和步骤6中不具体写怎么开始或结束，就写做什么不用写怎么做（怎么做是后面的事）
流程最好写成“收银员……”、“系统……”交替行为交互动作的描述
续例
续例
- 上例用例中的一些问题
顾客为什么不是参与者？
– 顾客没有真正与系统进行交互，直接操作系统的人是收银员；又如自助收银系统中，顾客就是参与者
上传下载为什么不是用例？
–用例的4个衡量标准“有否交互”、“是否是一系列行为序列”、“是否是不同的行为序列”、“是否体现业务价值”；不符合“有交互”，因为上传下载都是系统内的动作，交互指系统内外的交互
系统可不可以分为服务器端和客户端两个系统？
–表达需求时不分服务器端和客户端（两端是实现细节）
UML图中用例图的作用
用例图是承接需求的文档描述和其他模型（活动图，交互图，类图）的桥梁
概念类图
概念类图简介
- 概念类图又被称为“领域模型(Domain Model)”
- 类图是面向对象分析方法的核心，描述类（对象）和这些类（对象）之间的关系
- 概念类图与设计类图有所不同，他关注系统与外界的交互，而不是软件系统的内部构造机制
即概念类图表征交互而非表征实现
概念类图更接近业务，而非软件实现 - 类型、方法、可见性等复杂的软件构造细节不会在概念类图中
概念类图与设计类图不保证完全对应
概念类图的基本元素
概述
- 对象
标识符
状态
行为 - 类
对象集合的抽象 - 链接(Link)(Dependency)
对象之间的互相协作的关系
描述了对象之间的物理或业务联系 - 关联
对象之间链接的抽象 - 继承
泛化关系
关联与依赖
- 这两种关系的区别
一类用到另一类就是对另一类依赖
关联关系涉及到持有对方引用
关联关系强于依赖关系 - Two analysis classes are often related to one another in some fashion
In UML these relationships are called associations
Associations can be refined by indicating multiplicity (the term cardinality is used in data modelling) - If there are associations between classes, then there are links(dependencies) between instances of the classes
- 案例
(a)中，*表示一个收银员可以对应多个销售
(b)中，聚合关系表示的是整体与部分的关系
(c)中，组合关系表示的是整体与部分的关系&生命周期的关系
继承
- 继承代表一种泛化关系
泛化：父类与子类；子类得到父类的属性 - Organise the domain object classes into a hierarchy
- Classes at the top of the hierarchy reflect the common features of all classes
- Object classes inherit their attributes and services from one or more super-classes, these may then be specialised as necessary
- 案例
建立概念类图
建立概念类图的流程
建立概念类图的目的：在文字内容（用例描述）与设计内容之间找到中间状态；以文字转换成中间状态，再从中间状态转化到设计；概念类图就是这个中间状态；概念类图的输入是用例的文本描述
从用例文本描述到概念类图需要以下两步：
- 对每个用例文本描述，尤其是场景描述，建立局部的概念类图（即这个用例涉及哪些类）
根据用例的文本描述，识别候选类
筛选候选类，确定概念类
识别关联
识别重要属性 - 将所有用例产生的局部概念类图进行合并，建立软件系统的整体概念类图（子图们合并成大图，合并时要消除重复）
概念类图描述需求，类中保存着需求的信息、状态等
概念类图没有方法只有属性
候选类识别
一般找名词
- 发现软件系统与外界交互时可能涉及的对象与类，他们就是后选类
- 行为分析、名词分析、CRC等很多种方法都能用来分析用例文本描述
- 案例：超市销售系统中的名词分析
确定概念类的准则
- 依据系统需求
- 该类对象实例的状态与行为是否完全必要
候选类向概念类的转化
- 候选类对象既要维持一定状态，又要依据状态表现一定行为：确定为一个概念类
- 候选类对象只需要维护状态，不需要表现行为：作为其他概念类的属性
- 不需要维护状态，却需要表现行为：首先要重新审视需求是否有需求，因为没有状态支持的对象无法表现行为；如果确定没有需求的遗漏，就需要剔除该候选类，并将其行为转交给具备状态支持能力的其他概念类
- 既不需要维护状态，又不需要表现行为：应该被完全剔除
- 案例：超市销售系统生成概念类
识别关联
按照各种关联的定义来识别、匹配；重点关注组合/聚合、继承关系
- 分析用例文本描述，发现概念类之间的协作，需要协作的类之间需要建立关联
- 分析和补充问题域内的关系，例如概念类之间的整体部分关系和明显的语义联系（对问题域关系的补充要适可而止，不要把关系搞的过度复杂）
- 去除冗余关联和导出关联
- 案例：超市销售系统的关联分析与识别关联后的概念类图（初步）
- 识别关联后
关联与需求有关系：通过文字内容（需求、用例描述）就在识别关联后的图上检查，检查图上是不是有文字的所有内容，以此来检查需求是否被实现
识别重要属性
- 这些属性往往是实现类协作时必要的信息，是协作的条件、输入、结果或者过程记录（类们在协作时要用到的属性）
- 通过分析用例的描述，并与用户交流，补充问题域信息，可以发现重要的属性信息
识别属性之后，可以根据属性来补充问题域信息，更加丰富地描述需求的信息 - 在分析每个单独的用例（场景）描述时，为各个概念类发现的重要属性可能不多，甚至有些概念类没有任何重要属性；但是，系统通常有多个用例和很多场景，会建立多个局部的概念类图，只有在合并所有局部概念类图之后，各个概念类的重要属性才能得到全面的展现
- 案例：超市销售系统
概念类图绘制好之后，一定要检查改图足不足够表达需求，也是检查分析或设计有否遗漏之处
顺序图
用例模型与对象模型之间的鸿沟
如图
用例模型与对象模型之间有gap：
概念类图表现类与类之间的静态关系
顺序图表现动态关系
顺序图
- 顺序图是活动图的一种，代表动态关系，是一种行为的模型，表达的是系统的行为和动态的动作（通常以用例为单位来表示）
- A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case
- Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects
- 需求分析阶段，主要通过系统顺序图表达系统和外部参与者之间的交互行为
- 顺序图示例
这个顺序图画的是系统内部的交互（即表现的是对象和类之间的交互）
如图，指示为“对象”的部分里，有下划线的表示是对象，没有下划线的表示是一个类；name代表对象名，class代表该对象的类名
如图，指示为“组合段”的部分：组合段是一个框，有多种组合段，分别代表不同语义（opt表示optional，可选/可不选；alt表示alternative，多选一/必选一；loop代表循环等等） - 又一张顺序图示例
ref方框：表示交互引用
如图所示“循环条件”，此例中意为“如果能够得到下一个东西就一直循环”
如图所示“可选分支”，中间虚线代表供选择的两种方案
alt的选择涉及监护条件，此处意为“满足available时选第一个，满足unavailable时选择第二个”
消息种类
- 同步消息：发一个指令过去，自己就不执行了，由对方来执行；待对方执行完毕自己再执行
- 异步消息：发一个异步消息过去，之后还是各做各的（对方还有可能给自己发消息），相对不会受影响
系统顺序图
- 系统顺序图是在需求分析最开始时画的
- 系统顺序图画的是参与者与系统的交互，即外界与系统的交互是什么样（内部如何处理不管，如某对象访问数据库得到什么在如何如何……这些内部细节不管）
- 系统顺序图示例
状态图
状态图
-
状态图本意是表示软件如何对外界时间进行响应，“什么状态以后遇到什么事做什么事情”（通常以用例为单位做图）
-
从“不同状态——>做不同事（事件响应）——>状态切换（状态响应）”这种模式中抽象出模型
-
案例：小明的一天
int main(){ int state = GET_UP; while(1){ switch(state){ case GET_UP: get_up(); state = GO_TO_SCHOOL; break; case GO_TO_SCHOOL: go_to_school(); state = HAVE_LUNCH; break; case HAVE_LUNCH: have_lunch(); state = GO_HOME; break; ... default: break; } } return 0; }从该案例中抽象出状态流动模型如图：
状态图的几个概念
- 状态(State)：观察到的特性/属性在特定时间内的值
- 状态迁移(State transition)：状态从一个转换到另一个
- 触发器事件(Event)：致使系统发生可预测变化的事情
- 动作(Action)：碰到一个事件后会发生的动作；process that occurs as a consequence of making a transition
- 状态图示例：
触发器事件的发生使状态发生转移
监护条件与事件发生的后的活动常常相关联：此处意为“stop事件发生，监护条件满足normal就做某活动（亦满足别的值会做另一活动）” - 状态图的另一示例
建立状态图
- 确定上下文环境
状态图是立足于状态快照进行行为描述的，因此建立状态图时首先要搞清楚状态的主体，确定状态的上下文环境；常见的状态主体有：类、用例、多个用例和整个系统
整个状态图是立足于状态的行为描述的，需求中的描述（用例的文字描述）很重要
要识别主题是谁，如上一张图中，主体是“一个处理订单的逻辑或人”；或者主体还可能是整个系统，“什么状态下做什么事” - 识别状态
状态主题会表现出一些稳定的状态，他们需要被识别出来，并且标记出其中的初始状态和结束状态集；在有些情况下，可能会不存在确定的初始状态和结束状态 - 建立状态转换
转移是稳定状态间的切换；根据需求所描述的系统行为，建立各个稳定状态间可能存在的转换 - 补充详细信息，完善状态图
添加转换的触发事件、转换行为和监护条件等详细信息 - 案例：超市销售系统的销售处理用例的状态图的建立过程
销售流程有状态；流程的流转有状态迁移
明确状态图的主体：用例UC1销售处理
识别用例UC1销售处理可能存在的稳定状态
- 空闲状态/开始状态：收银员已经登录和获得授权
- 销售开始状态：开始一个新销售事务，系统开始执行一个销售任务的状态
- VIP顾客信息显示状态：输入了客户编号，系统显示该VIP顾客信息的状态
- 商品信息显示状态：刚刚输入了一个物品项，显示该物品（和赠品）描述信息的状态
- 列表显示状态：以列表方式显示所有已输入物品项（和赠品）信息的状态
- 错误提示状态：输入信息错误的状态
- 账单处理状态：输入结束，系统显示账单信息，收银员进行结账处理的状态
- 销售结束状态：更新信息，打印收据的状态
建立状态转换示例如下表
规则：如果第i行第j列的元素被标记为Y，则表示第i行的状态可以转换为第j列的状态
注：状态转换表是一种辅助工具，服务于本步骤“建立状态转移”
| 空闲 | 销售开始 | VIP顾客信息显示 | 商品信息显示 | 错误提示 | 列表显示 | 账单处理 | 销售结束 | |
|---|---|---|---|---|---|---|---|---|
| 空闲 | Y | |||||||
| 销售开始 | Y | Y | Y | Y | ||||
| VIP顾客信息显示 | Y | |||||||
| 商品提示信息 | Y | |||||||
| 错误提示 | Y | |||||||
| 列表显示 | Y | Y | Y | Y | ||||
| 账单处理 | Y | Y | ||||||
| 销售结束 | Y |
- 案例：超市销售系统的销售处理用例的状态图成品
结构化分析
结构化分析简述
结构化方法的历史
- 结构化方法是针对60年代到80年代软件开发界所面临的问题提出一系列分析、设计和编码的技术方法
- 关键是软件的复杂度的急剧上升，对代码结构的要求也越来越高
- 结构化方法本意是用来解决面条式代码的问题，希望代码可以有更好的结构、更好的表达
- 年鉴
结构化编程——1967
结构化设计——1975
结构化分析——1978
Information Engineering——1990
结构化分析的思想
- 思想：自顶向下，逐步求精
- 结构化分析：
从获取来的需求开始分析——需求是业务领域的模型
设计在分析之后——设计是软件领域的模型
分析是刚获取来的需求与软件设计之间的桥梁
结构化分析的简单过程
如图
先画上下文图，目标是：发现业务中的事件和事物，之后兵分两路：
发现业务中的事件；这些事件形成事件列表/功能列表；事件列表/功能列表可以用来描述业务事件；对业务事件的描述可以用来做数据流图/状态转移图——这是动态的模型
发现业务中的事物；这些事务形成概念列表；概念列表可以用来描述业务事物；对业务事物的描述可以用来做实体关系图——这是静态的模型
上下文图
上下文图是结构化需求分析方法里的最早的图
以此图为例，本系统是连锁超市销售系统
对外与外部实体们（人或其他系统）进行交互，传递的是信息
数据流图
数据流图简述
- 数据流图将系统看作是过程的集合
- 过程就是对数据的处理
处理：接受输入，进行数据转换，输出结果 - 事件的过程：输入——>处理——>输出；具体在处理过程中做复杂化和细化
- 数据流图展现了数据对象是如何在系统中变化和转移的
- 可能需要和软件系统外的实体尤其是人进行交互
- 数据的变化包括：被转化、被存储、被分布
- 所有以计算机为基础的系统都是一种信息的转化过程，如图：
数据流图的基本元素
两种图例
两种表示方法，其实都是同种内容
外部实体(External Entity)
- 外部实体作为信息的生产者和消费者，他们既生产信息，又接收信息
- 外部实体可能是人也可能是系统
- 数据必须从某处被产生（有源头），必须被送给某方（有目的）
过程(Process)
过程是数据处理的主要工作内容
- 做数据转化和计算工作
- Example: compute taxes, determine area, format report, display graph
Data must always be processed in some way to achieve system function
数据流(Data Flow)
数据流流经系统，开始状态是输入数据，之后被转化为输出数据
如图
图中的圆就是数据处理过程(Process)
数据存储(Data Store)
有时会涉及数据存储问题
如图
此例是查询数据的用例
数据流图的基础语法规则
- 过程是对数据的处理，必须有输入，也必须有输出，输入数据集应该和输出数据集存在差异
第一行错在没有输入数据集
第二行错在没有输出数据集
第三行错在输入数据集与输出数据集没有差异 - 不允许数据流之间直接相连，必须要经过过程
数据流必须是和过程产生关联的，他要么是过程的数据输入，要么是过程的数据输出
所有的对象都应该有一个可以唯一一个标示自己的名称
数据流图的分解、分层
数据流图的分层结构
如图
从上下文图开始：上下文图是最顶层
上下文图
0层图（0层数据流图）
……
n层图（n层数据流图，知道展开到足够细致为止）
建立数据流图
0层图
- 0层图中，同样有外部实体，过程，数据流等
- 根据需求描述，确定操作是什么
- 确定外部实体：外部实体既此用例的数据的产生者和消费者
- 绘图
- 案例
- 0层图中，过程（操作、处理）都是最基本的过程，程度较粗糙
- 操作/处理：会接受、读一些信息，会写一些信息
1层图
- 详细地阅读0层图中的“输入——>处理——>输出”过程们，做进一步分析
- 描述某个较模糊的处理过程，变成一系列另一层面的过程们
- 绘图
- 案例
- 输入、处理、输出；对处理进行分层细化
- 案例：超市销售系统的案例
本例中，原来的0层图中的过程2被细化成2.1、2.2等等等
若后续还有2层图等，就进一步细化，过程序号为2.1.1、2.1.2等
分解规则
细化过程中，遵循平衡原则
图中，父过程的输入流为a，父过程输出流为b，子图的输入流为a和c，输出流为b这样，他们的输入流就存在差异，破坏了平衡性
实体关系图(ERD)——数据的建模
实体关系图概述
- 实体关系图展示了：实体；实体内部属性；实体之间的关系
如图
- 实体关系图的图形表示
注：标识符属性类似主键 - 实体关系图的实例
实体
- 实体：有属性、状态、数据、角色/行为、与其它实体关系的，能在软件系统内操作的东西
- 常见的实体
外部实体，如：printer，user，sensor
普通事物，如：reports，displays，signals
抽象事件，如：interrupt，alarm
角色，如：manager，engineer，salesperson
组织单元，如：devision，team
地点，如：manufacturing floor
结构，如：employee record
其中：前两类有可能是业务里存在的；第三类可能是业务里没有，被我们抽象而得
这些实体代表一定角色，有一定的状态，代表一定行为 - 数据实体应该有属性，属性展示的是他自己
- 键：实体的一个或者多个属性，能够唯一确定和标示每一个实例，这些属性或者属性组合被称为实体的标识符，或称“键”
关系
- 关系将实体们连接/关联
- 关系具有多重性
建立实体关系图
- 找出实体
- 建立联系
- 补充信息（属性、关系种类等）
使用需求分析方法细化和明确需求
概述
面向对象分析、结构化分析都是需求分析方法，根据的是对需求的描述
需求分析的目标是：细化和明确需求内容；建立系统需求
细化和明确需求
- 为什么要细化
用户需求的描述的模糊性和系统设计所需要的严谨性之间的矛盾（差距） - 如何细化
需求分析建模
发现其中的遗漏、冲突、冗余和错误
发现遗漏、冲突、冗余和错误后会返工——迭代过程（获取、分析、获取、分析……） - 如在面向对象方法里，用例是需求的组织和表达（描述需求的），没强调是用某种严格的语言或形式表达出来，写的时候还是自然语言，还存在模糊性，这些模糊性在建模时来考虑如何做进一步完善
- 系统顺序图有助于发现交互性的缺失
看流程
画图发现，用例描述中的1、2之间缺少了系统的回复 - 概念类图有助于发现：部分信息的使用不准确；部分信息不明确；遗漏了重要内容
部分信息的使用不准确：例如步骤2中输入的是商品标识而不是商品；步骤5显示的是已输入商品的列表信息和总价
部分信息不明确：例如会员信息、商品信息、商品列表信息、赠品信息、更新的数据、收据等等各自的详细的内容并没有描述
遗漏了重要内容：例如总价的计算需要使用商品特价策略和总额特价策略，赠品的计算需要使用商品的赠送策略和总额赠送策略 - 状态图有助于发现界面的跳转
建立系统需求
概述
- 8种规格说明（相当于8种不同方式）
- 不同的分析方法适合不同的规格说明
By mode
By user class
By object
By feature
By stimulus——刺激相应（重点）
By functional hierarchy——功能性层次结构
Multiple organisation
7923
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
