【北京大学 软件工程】三、软件需求

一、需求的定义

需求与需求获取

（1）定义：一个需求是一个有关“要予构造”的陈述，描述了待开发产品/系统(或项)功能上的能力、性能参数者其它性质。

（2）什么样的陈述可以作为需求——需求的基本性质

IEEE标准830-1998要求单一需求必须具有5个基本性质：

1. 必要的(Necessary)。是要求的吗?
2. 无歧义的(Unambiguous)。只能用一种方式解释吗?
3. 可测的(testable)。可以对它进行测试吗?
4. 可跟踪的(Traceable)。可以从一个开发阶段到另一个阶段对它进行跟踪吗?
5. 可测量的(Measurable)。可以对它进行测量吗?

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

二、需求的分类

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

1、功能

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

例如

系统应对所有已销售的应纳税商品计管销售税。

系统应提供一种方法，使系统用户可根据本地利率调整销售税比例。

系统应能够产生月销售报表。

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

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

注意：

• 功能需求是整个需求的主体，即没有功能需求，就没有非功能需求，即性能需求、外部接口需求、设计约束和质量属性。
• 非功能需求对功能需求而言，可以是一对多的，例如:

2、性能

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

例如：

• 系统应该在5分钟内计算出给定季度的总销售税。
• 系统应该在1分钟内从100000条记录中检索出一个销售定单。
• ·该应用必须支持100个windows 95/NT工作站的并行访问。

注：性能需求隐含了一些满足功能需求的设计方案，经常对设计产生一些关键的影响。例如：排序，关于花费时间的规约将确定哪种算法是可行的。

3、外部接口

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

例如:

• 账户接收系统必须为月财务状况系统提供更新信息，如在“财务系统描述”第4修订版中所描述的。
• 引擎控制系统必须正确处理从飞行控制系统接收来的命令，符合接口控制文档B2-10A4，修订版C的1到8段的规定。

外部接口分为以下几类：

• 系统接口(System interfaces)：描述一个应用如何与系统的其他应用进行交互。
• 用户接口(User interfaces)：规约了软件产品和用户之间接口的逻辑特性。即规约对给用户所显示的数据，对用户所要求的数据以及用户如何控制该用户接口。
• 硬件接口(Hardware interfaces)：如果软件系统必须与硬件设备进行交互，那么就应说明所要求的支持和协议类型。
• 软件接口(Software interfaces)：允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。
• 通讯接口(Communications interfaces)：规约待开发系统与通讯设施(如，局域网)之间的交互。如果通讯需求包含了系统必须使用的网络类型(TCP/IP，WindowsNT，Novell)，那么有关类型的信息就应包含在SRS中。
• 内存约束(Memory constraints)：描述易失性存储和永久性存储的特性和限制，特别应描述它们是否被用于与一个系统中其它处理的通讯。
• 操作(Operation)：规约用户如何使系统进入正常和异常的运行以及在系统正常和异常运行下如何与系统进行交互。应该描述在用户组织中的操作模式，包括交互模式和非交互模式；描述每一模式的数据处理支持功能；描述有关系统备份、恢复和升级功能方面的需求。
• 地点需求(Site adaptation requirements)：描述系统安装以及如何调整一个地点，以适应新的系统。

4、设计约束

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

• 系统必须用C++或其他面向对象语言编写。系统用户接口需要菜单。
• 任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%。
• 必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗Arial字体。

5、质量属性

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

三、需求发现

常用的发现初始需求的技术，包括：自悟、交谈、观察、小组会、提炼、综合运用。

1、自悟

自悟(Introspection)

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

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

成功条件：若使自悟是成功的，需求人员必须具有比最终用户还要多的应用领域和过程方面的知识，并具有良好的想象能力。

2、交谈

交谈(Individual interviews)

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

成功条件：交谈通常是一种比自悟更好的技术。这种途径成功与否依赖于:

• 需求人员是否具有“正确提出问题”的能力；
• 回答人员是否具有“揭示需求本意”的能力。

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

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

• 判断什么时候对这一增长划界；
• 判断什么时候将这一增长通知客户。

3、观察

观察(Observation)

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

存在的风险：

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

4、小组会

小组会(Group session)

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

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

5、提炼

提炼(Extraction)

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

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

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

6、综合运用

注1：在意特定的环境中，每项技术都有其自己的优点和不足。在实施上述任何一项技术时，都可以辅以其他方法，例如原型构造，在举行小组会时可以使用原型，方便人员之间的交流。

注2：依据需求工程人员的技能和产品、合同的实际情况，往往需要“组合”地使用这些技术来开发初始需求。

注3：执行需求发现这项活动的人，其技能水平将对这项活动的成功具有重大的影响。

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

四、需求规约的概念和格式

1、SRS概念

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

2、基本性质

一般来说，SRS应必须具有以下4个性质：

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

其中，就功能的需求规约来说，还应考虑以下问题：

（1）功能源。

（2）功能共享的数据。

（3）功能与外部界面的交互。

（4）功能所使用的计算资源。

3、需求规约(草案)格式

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

第三部分“特定需求”，是文档的技术核心。一般来说，应根据不同类型的系统来构造这一部分，其中可能会涉及一些模板：

注：还可能给出其他组织方式。最终所选定的格式，应适合组织的经验、应用及环境、表达需求所使用的语言等。

五、需求规约的作用

1、概述

其作用可概括为:

第一，是最重要的，作为软件开发组织和用户之间一份事实上的技术合同书；是产品功能及其环境的体现。

第二，对于项目的其余大多数工作，它是一个管理控制点。

第三，对于产品的设计，它是一个正式的、受控的起始点。

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

2、软件测试计划

主要内容：对未来系统中的哪些功能和性能指标进行测试，以及达到何种要求。

作用：指导系统开发早期发现并修改一个错误减少测试代价。

注：在以后阶段的软件开发中，对这个测试计划要不断地修正和完善，并成为相应阶段文档的一部分。

注：大量的统计数字表明，在系统开发早期发现并修改一个错误的代价往往很低，越到系统开发的后期，改正同样错误所花费的代价越高。例如，假设在需求分析阶段检测并改正一个错误的代价为1个单位，那么到了软件测试阶段检测并改正同样的错误所花费的代价，一般需要10个单位，而到软件发布后的代价就可能高达100个单位。

3、用户系统操作描述

主要内容：从用户使用系统的角度,简要描述系统功能和性能.使用系统的主要步骤和方法，以及系统用户的责任等。

注：相当于一份初步的用户手册。

作用：

1. 在软件开发的早期，准备一份初步的用户手册可以使未来的系统用户能够从使用的角度检查、审核目标系统，从而比较容易判断这个系统是否符合他们的需要。
2. 为了书写这样的文档，也会迫使系统分析员从用户的角度来考虑软件系统。这样不论是审查还是复审时，就更容易发现不一致和误解的地方，这对保证软件质量和项目成功是很重要的。

4、需求规约不能实现的作用

第一，它不是一个设计文档。它是一个“为了”设计的文档。

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

因此，在SRS中不应给出：

• 项目成本；
• 交付进度；
• 报告规程；
• 软件开发方法；
• 质量保证规程；
• 配置管理规程；
• 验证和确认规程；
• 验收规程；
• 安装规程。

六、项目的需求及需求规约