软件工程导论（软件需求）

1.需求的作用

无论是采用自顶向下的软件开发，还是采用自底向下的软件开发，软件需求是软件开发的工作基础（第一步）

2.需求的定义

功能上的能力，性能参数。

五个基本性质：

（1）必要的

（2）无歧义的

（3）可测（测试）的

（4）可跟踪的

（5）可测量的

3.需求的分类

（1）功能需求（功能需求是整个需求的主体，没有功能需求，就没有非功能需求）

（2）性能需求 

（3）外部接口需求（系统接口，用户接口，硬件接口，软件接口，通讯接口）

（4）设计约束

（5）质量属性

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

                 存活性（健壮性），当系统的某一部分系统不能运行时，该软件继续运行或支持关键 功能的可能性。

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

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

                安全性，在一个预定的时间内，使软件系统安全的可能性。

                可移植性软件系统运行的平台类型。

4.需求发现

（1）自悟，适用条件:需求工程师不能直接与用户进行交流，自悟是乎是一种比较有吸引力的方法，可能确实是必须的。

（2）交谈，成功与否依赖于需求人员是否具有“正确提出问题”的能力，回答人员是否具有“揭示需求本意”的能力。

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

（3）观察，

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

存在的风险：客户可能抵触这一观察。其原因是他们认为开发者打扰了他们的正常业务。客户还可能认为开发者在签约之前，就已经熟悉了他们的业务。

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

（5）提炼，复审技术文档

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

在许多项目中，在任何交谈、观察、小组会或自悟之前，应该对该项目的背景文档进行复审，还应对系统规约进行复审

5.需求规约（SRS）的概念和格式

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

性质：      （1）重要性和稳定性程度

                 （2）可修改的

                 （3）完整的

                 （4）一致的（不存在互斥）

其中，就功能的需求规约来说，还应考虑以下问题
(1)功能源。
(2)功能共享的数据。
(3)功能与外部界面的交瓦。
(4)功能所使用的计算资源。

格式：（略）（“特定需求”是文档的技术核心）

5.需求规约的作用

单元测试→详细设计

集成测试→总体设计

确认测试→需求分析

（1）初始测试计划

（2）用户系统操作描述（相当于初步的用户手册）

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

6.项目的需求及需求规约

项目需求是客户和开发者之间有关技术合同-产品/系统需求的理解，应记录在工作陈述S0W中或其他某一项目文档(例如，项目管理计划)中。
SRS应只关注产品需求，即:
产品/系统需求-“交付给客户的产品是什么’