《软件需求》笔记

题目：《软件需求》笔记
整理：温昱
感谢：《软件需求》一书的作者Karl E. Wiegers和译者陆丽娜教授等
----------------------------------说明----------------------------
CMM强调过程改进应是渐进的，所以这篇笔记也不求理论全面，一步一步来。
----------------------------------需求的层次----------------------------
business requirement
user requirement
functional requirement

上图的说明：上图似乎暗示需求分析的最终结果是SRS，但事实常常并非如此。
1. 项目视图与范围文档也是最终文档。
2. 形式上，usecase文档和SRS是只要其一还是都要，可由项目组（在本软件组织的标准内）选择。但内容上，必须既描述了usecase又描述了function requirements，具体方案有3种。
2.1 只usecase，function requirement放在其说明中，此法应注意将公用function requirement分割到可重用的usecase中（本人认为适合用UML做OOA的情况）
2.2 只SRS，usecase以一定格式写入SRS，function requirement也是（本人认为usecase的形象性尽失）
2.3 二者结合，并注意建立usecase和function requirement之间的可跟踪性（本人认为，2.3和2.1结合说不得更好）
----------------------------------项目视图与范围文档----------------------------
视图：vision，描述待开发系统涉及的外部实体，从系统和这些实体的关系中，体现系统的功能。
范围：scope，描述待开发系统的应包括部分和不包括部分。

上图说明：
1. 关联图是“最顶层数据流图”的进一步抽象，把整个系统看成一个“过程”。（本人怀疑“过程”为“process”，翻成“处理”更好）
2. 关联图只是文档的冰山一角哟。
3. 需求变更的第一个问题就是“是否超出了项目范围”。
4. 其实就是《问题定义文档》（问题性质、工程目标和规模的书面报告，也需用户确认）。（问题定义->可行性分析->需求分析->概要设计->详细设计->编码->测试->维护）
5. RUP的business modeling应该生产出visoin and scope，不过RUP用business usecase代替关联图。
----------------------------------需求规格说明书 SRS----------------------------
完整性：不应该遗漏要求和必需的信息。
正确性：只有用户的代表能够决定用户需求的正确性。
可行性：需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。（注：可行性分为技术可行性、操作可行性、经济可行性）
必要性：跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。
明确性：读者应只能从其得到唯一的解释说明。自然语言极易导致含糊。
一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。
可证实：是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。需求之间不一致，不可行，不明确也能导致不可证实。
可追踪：每个需求有标识。能与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能与设计元素，源代码，用于构造实现和验证需求的测试相对应。
可修改：通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
优先权：为每个需求，特征，用例分配优先权。

----------------------------------usecase----------------------------
是表述user requirement的方法
温昱补注：不对，usecase是一种black box，可有不同level的usecase，比如business usecase相当于关联图，用于vision and scope。
----------------------------------需求优先级----------------------------
受体为usecase（不是business requirement（没有粒度）也不是function requirement（粒度太小））。
----------------------------------需求工程----------------------------
最开始《大学课本》里讲瀑布模型。
后来在《TSPi》中看到“需求工程”是〖启动->计划->需求->最终检查〗，“设计工程”是〖启动->计划->需求->设计->最终检查〗，非常吃惊。
再后在《AKA 杂志》中看到“测试生命周期”是〖测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估〗，感觉开窍了（做任何事都有计划和设计一番）。
如今在《软件需求》中又讲“需求工程”是需求管理外加〖问题获取->分析->编写SRS->验证--->迭代〗，呵呵，是上上一段“需求”的细化。

----------------------------------关于客户----------------------------
不妨将《客户权利书》和《客户义务书》写入合同。
客户权利书：
#1 要求分析人员使用符合客户语言习惯的表达（“交流”是关键）
#2 要求分析人员了解客户的业务及目标（“积极”地站在用户角度（我一开始在银行学业务时为何进步慢就在于此，呜呜））
#9 要求对变更的代价提供真实可信的评估（呵呵，以“权利”的形式告诉用户需求变更是有代价的，妙）
客户业务书：
#1 给分析人员讲解你的业务（“交流”）
#4 及时作出决定（多个用户的需求不一致，用户中的“头儿”要及时拍板）
#6 划分需求优先级（可不是分析员划）
#7 评审需求文档和原型（业务哟）
#9 应遵照开发组织处理需求变更的过程（需求冻结，不许改了，呵呵）
----------------------------------baseline----------------------------
务实地，baseline就是“评审”过的东东，达成“共识”的东东，要改动需要被配置的东东（通常存入配置管理库）。