《软件需求》，Karl E.Wiegers著
1 总论
一定要编写需求文档
需求的三个层次（从高到低）：
1. 业务需求，最高层次的目标要求
2. 用户需求，Use Case
3. 功能需求，必须实现的软件功能
优秀需求的特性：
1. 完整性
2. 正确性，一致性
3. 可行性
4. 必要性
5. 划分优先级
6. 无二义性
7. 可验证性（根据需求能否写出测试用例）
8. 可跟踪性
需求工程的结构：
1. 需求开发，分为四个步骤
a) 问题获取(elicitation)
b) 分析
c) 编写规格说明
d) 验证(评审，编制测试用例)
2. 需求管理，即需求追踪、变更控制等
需求文档是用户和开发组之间的契约，对双方同时形成约束
2 需求开发
建议需求开发过程：
1. 定义项目的视图和范围
2. 确定用户类
3. 在每个用户类中确定适当的代表
4. 确定需求决策者和他们的决策过程
5. 选择你所用的需求获取技术
6. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级
7. 从用户那里收集质量属性的信息和其它非功能需求
8. 详细拟订使用实例使其融合到必要的功能需求中
9. 评审使用实例的描述和功能需求
10. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解
11. 开发并评估用户界面原型以助想像还未理解的需求
12. 从使用实例中开发出概念测试用例
13. 用测试用例来论证使用实例、功能需求、分析模型和原型
14. 在继续进行设计和构造系统每一部分之前，重复6 ~ 1 3步
2.1 通过业务需求确定项目视图和范围
2.2 确定需求来源
确定需求的来源，将用户分类，与不同类的代表进行沟通
2.3 聆听客户的需求
1. 及早并经常进行座谈
2. 通过流程图和决策树描述用户的决策过程
3. 避免讨论不成熟的细节（如用户界面）
4. 使用USE CASE分析法，并编写Use Case 文档
5. 利用图形分析模型辅助
6. 用户的需求可分为9大类
a) 业务需求
b) Use Case
c) 业务规则
d) 功能需求
e) 质量属性，即非功能需求，如可靠性，易用性等
f) 外部接口需求，如“从某些设备读取信号”
g) 限制，如“必须使得系统可以WINDOWS和LINUX平台上运行”
h) 数据定义，如“用户ID必须为3位以上的数字、字母组合”
i) 解决思想，即用户自己建议的解决方案。分析人员应该探讨客户为什么提出这种方案
7. 如果需求不能在前期全部确定，尽量确定出一个“基线”
2.4 编写需求文档
2.4.1 需求规格说明书
精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件
需求一定要编号
不完整的需求要用“TBD(to be determined)”来标识，并指明由谁、在什么时候确定
使用IEEE 830-1998需求规格说明书模板
2.4.2 数据字典
数据字典应该独立成文
例：身份证号=15位或18位字母和数字的组成的字串，但只有最后一个字符可以使用字母
2.4.3 图形建模方法
数据流图，实体关系图，状态转化图，对话图，类图等
2.5 质量属性
从用户角度：
a. 有效性，系统真正可用时间所占的百分比
b. 高效性，效率、性能
c. 灵活性
d. 完整性，即安全性
e. 互操作性，与其他系统进行交互以利用现有资源的能力
f. 可靠性，无故障执行一段时间的概率
g. 健壮性，即可容错性
h. 可用性，即易用性
从开发者角度：
a. 可维护性，纠正一个缺陷的简易程度
b. 可移植性，从一个环境移植到另一个环境的工作量
c. 可重用性
d. 可测试性，如“一个模块的最大循环复杂度不能超过20”
2.6 通过原型法减少项目风险
建立原型是为了解决在产品开发的早期不确定的问题
两种类别：
1. 抛弃型原型
2. 进化型原型，可作为构造产品的基础
可以让人模拟软件系统，“快速地开发出一个原型”
2.7 设定需求优先级
必要性
常用的三级划分：
1. 基本的。必须实现
2. 条件的。可以增强功能，但没有也可以接受
3. 可选的。实现不实现均可
2.8 需求质量验证
2.8.1 需求评审
IBM制定了一个审查的推荐过程
2.8.2 开发测试用例
可以帮助找出需求中的错误
3 软件需求管理
3.1 变更控制
必须要过程化
3.2 版本控制
其他元素（如测试用例、代码）必须与需求文档总是保持一致，组内每个成员必须总是在最新版本的指导下工作
3.3 需求跟踪
通过可跟踪性链（traceability link）建立起需求与其他元素之间的关系，并利用它来追踪需求
一个常用的工具是：跟踪矩阵
商业化的工具：Caliber-RM，DOORS等
3.4 需求状态跟踪
如 已建议，已批准，已实现，已验证，已删除