SWEBOK中文版.doc

第一章 软件需求缩略词CIA机密性，完整性，可用性DAG定向非循环图FSM功能规模度量INCOSE系统工程国际委员会UML统一建模语言SysML系统建模语言介绍软件需求知识领域(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*, c14, 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, c12s52*, 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，需求验证）也是一个强有力的例子。需求优先排序是必要的，不仅是过滤重要需求的手段，而且也是为了解决突发事件的冲突和计划，这意味着要做出复杂的决策，需要详细的领域知识和良好的估计技能。然而，通常难以获得可以作为此类决策基础的真实信息。另外，需求往往依赖于彼此，优先级也是相对的。实际上，软件工程师在不了解所有需求的情况下经常执行需求优先级排序。需求优先排序可能遵循成本估值方法，涉及利益相关方的分析，从而规定了实施该需求带来的利益或总价值，而不是对未实施特定需求的处罚。它还涉及软件工程师的分析，以相对于其他需求来估计实施每个需求的成本。另一种需求优先级排序方法称为层次分析法，它涉及对所有需求的需求进行比较，以确定两者中哪一个具有较高优先级，以及在多大程度上是较高优先级。4.5 正式分析正式分析不仅涉及主题4，还涉及第5.3和6.3节。本课题与软件工程模型与方法知识领域的正式方法有关。正式分析对一些应用领域，特别是高度整合系统的应用领域产生了影响。 需求的正式表达需要具有正式定义的语义的语言。对需求表达的正式分析的使用有两个好处。首先，它能够准确，明确地指定用语言表达的需求，从而（原则上）避免了误解的可能性。其次，可以推理出需求，允许指定的软件的所需属性被证明。正式的推理要求工具支持对于除琐碎系统以外的其他任何工具都是可行的，而工具通常分为两种：定理验证器或模型检查器。在这两种情况下都不能完全自动化证明，而为了使用这些工具而需要正式推理的能力水平限制了更广泛的正式分析应用。大多数正式分析集中在需求分析相对较晚的阶段。 通过适用形式化，直到业务目标和用户需求通过诸如第4节中其他地方描述的手段进行突出重点，才适用正式化。但是，一旦需求已经稳定并且已经被详细说明来指定软件的具体属性，那么至少对关键需求进行正式化是有益的。这允许静态验证，由需求确定的软件确实具有客户，用户和软件工程师期望拥有的属性（例如，不存在死锁）。5. 需求规范1*, c4s2, c4s3, c12s25 2*, c10 对于大多数工程专业来说，术语“指定”是指对产品设计目标的数值或限制的分配。在软件工程中，“软件需求规范”通常是指可以系统地审查，评估和批准的文档的生成。对于复杂系统，特别是那些涉及大量非软件组件的系统，可以生成多达三种不同类型的文档：系统定义，系统需求和软件需求。对于简单的软件产品，只需要三分之一。 所有这三个文件都在这里进行了描述，理解是它们可以合适组合。 系统工程的描述可以在本指南的“软件工程相关学科”一章中找到。5.1 系统定义文件本文档（有时称为用户要求文档或操作文档概念）记录系统要求。 它从域角度定义了高级系统要求。 其读者群体包括系统用户/客户的代表（市场营销可能扮演市场驱动软件的角色），因此其内容必须按照域名进行。该文件列出了系统要求以及有关系统总体目标，目标环境以及约束，假设和非功能性要求的说明的背景信息。它可能包括旨在说明系统上下文，使用场景和主要域实体以及工作流程的概念模型。5.2 系统需求规范具有大量软件和非软件组件的系统开发人员（例如，现代客机）通常将系统需求的描述与软件需求的描述分开。在此视图中，指定系统需求，软件需求来自系统需求，然后指定软件组件的需求。严格来说，系统需求规范是系统工程活动，不属于本指南的范围。5.3 软件需求规范软件需求规范为客户和承包商或供应商之间的协议（市场驱动的项目，营销和开发部门可能扮演的角色）关于软件产品要做什么以及它不期望做什么做出了规范。软件需求规定允许在设计开始之前对需求进行严格的评估，并减少以后的重新设计。它还应该为估算产品成本，风险和时间表提供一个现实的依据。组织还可以使用软件需求规范文件作为开发有效的验证和验证计划的基础。软件需求规范为将软件产品转移到新用户或软件平台提供了明智的基础。最后，它可以为软件增强提供依据。软件需求通常以自然语言编写，但在软件需求规范中，可以通过正式或半形式的描述进行补充。选择适当的符号可以使软件架构的特定要求和方面比自然语言更准确和简洁地描述。一般规则是应该使用允许尽可能精确地描述要求的符号。这对安全关键，监管和某些其他类型的可靠软件尤其重要。然而，符号的选择往往受到文献作者和读者的训练，技能和偏好的限制。已经开发了许多质量指标，可用于将软件需求规范的质量与其他项目变量（如成本，验收，性能，进度和重复性）相关联。 个别软件需求说明书的质量指标包括要求，指令，弱词，选项和持续性。 整个软件需求规范文件的指标包括大小，可读性，规格，深度和文本结构。6. 需求验证1*, c4s6 2*, c13, c15 需求文件可能需要验证和验证程序。 可以验证需求，以确保软件工程师了解需求; 验证需求文件是否符合公司标准，并且可以理解，一致和完整也很重要。 在文件化公司标准或术语与广泛接受的标准不一致的情况下，两者之间的映射应在文档中同意并附加。正式符号提供了允许最后两个属性被证明的重要优点（至少在有限的意义上）。不同的利益相关者，包括客户和开发人员的代表，应该审查文件。需求文件与软件生命周期流程的其他可交付成果具有相同的配置管理实践。实际上，个人需求也需要进行配置管理，通常使用需求管理工具（参见主题8，软件需求工具）。在需求验证的需求过程中明确安排一个或多个点是正常的。 目的是在资源承诺满足需求之前解决任何问题。需求验证涉及检查需求文档的过程，以确保其定义正确的软件（即用户期望的软件）。6.1 需求评审也许最常见的验证手段是通过对需求文件的检查或审查。一组评审员被分配一个简短的内容来寻找错误，错误的假设，缺乏明确性和偏离标准实践。进行审查的小组的组成很重要（例如，客户至少有一名客户的代表应被包括在客户驱动的项目中），并且可能有助于以清单的形式提供关于要查找的内容的指导。在完成系统定义文件，系统指定文件，软件需求规范文件，新版本的基准规范或过程中的任何其他步骤之后，可以构建审查。6.2 原型设计原型通常是验证软件工程师对软件需求的解释以及引出新需求的手段。与引出一样，在原型验证可能适合的过程中存在一系列原型技术和许多要点。原型的优点是，它们可以使软件工程师的假设更容易解释，并在必要时对其为什么是错误提供有用的反馈。例如，通过动画原型可以比通过文本描述或图形模型更好地了解用户界面的动态行为。在原型设计之后定义的要求的波动性非常低，因为利益相关者和软件工程师之间达成一致 - 因此，对于安全关键和关键特征，原型设计将真正有帮助。不过也有缺点。这些包括用户的注意力受到原型的化妆品问题或质量问题的核心潜在功能的束缚。因此，一些提倡避免软件的原型，例如基于flip-chart的模型。原型开发成本可能很高。但是，如果避免因试图满足错误要求而导致的资源浪费，则可以更容易理解成本。早期原型可能包含最终解决方案。原型可能是进化的，而不是一次性的。6.3模型验证通常需要验证分析过程中开发的模型的质量。例如，在对象模型中，执行静态分析以验证在利益相关者的领域交换数据的对象之间存在通信路径是有用的。如果使用正式的分析符号，可以使用正式推理来证明规范属性。本课题与软件工程模型与方法KA密切相关。6.4 验收测试软件需求的基本属性是可以验证成品是否满足需求。无法验证的需求只是“愿望”。因此，重要的任务是计划如何验证每个需求。在大多数情况下，设计验收测试是为了最终用户通常使用系统进行业务。识别和设计验收测试可能会对非功能性要求产生影响（见第1.3节功能和非功能性要求）。 要进行验证，必须对其进行分析和分解，以便能够定量表达。附加信息可以在软件测试KA中的验收/质量/一致性测试中找到。7. 实际问题1*, c4s1, c4s4, c4s6, c4s72*, c3, c12, c14, c16, c1821 这个KA中呈现的主题分解的第一级似乎可以描述一个线性的活动顺序。 这是该过程的简化视图。需求过程跨越整个软件生命周期。在准确地反映要构建的软件或已经构建的软件的状态下，变更管理和维护需求是软件工程流程成功的关键。并不是每个组织都有文件记录和管理要求。在强大的“产品愿景”和有限的资源驱动下，动态创业公司通常会将需求文档视为不必要的开销。然而，随着这些公司的扩张，随着他们的客户群体的增长，随着产品开始发展，他们发现他们需要恢复激励产品功能的要求，以评估所提出的改变的影响。因此，需求文件和变更管理是任何需求流程成功的关键。7.1 需求过程的迭代性质软件行业的发展周期越来越短，在竞争激烈的市场驱动型行业尤为突出。此外，大多数项目都受到环境的某种限制，许多项目都是对现有软件进行升级或修改，其中架构是给定的。因此，在实践中，将需求过程实施为线性确定性过程几乎总是不切实际的，其中从利益相关者获取软件需求，基线化，分配和移交给软件开发团队。毫无疑问，对大型软件项目的需求已经被完全理解或完全确定了。相反，需求通常迭代到一定程度的质量和细节，足以允许进行设计和采购决策。在一些项目中，这可能会导致在所有财产被完全理解之前，基准线的需求。如果在软件工程过程中出现问题，这样做会导致昂贵的返工。然而，软件工程师必然受到项目管理计划的约束，因此必须采取措施，确保在可用资源下，需求的“质量”尽可能高。 例如，他们应该明确提出支持这些需求以及任何已知问题的假设。对于迭代开发的软件产品，项目团队只能基于当前迭代所需的那些需求。需求专家可以继续开发未来迭代的需求，而开发人员继续设计和构建当前的迭代。这种方法为客户提供快速的业务价值，同时最大限度地降低返工成本。在几乎所有情况下，随着设计和开发的进行，需求理解不断发展。这通常导致在生命周期晚期修订要求。也许在了解软件需求方面最关键的一点是，要求的重要部分将会发生变化。这有时是由于分析中的错误，但它常常是“环境”变化的必然结果 - 例如，客户的经营或业务环境，当局强加的监管流程或软件必须销售的市场。无论是什么原因，重要的是认识到变革的必然性，并采取步骤来减轻其影响。必须通过确保提出的更改通过定义的审批和审批流程，并通过应用仔细的需求跟踪，影响分析和软件配置管理来管理变更（请参阅软件配置管理KA）。因此，需求过程不仅仅是软件开发中的前端任务，而是整个软件生命周期。在一个典型的项目中，软件需求活动随着时间的推移从诱导到变革管理发展。自上而下的分析和设计方法的组合以及在中间满足的自下而上的实施和重构方法可以提供两个世界中最好的。然而，这在实践中是难以实现的，因为它在很大程度上取决于软件工程师的成熟度和专业知识。7.2 变更管理变更管理是管理要求的核心。本主题描述变更管理的作用，需要进行的程序以及应用于建议的变更的分析。它与软件配置管理KA有紧密的联系。7.3 需求属性需求不仅包括所需求的规范，而且还包括有助于管理和解释需求的辅助信息。随着正在开发或维护的软件的发展，需求属性必须进行定义，记录和更新。这应包括需求的各种分类尺寸（见4.1节，要求分类）和验证方法或相关验收测试计划部分。它还可以包括其他信息，例如每个需求的总结理由，每个需求的来源以及变更历史。然而，最重要的需求属性是允许唯一和明确识别需求的标识符。7.4 需求跟踪需求跟踪涉及恢复需求来源并预测需求的影响。跟踪是在需求变化时进行影响分析的基础。应该追溯到需求和利益相关者的追溯（例如从软件需求到系统需求）。相反，一个要求应该可追溯到满足它的需求和设计实体（例如，从系统要求到从其中阐述的软件需求，以及实现它的代码模块，或测试用例 与该代码相关，甚至是描述实际功能的用户手册中的给定部分）以及验证它的测试用例。典型项目的需求跟踪将形成复杂的有向无环图（DAG）（见计算基础KA中的图表）需求。维护最新的图表或可追溯性矩阵是在产品的整个生命周期中必须考虑的活动。如果可追溯性信息随着需求的变化继续发生而不更新，则可追溯性信息对于影响分析变得不可靠。7.5 需求测量实际上，对于特定软件产品的需求的“体积”的一些概念通常是有用的。这个数字在评估需求变化的“大小”，估计开发或维护任务的成本或简单地用作其他测量中的分母时很有用。功能尺寸测量（FSM）是一种用于评估身体功能需求的尺寸的技术。有关尺寸测量和标准的其他信息将在软件工程流程KA中找到。8. 软件需求模型处理软件需求的工具大致分为两类：建模工具和管理需求的工具。 需求管理工具通常支持一系列活动，包括文档，跟踪和变更管理，并对实践产生重大影响。事实上，跟踪和变更管理真的只有在一个工具的支持下才可行。由于需求管理是良好需求实践的基础，许多组织已经投入了需求管理工具，尽管更多的管理工具更多地以更特殊的方式（通常使用电子表格）来满足需求。