软件工程 chapter03 - 软件需求

1. 需求的定义

一个需求是一个有关‘要予构造’的陈述，描述了待开发产品 / 系统（或项） 功能上的能力、性能参数、或者其他性质。

2. 需求的基本性质

2.1 必要的

2.2 无歧义的

这个需求是否只能用一种方式解释

2.3 可测的

这个可测指的是是否可用对它进行测试

2.4 可跟踪的

2.5 可测量的

3. 需求的分类

需求分类分为：需求功能、性能、外部接口、设计约束、质量属性

3.1 功能需求

功能需求规约了系统或系统构建必须执行的功能

例如：

• 系统应对所有已销售的应纳税商品计算销售税
• 系统应提供一种方法，使系统用户可根据本地利率调整销售税比例
• 系统应能够产生月销售报表

除了对要执行的功能给出一个陈述外，还应规约如下内容：

• 关于该功能输入的所有假定，或为了验证该功能输入，有关检测的假定
• 功能内的任一次序，这一次序是与外部有关的
• 对异常条件的响应，包括所有内外部所产生的错误
• 需求的时序或优先程度
• 功能之间的互斥规则
• 系统内部状态的假定
• 为了该功能的执行，所需要的输入和输出次序
• 用于转换或内部计算所需要的公式

3.2 性能需求

性能需求规约了一个系统或系统构件必须具有的性能特性。

例如：

• 系统应该在5分钟内计算出给定季度的总销售税

3.3 外部接口

如：账户接受系统必须为月财务状况系统提供更新信息

外部接口需求规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它也能规约其格式、时间或其他因素。

3.4 设计约束

如：系统必须用C++编写

设计约束限制了系统或系统构件的设计方案。就约束的本身而言，对其进行权衡或调整是相当困难的，甚至是不可能的。它们必须予以满足。这一性质，是与其它需求的最主要差别。为了满足功能、性能和其它需求，许多设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。

3.5 质量属性

可靠性，存活性，可维护性，用户友好性，安全性，可移植性

质量属性(Quality attribute) 规约了软件产品必须具有的一个性质是否达到质量方面一一个所期望的水平。

4. 需求的发现

4.1 自悟

把自己当作系统的最终用户

需求人员把自己作为系统的最终用户，审视该系统并提出问题:“如果是我使用这一系统，则我需要…”
适用条件:需求工程师不能直接与用户进行交流，自悟是乎是一种比较有吸引力的方法，可能确实是必须的。
成功条件:若使自悟是成功的，需求人员必须具有比最终用户还要多的应用领域和过程方面的知识，并具有良好的想象能力。

4.2 交谈

给客户提问题，询问交谈

为了确定系统应该提供的功能，需求人员通过提出问题，用户回答，直接询问用户想要的是一个什么样的系统。

成功条件:交谈通常是一种比自悟更好的技术。这种途径成功与否依赖于:
- 需求人员是否具有“正确提出问题”的能力,
- 回答人员是否具有“揭示需求本意”的能力。

存在的风险:在交谈期间需求可能不断增长，或是以前没有认识到的合理需求的一种表现， 说是“完美蠕行"(Creepingelegance)病症的体现，以至于很难予以控制，可能导致超出项目成本和进度的限制。

应对措施:项目管理人员和客户管理人员应该定期地对交谈过程的结果进行复审。其中具有挑战的问题是:

判断:

• 什么时候对这一增长划界;
• 什么时候将这一增长通知客户

4.3 观察

观察用户执行过程，观察用户如何操作，了解环境与过程。

通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建的新系统与现存系统、过程以及工作方法之间必须进行的交互。尽管了解的这些信息可以通过交谈获取，但“第一手材料”一般总是能够比较好的"符合现实”的。

4.4 小组会

联席会议

举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。其中:

• 通常是由开发组织的一个代表作为首席需求工程师或软件工程项目经理，主持这一会议。但还可以采用其它形式，这依赖于其应用领域和主持人的能力。主持人的作用主要是掌握会议的进程。
• 必须仔细地选择该小组的成员，不仅要考虑他们对现存的和未来运行环境的理解程度，还要考虑他们的人品。

4.5 提炼

复审技术文档

复审技术文档(例如，有关需要的陈述，功能和性能目标的陈述，系统规约接口标准，硬件设计文档以及ConOps文档)，并提出相关的信息。

适用条件:提炼方法是针对已经有了部分需求文档的情况。.依据产品的本来情况，可能有很多文档需要复审，以确定其中是否包含相关联的信息。在有的情况，也可能只有少数文档需要复审。

在许多项目中，在任何交谈、观察、小组会或自悟之前，应该对该项目的背景文档进行复审，还应对系统规约进行复审，同时了解相关的标准和政策。

4.6 综合运用

多方法、组合使用技术、执行需求的技能水平、验证需求

1. 在任意特定的环境中，每项技术都有其自己的优点和不足。在实施上述任何一项技术时，都可以辅以其他方法，例如原型构造，在举行小组会时可以使用原型，方便人员之间的交流。
2. 依据需求工程人员的技能和产品、合同的实际情况，往往需要“组合”地使用这些技术来开发初始需求。
3. 执行需求发现这项活动的人，其技能水平将对这项活动的成功具有重大的影响。
4. 大型复杂项目和一些有能力的组织，在开发需求文档时，往往使用系统化的需求获取、分析技术和工具。一些方法提供了系统化、自动化的功能，并可逐一验证单一需求所具有的五个性质，验证需求规约是否具有四个性质。

5. 需求工程

提出问题、征求需求、开发、协商

1. 起始一提出一系列问题…
   - 对问题的基本理解
   - 谁需要解决方案
   - 所期望解决方案的性质
2. 与项目利益相关者和开发人员之间达成初步交流合作的效果
3. 导出一征求各利益相关者的需求
   • 精化一开发一个需求模型，来说明软件的功能、特征和信息的各个方面
   • 协商一协商形成一个能令开发人员和客户都满意的可交付系统
4. 规格说明一是下面的一个(或者多个)
   • 一份写好的文档
   • 一套模型
   • 一个形式化的数学模型
   • 一组使用场景(使用案例)
   • 一个原型
5. 确认一一组检查机制来发现
   • 内容或解释上的错误
   • 需要进一步解释的地方
   • 丢失的信息
   • 不一致性(建造大型产品或系统时遇到的主要问题)
   • 冲突的需求或是不可实现的(不能达到的)需求
6. 需求管理

6. 需求规约

6.1 需求规约的概念与性质

所有需求陈述的正式文档，软件系统的概念模型

1. 概念

• 一个需求规约是一个软件项/产品/系统所有需求陈述的正式文档，是一个软件产品/系统的概念模型。

2. 基本性质
   一般来说，SRS应必须具有以下4个性质:

• 重要性和稳定性程度(Ranked for importance andstability).例如:基本需求、可选的需求和期望的需求。
• 可修改的(Modifiable) :在不过多地影响其它需求的前提下，可以容易地修改-一个单一需求.
• 完整的(Complete) :没有被遗漏的需求.
• 一致的(Consistent) :不存在互斥的需求.

6.2 需求规约的格式

在获取以上初始需求的基础上，可采用IEEE标准830-1998所给出的格式，完成一一个完整的需求文档草案的编制工作。

1.引言
1.1目的
1.2范围
1.3定义，缩略语
1.4参考文献
1.5 概述(即项目范围)
2.总体描述
2.1产品概述
2.2产品功能
2.3用户特性
2.4约束
2.5假设和依赖
3.特定需求
附录

7. 需求规约的作用

技术合同书
需求规约是软件开发组织和用户之间的技术合同书，只有当需求规约完成后才能开始产品的设计

其作用可概括为:
第一，是最重要的，作为软件开发组织和用户之间一份事实上的技术合同书;是产品功能及其环境的体现。
第二，对于项目的其余大多数工作，它是一个管理控制点。
第三，对于产品的设计，它是一个正式的、受控的起始点。
第四，是创建产品验收测试计划和用户指南的基础,即基于需求规约一般还会产生另外两个文档，初始测试计划和用户系统操作描述。

8.软件测试计划

在需求分析阶段会形成（确认测试）的测试计划

9.用户系统操作描述

主要内容:从用户使用系统的角度,简要描述系统功能和性能,使用系统的主要步骤和方法，以及系统用户的责任等。系统，
注:相当于一份初步的用户手册。

10. 需求规约不能实现的作用

不是设计文档，不是进度或规划文档。

第一，它不是一个设计文档。它是一个“为了”设计的文档。
第二，它不是进度或规划文档，不应该包含更适宜包含在工作陈述(SOW)、软件项目管理计划(SPMP)、软件生存周期管理计划(SLCMP)、软件配置管理计划(SCMP)或软件质量保证计划(SQAP)等文档中的信息。

因此，在SRS中不应给出:
项目成本;
交付进度;
报告规程;
软件开发方法;质量保证规程;配置管理规程;
验证和确认规程;验收规程;安装规程。

11. 项目需求与需求规约

11.1 建立根基

11.2 需求诱导

11.3 起始工作产品

11.4 质量功能部署

11.5 非功能需求

11.6 用例

11.7 用例图

11.8 构建分析模型

11.9 需求诱导

11.10 类图

11.11 状态图

11.12 分析模式

12. 协商需求

13. 需求监控

14. 确认需求