需求发现
- 自悟
- 交谈
- 观察
- 小组会
- 提炼
需求的获取
需求获取的任务
- 发现和分析问题的原因/结果关系
- 与用户进行各种方式的交流
- 按照数据、过程和接口观察问题的不同侧面
- 获取的需求文档化,形式用例、决策表、决策树
需求获取应遵循的原则
- 深入浅出的原则
- 以流程为主线的原则
需求获取的过程
1).开发高层的业务模型
2).定义项目范围和高层需求
3).识别用户类和用户代表
4).获取具体的需求
5).确定目标系统的业务工作流
6).需求整理与总结
需求分析阶段任务
获取需求
- 通过启发、引导从客户（或用户）那里得到的原始需求是他们的业务要求（needs）
分析需求
- 完整性
- 正确性
- 合理性
- 可行性
- 充分性
需求定义
- 编写需求规格说明
验证需求
- 对编写的需求规格说明进行评审
需求的作用
- 现代系统中软件的作用
- 软件在系统工程中的作用
- 自顶向下和自底向上的开发
需求的定义
需求的基本性质
- 必要性
- 无歧义
- 可测的
- 可跟踪
- 可测量
需求的分类
- 功能需求
- 业务需求(why)
- 范围文档
- 特性
- 价值
- 用户需求(what)
- 用例说明文档
- 系统需求(how)
- 系统行为
- 需求规格说明文档
- 业务需求(why)
- 非功能需求
- 性能
- 外部接口
- 设计约束
- 质量属性
需求规约
一个需求规约时一个软件所有需求陈述的正式文档，是软件的概念模型
基本性质
- 重要性与稳定性程度
- 可修改
- 完整
- 一致
格式
- 引言
- 总体描述
- 特定需求
作用
- 双方的技术合同书
- 项目管理控制点
- 产品设计的起始点
- 测试和使用的基础
系统需求规格说明
需求分析阶段的重要任务之一是根据分析的结果编写需求规格说明，经过严格评审并得到用户确认之后，作为这个阶段的最终成果。 按照国家标准GB/T 8567—2006《计算机软件文档编制规范》，涉及需求规格说明的文档有“软件需求规格说明（SRS）”、“数据需求说明（DRD）”等。
应该包含在SRS中的内容
- 功能：软件应该提供什么功能？
- 外部接口：软件如何与人、系统硬件和其他系统等进行相互作用？
- 性能：软件系统在运行速度、可用性、响应时间、恢复时间等方面有什么要求？
- 特性：软件系统在可移植性、可维护性、安全性等方面有什么考虑？
- 设计约束：是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略？
不应该包括在SRS 中的内容
- 项目开发计划
- 诸如成本、人员、进度、工具、方法等
- 产品保证计划
- 诸如配置管理、验证与测试、 质量保证等
- 软件设计细节
- 需求通常用于表达“做什么”， 而不描述“如何做”
编写需求规格说明的原则
- 原则1：只描述“做什么”而无须描述“怎么做”
- 原则2：必须说明运行环境
- 原则3：考虑用户、分析员和实现者的交流
- 对形式化和自然语言之间作出恰当的选择
- 明确的理解最重要，不存在十全十美的软件规格说明书
- 原则4：力求寻找到恰如其分的需求详细程度
- 一个有益的原则就是编写单个的可测试需求文档
- 建议将可测试的需求作为衡量软件产品规模大小的尺度
- 原则5：文档段落不宜太长
- 简短
- 记住：不要在需求说明中使用“和/或”、“等等”之类的词
- 原则6：避免使用模糊的、主观的术语
- 如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等
- 不可验证
- 建议：采用一种标准的SRS 模板
SRS模板
需求规格说明的质量要求
- 正确性
- 一致性
- 完整性
- 可验证性
- 无二义性
- 可修改性
- 可跟踪行
需求评审
评审的主要内容
1）功能 2）性能 3）接口 4）数据 5）硬件 6）软件 7）通信 8）正确性 9）完整性 10）可行性 11）一致性 12）兼容性 13）清晰性/无歧义性 14）安全性 15）健壮性 16）可理解性 17）可修改性 18）可测试性和可验证性 19）可维护性 20）可追踪性 21）可靠性 22）其他
需求评审中的常见风险
1）需求评审的参与者选取不当 2）评审规模过大（10-30页） 3）评审组规模过大（3-7人） 4）评审时间过长（2h以内）
需求管理
需求跟踪
需求跟踪性是维护需求与软件制品之间的映射（例如设计对象、用例、测试用例、已实现的软件组件等），以满足整个开发生命周期的需要。
- 建立需求跟踪性的过程
- 识别并唯一地标识SRS 中的每一个需求
- 建立和更新SRS 中的跟踪矩阵
- 工作制品的创建者负责增加该制品与需求的跟踪信息
- 跟踪矩阵应该作为工作制品的一部分进行审查
需求变更管理
需求管理的所有活动中，最重要的是—— “需求变更管理”，包括: 识别出的问题-->问题分析和变更描述-->变更分析和成本计算-->变更实现-->修正后的需求