第二章 软件需求和需求规约

1.1. 需求与需求获取

　　1.1.1. 需求的定义

　　　　(1) 一个需求描述了待开发产品的系统功能上的能力、性能参数或其它性质

　　　　(2) 需求的5个性质

　　　　　　①　必要的：该需求是用户所要求的

　　　　　　②　无歧义的：该需求只能用一种方式解释

　　　　　　③　可测的：该需求可以进行测试

　　　　　　④　可跟踪的：该需求可从一个开发阶段跟踪到另一个阶段

　　　　　　⑤　可测量的：该需求是可测量的

　　1.1.2. 需求的分类

　　　　(1) 功能需求

    　　　　规约了系统或系统构件必须执行的能力，是整个需求的主体

　　　　(2) 非功能需求

　　　　　　a.性能需求：规约了一个系统或构件在性能方面必须具有的一些特性

　　　　　　　　举例：系统在5min内计算出结果、功能误报率小于1%-2%等

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

　　　　　　　　举例：对要构建的账户接收系统，必须为月财务状况系统提供更新信息

　　　　　　c.设计约束：限制了软件系统或构件的设计方案的范围。需考虑法规政策、硬件限制等。

　　　　　　　　举例：系统必须用C++或其他面向对象语言编写，并且系统用户接口需要菜单任取1s，一个特定应用所消耗的可用计算能力平均不超过50%

　　　　　　d.质量属性：规约了软件产品所具有的一个性质（包括功能和其他需求）必须达到其质量方面一个 所期望的水平。

　　　　　　　　举例：

　　　　　　　　　　可靠性：软件系统在指定环境中没有失败而正常运行的概率

　　　　　　　　　　存活性：当系统的某一部分不能运行时，该软件继续运行

　　　　　　　　　　可维护性：发现并改正一个软件故障或对特定的范围进行修改所要求的平均工作

　　　　　　　　　　用户友好性：学习和使用一个软件系统的容易程度

　　1.1.3. 需求发现技术

　　　　自悟：需求人员 把自己作为系统的最终用户，审视该系统并提 出问题，“如果是我使用这一系统，则我需要…….”。

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

　　　　观察：通过 观察用户执行其现行的任务和过程，或通过观察他们 如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解 要建立的新系统与现存系统、过程以及工作方法间必须进行的交互。　　　　

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

　　　　提炼：复审技术文档，并提取相关信息。

1.2. 需求规约

　　1.2.1. 需求规约的定义

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

　　　　重要性和稳定性程度：按需求的重要性和稳定性对需求进行分级，如基本需求、可选需求和期望需求

　　　　可修改的：在不过多地影响其他需求的前提下，可以容易地修改 一个单一需求；

　　　　完整的：没有被遗漏的需求

　　　　一致的：不存在互斥的需求。

　　1.2.2. 需求规约的格式

　　　　 

　　1.2.3. 需求规约的表达

　　　　非形式化需求规约：以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。 适用于规模比较小的、复杂程度不大高的小型软件项目，或在获取SRS（草案）时使用的。

　　　　半形式化需求规约：以 半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约； 一些有能力的组织针对大型复杂项目，在开发需求文档时往往使用系统化的 需求获取、分析技术和工具。　　　　

　　　　形式化需求规约：以一种基于良构数学概念的符号体系来编制需求规约，一般 常 伴有解释性注 释的支持。主要针对质量（特别是安全性）要求比较高的软件产品/系统或其中某一部分。

　　1.2.4. 需求规约的作用

　　　　需求规约是软件开发组织和用户之间一份事实上的 技术合同书，是产品功能及其环境的体现。

　　　　对于项目的其余大多数工作，需求规约是一个管理控制点。

　　　　对于产品／系统的设计，需求规约是一个正式的、受控的起始点。

　　　　需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产 生另外两个文档——初始测试计划和用户系统操作描述 。