软件需求与软件需求规约

软件需求与软件需求规约

需求与需求获取

不论是自顶向下的软件开发，还是自底向上的软件开发，正确定义问题，是解决问题的前提

自顶向下：问题到平台

自底向上：平台到问题

——定义问题的基本要素是什么/p>

——定义问题的基本格式/p>

定义问题的基本要素

定义问题的基本要素是“需求”

需求：一个需求是一个有关“要予构造”的陈述，用以描述待开发产品（或项）功能上的能力、性能参数或者其他性质

功能：可以处理某操作任务的任选组合

性能：有能力支持100个以上的并发用户平均响应时间小于1秒，最大响应时间小于5秒

 需求的5个基本性质

必要的（necessary）用户要求的

无歧义的（UNambiguous）只能有一种解释，没有其他

可测试的（testable）产品开出出阿里过后能否进行测试

可跟踪的（traceable）可以从一个开发阶段到另外的一个阶段

可测量的（measureable）该需求是可以进行测量的

注意：确定需求是否满足以上五个性质的复杂耗时的过程

 需求分类

功能需求：功能需求桂月亮或者系统构件必须执行的功能

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

关于功能需求需要考虑的问题

1. 功能源
2. 功能共享的数据
3. 功能与外部界面的交互
4. 功能所使用的计算资源

可以见得，功能需求是整个需求的主体， 没有功能需求，就谈不上其他需求，即性能需求，外部接口需求，设计约束和质量属性。

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

外部接口需求：外部接口需求规约了系统或系统构件必须进行交互的硬件、软件和数据库元素，也可能规约其格式、时间或者其他因素

分类

用户接口、硬件接口、软件接口、通讯接口、内存约束、操作、地点需求

设计约束：设计约束限制了系统或系统构件的设计方案。就约束的半身而言，对其进行均衡或者调整是相当困难的，甚至是不可能的。它们必须予以满足。这也是与其他需求的差别。

分类

法规政策、硬件限制、与其他的应用接口、并发操作、审计功能、控制功能、高级语言需求、握手协议、应用的关键程度、安全的考虑。

质量属性：质量属性桂月亮软件产品必须具有一个性质是否达到质量方面一个所期待的水平。

需求发现技术

常用的技术：自悟、交谈、观察、小组会、提炼

需求规约

定义需求的基本格式

——需求规约（SRS）

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

基本性质：重要性和稳定性程度、可修改、完整性、一致性

大型复杂项目和一些有能力的组织，在开发需求文档时，往往使用系统化的需求分析技术和工具。其中一些方法提供了系统化、自动化的功能，逐一验证单一需求所具有的五个性质，并进一步验证需求规约是否具有以上四个性质。

需求规约实例

XXXX系统需求规格说明书

1. 引言

1.1编写的目的

说明编写本需求分析规格说明书的目的。

1.2背景说明

（1）给出待开发的软件产品的名称

（2）说明本项目的提出者、开发者、用户；

（3）说明该软件产品将做什么，如必要，说明不做什么

1.3术语定义

1.4参考资料

1. 概述

2.1功能概述

叙述待开发软件产品将完成的主要功能，并用方框图来表示各功能及其相互关系

2.2约束

叙述对系统设计产生影响的显示条件，并对下一节中所述的某些特殊需求提供理由，如管理模式、硬件限制、与其他应用的接口、安全保密的考虑等

1. 数据流图与数据字典

3.1数据流图

3.1.1数据流图

（1）画出该数据流图1

（2）加工说明

（a）编

（b）加工名

（c）输入流

（d）输出流

（e）加工逻辑

（3）数据流说明

3.1.2数据流图2

………………………

3.2数据字典

3.2.1文件说明

说明文件的成分及组织方式

3.2.2数据项说明

以表格的形式说明每一项数据、格式如下

1. 接口

4.1用户接口

说明人机界面的需求，包含：

1. 屏幕格式
2. 表过菜单的页面打印格式及内容
3. 可用的功能键及鼠标

4.2硬件接口

说明该软件产品与硬件之间各接口c51的逻辑特点以及运行该软件的硬件设备特征

4.3软件接口

说明该软件产品与其他软件之间接口，对于每个需要的软件产品，应提供：

1. 名称；
2. 规格说明；
3. 版本 ；

1. 性能需求

5.1精度

逐项说明对各项输入数据和输出数据达到的精度，包含传输中的精度要求。

5.2时间特征

定量地说明本软件的时间特征，如响应时间、更新处理时间、数据传输、转换时间、计算时间等。

5.3灵活性

说明本软件所具有的灵活性，即对当前用户需求（如操作方式、运行环境、结果精度、时间特性等）有某些变化时，本软件的适应能力

1. 属性

6.1可用性

规定某些需求，如检查点、恢复方法和重启动性，以确保软件可使用。

6.2保密性

规定保护软件的要素。

6.3可维护性

规定确保软件是可维护的需求，如模块耦合矩阵。

6.4可移植性

规定用户程序、用户接口的兼容方面的约束。

1. 其他需求

7.1数据库

说明作为产品的一部分来开发的数据库的需求。如：

（1）使用的频率；                         （2）访问的能力

（3）数据元素和文件描述；       （4）数据元素、记录和文件关系

（5）静态和动态组织；                （5）数据保留要求。

7.2操作

列出用户要求的正常以及特殊格式的操作，如：

（1）在用户组织中各种方式的操作；                （2）后援和恢复操作；

7.3故障处理

列出可能发生的软件和硬件故障，并指出这些故障对各项性能指标所产生的影响及对故障处理的要求。

注意：以上给出的是一份需求规约说明书的样例，在实际软件工程中，每个开发组织可根据相关的标准和从事的开发领域，规定自己组织的软件需求分析规格说明书的格式。

表达需求规约（规格说明书）的三种风格

1非形式化的规约

即以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章

2半形式化的规约

即以半形式化符 体系（包含术语表、标准化的表达格式等）来表达需求规约。因此，半形式化规约的编制应遵循一个标准的表示模板（一些约定）。

3形式化规约

即以一种基于良构数学概念的符 体系来编制需求规约，一般往往有解释性注释的支持。

需求规约的作用

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

SRS不能实现的作用

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

因此在SRS中不应给出：

   项目成本；交付进度； 告规程；软件开发方法；质量保证规程；验收规程；安装规程。