02333软件工程——软件需求与软件需求规约

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

• 第一节 需求与需求获取
• • 需求定义
  • 需求分类
  • 需求发现技术
• 第二节 需求规约
• • 需求规约定义
  • 需求规约格式
  • 需求规约的表达
  • 需求规约的作用

第一节 需求与需求获取

需求定义

1. 一个需求是有关一个“要予构造”的概述，描述了待开发产品/系统应该具有的功能上的能力、性能参数或其它性质。
   例如：
   系统必须实现“某一业务”功能，并有能力支持1000个以上的并发用户，平均相应时间应该小于1s,最大响应时间应小于5s。
   系统必须有能力存储连续100天操作所产生的事务。
2. 对于单一一个需求，必须具有的5个基本性质：
   （1） 必要的：该需求是用户所要求的；
   （2） 无歧义的：该需求只能用一种方式解释；
   （3） 可测的：该需求是可进行测试的；
   （4） 可跟踪的：该需求可从一个开发阶段跟踪到另一个阶段；
   （5） 可测量的：该需求是可测量的；

需求分类

可以把软件需求分为两大类：一类是功能需求，一类是非功能需求，而非功能需求又可分为性能需求、外部接口需求、设计约束和质量属性需求。

需求发现技术

初始发现需求的常用技术包括以下几个：

1. 自悟：需求人员把自己作为系统的最终用户，审视该系统并提出问题，“如果是我使用这一系统，则我需要…”。
2. 交谈：为确定系统应该提供的功能，需求人员通过提出问题/用户回答这一方式，直接询问用户需要的是一个什么样的系统。
3. 观察：通过观察用户执行其现行的任务和过程，了解系统运行的环境；特别是了解要建立的新系统与现存系统、过程以及工作方法间必须进行的交互。
4. 小组会：举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。
5. 提炼：复审技术文档，并提取相关信息。

第二节 需求规约

需求规约定义

需求规约是一个软件/产品/系统所有需求陈述的正式文档，它表达了一个软件/产品/系统的概念模型。
需求规约一般需要满足以下4个基本性质：
重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级，例如：基本需求、可选需求和期望需求。
可修改性：在不过多地影响其它需求的前提下，可以容易地修改一个单一需求。
完整的：没有遗漏的需求。
一致的：不存在互斥的需求。

需求规约格式

IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板，其中第三部分“特定需求”是文档的技术核心。

需求规约的表达

在实际工程中，需求规约的表发主要存在3中不同的风格：

1. 非形式化的需求规约：以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。适用于规模较小的、复杂程度不大高的小型软件项目，或在获取SRS（草案）时使用的。
2. 半形式化的需求规约：以半形式化符 体系（包括术语表、标准的表达格式等）来表达需求规约。
3. 形式化的需求规约：以一种居于良构数学概念的符 体系来编制需求规约，一般常伴有解释性注释的支持。

需求规约的作用

1. 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
2. 对于项目的其余大多数工作，需求规约是一个管理控制点。
3. 对于产品/系统的设计，需求规约是一个正式的、受控的起始点。
4. 需求规约是创建产品验收测试计划和用户指南的基础，基于需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。