需求分析方法
一、需求分析基础
为什么要需求分析?知识点
需要通过需求分析,将用户的理解、问题的描述转化为共同的理解、解决方案的描述
需求分析的任务:知识点
- 建立分析模型,达成开发者和用户对需求信息的共同理解
- 依据共同的理解,发挥创造性,创建软件系统解决方案
需求分析模型:知识点
常见分析模型:知识点
二、面向对象分析
面向对象分析的过程:知识点
重要:用例是我们软件需求的一种表示或组织的方法之一
用例的定义:知识点
-
在子系统(或者子系统或者类)和外部对象的交互当中所执行的行为序列的描述,包括各种不同的序列和错误的序列,它们能够联合提供一种有价值的服务
-
用例描述了在不同条件下系统对某一用户的请求的响应。根据用户的请求和请求时的系统条件,系统将执行不同的行为序列,每一个行为序列被称为一个场景。一个用例是多个场景的集合
例如:销售处理可以是一个用例。它在一切顺利时是一种正常行为流程。当然,购买多个商品可以分别输入商品号与数量,可能商品无法识别或用户提出退回商品。上述每个行为是一个场景,联合起来构成用例
用例图基本元素:知识点
- 用例
- 参与者
- 关系
- 系统边界
用例图的建立:知识点
- 目标分析与解决方向的确定
- 寻找参与者
- 寻找用例
- 细化用例
超市销售系统用例:
细化:如果用例的粒度不合适就需要进行细化和调整
例如:特价策略制定、赠送策略制定的业务目的、发起源、过程基本相同,仅仅是业务数据不同。可以合并为一个用例销售策略制定
常见错误:
- 不要将用例细化为单个操作(增加、修改、删除)
- 不要将同一个业务目标细化为不同用例(特价和赠送策略制定)
- 不要将没有业务价值的内容作为用例(登录、数据库连接)
用例模板:知识点
例子:
概念类图:知识点
- 又称为“领域模型”
- 类图是面向对象分析方法的核心(描述类和这些类(对象)之间的关系)
- 与设计类图不同:关注系统与外界的交互
- 类型、方法、可见性等复杂软件构造细节不会在其中
基本元素:
建立概念类图:知识点
- 对每个用例文本描述,尤其是场景描述,建立局部的概念类图(先根据用例文本描述识别候选类,筛选候选类,确定概念类,识别关联,识别重要属性)
- 将所有用例产生的局部概念类图合并,建立软件系统的整体概念类图
候选类:软件系统与外界交互时可能设计的对象与类(行为分析、名词分析等)
名词分析:
确定概念类:依据系统的需求/该类的对象实例状态与行为是否完全必要
候选类向概念类的转化:只有既要维持状态又要依据状态表现一定的行为的才需要确定为一个概念类。只有状态:附加为其他概念类的属性;只有行为:审视需求是否有漏洞,如果没有也得剔除;都没有:完全剔除
识别关联
分析用例文本描述,发现概念类之间的协作
其中:三角形表示继承;空心正方形表示聚合;实心正方形表示组合
识别重要属性:
顺序图:知识点
分析阶段,主要是利用系统顺序图,表达系统和外部参与者之间的交互行为。
简单示例:
消息种类:
同步消息是实现,三角箭头。返回消息应该是虚线。Opt是可选项。Loop是循环。alt多选一
状态图:知识点
表明了软件会如何对外部事件做出反应
状态:可观测的情况集合,表明了一定时间内系统的行为的特征
状态转换State translation:从一个状态进入另一个状态
事件Event:导致系统展现出一些可预测的行为的发生的事情
活动Action:作为进行一个转变的序列发生的过程
建立状态图:知识点
- 确定上下文环境(状态图是立足于状态快照进行行为描述的,先要搞清楚状态的主体。状态主体:类、用例、多个用例和整个系统)
- 识别状态:状态主体会表现出一些稳定的状态,需要被识别出来。
- 建立状态转换:根据需求所描述的系统行为,建立各个稳定状态之间可能存在的转换。
- 补充详细信息,完善状态图:添加转换的触发事件、转换行为和监护条件等详细信息
例:销售处理用例状态图:
建立状态转换示例:
其中,y表示可以从i行到j列的状态
三、结构化分析
结构化分析思想:
- 自顶向下分解
- 图(数据流图、实体关系图、状态转移图)
结构化分析的简单过程
数据流图(DFD)
将系统看成是过程的集合;过程就是对数据的处理:接收输入,进行数据转换,输出结果
数据的变化包括:被转换、被存储、或者被分布
数据流图:知识点
数据流图的基本元素:
语法规则:必须有输入和输出,输入数据集和输出数据集需要存在差异;数据流必须和过程产生关系,要么是过程的输入,要么是输出。
分层:上下文图/0层图/N层图
上下文图:
整个系统只有一个过程
0层图
单一过程的细节描述
N层图
0层图的每个过程都可以继续分层
过程分解的平衡原则
必须保证子图的输入输出和父图保持一致
实体关系图:知识点
数据的建模,说明数据的结构、定义和关系等
实体:需要在系统中收集和存储的现实世界事物的类别描述
关系:
例如:
ERD的图形表示:
四、使用需求分析方法细化和明确需求
细化和明确需求:知识点
为什么要细化?
- 用户需求的描述的模糊性和系统设计所需要的严谨性之间的矛盾
如何细化?
- 需求分析建模
- 发现其中的遗漏、冲突、冗余和错误
- 迭代
建立系统需求
需要建立系统与外界的基本交互顺序(刺激,响应)
通常是编号与需求描述的一张表,编号是类名和成员变量/方法