lec6-需求基础
需求工程
需求工程的过程模型:
- 需求工程
- 需求开发
- 需求获取 ->
- 需求分析 ->
- 需求规格说明 ->
- 需求验证
- 需求管理
- 需求开发
需求获取:
- 从人, 文档, 或者环境中获取需求的过程
- 方法和技术:
- 面谈, 问卷, 文档分析, 头脑风暴, 专题讨论, 原型, 民族志, 竞品分析

需求分析:
- 整体概念:
- 通过建模来整合各种信息
- 为问题定义出一个需求集合, 集合可以界定一个有效的解决方案
- 检查需求当中存在的错误, 不一致等缺陷并且修正
- 过程:
- 边界分析
- 系统边界的定义保证系统能够和
- 系统用例图通常被用来定义系统的边界
- 需求建模
- 建模是为了展现和解释信息的描述活动
- 常用的技术包括类图, 顺序图, 状态图等建模技术
- 边界分析
需求规格说明:
- 目标:
- 在系统用户之间交流需求信息
- 要简洁, 准确, 一致, 容易理解
- 需求工程师需要定制文档模板 + 编写文档
需求验证:
- 要求规格说明文档需要:
- 文档内每条需求豆正确, 准确反映了用户的意图
- 文档记录的需求集在整体上由 完整性和一致性
- 文档的组织方式和需求的书写具有 可读性和可修改性
- 验证方法:
- 同级评审 + 原型 + 模拟
需求管理:
- 保证需求作用的持续, 稳定 有效发挥
- 因为之后的设计, 测试, 实现等软件系统开发活动都需要围绕需求开展工作
- 进行变更控制(与时俱进)
- 纳入和实现合理的变更请求, 拒绝不合理的变更请求
需求基础
什么是需求(名词解释)
-
IEEE需求定义:
- 用户为了解决问题或达到某些目标所需要的条件或能力
- 系统或系统部件为了满足合同, 标准, 规范或其他正式文档所规定的要求而需要具备的条件或能力
- 对 1 或 2 中的一个条件或一种能力的文档化表述
-
需求的表述
- 需求是一种期望,可以表述为“系统应该在”, “在xxx时候, 系统应该xxx”
- R1: 系统应该允许顾客退回已经购买的产品
-
需求 - 问题域 - 规格说明
- 需求
- 是一种期望
- 源于现实又高于现实
- 需求是多变的和可以调整的
- 问题域
- 需求的产生地和解决地
- 现实世界运行规律的一种反映
- 规格说明
- 软件产品的方案描述, 以软件产品的运行机制为主要内容
- 不是需求但是实现需求, 不是问题域但是需要与问题域互动

- 需求
需求的层次
从高到低: 业务需求 -> 用户需求 - >系统需求
业务需求:
- 系统建立的战略出发点, 高层次的目标,描述了组织为什么要开发系统
- eg:
- R2: 在系统使用3个月后, 销售额应该提高 20%
用户需求:
- 执行实际工作的用户对系统能够完成的具体任务的期望, 系统能帮助用户做什么
- 直接用户 + 简介用户(软件销售人员和售后支持人员)
- eg:
- 系统要帮助收银员完成销售处理
系统需求:
- 用户对系统行为的期望,每个系统级需求反映了一次外界与系统的交互行为, 描述了开发人员需要实现什么
- 将⽤户需求转化为系统需求的过程是⼀个复杂的过程

需求分类

-
IEEE需求分类:
-
功能需求(唯一的功能性需求) - 性能需求 - 质量需求 - 对外接口 - 约束
-
功能需求:
- 最重要的需求, 能够带来业务价值, 最需要按照三个抽象层次展开
-
性能需求:
- 需要进行专门的模拟和测试
- 比如 速度, 容量, 吞吐量等等
- PR6: 98% 的查询时间不能超过10s
-
质量需求:
-
对越复杂的系统越是重要
-
可靠性, 可用性, 安全性, 可维护性, 可移植性, 易用性

-
-
对外接口:
解系统与其它系统之间的软硬件接口 -
约束:
总体上限制了开发人员设计和构建系统时的选择范围- 系统开发以及运行的环境
- 问题域的相关标准, 法律法规等
- 商业规则
-
重点:


7512

被折叠的 条评论
为什么被折叠?



