软件需求（ SOFTWARE REQUIREMENTS）

软件需求知识领域与软件需求的启发，分析，规范和验证以及软件产品整个生命周期中的需求管理有关。在研究人员和行业从业人员，当与需求相关的活动执行不当时软件项目将非常脆弱。
软件需求表达了软件产品上的需求和约束，这些需求和约束有助于解决某些实际问题。
其知识领域涉及软件需求的提取、分析、细化和验证，以及软件产品整个生命周期的需求管理。
软件需求与软件设计，软件测试，软件维护，软件配置管理，软件工程管理，软件工程过程，软件工程模型和方法以及软件质量密切相关。

SWEBOK将软件需求分为以下知识域

1.软件需求基础

1.1.软件需求定义

软件需求通常情况下描述了解决现实世界中某些问题的内容，当然也有可能描述其他更多的抽象问题。

软件需求的基本属性是 “能够被验证”。同时他还包括优先级、完成进度、需求跟踪标识等属性。

1.2.产品与过程需求

产品需求用于描述，开发的功能应该满足什么样的要求。

而过程需求规定了开发过程中的约束（如软件需要采取那种方法论进行开发）

过程需求也可能不是产品经理提出，而是执行开发工作的技术人员提出。

1.3.功能与非功能需求

功能需求描述了软件要实现的功能，也有可能是一种测试流程。

非功能能需求也被称为约束或质量需求。他可能是可维护性要求、安全要求、可靠性要求、操作性要求等。

1.4.衍生属性

一些需求代表了软件的衍生属性，即不能由单个组件解决的需求，但取决于所有软件组件如何互操作。例如呼叫中心的吞吐量要求，取决于电话系统，信息系统和运营商在实际操作条件下的交互方式。衍生属性的重要性取决于系统体系结构。

1.5.定量需求

需求应该避免含糊不清的要求，而需要提出清晰可验证的量化要求。

例如 “字体大小适中”这种就是模糊不清的需求，而“文字采用10pt大小”就是清晰量化的需求。

1.6.系统需求与软件需求

系统需求包含了软件需求，软件需求是系统需求的一部分。

系统需求阐述了整个项目的要求，如团队、资源、第三方等。

2.需求过程

2.1.过程模型

本主题的目的是提供对需求过程的理解。

它不是软件生命周期中的一个独立的前端活动，而是一个在项目开始时启动的过程，在整个生命周期中都将继续引用该过程；
将软件需求识别为配置项，并使用与软件生命周期过程中其他产品相同的软件配置管理实践来管理它们；
需要适应组织和项目环境。

特别是，该主题涉及如何针对不同类型的项目和约束来配置启发，分析，指定和验证活动。该主题还包括为需求过程提供输入的活动，例如市场营销和可行性研究。

2.2.过程参与者

本主题介绍了参与需求过程的人员的角色。这个过程从根本上讲是跨学科的，需求专家需要在利益相关者的领域和软件工程的领域之间进行协调。除了需求专家之外，通常还有很多人参与其中，他们每个人在软件中都有利害关系。利益相关者在各个项目中会有所不同，但始终会包括用户/运营商和客户（他们不必相同）。

软件涉及角色的典型例子包括(但不限于)以下内容:

用户：软件的使用人。通常包括不同工作内容的一组人。
客户：通常是委托开发软件的人。
市场分析师：大众市场不会有明确的客户。所以需要营销人员来确定大众需要什么，来充当客户角色。
监管人：许多应用行业都受到部门监管，如银行和公共交通。这些行业中的软件必须符合监管机构的要求。
软件工程师：这些人对通过开发软件来获利，例如，通过重复使用其他产品中的组件或从其他产品中获利。在这种情况下，如果特定产品的客户有特定的要求，这些要求损害了组件重用的潜力，则软件工程师必须仔细权衡自己和客户的利益。特定的需求（尤其是约束）可能会对项目成本或交付产生重大影响，因为它们对工程师的技能设置有好有坏。这些需求之间的重要权衡应予以确定。

完美地满足每一个参与者的需求是不可能的，产品经理的工作就是在主要参与者可以接受的范围内以及在预算、技术、法规和其他约束条件下进行权衡。

这样做的一个先决条件是所有的参与者都被识别出来，并根据他们的需求来权衡利害关系。

2.3.过程支持与管理

软件工程管理为过程模型建立了环境(启动和范围定义)。

它的主要目的是将2.1中提到的过程活动与成本、人力资源、培训和工具等问题联系起来。

本节介绍了需求过程所需和消耗的项目管理资源。它为软件工程管理KA的第一个主题（启动和范围定义）建立了基础。其主要目的是使2.1中确定的过程活动与成本，人力资源，培训和工具问题之间建立联系。

2.4.过程质量与改进

本主题涉及质量评估和需求过程的改进。其目的是强调需求过程在软件需求1-5的成本和软件产品的及时性以及客户对其的满意度方面所起的关键作用。这将有助于以软件和系统的质量标准以及流程改进模型来指导需求流程。

流程质量和改进与软件质量KA和软件工程流程KA密切相关，包括

通过过程改进标准和模型来要求过程覆盖；
需求过程措施和基准测试；
改进计划和实施；
安全/ CIA改进/计划和实施。

3.需求启发

需求引发与软件需求的起源以及产品经理如何收集它们有关。这是了解软件需要解决的问题的第一阶段。从根本上讲，这是一项人类活动，在此可以识别利益相关者并在开发团队和客户之间建立关系。它被不同地称为“需求捕获”，“需求发现”和“需求获取”。

良好的需求启发过程的基本原则之一是各个利益相关者之间的有效沟通。在不同的时间点，与不同的利益相关者之间的交流将贯穿整个软件开发生命周期（SDLC）。在开发开始之前，需求专家必须在软件用户(和其他涉众)的行业和软件工程师的技术世界之间进行协调。在不同抽象级别上的一组内部一致的模型促进了软件用户/涉众和软件工程师之间的配合。

需求启发的一个关键要素是告知项目范围。这涉及提供对所指定软件及其用途的描述，并确定可交付成果的优先级，以确保首先满足客户最重要的业务需求。这样可以最大程度地减少需求专家花时间来提出不重要的需求或交付软件时不再相关的需求的风险。另一方面，描述必须是可伸缩和可扩展的，以接受未在第一正式需求列表中表达且与变更中预期的先前兼容的其他要求。

3.1.需求来源

在典型的软件中需求有许多来源，识别和评估所有潜在的来源是至关重要的。本主题旨在提高人们对软件需求的各种来源以及管理这些需求的框架的认识。

目标。目标提供了开发软件的动机，但通常是模糊的表述。产品经理需要特别注意评估价值(相对于优先级)和目标成本。可行性研究是一种成本相对较低的方法。
行业知识。产品经理需要获得或拥有有关应用程序行业的可用知识。行业知识提供了背景，所有引出的需求知识必须在此基础上设置以便理解它。在知识领域中“模拟本体论”方法是一个很好的实践。应用行业内相关概念之间的关系也应该被识别。
干系人。（可以参考2.2过程参与者部分）许多软件被证明是不能令人满意的，因为它强调了一组利益相关者的需求，却以牺牲其他利益相关者为代价。因此，交付的软件很难使用，或者颠覆了客户组织的文化或规则结构。产品经理需要识别、表示和管理许多不同类型的干系人的“观点”。
业务规则。这些语句可以约束业务本身的结构或行为的某些方面。例如 “没有全部支付学费的学生就不能注册下学期的课程”这是一个商业规则的例子，它将成为大学课程注册软件的需求来源。
操作环境。需求将来自执行软件的环境。例如，这些可能是实时软件中的时间约束或业务环境中的性能约束。这些必须积极的寻找，因为它们会极大地影响软件的可行性和成本，并限制软件的设计规则。
组织环境。通常需要软件来支持业务过程，对业务过程的选择可能受到组织的结构、文化和内部规则的制约。产品经理需要对这些问题比较敏感，因为一般来说，新软件不应该强制在业务过程中进行计划外的更改。

3.2.获取技术

一旦确定了需求来源，产品经理便可以开始从中获取需求信息。请注意需求很少是现成的。产品经理需要从这些信息中获取信息来制定需求。本主题集中于让人类参与者表达需求相关信息的技术。这是一项非常困难的任务，产品经理需要敏感地认识到这样一个事实，即用户可能难以描述他们的任务，可能会遗漏重要的信息，或者可能不愿意或不能合作。特别重要的是要明白，启发式抽取不是一种被动的活动。即使有合作的是善于表达的参与者，产品经理也必须努力工作来引出正确的信息。许多业务或技术需求都是默认的或不能从最终用户获得的反馈。计划、验证和确认在需求获取中的重要性怎么强调都不过分。

需求捕获技术最主要有:

谈话。采访干系人是抽取需求的“传统”方法。重要的是要了解访谈的优势和局限性以及应该如何进行。
场景。场景提供了一种有价值的手段来为激发用户需求提供环境。它们允许产品经理通过提供一个关于用户任务的问题框架“如果……会怎么样”和“如何做到”之类的问题。场景的最常见类型是用例描述。这里有一个主题4.2（概念建模）的链接，因为场景符号（例如用例图）在建模软件中很常见。
原型。对于澄清不明确的需求，该技术是一种有价值的工具。它们可以与场景类似的方式进行操作，为用户提供一个环境，用户可以在其中更好地理解需要提供哪些信息。原型技术的范围很广——从视觉设计模型到软件产品的测试版本——它们在需求捕获和需求验证方面的不同用途有很大的重叠（可参考6.2“原型设计”章节）。低保真度原型通常是首选，避免干系人锁定不必要的次要特征，这些特征可能会以意想不到的方式限制设计灵活性。
评审会议。评审会议的目的是通过更多干系人的参与，从而发挥集体智慧得到更多合理的需求。他们可以集思广益，重新思考那些通过谈话难以表达出来的想法。另一个优点是冲突的需求很早就出现了，可以让干系人识别这些需求发生的情况。这个方法可以获得更丰富和一致性更高的需求集。但是需要谨慎地处理会议(因此需要一个协调人)，以防止出现团队的关键能力被团队忠诚所侵蚀的情况，或者仅仅满足了那些更有发言权群体(可能是高层)的需求而对其他干系人产生不利。
观察法。在组织环境中软件环境的重要性，已导致将诸如“民族志”的观察技术用于需求激发。产品经理通过将自己沉浸在环境中来学习用户任务，并观察用户如何通过相互交互以及软件工具和其他资源来执行他们的任务。这些技术相对昂贵，但也很有指导意义，因为它们说明了许多用户任务和业务流程太过微妙和复杂，以至于参与者很难描述它们。
用户故事。该技术通常用于自适应方法（请参阅软件工程模型和方法KA中的敏捷方法），并且指的是以客户术语表示的对所需功能的简短高级描述。典型的用户故事具有以下形式： “作为一个<什么角色>，我想要<什么功能>，以便得到<什么好处>” 。（“ As a ，I want so that ”）。用户描述应该包含足够的信息，以便开发人员能够对实现它的工作做出合理的评估。这样做的目的是为了避免在项目中经常发生的一些浪费，在这些项目中详细的需求在工作开始之前就被收集起来了，但是这些需求在工作开始之前就变得无效了。在实现用户故事之前，客户必须编写一个适当的验收过程，以确定用户故事的目标是否已经实现。

作为一个[ 客户 ]，我想要[ 购物车功能 ]，这样我就可以[ 轻松地在线购买商品 ]。
作为一个[ 经理 ]，我想要[ 生成报告功能 ]这样我就可以[ 理解哪些部门需要更多资源 ]。
作为一个[ 客户 ]，我想要[ 在物品到达时收到短信 ]这样我就可以[ 马上去取回 ]

其他技术。还有一系列其他技术支持提取需求信息，从分析竞争对手的产品到应用数据挖掘技术，再到使用行业知识库或客户请求数据库。

4.需求分析

本主题涉及分析需求的过程。

发现和解决需求之间的冲突;
发现软件的边界，以及它必须如何与组织和操作环境交互;
详细阐述系统需求以导出软件需求。

需求分析的传统观点是，可以将其简化为使用多种分析方法之一的概念建模，例如结构化分析方法。虽然概念建模很重要，但我们包括需求分类，以帮助告知需求(需求分类)和建立这些权衡的过程(需求协商)之间的权衡。必须谨慎地足够精确地描述需求，以使需求能够被验证，它们的实现被验证，并且它们的成本被估计。

4.1.需求分类

需求可以在许多维度上分类。例子包括以下:

要求是功能性的还是非功能性的(见第1.3节功能性和非功能性要求)。
需求是从一个或多个高级需求衍生而来，还是来自衍生属性（请参见第1.4节，衍生属性），还是由利益相关者或其他来源直接施加于软件上。
要求是对产品还是对过程(见1.2，产品和过程要求)。对过程的要求可以约束承包商的选择、采用的软件工程过程或要遵守的标准。
需求优先级。优先级越高表明需求就越重要。通常按指定级别分类，如强制、高度期望、期望或可选，优先级常常必须与开发和实现的成本进行平衡。
需求的范围。范围是指需求对软件和软件组件的影响程度。有些需求，特别是某些非功能性需求，具有全局范围，因为它们的满足不能分配给离散的组件。因此，具有全局范围的需求可能强烈地影响软件体系结构和许多组件的设计，而具有较小范围的需求可能提供许多设计选择，对其他需求的满足影响很小。
易变性/稳定性。有些需求在软件的生命周期中——甚至在开发过程本身中——会发生变化。如果可以对需求变更的可能性进行一些估计，那么它是有用的。例如，在银行应用程序中，计算客户帐户的函数和信用利息的需求可能比支持特定类型的免税帐户的需求更稳定。前者反映了银行领域的一个基本特征(帐户可以赚取利息)，而后者可能因立法的改变而过时。标记潜在的不稳定需求可以帮助产品经理建立更能容忍更改的设计。

其他分类可能也合适，具体取决于组织的常规做法和应用程序本身。需求分类和需求属性之间有很强的重叠(见7.3节，需求属性)。

4.2.概念建模

实际问题模型的开发是软件需求分析的关键。他们的目的是帮助理解问题发生的情况，以及描述解决方案。因此，概念模型包含来自问题领域的实体模型，配置成反映它们在现实世界中的关系和依赖关系。

可以开发多种模型。这些包括用例图、数据流模型、状态模型、基于目标的模型、用户交互、对象模型、数据模型，以及许多其他工具。这些建模符号是统一建模语言 (UML)的一部分。例如，用例图通常用于描述边界将参与者（外部环境中的用户或系统）与内部行为分开的场景，其中每个用例都描述了系统的功能。

影响建模符号选择的因素包括:

问题的性质。某些类型的软件要求对某些方面进行特别严格的分析。例如，状态和参数模型(SysML[4]的一部分)对于实时软件可能比信息系统更重要，而对于对象和活动模型通常相反。
产品经理的专业知识。采用产品经理有经验的建模符号或方法通常更有效。
客户的工艺要求（见1.2节，产品与过程需求）。客户可以使用他们喜欢的符号或方法，或者禁止他们不熟悉的任何符号或方法。这个因素可能与前一个因素相冲突。

请注意，在几乎所有情况下，构建软件关联模型都是有用的。软件关联提供了目标软件与其外部环境之间的连接。这对于理解软件在其操作环境中的关联以及识别其与环境的接口是至关重要的。

这个子主题不寻求“教授”一种特定的建模风格或表示法，而是提供关于建模的目的和意图的指导。

4.3.体系结构设计和需求分配

在某种程度上，必须制定解决方案体系结构。体系结构设计是需求过程与软件或系统设计重叠的地方，并说明了完全分离两个任务是多么不可能。该主题与软件设计KA中的软件结构和体系结构密切相关。在许多情况下，产品经理扮演软件架构师的角色，因为在分析和细化需求的过程中，需要识别负责满足需求的架构/设计组件。这就是需求分配——分配给负责满足需求的体系结构组件。

分配对于详细分析需求非常重要。因此，举例来说，一旦一组需求被分配给一个组件，单个的需求可以被进一步分析，以发现关于组件需要如何与其他组件交互以满足分配需求的进一步需求。在大型项目中，分配刺激了对每个子系统的新一轮分析。例如，对汽车特定制动性能的要求(制动距离、在恶劣驾驶条件下的安全性、应用的平稳性、所需的踏板压力等等)可能会分配给制动硬件(机械和液压组件)和防抱死制动系统(ABS)。只有当对防抱死制动系统的需求被识别出来，并且被分配给它时，ABS的能力，制动硬件，和紧急属性(例如汽车重量)才能被用来识别详细的ABS软件需求。

结构设计与概念建模密切相关（请参见第4.2节，概念建模）。

4.4.需求协商

这个小主题的另一个常用术语是“冲突解决”。例如，这涉及到解决两个干系人之间发生冲突的需求问题，比如需求和资源之间的冲突，或者功能性和非功能性需求之间的冲突。在大多数情况下，产品经理做出单方面的决定是不明智的，因此有必要与利益相关者进行协商，以在适当的权衡上达成共识。出于契约的原因，这样的决策可以追溯到客户，这通常很重要。我们将其分类为软件需求分析主题，因为问题会在分析的结果中出现。然而，也可以将其视为需求验证主题(参见主题6，需求验证)。

需求优先级是必要的，不仅是作为处理重要需求的一种手段，也是为了解决冲突和计划阶段交付，这意味着做出复杂的决策，需要详细的行业知识和良好的评估技能。然而，要获得作为此类决策基础的真实信息往往很困难。此外，需求常常相互依赖，并且优先级是相对的。在实践中，产品经理经常在不了解所有需求的情况下执行需求优先级划分。需求优先级的确定可能遵循成本价值的方法，该方法涉及到利益相关者对需求实现带来的收益或合计的价值的分析，以及未实现特定需求的惩罚。它还包括由软件工程师进行的分析，对实现每个需求相对于其他需求的成本进行规模估算。另一种需求优先级划分方法称为层次分析法，它涉及到比较所有独特的需求对，以确定两者中哪一个具有更高的优先级，以及在何种程度上。

4.5.形式化分析

形式化化分析已经对一些应用领域产生了影响，特别是那些具有高度完整性的系统。需求的正式表达需要一种具有正式修正语义的语言。对需求表达使用形式化分析有两个好处。首先，它使用语言表达的需求能够精确而明确地指定，从而(在原则上)避免可能的误解。其次，可以对需求进行推理，允许特定软件的期望属性得到证明。形式推理需要工具支持，以使其适用于除琐碎系统之外的任何事物，而工具通常分为两类: 定理证明者或模型检验者。在这两种情况下，证明都不能完全自动化，而使用工具所需的形式推理能力限制了形式分析的更广泛应用。

大多数正式的分析集中在需求分析的相对较晚的阶段。在业务目标和用户需求通过第4节中其他地方描述的方法得到关注之前，应用形式化通常是适得其反的。然而，一旦需求稳定下来，并且详细说明了软件的具体属性，至少将关键需求形式化可能是有益的。这允许静态验证，即根据需求指定的软件确实具有客户、用户和软件工程师所期望的属性(例如，不存在死锁)。

5.需求规格说明

对于大多数工程专业来说，术语“规格”指的是对产品设计目标的数值分配或限制。在软件工程中，“软件需求规格说明”通常指的是可以系统地审查、评估和批准的文档的生成。对于复杂的系统，特别是那些涉及实质性的非软件组件的系统，会产生多达三种不同类型的文档: 系统定义、系统需求和软件需求。对于简单的软件产品，只需要其中的三分之一。这里描述了这三个文档，并理解它们可以适当地组合在一起。

5.1.系统定义文档

该文档(有时称为用户需求文档或操作概念文档)记录系统需求。它从行业的角度去裁剪高层次的系统需求。其读者包括系统用户/客户的代表(市场营销对于市场驱动的软件可能扮演这些角色)，所以它的内容必须按照行业来表达。该文档列出了系统需求以及关于系统总体目标、目标环境的背景信息，以及约束条件、假设和非功能需求的陈述。它可能包括设计用来说明系统环境、使用场景和主要行业实体以及工作流的概念模型。

5.2.系统需求规格说明

拥有大量软件和非软件组件的系统(例如现代客机)的开发人员经常将系统需求描述与软件需求描述分开。在这个视图中，指定了系统需求，从系统需求派生出软件需求，然后指定了软件组件的需求。严格地说，系统需求说明是一项系统工程活动。

5.3.软件需求规格说明

软件需求规定为客户和承包商或供应商(在市场驱动的项目中，这些角色可能由市场和开发部门扮演)就软件产品应该做什么以及不应该做什么达成协议奠定了基础。

软件需求说明允许在设计开始之前对需求进行严格的评估，并减少以后的重新设计。它还应该为估算产品成本、风险和进度提供一个现实的基础。

组织也可以使用软件需求规格文件作为开发有效的验证和验证计划的基础。

软件需求说明为将软件产品转移到新用户或软件平台提供了一个知情的基础。最后，为软件的改进提供了依据。

软件需求通常是用自然语言编写的，但是在软件需求说明中，这可能由正式或半正式的描述来补充。选择适当的符号可以比自然语言更精确和简明地描述软件架构的特定需求和方面。一般的规则是，应该使用允许尽可能精确地描述需求的符号。这对于安全关键型、监管型和其他类型的可靠软件尤其重要。但是，符号的选择常常受到文档作者和读者的培训、技能和偏好的限制。

已经开发了许多质量指标，这些指标可以用来将软件需求的质量与其他项目变量(如成本、验收、性能、进度和再现性)联系起来。个别软件需求声明的质量指标包括命令、指令、弱短语、选项和延续。整个软件需求说明文件的指标包括大小、可读性、说明、深度和文本结构。

6.需求确认

需求文件可能要经过验证和验证程序。可以验证需求以确保软件工程师已经理解需求；验证需求文档是否符合公司标准以及可理解，一致和完整也很重要。如果书面的公司标准或术语与广泛接受的标准不一致，则应在两者之间达成映射并将其附加到文件中。

正式的符号提供了重要的优点，即可以证明最后两个属性（至少在限定的意义上）。不同的利益相关者，包括客户和开发人员的代表，应审查文档。需求文档应与软件生命周期过程中的其他可交付成果遵循相同的配置管理惯例。如果可行，通常还使用需求管理工具对单个需求进行配置管理（请参阅主题8，软件需求工具）。

通常，在需求过程中明确安排一个或多个验证需求的点。目的是在致力于解决需求之前先解决所有问题。需求确认与检查需求文档以确保定义正确的软件（即用户期望的软件）。

6.1.需求评审

验证的最常用方法可能是检查或审查需求文档。为一组审阅者分配了一个摘要，以查找错误，错误的假设，缺乏清晰性以及与标准做法的背离。进行审核的小组的组成非常重要（例如，对于一个客户驱动的项目，至少应包括一位客户代表），这可能有助于以清单的形式提供有关寻找内容的指导。

可以在完成系统定义文档，系统规范文档，软件要求规范文档，新发行版的基准规范或过程中的任何其他步骤时进行评审。

6.2.建造原型

原型制作通常是一种验证产品经理对软件需求的解释以及得出新需求的方法。与启发式一样，在原型验证可能适用的过程中，存在许多原型技术和许多要点。原型的优势在于，它们可以使解释产品经理的假设变得更加容易，并在需要时提供有关错误原因的有用反馈。例如，通过动画原型比通过文本描述或图形模型可以更好地理解用户界面的动态行为。在样机完成后定义的需求的波动性极低，因为利益相关者与产品经理之间达成了协议，因此，对于安全性至关紧要的特性，样机确实会有所帮助。但是，也有缺点。其中包括由于外观问题或原型质量问题而使用户的注意力从核心底层功能上转移开来的危险。因此，一些主张避免使用软件的原型，例如基于动态图表的模型。原型开发成本可能很高。但是，如果避免因试图满足错误要求而造成资源浪费，则可以更容易地证明其成本合理。早期的原型可能包含最终解决方案的各个方面。原型可能是进化的，而不是一次性的。

6.3.模型确认

通常有必要验证分析过程中开发的模型的质量。例如，在对象模型中，执行静态分析以验证在利益相关者域内交换数据的对象之间存在通信路径非常有用。如果使用形式分析符号，则可以使用形式推理来证明规范属性。该主题与软件工程模型和方法KA密切相关。

6.4.接收测试

软件需求的一个基本特性是，应该有可能验证成品是否满足要求。无法验证的需求实际上只是“愿望”。因此，一项重要任务是计划如何验证每个需求。在大多数情况下，设计验收测试是针对最终用户通常如何使用该系统开展业务的。
识别和设计验收测试对于非功能性需求可能很难（请参阅第1.3节“功能性和非功能性需求”）。要进行验证，他们必须首先被分析和分解到可以定量表达的地步。
可以在软件测试KA的验收/资格/一致性测试中找到其他信息。

7.实际考虑

需求过程跨越整个软件生命周期。变更管理和对需求的维护在准确反映要构建的软件或已构建的软件的状态下，对于软件工程过程的成功至关重要。

并非每个组织都有记录和管理需求的文化。在强大的“产品远景”和有限的资源的驱动下，动态启动公司通常将需求文档视为不必要的开销。但是，大多数时候，随着这些公司的扩张，客户群的增长以及产品的发展，他们发现他们需要恢复激发产品功能的需求，以评估提议的变更的影响。因此，需求文档和变更管理是任何需求流程成功的关键。

7.1.需求过程的迭代本质

越来越短的开发周期给软件行业带来了普遍压力，这在竞争激烈，市场驱动的行业中尤为明显。而且，大多数项目都受到其环境的某种限制，许多项目是对已有架构的现有软件的升级或修订。因此，在实践中，将需求过程作为线性的确定性过程来实施几乎总是不切实际的，在该过程中，从利益相关者那里得出软件需求，将其基线化，分配并移交给软件开发团队。大型软件项目的需求永远被完全理解或明确指定是一个神话。

取而代之的是，需求通常会迭代到足以使设计和采购决策得以做出的质量和细节水平。在某些项目中，这可能导致在完全了解其所有属性之前将这些需求作为基准。如果在软件工程过程中出现问题，则有可能进行昂贵的返工。但是，产品经理必然受到项目管理计划的约束，因此必须采取措施以确保在可用资源允许的情况下，要求的“质量”尽可能高。例如，他们应该明确提出支持需求的任何假设以及任何已知问题。

对于迭代开发的软件产品，项目团队可能仅将当前迭代所需的那些需求作为基线。需求专家可以继续为将来的迭代开发需求，而开发人员则可以进行当前迭代的设计和构建。这种方法可快速为客户提供业务价值，同时最大程度地减少返工成本。

在几乎所有情况下，随着设计和开发的进行，对需求的理解也在不断发展。这通常会导致生命周期后期需求的修订。理解软件需求的最关键点可能是需求的很大一部分将改变。有时这是由于分析错误引起的，但通常是“环境”变化的必然结果，例如，客户的运营或商业环境，当局施加的监管流程或软件必须销售到的市场。无论是什么原因，重要的是要认识到变化的必然性，并采取措施减轻其影响。必须通过确保建议的更改经过明确的审核和批准流程并应用仔细的需求跟踪，影响分析和软件配置管理来管理更改（请参阅软件配置管理KA）。因此，需求过程不仅是软件开发中的前端任务，而且涵盖了整个软件生命周期。在一个典型的项目中，软件需求活动会随着时间的推移从启发到变更管理。自上而下的分析和设计方法与自下而上的实现和重构方法在中间相结合，可以提供两全其美的效果。但是，这在实践中很难实现，因为它在很大程度上取决于产品经理的成熟度和专业知识。

7.2.变更管理

变更管理对于需求管理至关重要。本主题描述了变更管理的角色，需要采用的程序以及应应用于拟议变更的分析。它与软件配置管理KA有很强的链接。

7.3.需求属性

需求不仅应包括对需求的说明，还应包括辅助信息，以帮助管理和解释需求。随着开发或维护中的软件的发展，必须定义，记录和更新需求属性。这应该包括需求的各种分类维度（请参见第4.1节，需求分类）以及验证方法或相关的验收测试计划部分。它还可能包括其他信息，例如每个需求的摘要理由，每个需求的来源以及变更历史。但是，最重要的需求属性是一个标识符，它可以唯一且明确地标识需求。

7.4.需求追踪

需求跟踪与恢复需求源和预测需求影响有关。当需求发生变化时，跟踪对于执行影响分析至关重要。需求应追溯到激发需求的需求和利益相关者（例如，从软件需求到可以帮助满足的系统需求）。相反，需求应该追溯到需求和满足需求的设计实体（例如，从系统需求到已经详细阐述的软件需求，再到实现它的代码模块或测试用例）。与该代码有关，甚至在用户手册中描述了实际功能的给定部分中也是如此），并在包含该代码的测试案例中使用。

对典型项目的需求跟踪将形成需求的复杂有向无环图（DAG）（请参阅计算基础 KA中的图）。维护最新的图形或可追溯性矩阵是产品整个生命周期中必须考虑的一项活动。如果随着需求的变化继续发生而未更新可追溯性信息，则可追溯性信息对于影响分析将变得不可靠。

7.5.需求度量

实际上，对特定软件产品的需求“量”有一些概念通常很有用。此数字可用于评估需求变化的“大小”，估计开发或维护任务的成本，或仅用作其他度量的分母。软件规模度量（FSM）是一种用于评估功能需求主体大小的技术。

有关尺寸测量和标准的其他信息，请参见软件工程过程KA。

8.软件需求工具

用于处理软件需求的工具大致分为两类：用于建模的工具和用于管理需求的工具。

需求管理工具通常支持一系列活动，包括文档，跟踪和变更管理，并且对实践产生了重大影响。确实，只有在工具支持的情况下，跟踪和变更管理才切实可行。由于需求管理是良好需求实践的基础，因此许多组织已经投资了需求管理工具，尽管更多的组织以更多的临时性和通常不太令人满意的方式（例如，使用电子表格）来管理其需求。

SWEBOK软件工程知识体系 - 1.软件需求相关推荐

SWEBOK软件工程知识体系 - 11.软件工程专业实践
软件工程专业实践(SOFTWARE ENGINEERING PROFESSIONAL PRACTICE) 软件工程专业实践知识领域(KA)涉及软件工程师必须具备的知识.技能和态度,以专业.负责和道德的 ...
SWEBOK软件工程知识体系 - 13.计算基础
计算基础(COMPUTING FOUNDATIONS) 计算基础知识领域(KA)的范围包括软件演化和执行的开发和操作环境.因为任何软件都不可能在真空中存在,也不可能在没有计算机的情况下运行,所以这种环 ...
SWEBOK软件工程知识体系 - 10.软件质量
软件质量(SOFTWARE QUALITY) 什么是软件质量,为什么它如此重要以至于它包含在SWEBOK指南的许多知识领域(KA)中? 其中一个原因是软件质量这个术语过载了.软件质量可以是指:软件产品 ...
软件工程复习07：软件需求
作者:非妃是公主专栏:<程序人生> 个性签:顺境不惰,逆境不馁,以心制境,万事可成.--曾国藩专栏地址软件工程专栏地址专栏系列文章软件工程复习01:软件工程概述软件工程复习02 ...
【系统分析】软件工程-知识体系概览
提示:单击可放大图片注:作为系统分析师需要掌握软件工程相关知识体系,软件工程是计算机专业一门必修课,涵盖内容非常多,这里整理的概览图只是概要提到涉及的点.如需进一步研究请自行查阅相关材料. 软件工程 ...
软件工程之需求分析②（软件需求规则说明书、数据要求说明书、初步用户手册、软件开发实施计划）
软件需求分析阶段研究的对象是软件项目的用户要求,如何准确表达用户的要求,怎样与用户共同明确将要开发的是一个什么样的系统,是需求分析要解决的主要问题.也就是说需求阶段的任务并不是确定系统怎样完成工作 ...
软件工程质量管理体系要求_软件质量管理| 软件工程
软件工程质量管理体系要求软件质量管理体系 (Software quality management system) A quality management system frequently me ...
【AI案例】（二）搭建大数据Python生态知识体系
文章目录 1. 软件在大数据方向的应用 2. 大数据方向应用: 3. 大数据的应用流程 4. 传统数据分析的痛点: 5. 大数据的应用流程与生态圈 6. 大数据技术框架应用 7. Flink框架应用 ...
软件设计师知识体系归纳总结
软件设计师知识体系归纳总结历年考点上午题下午题第一章计算机组成原理及体系结构 1.数据的表示 1.1进制转换 (1) R进制转十进制 (2) 十进制转R进制 (3) 二进制八进制十六进制 ...

SWEBOK软件工程知识体系 - 1.软件需求