- 名词解释
- 需求
- 区分需求的三个层次
- 给出⼀个实例, 给出其三个层次的例⼦
- 对给定的需求示例, 判定其层次
- 例如课程实验/ATM/图书管理…
- 掌握需求的类型
- 对给定的实例, 给出其不同类型的需求例⼦
- 对给定的需求示例, 判定其类型
- 例如课程实验/ATM/图书管理…
需求工程活动
- 需求开发
- 需求获取: 从人, 文档或环境中获取需求, 从空白建立最初的原始需求
- 目标分析
- 用户需求获取
- 常与需求分析交织进行
- 需求分析: 通过建模来整合各种信息, 使得人们更好地理解问题, 保证需求的完整性和一致性
- 边界分析
- 需求建模
- 需求规格说明: 将完整, 一致的软件解决方案以文档的方式固定下来, 主要目的是在系统用户之间交流需求信息
- 定制文档模版
- 编写文档
- 需求验证: 保证需求规格说明文档的质量, 确保其完整性和一致性, 反映用户的真实意图.
- 同级评审
- 原型/模拟
需求验证之后的软件需求规格说明将作为后续工作的基础纳入配置管理
- 需求管理: 对需求基线的管理, 在需求基线完成后正式开始, 在需求开发结束之后持续存在, 在后续开发中保证需求作用的持续稳定发挥, 确保需求被正确理解和实现.
需求的定义
用户条件能力, 系统条件能力, 文档化表述
- 用户为了解决问题或达到某些目标所需要的条件或能力;
- 系统或系统部件为了满足合同, 标准, 规范或其他正式文档所规定的要求而需要具备的条件或能力;
- 对1或2中的一个条件或一种能力的文档化表述.
需求的三个层次
给出一个实例, 给出其三个层次的例子
判定给定需求示例, 判断其层次
- 业务需求 → 解决方案与系统特性
- 抽象层次最高, 系统的战略出发点, 表现为高层次的目标, “为什么”要开发系统
- 用户需求 → 问题域知识
- 用户对系统所能完成的具体任务的期望, 需要问题域知识作为背景支持才能了解
- 一系列用户需求联合满足一个业务需求
- 可以与系统级需求混用指导设计, 然而在包含多个逻辑处理过程时还是需要分解为系统级需求
- 系统级需求 → 需求分析模型
- 用户对系统行为的期望, 每个系统级需求反映了一次外界与系统的交互行为或系统的一个实现细节
- 一系列系统级需求联合满足一个用户需求
- 尽可能不涉及系统的内部构造细节, 以与外界的交互为主(软件是黑盒)
业务需求 → 指导需求获取 → 用户需求 → 通过需求分析转化为系统需求 → 系统级需求
需求的类型
对给定的实例, 给出其不同类型需求的例子
对给定的需求示例, 判断其类型
需求谱系:
- 不切实际的期望 → 技术/资源/问题域上不可行
- 需求
- 项目需求
- 过程需求
- 系统需求
- 硬件需求
- 其他需求
- 软件需求
- 功能需求: 和系统主要工作相关, 即在不考虑物理约束的情况下, 用户希望系统能执行的活动, 是软件能够解决用户问题并产生价值的基础.
- 非功能需求
- 质量属性: 可靠性, 可用性, 安全性, 可维护性, 可移植性, 易用性…, 常为隐式
- 性能需求: 多好多快地完成任务(速度, 容量, 吞吐量, 负载, 实时性…)
- 对外接口: 系统和环境中其他系统之间需要建立的接口(UI, 软硬件接口, 网络通信接口…)
- 约束: 系统构造时需要遵守的约定(系统开发运行的环境, 问题域内相关标准, 商业规则)
- (数据需求: 需要在数据库, 文件或其他介质中存储的数据描述, 是功能需求的补充)
