第六章 需求分析方法
1.建立用例图
参与者是与开发的系统进行交互的用户或其他系统等角色
用例图中一个单一的参与者可以代表多个用户（或系统）
一个单一的用户（或系统）可能扮演多种角色
参与者不一定是人，例如，需要从当前系统获取信息的外部系统也是参与者
步骤：1）目标分析与解决方向确定 2）寻找参与者 3）寻找用例 4）细化用例
【示例1】
×××连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门面店。
首先是随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。其次是商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废的现象上升明显。再次是商店面临的竞争比以前更大，希望在降低成本，吸引顾客，增强竞争力的同时，保持盈利水平。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：帮助收银员处理销售与退货任务从上述特性可以发现涉及的用户类别：总经理，客户经理，收银员，管理员
总经理的目标有：产品调整（增删改产品信息），特价策略制定（增删改特价策略），赠送策略制定（增删改赠送策略），库存分析；（分析可能的商品积压）
客户经理的目标有：会员管理；（会员发展、礼品赠送），库存管理；（商品入库、出库和库存分析）
收银员的目标有：销售处理（销售），退货；（退货）
管理员的目标有：用户管理（增删改用户信息）
如果用例的粒度不合适就需要进行细化和调整。判断标准是：用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务。
不要将没有业务价值（而是技术实现需要）的事件作为用例（例如，登录（安全性需求）、输入/输入数据检查（数据需求或者业务规则）、连接数据库、网络传输等等）
不要将没有独立业务价值的单个操作（仅仅是技术实现上独立）作为用例，例如删除、增加、修改、保存
总经理的目标有：特价策略制定、赠送策略制定两个用例的业务目的、发起源和过程基本相同，仅仅是业务数据不同，所以可以合并为一个用例销售策略制定。
客户经理的目标有：会员管理用例有两个明显不同的业务事件，可以被细化为发展会员和礼品赠送2个更细粒度的用例。
客户经理的库存管理用例也有三个不同的业务目标：出库、入库和库存分析，所以也应该细化为三个用例商品出库、商品入库和库存分析，其中库存分析用例与总经理的库存分析用例相同。
【常见错误】
不要将用例细化为单个操作
不要将单个步骤细化为用例
不要将片面的一个方面细化为用例
不要将“登录”、“数据验证”、“连接数据库”等没有业务价值的内容作为用例
【示例2】
网上书店系统（OBS）是一个基于web的应用程序，允许用户浏览和购买网上产品。该应用程序支持网上购物车的概念，类似于其他网上零售商，如Amazon.com,。该系统的结账功能将集成信用卡交易处理以及内部计费系统。该系统还提供管理员视图，允许授权的员工查看和管理产品、用户和订单。
用户：购买、浏览
员工：查看用户、订单、产品管理
管理员：授权
信用卡：结账
内部计费：结账
注意：内部计费指的是单位内部，而不是系统内部
2.建立分析类图（概念类图／领域模型）
注意：与设计类图有所不同，分析类图关注现实世界问题域，而不是软件系统的内部构造机制；
类型、方法、可见性等复杂的软件构造细节不会在概念类图中，不允许出现与现实无关的内容
对象：标识（对象自治、对象请求协作）、状态（存储数据，如密码、名称……）、行为（利用数据做什么）
链接：对象间交互的路径（a拥有b的引用——a拥有b的可见性——a可以导航到b）
类：对象的集合
关联：潜在的链接抽象
要写出分析的步骤：
1）识别候选类（名词分析法）
2）确定概念类 （看是否满足既有状态又有行为）
既需要维持一定的状态，又需要依据状态表现一定的行为——确定为一个概念类
如只需要维护状态，不需要表现行为——其他概念类的属性
不需要维护状态，却需要表现行为——首先重新审视需求是否有遗漏，因为没有状态支持的对象无法表现行为；如果确定没有需求的遗漏，就需要剔除该候选类，并将行为转交给具备状态支持能力的其他概念类
既不需要维护状态，又不需要表现行为——应该被完全剔除
3）识别关联（文本中提取出“名词＋动词＋名词”的结构）
第一标准是满足需求的要求，第二标准是现实状况
4）识别重要属性
概念类图只需要用到四种关系线：
聚合关系不必可以使用，但是组合关系要适当的使用
继承关系、组合关系、聚合关系、普通关联
【示例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】
- 顾客向系统提起查询请求
- 系统根据请求为顾客提供一个CD的推荐列表
- 顾客在推荐列表中选定一个CD，然后要求查看更详细的信息
- 系统为顾客提供选定CD的详细信息
- 顾客购买选定CD.
- 顾客离开
分析：
查询请求：有状态、有行为
顾客和CD：看戏球，不确定是否存储详细信息
推荐列表：有状态、有行为（增删改）
3.建立系统顺序图（交互图）
步骤：1）确定上下文环境 2）根据用例描述找到交互对象 3）按照用例描述中的流程顺序逐步添加消息
同步消息、异步消息、返回消息
注意：
（1）异步消息的箭头无论是从用户到系统还是从系统到用户都是一样的
（2）opt标签表示可选；loop标签表示循环，要在旁边用［］内写循环条件；alt标签表示候选（基本上只会放一次返回消息），每一种可选分支之间要用虚线分割，而且在表示执行态的圆柱上面要写监护条件，放在［］里面。
4.建立状态图
状态: 一组观察到的情况，在一个给定的时间描述系统行为
状态转换: 从一个状态到另一个状态的转移
事件: 导致系统表现出可预测行为的事件
活动: 作为产生转换的结果而发生的过程
步骤：1）确定上下文环境 2）识别状态 3）建立状态转换 4）补充详细信息，完善状态图
注意：并不是所有的状态图都有开始态和结束态，开始态通常只有一个，结束态可以有多个
【示例】明确状态图的主体：用例UC1销售处理。
空闲状态（开始状态）：收银员已经登录和获得授权，但并没有请求开始销售工作的状态；
销售开始状态：开始一个新销售事务，系统开始执行一个销售任务的状态；
会员信息显示状态：输入了客户编号，系统显示该会员信息的状态；
商品信息显示状态：刚刚输入了一个物品项，显示该物品（和赠品）描述信息的状态；
列表显示状态：以列表方式显示所有已输入物品项（和赠品）信息的状态；
错误提示状态：输入信息错误的状态；
账单处理状态：输入结束，系统显示账单信息，收银员进行结帐处理的状态。
销售结束状态：更新信息，打印收据的状态。
第七章 需求文档化与验证
1.为什么建立需求规格说明？结合试验说明
（1）软件开发过程中，子任务与人员之间存在错综复杂的关系，存在大量的沟通和交流，所以要编写软件开发中要编写不同类型的文档，每种文档都是针对项目中需要广泛交流的内容。因为软件需求需要进行广泛交流，所以要把需求文档化。
（2）需求规格说明是在软件产品的角度以系统级需求列表的方式描述软件系统解决方案
用例侧重于交互流程，规格（解决方案）侧重于独立需求
用例以一次交互为基础，规格需求以一次交互中的软件系统处理细节为基础
2.对给定的需求规格说明示例，判定并修正其错误。
首先了解需求文档化要点：
1）技术文档写作要点（简洁，精确，易读，易修改）；
2）需求书写要点（使用用户术语，可验证，可行性）；
3）需求规格说明文档书写要点（充分利用标准的文档模板，保持所以内容位置得当；保持文档内的需求集具有完备性和一致性；为需求划分优先级）
【错误示例】
付款过程完成后，相关信息应被添加到日志文件
该系统应被构造成将来很容易添加新功能
计算购买的汽油的价格：该类汽油每加仑的价格乘以购买的加仑数（使用两位小数点表示加仑小数部分）
该系统一周7天，一天24小时都可用
3.给定的需求示例，设计功能测试用例
结合测试方法
链接
👉软件工程与计算II重点整理(第1-5章)
👉软件工程与计算II重点整理(第8-11章)
👉软件工程与计算II重点整理(第12-15章)
👉软件工程与计算II重点整理(第16-19章)
👉软件工程与计算II重点整理(第20-23章)