SWEBOK中文版

第一章软件需求
缩略词
介绍
软件需求知识领域(KA)涉及软件需求的引出、分析、说明和验证，以及软件产品整个生命周期中需求的管理。

在研究人员和行业从业者中，人们普遍认为，当需求相关的活动表现不佳时，软件项目是非常脆弱的。

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

术语“需求工程”在这个领域被广泛使用，表明系统地处理要求。

出于一致性的原因，“工程”这个词除了用于软件工程之外，不会被用于在KA中。

出于同样的原因，“需求工程师”这一术语出现在一些文献中，也不会被使用。

相反，术语“软件工程师”或某些特定情况下将使
用“需求专家”，后者通常是由软件工程师以外的其他人扮演。

但这并不意味着软件工程师无法执行该功能。

一个固有风险被提议要分解：一个瀑布式的过程可以被推断出来。

为了防范这一问题，主题2被设计为通过阐述流程运行的资源和限制因素以及确定流程的方式来提供需求流程的高级概述。

另一种分解可以基于产品的结构(系统需求、软件需求、原型、用例等等)。

基于过程的故障反映了这样一个事实:如果要成功，需求过程必须被看作是一个涉及复杂的、紧密耦合的活动(包括顺序和并发)的过程，而不是在软件开发项目开始时执行的离散的、一次性的活动。

软件要求KA与软件设计，软件测试，软件维护，软件配置管理，软件工程管理，软件工程流程，软件工程模型和方法以及软件质量KA密切相关。

软件需求主题的分解
软件需求的主题的分解KA如图1.1所示。

1.软件需求基本元素
[1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6, c12]
1.1软件需求的定义
在最基本的情况下，软件需求是为了解决现实世界中的一些问题必须展现的一个属性。

它的目的可能是使某些任务的一部分自动化，以支持组织的业务流程，纠正现有软件的缺陷或控制设备 - 仅列举可能
的软件解决方案的许多问题中的一些。

用户，业务流程和设备的功能通常很复杂。

因此，通过扩展，对于特定软件的要求通常是来自组织的不同级别的各种人以及与软件将在其中运行的环境中涉及或与该特征相关联的人的复杂组合。

图1.1软件需求的主题的分解KA
所有软件要求的一个基本属性是，它们作为功能要求的单个功能可视为系统级别的非功能要求。

验证某些软件需求可能是困难或昂贵的。

例如，对呼叫中心的吞吐量要求的验证可能需要开发仿真软件。

软件需求，软件测试和质量人员必须确保可以在可用的资源限制内验证该项目。

除了行为属性之外，需求还有其他属性。

常见的例子包括在有限资源面前实现权衡的优先等级，以及使项目进度得到监控的状态值。

通常，软件需求被唯一识别，使得它们可以在特征和软件的整个生命周期中经受软件配置管理。

1.2 产品和过程需求
产品需求是所开发的软件的一个需求或限制（例如，“该软件将在其注册课程之前验证学生满足所有先决条件”）。

过程需求本质上是对软件开发的约束(例如，“软件应该使用RUP 过程来开发”)。

一些软件需求产生了隐式的过程需求。

验证技术的选择就是一个例子。

另一个可能是使用特别严格的分析技术（如正式指定方法）来减少可能导致可靠性不足的故障。

过程要求也可由开发组织，其客户或第三方（如安全监管者）直接施加。

1.3 功能性和非功能性需求
功能需求描述了软件执行的功能; 例如，格式化一些文本或调制信
号。

它们有时被称为功能或特性。

功能需求也可以被描述为一个可以编写有限的测试步骤来验证其行为的方法。

非功能性需求是限制解决方案的需求。

有时称为非功能性需求是约束或质量需求。

它们可以根据性能需求，可维护性需求，安全需求，可靠性需求，互操作性需求或许多其它类型的软件需求之一进一步分类（参见软件质量KA中的型号和质量特性）。

1.4 应急属性
一些需求代表了软件的应急特性，即不能由单个组件解决的需求，但这取决于所有的软件组件是如何互操作的。

例如，呼叫中心的吞吐量要求取决于电话系统、信息系统和操作人员如何在实际操作条件下进行交互。

应急属性非常依赖于系统体系结构。

1.5 可量化的需求
软件需求应尽可能清楚明确地说明，并酌情定量说明。

重要的是要避免模糊和不真实的需求，这些需求依赖于他们对主观判断的解释(“软件应该是可靠的”;“软件应该是用户友好的”)。

这对于非功能性需求尤其重要。

量化需求的两个例子如下：呼叫中心的软件必须将中心的吞吐量提高20％; 并且系统在运行的任何一个小时内产生致命错误的概率应小于1 * 10-8。

吞吐量需求处于非常高的水平，需要使用它来导出一些详细的要求。

可靠性要求将严格限制系统架构。

1.6 系统需求和软件需求
在这个主题中，“系统”是指要完成定义的目标的元素的相互作用的组合。

这些包括由国际软件和系统工程理事会（INCOSE）[3]定义的硬件，软件，固件，人员，信息，技术，设施，服务和其他支持元素。

系统需求是整个系统的需求。

在包含软件组件的系统中，软件需求来自于系统需求。

KA以限制的方式定义了“用户需求”，作为系统客户或最终用户的需求。

相比之下，系统需求包括用户需求，其他利益相关者（如监管机构）的需求以及没有可识别人力资源的需求。

2.需求过程
[1*, c4s4] [2*, c1–4, c6, c22, c23]
本部分介绍软件需求过程，确定剩余的五个主题，并展示需求过程如何与整个软件工程流程相衔接。

2.1 流程模型
该主题的目的是提供一种理解，即需求过程不是软件生命周期的离散前端活动，而是一个在整个生命周期中不断被重新设计的项目开始的过程;
该主题的目的是提供一个理解，即需求过程将软件需求确定为配置项目，并使用与软件生命周期流程的其他产品相同的软件配置管理实践进行管理;
该主题的目的是提供一种理解，即需求过程需要适应组织和项目
环境。

特别地，该主题涉及引导，分析，指定和验证的活动如何与不同类型的项目和约束相匹配。

该主题还包括为需求过程提供投入的活动，如市场营销和可行性研究。

2.2 过程参与者
本主题介绍参与需求过程的人员的角色。

这个过程从根本上是跨学科的，需求专家需要在利益相关方的领域和软件工程的领域之间进行调解。

除了需求专家以外，还有许多人参与其中，他们每个人都有软件的股份。

利益相关者将根据不同的项目而有所不同，但总是包括用户/运营商和客户（不需要相同）。

软件利益相关者的典型例子包括（但不限于）以下内容：
用户：该组包括操作软件的人员。

通常是涉及不同角色和要求的人的异质性群体。

客户：该组包括委托软件或代表软件目标市场的人员。

市场分析师:大众市场产品将不会有一个委托客户，因此市场营销人员通常需要建立市场需求，并充当代理客户。

监管机构：银行和公共交通等许多应用领域受到监管。

这些领域的软件必须符合监管机构的要求。

软件工程师:这些人从开发软件的过程中获得了合理的利益，例如，重用其他产品的组件。

如果在这种情况下，某个特定产品的客户有特定的需求，这可能会损害组件重用的潜力，那么软件工程师必须
仔细权衡他们自己的利益和客户的利益。

特定的需求，特别是约束，可能会对项目成本或交付产生重大影响，因为它们要么与工程师的技能组合很好，要么很差。

应该确定这些需求之间的重要权衡。

不可能完全满足每个利益相关者的要求，而且软件工程师的工作是协商主要利益相关者可以接受的折中方案，并且在预算，技术，监管和其他限制之内。

这样做的先决条件是所有的利益相关者都被识别，他们的“利害关系”的性质被分析，并且他们的需求被引出。

2.3 过程支持与管理
本节介绍需求过程所需和使用的项目管理资源。

它为软件工程管理KA的第一个主题（起始和范围定义）建立了上下文。

其主要目的是使2.1中识别的流程活动与成本，人力资源，培训和工具等问题联系起来。

2.4 过程质量和改进
本课题涉及质量评估和需求流程改进。

其目的是强调需求过程在软件产品的成本和及时性以及客户对其的满意度方面的关键作用。

它将有助于将需求过程定位为软件和系统的质量标准和过程改进模型。

过程质量和改进与软件质量KA和软件工程流程KA密切相关，包括流程改进标准和模式要求流程覆盖；需求过程度量和基准测试；改进规划和实施；安全/ CIA改进/规划和实施。

3.需求获取
[1*, c4s5] [2*, c5, c6, c9]
需求获取涉及软件需求的来源以及软件工程师如何收集它们。

了解软件需要解决的问题是它的第一阶段。

这在根本上是一种人类活动，是利益攸关方的确定和开发团队与客户之间建立关系的地方。

它被称为“需求捕获”，“需求发现”和“需求获取”。

良好需求获取过程的基本原则之一是各利益攸关方之间有效沟通。

在不同的时间点，不同的利益相关者通过整个软件开发生命周期（SDLC）流程进行这种沟通。

在开发开始之前，需求专家可能会形成此通信的渠道。

他们必须在软件用户（和其他利益相关者）的领域和软件工程师的技术世界之间进行调解。

一系列内部一致的抽象层次模型促进了软件用户/利益相关者和软件工程师之间的沟通。

需求获取的关键要素是通知项目范围。

这涉及提供指定的软件的描述及其目的，并确定可交付成果的优先级，以确保客户最重要的业务需求得到满足。

这最大限度地减少了需求专家花费时间引出低重要性的需求的风险，或者在软件交付时变得不再相关的风险。

另一方面，描述必须是可扩展的和可扩展的，以接受在第一正式列表中未表达的进一步的需求，并且与递归方法中考虑的先前的需求兼容。

3.1 需求来源
需求在典型软件中有许多来源，并且所有潜在的来源都必须被识别和评估。

本主题旨在提高对各种软件需求来源的认识以及管理软件需
求的框架。

所涉及的要点如下：
目标。

术语“目标”（有时称为“业务关注”或“关键成功因素”）是指软件的整体、高层次目标。

目标为软件提供了动力，但通常是含糊不明确的。

软件工程师需要特别注意评估目标的价值（相对于优先级）和成本。

可行性研究是一种相对较低成本的方法。

领域知识。

软件工程师需要获取或掌握有关应用领域的知识。

领域知识提供了背景，为了理解这些知识，必须设置所有获取的需求知识。

在知识领域中模仿本体论的方法是一个很好的做法。

应确定应用领域相关概念之间的关系。

利益相关者（见第2.2节，过程参与者）。

许多软件已经被证明是不能令人满意的，因为它强调了一组利益相关者的需求，而牺牲了他人的需求。

因此，交付的软件很难使用，或颠覆了客户组织的文化或政治结构。

软件工程师需要识别，代表和管理许多不同类型的利益相关者的“观点”。

业务规则。

这些语句定义或约束了结构的某些方面或业务本身的行为。

“如果有一些未支付的学费，学生就不能注册下学期的课程”将成为一个商业规则的例子，这将成为大学课程注册软件的一个要求来源。

操作环境。

需求将来自软件将被执行的环境。

这些可能是例如实时软件中的时序限制或业务环境中的性能约束。

这些必须积极寻求，因为它们可以极大地影响软件的可行性和成本，并限制设计选择。

组织环境。

通常需要软件来支持业务流程，其选择可能受组织结
构，文化和内部政治的制约。

软件工程师需要对这些敏感，因为一般来说，新软件不应该强制业务流程中的计划外变更。

3.2 获取技巧
一旦需求来源被识别，软件工程师就可以开始从他们那里获取需求信息。

请注意，需求很少能得到现成的。

相反，软件工程师会从他或她制定需求的信息中获得信息。

本课题集中在让人类利益相关者阐明需求相关信息的技术。

这是一个非常困难的任务，软件工程师需要对这样一个事实敏感(例如)用户可能难以描述他们的任务，可能会留下重要的信息，或者可能不愿意或者不能合作。

特别重要的是要明白，获取并不是一种被动的活动，即使可以合作并且有明确的利益相关者，软件工程师也必须努力获取正确的信息。

许多业务或技术需求是默认的，或者是尚未从最终用户那里获得的反馈。

规划，确认和验证在需求获取过程中的重要性不能夸大。

许多技术存在于需求启发中;主要的是：
访谈。

采访利益相关者是一种“传统”的获取需求的方法。

了解访谈的优点和局限性以及如何进行这一点很重要。

情景。

情景提供了一个有用的手段，为用户需求的获取提供上下文。

他们允许软件工程师通过允许“如何”和“如何完成”问题提出一个关于用户任务问题的框架。

最常见的场景类型是用例描述。

由于场景符号（例如用例图）在建模软件中很常见，因此有一个链接到主题4.2（概念建模）。

原型。

这种技术是澄清不明确要求的有价值的工具。

他们可以通过为用户提供一个上下文，以类似的方式采取行动，他们可以更好地了解他们需要提供哪些信息。

有各种各样的原型技术-从屏幕设计的纸张模型到软件产品的beta测试版本，以及用于需求启发和需求验证的单独用途的强烈重叠（参见第6.2节“样机”）。

低品质原型通常是优先的，以避免利益相关者“锚定”更高品质的原型的轻微的附带特征，可以以非预期的方式限制设计灵活性。

便利会议。

这些会议的目的是试图实现一个总结效果，一群人可以比单独工作更多地了解他们的软件需求。

他们可以集思广益，反思可能难以通过采访带来表面的想法。

另一个优点是，快速的要求早就表现出来，让利益相关者认识到这些需求发生在哪里。

当它工作得很好时，这种技术可能会导致比否则可以实现的更丰富和更一致的要求。

然而，需要小心处理会议（因此需要协调人），以防止团队的关键能力受到团队忠诚度的削弱，或者反映出一些直言不讳的人（或许是高级人士）的关切，有利于别人的人。

观察。

软件环境在组织环境中的重要性导致了观察技术的适应性，如民族志需求获取。

软件工程师通过将自己沉浸在环境中，了解用户的任务，并通过与软件工具和其他资源的交互来观察用户如何执行任务。

这些技术相对昂贵，但也是有指导意义的，因为它们说明了许多用户任务和业务流程过于微妙和复杂，无法让它们的参与者轻松地描述它们。

用户故事。

这种技术通常用于自适应方法（参见软件工程模型和
方法KA中的敏捷方法），并且是指以客户术语表达的所需功能的简短，高级描述。

一个典型的用户故事的形式是：“作为一个<角色>，我想要<目标/愿望>，这样就会<有益>。

用户故事旨在包含足够的信息，以便开发人员能够对实现它的努力做出合理的估计。

这样做的目的是为了避免一些在项目中经常出现的浪费，这些项目在项目开始之前就已经收集了详细的需求，但是在项目开始之前就已经失效了。

所以在实施用户故事之前，客户必须写出适当的接受程序，以确定用户故事的目标是否已经实现。

其他技术。

支持需求信息获取的一系列其他技术的存在，范围从分析竞争对手的产品到应用数据挖掘技术到使用域知识或客户请求数据库的来源。

4.需求分析
[1*, c4s1, c4s5, c10s4, c12s5]
[2*, c7, c11, c12, c17]
本课题涉及分析需求检测和解决需求之间冲突的过程;本课题涉及分析需求的过程，以发现软件的界限以及如何与其组织和操作环境相互作用;本课题涉及分析需求的过程，以制定系统需求来推导软件需求。

传统的需求分析的观点是，使用许多分析方法，例如结构化分析方法，将其简化为概念建模。

虽然概念建模很重要，但是我们有需求的分类，以帮助在需求(需求分类)和建立这些权衡的过程(需求协商)之间进行权衡。

必须谨慎地描述需求，以确保需求得到验证，它们的实施被验证，以及估算其成本。

4.1 需求分类
需求可以分为许多方面，示例包括：
需求是功能性的还是非功能性的(见 1.3节，功能和非功能需求)。

该要求是来自一个或多个高级别要求或紧急财产（见第 1.4节“紧急财产”），还是由利益相关者或其他来源直接施加在软件上。

需求是否符合产品或过程（见第1.2节“产品和流程要求”）。

对这一过程的要求可以约束承包商的选择，要采用的软件工程流程或要遵守的标准。

需求优先。

优先级越高，满足软件总体目标的需求就越重要。

通常按照强制性，非常可取的，可取的或可选的定点分级，优先级通常必须与开发和实施的成本进行平衡。

需求的范围。

范围是指需求影响软件和软件组件的程度。

一些要求，特别是某些非功能性需求，具有全球范围，因为它们的满意度不能分配给分立的组件。

因此，全球范围的需求可能会严重影响软件体系结构和许多组件的设计，而范围狭窄的设计可能会提供多种设计选择，对其他需求的满意度影响不大。

波动率/稳定性。

软件生命周期中的一些要求也会发生变化，甚至在开发过程本身也会发生变化。

如果对需求可能发生变化的可能性
进行一些估计，那么这是非常有用的。

例如，在银行业务申请中，计算客户账户利息的功能需求比支持特定类型免税账户的要求更为稳定。

前者反映了银行领域的一个基本特征（该账户可以赚取利息），而后者可能会由于政府立法的改变而过时。

潜在的不稳定的需求可以帮助软件工程师建立一个更能适应变化的设计。

根据组织的正常做法和应用程序本身，其他分类也可能是适当的。

需求分类和需求属性之间存在很强的重叠（参见第7.3节“需求属性”）。

4.2 概念建模
现实世界问题模型的发展是软件需求分析的关键。

他们的目的是帮助了解问题发生的情况，以及描述解决方案。

因此，概念模型包括来自问题领域的实体的模型，有助于反映其真实世界的关系和依赖关系。

本课题与软件工程模型与方法KA密切相关。

可以开发几种类型的模型。

这些包括用例图，数据流模型，状态模型，基于目标的模型，用户交互，对象模型，数据模型等。

许多这些建模符号是统一建模语言（UML）的一部分。

例如，用例图通常用于描述边界将执行者（外部环境中的用户或系统）与每个用例描述系统功能的内部行为分开的场景。

影响建模符号选择的因素包括：
问题的本质。

某些类型的软件需要特别严格地分析某些方面。

例
如，作为SysML 4的一部分，状态和参数模型对于实时软件来说可能比信息系统更重要，而对于对象和活动模型来说，它通常是相反的。

软件工程师的专业知识。

采用软件工程师具有经验的建模符号或方法往往更有成效。

客户的过程需求(见1.2节“产品和过程需求”)。

客户可以使用他们喜欢的符号或方法，或者禁止任何他们不熟悉的东西。

这个因素可能与之前的因素相冲突。

请注意，在几乎所有情况下，开始构建软件上下文的模型是有用的。

软件上下文提供了预期软件与其外部环境之间的连接。

这对于了解软件在其操作环境中的上下文以及识别其与环境的接口至关重要。

这个子主题的目的并不是在“教”一种特定的建模风格或符号，而是为建模的目的和意图提供指导。

4.3 结构设计和需求分配
在某些时候，必须导出解决方案架构。

架构设计是需求过程与软件或系统设计重叠的重点，并说明了将这两个任务完全分离是根本不可能的。

本课题与软件设计KA中的软件结构与架构密切相关。

在许多情况下，软件工程师担任软件架构师，因为分析和阐述需求的过程要求确定满足需求的架构/设计组件。

这是需求分配-负责满足要求的架构组件的分配。

分配对于需求的详细分析很重要。

因此，例如，一旦已经将一组要求分配给组件，则可以进一步分析单个需求以发现关于组件如何与
其他组件交互来满足分配的需求的进一步需求。

在大型项目中，分配对每个子系统进行了新一轮分析。

作为示例，可以向制动硬件（机械和液压组件）分配用于汽车的特定制动性能的要求（制动距离，驾驶条件差的安全性，应用的平滑性，所需的踏板压力等）防抱死制动系统（ABS）。

只有当确定了防抱死制动系统的需求，并且分配给它的需求可以使用ABS的能力，制动硬件和紧急特性（如汽车重量）来识别详细的ABS软件需求。

架构设计与概念建模密切相关（见第4.2节“概念建模”）。

4.4 需求协商
通常用于这个子主题的另一个术语是“冲突解决”。

这涉及到解决需求问题的冲突，例如，需求和资源之间的两个利益攸关方之间发生冲突，或者在功能和非功能需求之间发生冲突。

在大多数情况下，软件工程师做出单方面决定是不明智的，所以有必要与利益相关者协商，就适当的权衡达成共识。

由于合同原因，这样的决定可以追溯到客户，这通常是很重要的。

我们把这个分类为软件需求分析主题，因为分析的结果出现问题。

然而，也可以考虑一个需求验证主题（参见主题6，需求验证）也是一个强有力的例子。

需求优先排序是必要的，不仅是过滤重要需求的手段，而且也是为了解决突发事件的冲突和计划，这意味着要做出复杂的决策，需要详细的领域知识和良好的估计技能。

然而，通常难以获得可以作为此类决策基础的真实信息。

另外，需求往往依赖于彼此，优先级也是相。