软件需求基本面基本知识详解

介绍

软件需求知识领域(KA)涉及软件需求的获取、分析、规范和验证，以及软件产品整个生命周期的需求管理。研究人员和行业从业者普遍认为，当需求相关的活动执行得不好时，软件项目是非常脆弱的。

软件需求表达了软件产品上的需求和约束，这些需求和约束有助于解决一些现实世界的问题。

术语“需求工程”在该领域中被广泛使用，以表示对需求的系统处理。出于一致性的原因，除了软件工程本身之外，术语“工程”将不会在这个知识领域中使用。

出于同样的原因，在一些文献中出现的术语“需求工程师”也不会被使用。相反，术语“软件工程师”或者，在某些特定的情况下，“需求专家”将被使用，后者所涉及的角色通常是由个人而不是软件工程师来执行的。然而，这并不意味着软件工程师不能执行该功能。

拟议故障的内在风险是，可能会推断出类似瀑布的过程。为了防止这种情况发生，主题2，需求过程，被设计为通过列出过程运行和配置它的资源和约束来提供一个高层次的需求过程概述。

可选的分解可以使用基于产品的结构(系统需求、软件需求、原型、用例，等等)。基于过程的分解反映了这样一个事实，即需求过程如果要成功，就必须被看作是一个包含复杂的紧密耦合活动(包括顺序的和并发的)的过程，而不是在软件开发项目开始时执行的离散的、一次性的活动。

软件需求知识领域与软件设计、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程模型和方法、软件质量知识领域密切相关。

1.软件需求基本面

1.1软件需求的定义

从最基本的意义上说，软件需求是为了解决现实世界中的某些问题而必须表现出来的一种属性。它的目标可能是自动化某个人的部分任务，以支持组织的业务过程，纠正现有软件的缺陷，或控制设备——这只是软件解决方案可能解决的众多问题中的一小部分。用户、业务过程和设备的运作方式通常是复杂的。因此，通过扩展，对特定软件的需求通常是来自组织不同级别的各种人员的复杂组合，这些人员以某种方式涉及到或与软件将在其中运行的环境中的此特性有关。

所有软件需求的一个基本属性是，它们可以作为功能需求的单个特性进行验证，或者在系统层面上作为非功能需求进行验证。验证某些软件需求可能是困难的或昂贵的。例如，验证呼叫中心的吞吐量需求可能需要开发仿真软件。软件需求、软件测试和质量人员必须确保在可用的资源限制范围内验证需求。

除了行为属性之外，需求还有其他属性。常见的例子包括在资源有限的情况下使用优先级评级来进行权衡，以及使用状态值来监控项目进度。通常，软件需求是唯一确定的，这样它们就可以在整个软件特性和软件的生命周期中接受软件配置管理。

1.2产品和过程要求

产品需求是对要开发的软件的需求或约束(例如，“在学生注册一门课程之前，软件应该验证他或她满足了所有的先决条件”)。过程需求本质上是软件开发的约束(例如，“软件应该使用RUP过程开发”)。

一些软件需求生成隐式过程需求。选择验证技术就是一个例子。另一种可能是使用特别严格的分析技术(例如形式规范方法)来减少可能导致不充分可靠性的错误。过程需求也可能由开发组织、他们的客户或第三方(如安全监管者)直接施加。

1.3功能性和非功能性需求

功能需求描述软件要执行的功能;例如，格式化一些文本或调制一个信号。它们有时被称为功能或特性。功能性需求也可以被描述为可以为其编写有限的测试步骤集来验证其行为的需求。

非功能性需求是用来约束解决方案的需求。非功能性需求有时被称为约束或质量需求。根据它们是性能需求、可维护性需求、安全性需求、可靠性需求、安全性需求、互操作性需求还是许多其他类型的软件需求之一，它们可以被进一步分类(参见软件质量知识领域中的模型和质量特征)。

1.4突现属性

有些需求代表了软件的突现特性——也就是说，这些需求不能由单个组件解决，而是依赖于所有软件组件如何互操作。例如，呼叫中心的吞吐量需求取决于电话系统、信息系统和操作员在实际操作条件下如何相互作用。突现属性非常依赖于系统架构。

1.5可量化的需求

软件需求应该尽可能清晰和明确地表述，如果合适的话，还应该定量地表述。重要的是要避免模糊和无法验证的需求，这些需求依赖于主观判断的解释(“软件应该是可靠的”;“本软件应易于使用”)。这对于非功能性需求尤其重要。量化需求的两个例子如下:呼叫中心的软件必须将该中心的吞吐量提高20%;和一个系统都有一个概率生成一个致命错误在任何小于1 * 10-8小时的运行。吞吐量需求处于非常高的水平，将需要用于派生许多详细的需求。可靠性要求将严格限制系统的架构。

1.6系统需求和软件需求

在本主题中，“系统”指的是实现既定目标的要素相互作用的组合。这些包括硬件、软件、固件、人员、信息、技术、设施、服务和其他支持元素，根据国际软件和系统工程委员会(INCOSE)的定义。

系统需求是对整个系统的需求。在一个包含软件组件的系统中，软件需求是从系统需求派生出来的。

这个知识领域以一种受限的方式定义了“用户需求”，即系统的客户或最终用户的需求。相比之下，系统需求包含用户需求、其他利益攸关方的需求(比如监管部门)，以及没有可识别的人力资源的需求。

责任编辑：PSY

原文标题：软件需求基本面

文章出处：【微信公众号：汽车电子硬件设计】欢迎添加关注！文章转载请注明出处。