4.需求工程
需求工程概述
- 软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望
- 软件需求是指用户解决问题或达到目标所需的条件或能力,是系统或系统部分要满足合同、标准、规范、或其他正式规定文档所需具有的条件或能力,以及反映这些条件或能力的文档说明
需求分类
PIECES框架是系统非功能性需求分类的技术
- 性能
- 性能用于描述企业当前的运行效率,可以分析当前业务的处理速度
- 信息
- 信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种 问题
- 经济
- 经济指标主要是从成本和收益的角度分析企业当前存在的问题
- 控制
- 提高信息系统的安全和控制水平
- 效率
- 提高企业的人、财、物等的使用效率
- 服务
- 提高企业对客户、供应商、合作伙伴、顾客等的服务质量
需求获取
需求获取方法
- 用户访谈
- 1对1-3,又代表性的用户
- 问卷调查
- 用户多,无法一一访谈
- 现场观摩
- 针对较为复杂的流程和操作
- 联合需求计划(JRP)
- 高度组织的群体会议,各方参与,成本较高
- 情节串联板
- 一系列图片,通过这些图片来讲故事
- 收集资料
- 把与系统有关的,对系统开发有益的信息收集起来
- 参加业务实践
- 有效地发现问题的本质和寻找解决问题的方法
- 阅读历史文档
- 对手机数据性的信息较为有用
- 抽样调查
- 降低成本
- 样本大小=α∗(可信度系数/可接受的错误)样本大小 = α*(可信度系数/可接受的错误)样本大小=α∗(可信度系数/可接受的错误)注:α一般取0.25
需求分析
结构化需求分析
数据流图
状态转换图
E-R图
面向对象需求分析
相关概念
-
对象
- 属性(数据)+ 方法(操作)+对象ID
-
类
- 实体类,控制类,边界类
-
继承与泛化
- 复用机制
-
封装
- 隐藏对象的属性和实现细节,仅对外公开接口
-
多态
- 不同对象收到同样的消息产生不同的结果
-
接口
- 一种特殊的类,他只有方法定义没有实现
-
重载
- 一个类可以又多个同名而参数类型不同的方法
-
消息和消息通信
- 消息是异步通信的
-
类是描述具有相同属性、方法、关系和语义的对象的集合,一个类实现一个或多个接口
-
接口是值类或构件提供特定服务的一组操作的集合,接口描述了类或构件对外的可见的动作
-
构件是物理上或可替换的系统部分,它实现了一个接口集合
-
包是一种将又组织的元素分组的机制
-
用例是描述一系列的动作,产生有价值的结果
-
协作定义了交互的操作,是一些角色和其它事务一起工作,提供一些合作的动作,这些动作比事物的总和要大
-
节点是一个物理元素,它在运行时存在,代表一个可计算的资源,通常占用一些内存和具有处理能力
UML
- 静态图(结构图)
- 类图
- 一组类、接口、协作和它们之间的关系
- 对象图
- 一组对象及它们之间的关系
- 构件图
- 一个封装的类和它的接口
- 部署图
- 软硬件之间的映射
- 制品图
- 系统的物理结构
- 包图
- 由模型本身分解而成的组织单元,以及他们之间的依赖关系
- 组合结构图
- 类图
- 动态图(行为图)
- 用例图
- ==系统与外部参与者的交互
- 交互图
- 顺序图
- 强调按时间顺序
- 通信图(协作图)
- 定时图
- 强调实际实践
- 交互概览图
- 顺序图
- 状态图
- 状态转换变迁
- 活动图
- 类似程序流程图,并行行为
- 用例图
用例图
- 用例图描述一组用例、参与者及它们之间的关系
- 用户角度描述系统功能
- 参与者是外部触发因素(包括用户、组织、外部系统、时间)
- 用例是功能单元
- 关系包括
- 包含关系
- 扩展关系
- 泛化关系
- 用例建模的流程
- 识别参与者(必须)
- 合并需求获取用例(必须)
- 细化用例描述(必须)
- 调整用例模型(可选)
包含、扩展、泛化
-
包含关系
- 其中这个提取出来的公共用例成为抽象用例,而把原始用例称为基本用例或基础用例系,当考研冲两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们
B包含于A
-
扩展关系
- 如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样使描述可能更加清晰
B由A扩展
-
泛化关系
- 当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父用例,其它的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系
箭头左边由右边泛化而来
类图与对象图
- 类图
- 类图表述一组类、接口、协作和它们之间的关系
- 对象图
- 对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照
- 类名,方法名,属性名
- 多重度
- 关系
对应关系表示
- 1
- 表示一个集合中的一个对象对应另一个集合中的1个对象
- 0…*
- 表示一个集合中的一个对象对应另一个集合中的0个或多个对象
- 1…*
- 表示一个集合中的一个对象对应另一个集合中的一个或多个对象
- *
- 表示一个集合中的一个对象对应另一个集合中的多个的对象
各类关系
在关系中a指向b,则表示a 通过(包含/扩展/泛化)得到 b
- 依赖关系
- 一个事物发生变化影响另一个事物
- 泛化关系
- 特殊/一般关系
- 关联关系
- 聚合关系
- 整体与部分生命周期不同
- 组合关系
- 整体与部分生命周期相同
- 聚合关系
- 实现关系
- 接口与类之间的关系
顺序图
顺序图的一种交互图,它强调对象之间消息发送的顺序,同时显示对象之间的交互
活动图
活动图将进程或其它计算结构展示位计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要,并强调对象间的控制流程
状态图
状态图描述一个状态机,它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要,而且它强调事件导致的对象行为,这是非常有助于对反应式系统建模
通信图(协作图)
通信图是一种交互图,它强调收发形象的对象或参与者的组织结构。顺序图和通信图表达了类似的基本概念,但它们所强调的概念不同,顺序图强调的是时序,通信图强调的是对象之间的组织结构(关系)
构件图
构件图描述一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构件大的系统来说,构件图是很重要的。构件图是类图的变体
部署图
部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署试图,通常一个节点包含一个或多个部署图
需求建模
需求定义
- 用结构化和自然语言编写文本型文档
- 建立图形化模型
- 编写形式化规格说明
- 严格定义法
- 所有需求都能够被预先定义
- 开发人员与用户之间能够准确而清晰地交流
- 采用图形/文字可以充分体现最终系统
- 原型法
- 并非所有的需求都能在开发前被准确地说明
- 项目参与者之间通常都存在交流上的困难
- 需要实际的、可供用户参与的系统模型
- 由合适的系统开发环境
- 反复是完全需要和值得提倡的,需求一旦确定,就应遵从严格的方法
需求验证
需求管理
需求状态变迁图
需求跟踪
需求风险管理
- 带有风险的做法
- 无足够用户参与
- 忽略了用户分类
- 用户需求的不断增加
- 模棱两可的需求
- 不必要的特性
- 过于精简的SRS
- 不准确的估算