火星时代原画班学费:《软件需求》笔记

来源:百度文库 编辑:中财网 时间:2024/05/10 05:30:11

《软件需求》笔记

题目:《软件需求》笔记

整理:温昱

感谢:《软件需求》一书的作者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就是“评审”过的东东,达成“共识”的东东,要改动需要被配置的东东(通常存入配置管理库)。