系统与软件工程 产品线需求工程的工具和方法 征求意见稿

1GB/TXXXXX—XXXX/ISO/IEC26551:2016系统与软件工程产品线需求工程的工具和方法本文件在软件与系统产品线需求工程的工具和方法的范围内：——为软件和系统产品线以及相关成员产品的需求工程提供特定的术语和定义；——定义过程组及在产品线需求工程中执行的过程（这些过程根据目的、输入、任务和输出进行描述）；——定义方法能力，以支持每个过程的定义任务；——定义工具能力，将任务或定义的方法能力自动化或半自动化。本文件关注的是产品族而不是单系统的需求工具和方法的过程和能力。本文件不适用于实物制品。相反，系统级制品和软件生存周期制品，如需求文件、架构数据、验证计划、行为模型等，都使用本文件方法和工具生成。对于系统的软件组件，本文件可用于处理产品线的系统要素和用于处理产品线的软件要素（如有）。产品线过程在不同层次的产品中是递归的。2规范性引用文件本文件没有规范性引用文件。3术语和定义下列术语和定义适用于本文件。3.1应用需求资产applicationassetsinrequirements在应用需求工程过程中产生的特定于应用的制品，例如应用需求规格说明（3.4）和应用需求模型。3.2应用需求获取applicationrequirementselicitation识别与应用相关的利益相关方，获取应用特定需求并绑定适当的变体的子过程。3.3应用需求分析applicationrequirementsanalysis理解所有应用特定需求（3.9）的子过程，通过建模来检查不正确和不一致的应用需求，然后分析和协商不能通过领域需求来满足的应用需求。3.4应用需求规格说明applicationrequirementsspecification文档化应用特定需求（3.9）并将其与领域需求规格说明（3.13）集成的子过程，领域需求规格说明的变体被绑定。3.5应用需求验证和确认applicationrequirementsverificationandvalidation确认应用特定需求（3.9）的一致性和可行性，并确保绑定的变体满足特定产品的需求的子过程。2GB/TXXXXX—XXXX/ISO/IEC26551:20163.6应用需求管理applicationrequirementsmanagement管理应用需求的可追溯性和变更的子过程.3.7方面aspect在产品线工程过程组和任务中，能关联专门方法和工具的特定因素。3.8资产建议assetproposal包括主要资产（功能域和所有应用的高层级通用与可变特征）的制品，这些资产可包含在产品线中，并具有量化的成本和收益，以及评估结果。3.9应用特定需求applicationspecificrequirements特定于应用的需求，或者领域需求中未涵盖的需求。3.10领域需求资产domainassetsinrequirements在领域需求工程中产生的可重用制品，如资产建议（3.8）、领域需求规格说明（3.13）和领域需求模型。3.11领域需求获取domainrequirementselicitation识别领域利益相关方对产品线的原始需求的子过程。3.12领域需求分析domainrequirementsanalysis对领域需求建模的子过程，以便分析和检查需求中产品线的共性和可变性。3.13领域需求规格说明domainrequirementsspecification根据领域分析结果文档化产品线领域需求的子过程。3.14领域需求验证和确认domainrequirementsverificationandvalidation确认领域需求正确、一致和完整的子过程。3.15领域需求管理domainrequirementsmanagement管理领域需求及与其相关的领域和应用制品的可追溯性和变更的子过程。3.16功能域functionaldomain通常一起使用的分类功能。3.17产品计划productionplan描述如何使用领域资产开发产品线成员产品。3.18需求可追溯性requirementstraceability领域和应用需求各自可追溯性以及它们之间的可追溯性。3.19构造texture3GB/TXXXXX—XXXX/ISO/IEC26551:2016架构性构造architecturaltexture实现产品线应用的通用开发规则和约束条件的集合。3.20需求可变性variabilityinrequirements需求工程的外部和内部可变性。4产品线需求工程参考模型产品线需求工程的方法和工具应支持领域和应用需求工程过程的系统管理和交互。还需要与其他产品线工程生存周期过程充分集成，以实现所有需求制品与相关的设计、实现和测试制品之间的可追溯性。产品线需求工程实践、方法和工具按照聚焦于产品线需求工程的框架进行描述(见图1)。产品线范围界定通过与领域和应用需求工程的持续交互来创建和维护产品线范围，从而引导和控制产品线的所有工作。领域需求工程用于：——将产品线范围界定中定义的特征分解为原始需求和从利益相关方及领域专家获取的其他需求和派生需求；——利用需求可变性分析领域需求；——对领域需求的静态和行为结构进行建模和仿真；——文档化领域需求规格说明，这些需求能够被产品线的特定成员产品绑定。随着产品线的复杂性增加，可变性的复杂性也相应增加。将可变性与领域需求工程分离可缓解这个问题。独立定义需求可变性有助于清晰理解工具和方法所需的必要功能，并帮助选择支持产品线需求工程的工具。应用需求工程用于：——识别领域特征和特定应用的特征之间的差距；——重用资产库领域需求，并获取应用特定需求；——通过绑定领域可变性模型并添加特定应用的可变性来定义应用可变性模型；——分析并文档化应用特定需求；——为产品线范围界定和领域需求工程提供反馈，以促进产品线的发展。图1产品线需求工程参考模型划分为五个过程：产品线范围界定、领域需求工程、需求工程可变性管理、需求工程资产管理和应用需求工程。每个过程都划分为子过程，以解决技术管理问题，每个子过程都根据以下属性进行描述：——子过程的标题；——子过程的目的；——产生输出的输入；——获得输出的任务；——子过程的输出。4GB/TXXXXX—XXXX/ISO/IEC26551:2016图1产品线需求工框架产品线范围界定定义了成员产品及主要（外部可见）特征、从经济角度分析产品，并控制和计划产品线及产品的生产。这一过程的主要结果是资产建议。资产建议包括产品线的主要资产（功能域和高层级通用和可变特征）及量化的成本和收益，以及产品线开发预期的投资回报率。可提出多个资产建议，以找出最优的产品和资产集合。领域和应用需求工程从资产建议中定义的特征开始。产品线范围界定完成以下工作，并定义支持工具和方法的能力：——产品范围界定，确定产品组合定义，并为向客户或市场发布特定应用提供路线图；——领域范围界定，识别并限制功能域范围，以提供足够的重用潜力；——资产范围界定，识别可重用资产，评估成本和效益以证明产品线启动的合理性。领域需求工程从使用产品线范围界定的结果开始。全面地获取产品线的原始领域需求，并构建包括可变性模型的原始需求规格说明。向组织的业务管理过程组提供关于特征集和产品路线图中所需变更的整体反馈。领域需求工程文档化领域需求规格，以便之后在领域设计和应用需求工程中使用。领域需求工程完成以下工作，并定义支持工具和方法的能力：——领域需求获取，获取原始领域需求和这些需求的预期变化；——领域需求分析，识别功能性和非功能性需求以及这些需求的可变性；——领域需求规格说明，根据分析结果文档化领域需求；——领域需求验证和确认，确认领域需求是一致的、可行的，并且确保产品线所有产品需求都能被充分理解；——领域需求管理，为需求工程的双重性质，即领域和应用需求工程，提供管理服务。需求工程可变性管理应与领域需求工程并行进行，因为可变性模型是随着领域和应用需求一起逐渐澄清和修改的。可变性建模作为领域需求获取的一部分开始，并在整个产品线生存周期中不断发展。该过程负责明确地文档化外部可变性的可变性模型。随着领域需求工程活动的进行，一些额外的内部可变性可能会被添加到可变性模型中。需求工程可变性管理完成以下工作，并定义支持工具和方法的能力：5GB/TXXXXX—XXXX/ISO/IEC26551:2016——文本需求可变性，用自然语言表达和文档化需求可变性，并使其明确；——需求模型可变性，用建模语言表达和文档化需求可变性，并使其明确；——需求可变性机制，对将被作为需求一部分的可变性机制进行分类；——需求可变性和可变性模型之间的可追溯性，建立并维护文本需求、需求模型和可变性模型之间的链接。在需求工程的资产管理过程中，领域需求工程产生的需求制品被构建为领域资产。需求可变性和通用性都作为领域资产进行管理。此外，具有高重用潜力的应用需求制品被识别为潜在的领域资产。需求工程资产管理为需求资产添加或开发额外的细节和粘接器，以便有效和高效地使用。在这个过程域中，还应分析需求领域资产之间的关系，以便成功地重用或管理其更改。在资产库中配置领域资产和管理领域资产的过程参考ISO/IEC26555的资产管理。需求工程资产管理完成以下工作，并定义支持工具和方法的能力：——领域需求制品，作为识别和开发领域资产的必要信息，以帮助应用工程师在应用开发中重用需求资产；——应用需求制品，作为识别和管理的应用需求资产被后续应用参考。应用需求工程为每一产品线成员识别特定的需求。它开始评估现有的通用和可变需求的可重用性，以充分利用产品线平台。还可向领域需求工程提供反馈，从而决定是否将应用需求资产合并到领域资产中。应用需求工程完成以下工作，并定义支持工具和方法的能力。——应用需求获取，识别领域特征与应用特定特征之间的差距，重用资产库领域需求，并获取应用特定需求。——应用需求分析，对应用特定需求进行抽象、组织和建模。这个子过程应确保应用的利益相关方的所有需求都被理解，并且应仔细检查应用需求的正确性、完整性和一致性。——应用需求规格说明，将已分析的应用特定需求与领域需求规格的绑定部分一起文档化。——应用需求验证和确认，确认特定产品需求的一致性和可行性，并确保绑定的变体与特定产品需求相关。——应用需求管理，为成员产品需求的后续变更提供管理服务。注1：产品线需求工程过程与ISO/IEC12207和ISO/IEC/IEEE15288兼容，见附录BISO/IEC12207、对产品线需求工程方面的识别和分析使组织能够理解需求工程过程，并为成功地实施过程制定策略。产品线的需求工程过程应根据这些方面来定义，支持这些过程的工具和方法的能力应根据这些方面来确定。注2：附录C描述了子过程、关键方面以及相关工具表1给出了产品线需求工程的各个特性的关键方面。表1识别产品线特定需求工程任务的关键方面——应用工程：重用领域需求，绑定特定应用的外部可变性。以此规定应用需求；——资产：领域需求工程通过资产库向应用工程提供需求的通用部分（领域需求）。因此，需求工程和管理的领域资产是一个突出的方面；——绑定：需求工程绑定应考虑反映外部的可变性。因此，绑定是产品线开发的一个独特方面；6GB/TXXXXX—XXXX/ISO/IEC26551:2016——协作：由于领域需求工程和应用需求工程可并行执行，因此工程团队之间以及领域资产、可变性管理、产品管理、范围确定等过程之间的协作是必要的。这使协作成为产品线开发环境一个重要方面；——配置：产品线需求工程的产品和制品的配置可是多维的，即存在于时间和空间中，保持这些维度的完整性是一个重要的方面；——领域架构：领域需求工程提供领域需求作为建立参考架构的主要输入；——领域工程：领域需求工程过程不存在于单产品开发中。然而，这一过程对于产品线是必要的；——使能技术支持：实现产品线需求工程所需的技术是产品线实现的关键成功因素；——测量和跟踪：在产品线需求工程中，数据收集、度量和跟踪需要考虑领域工程、应用工程、产品管理和领域资产。这意味着产品线的度量是多维的，因此应考虑所需的活动、角色、过程、工具和方法；——平台：平台实现了在产品之间重用通用元素（例如：制品、组件、连接器等）。产品线需求工程制品是平台的关键要素；——产品管理：需求工程应从可预见的产品线策略中处理产品线的可重用性。由于需求根据风险和机会不断演化，产品管理应监控和支持需求的演化；——可重用性：需求工程过程中资产的可重用性与实现产品线的总体目标密切相关，实现整个产品线的可重用性是需求工程的一个不同的方面；——构造：产品线需求是建立构造的主要输入。特别是对于功能和非功能需求的开发规则和具体细节，应建立相应的架构性构造；——可追溯性：在可变性和来自领域/应用需求工程的制品之间存在各种跟踪链接。应开发一个追溯性方案来处理追溯问题；——验证和确认：在产品线开发环境中，从不同的角度(如领域、应用、可变性、领域资产等)提供对需求进行验证和确认的客观证据是一个重要方面，因此需要提供单产品开发的差异化方案；——可变性：需求工程可变性主要处理与可重用性策略相关的外部可变性，单产品开发不关注可变性。5产品线范围界定产品线组织需要确定哪些产品和特征构成产品线，然后该组织确定哪些特征是通过重用或改编遗留资产实现的，或者哪些是新开发的。通过客观和定量的努力，该组织估计产品线的预期经济效益，并根据经济效益做出产品线启动的决定。产品线范围界定过程包括三个关键子过程：——产品范围界定，根据市场输入，确定潜在的成员产品和原始的通用和可变的特征；——领域范围界定，将领域分解为子域（或功能域），并将产品范围界定中确定的原始特征映射到子域；——资产范围界定，确定可重用资产，计算成本/收益估计，以证明产品线启动的合理性，并提供产品线的路线图。上述三种类型的范围界定可迭代。5.1产品范围界定5.1.1目的产品范围界定的目的是确定产品组合定义：7GB/TXXXXX—XXXX/ISO/IEC26551:2016a)产品线组织开发、生产、营销、销售的产品；b)产品提供的通用特征和可变特征，即满足用户需求，并实现产品线组织的长期和短期业务目标；c)产品推向市场的时间表。5.1.1.1输入该子过程的输入如下所述。——产品定义战略：两种主要类型是客户驱动和生产者驱动的战略。在客户驱动的战略中，产品线的成员产品是根据市场输入，特别是根据客户的需求和短缺来按需定义的，在生产者驱动的战略中，产品线组织定义了产品。——市场信息：针对产品范围界定阶段，来自以下几点:.细分市场、其特征和预期的未来演化；.客户需求及预期演化；.技术及预期演化；.现有和潜在的竞争对手；.竞争产品及预期演变。——其他内部信息：为发展和保持对整个产品线组织的理解和控制所必需的信息。5.1.1.2输出该子过程的输出如下所述。——产品组合定义，即确立（原始）产品路线图，包括产品、其外部可见的通用和可变特征集以及市场引入时间表。——定义高级产品计划。5.1.1.3任务该子过程的任务如下所述。——结构化范围界定信息。结构化市场信息、产品线的候选成员产品信息以及业务目标以便于为处理进一步范围界定活动提供参考。——识别产品。进行潜在成员产品（包括现有成员产品和新成员产品）的识别以满足市场需求和业务目标。识别和分析现有的产品、原型和其他可重用的资产。关于产品的信息可从内部（例如领域专家）和外部（例如组件供应商的外部专家）资源收集。——分析通用和可变特征。通过分析产品线内部或外部的特征，可对一组系统进行初步分析。——定义产品组合。确定构成产品线的成员产品和特征。产品组合的决策宜与组织的产品定义战略（如客户驱动或生产者驱动的战略）相一致。5.1.2结构化范围界定信息将用于范围界定的信息提取和结构化，以便范围界定参与者做出正确的决定。方法宜支持用于范围界定的结构化信息，具有以下能力：——选择用于范围界定的信息；——提供用于将必要信息结构化的模板；——厘清所选信息集之间的关系及依据；——根据提供的模板重新组织信息。工具宜通过允许用户执行以下操作来支持结构化范围界定信息：8GB/TXXXXX—XXXX/ISO/IEC26551:2016——访问用于范围界定的信息（或提供访问接口）；——允许使用模板进行文档编制；——支持结构化信息的维护；——允许结构化信息的重用。5.1.3识别产品该任务的目标是找到产品线的成员产品、发布计划及高级别特征。方法宜支持识别成员产品，具备以下能力：——识别现有的或未来可能在产品线中生产的成员产品；——生成潜在的成员产品列表；——分析所生成的潜在成员产品列表（使用目标、市场定义等）；——选择并定义原始成员产品列表；——验证所定义的原始成员产品列表。工具宜通过以下方式支持成员产品的识别：——支持团队协作；——支持成员产品识别过程的文件编制。允许用户执行以下操作：——收集产品线中现有和未来可能生产的产品信息；——聚类收集的候选产品信息；——管理聚类的候选产品信息；——可视化、建模并组织有关现有、未来和假设产品的信息，作为产品线候选产品。5.1.4分析通用特征和可变特征该任务中分析的通用和可变特征进行了抽象。这些通用的和可变的特征，包括产品质量，用于确认产品线是否满足组织的期望，通过重用降低成本。方法宜支持分析通用和可变特征，具有以下能力：——分析描述产品线中表征产品的特征（高级）；——分析产品质量（可在领域需求工程中完善为质量属性）；——区分通用特征和可变特征；——建模特征（使用适当的特征建模符号）；——评估通用和可变特征，以确保确定产品的主要特征被识别（通过研讨班、头脑风暴和分类等——提供文档模板，用于文档化通用和可变特征。工具宜支持分析通用和可变特征，允许用户执行以下操作：——可视化通用/可变特征和产品质量；——允许使用模板进行文档编制；——允许在进一步范围界定和需求工程活动中引用分析结果；——支持文档化与决策形成相关的全部理由，并使其在进一步的范围界定和需求工程活动中被引5.1.5定义产品组合方法宜支持定义产品组合，具有以下能力：——结构化有关市场信息、原始产品清单及高级别特征的问题；——使用决策过程（例如头脑风暴法、名义团体法、德尔菲法）做出决策；9GB/TXXXXX—XXXX/ISO/IEC26551:2016——验证该决策；——提供检查单以验证决策。工具宜支持通过以下方式定义产品组合：——提供协助决策的模板；——文档化已定义的产品组合。5.2领域范围界定5.2.1目的领域范围界定的目的是分解功能域并将原始功能映射到功能域，以降低复杂性并提高产品线的可重用性。5.2.1.1输入该子过程的输入如下所述：——产品组合定义；——从领域专家和现有产品经验中收集的信息。5.2.1.2输出该子过程的输出如下所述：——建立领域范围定义[包括功能（子功能）域及通用和可变特征]；——定义一组高级别特征；——产品组合的定义得到完善。5.2.1.3任务该子过程的任务如下所述。——确定功能域。查找、分析和分类功能，以最大限度地提高可重用性。功能域可通过将特征分组并分级派生出来（即包括子领域）。——将特征映射到功能域。将识别的特征分解到功能域。——定义领域范围。评估并选择最适合重用的功能域。5.2.2识别功能域功能域由对产品线产品具有足够经验和知识的专家确定和分类，验证功能域和特征的技术可行性，并进一步完善特征。方法宜支持识别功能域，具有以下能力：——分析产品线各领域的功能（定义领域边界方法示例：包含或排除的规则、结构图、上下文关系图等）；——对共同使用的功能进行分类；——文档化和结构化已确定的功能域；——验证分类后的功能域。工具宜支持识别功能域，具有以下能力：——支持团队协作；——显示分析和分类的结果。允许用户执行以下操作：GB/TXXXXX—XXXX/ISO/IEC26551:2016——可持续地管理分析和分类的功能域；——文档化功能域；——管理功能域和有关分析之间的关系。5.2.3将特征映射到功能域建立识别出的功能域、产品和特征的映射表，以表示它们之间的关系。方法宜支持将功能域映射到特征，具有以下能力：——分析功能域和特征之间的关系；——将特征映射到功能域；——完善功能域和特征；——验证映射结果。工具宜支持将功能域映射到特征，具有以下能力：——显示功能域和特征（例如由功能域列和特征行组成的excel工作表）；——允许对定义功能域的基本原理进行文档化。允许用户执行以下操作：——创建功能域和特征之间的关系；——管理功能域和特征之间的关系。5.2.4定义领域范围定义领域范围是为了说明功能域、产品和特征之间的关系。方法宜支持定义领域范围，具有以下能力：——根据可变性和性能维度评估功能域；——使用适当的决策过程选择功能域（例如头脑风暴，名义组技术（NominalGroupTechnique，NGT），德尔菲）；——管理与功能域选择有关的问题；——验证定义的领域范围。工具宜支持定义领域范围，具有以下能力：——显示领域范围定义；——提供用于评审、评论和通信的协作环境。允许用户执行以下操作：——评估、验证和文档化领域范围定义；——提出并解决与领域范围有关的问题。5.3资产范围界定5.3.1目的资产范围界定的目的是识别潜在的可重用资产，并估计重用建议资产的经济效益。资产的评估是基于工程设计所需的工作量，使用从现有相关产品和领域专家收集的历史数据中得出的工作量估计函数进行量化。5.3.1.1输入该子过程的输入如下所述：——领域范围定义（包括功能域及通用和可变特征）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——估计模型和当前实践的其他信息；——可用的测量数据（即相关领域的历史数据）。5.3.1.2输出该子过程的输出如下所述：——提出资产建议（包括功能、特征和工作量估计）；——建立了量化的领域定义；——生成投资回报率（ReturnOnInves，ROI）估计；——提供现有资产清单。5.3.1.3任务该子过程的任务如下所述。——从现有的单产品中收集历史数据。识别和收集有关现有产品的信息，以更好地理解该领域并识别潜在的可重用资产。——估计修改潜在资产所需的额外工作。估计使潜在资产适合产品线所需的额外工作。——在产品组合定义中估计新产品的预期开发成果。评估将新产品纳入产品组合的成本、工作量和风险。该计算基于对现有相关产品、开发限制、系统/软件属性和市场属性的学习。——估计重用建议资产的经济效益。评估重用现有资产、重用新开发的领域资产以及减少由于质量改进而导致的返工和故障所带来的经济效益。——根据经济评估结果得出资产方案。定义资产建议，包括资产（功能域和特征）及经济评估结果。通过扩展域定义建立资产建议。为领域所有资产创建详细和量化的工作量估计。5.3.2从现有单产品收集历史数据工作量估算可根据历史数据进行，如现有相关产品在特定时间段内累积的测量数据。方法宜支持从现有单产品中收集历史数据，具有以下能力：——定义宜收集何种历史数据；——整合各种来源的数据；——搜索数据；——验证所收集数据的有效性。工具宜支持从现有单产品收集历史数据，允许用户执行以下操作：——允许文档化从现有单产品收集历史数据的结果；——从其他工具导入源；——提供对历史数据的管理能力。5.3.3估计修改潜在资产所需的额外工作虽然有些资产可按原样重用，但有些资产需在修改后重用。因此，领域资产开发之前应估计修改工作量，因为如果修改工作量太高，就难以预期从领域资产重用中获益。方法宜支持估计修改潜在资产所需的额外工作，具有以下能力：——分析现有产品和新产品之间的关系；——分析新产品预期开发工作的因素；——定义新产品的工作量估计函数；——提供可用于工作估计的度量；——允许在必要时添加新的度量。GB/TXXXXX—XXXX/ISO/IEC26551:2016工具宜支持估计修改潜在资产所需的预期额外工作，具有以下能力：——展示资产、功能域、特征、产品之间的关系及对经济效益的影响；——提供用于估计的度量，以便工具用户可在其中进行选择；——允许在必要时添加新的度量。5.3.4在产品组合定义中估计新产品的预期开发工作量产品组合定义中包含的一些产品是新产品，因此应根据从现有相关产品收集的测量数据来估计工作量。在估计产品线的整体效益时，宜单独考虑这种估计。方法宜支持估计产品组合定义中、新产品的预期开发工作量，具有以下能力：——分析现有产品和新产品之间的关系；——分析新产品预期开发工作的因素；——定义新产品的工作量估计函数。工具宜支持在产品组合定义中估计新产品的预期开发工作量，具有以下功能：——提供工具用户可选择的工作量估计的度量；——如果需要，允许添加新的度量；——显示资产、功能域、特征、产品之间的关系及对经济效益的影响程度。允许用户执行操作：文档化新产品预期经济效益的估计结果。5.3.5估算建议资产再利用的经济效益根据历史数据及经验开发，计算建议资产预期成本及收益的工作量估计函数。方法宜支持估计重新使用建议资产的经济效益，具有以下能力：——收集历史数据；——分析历史数据；——从历史信息中估计预期收益。工具宜支持估算重用建议资产的收益，具有下列能力：——文档化估算建议资产重用效益的过程；——从各种来源导入历史数据；——显示领域、子领域、产品和收益之间的关系。5.3.6根据经济评价结果得出资产方案该任务的目标是集成以前估计的结果，用于得出资产方案，包括由于产品线而造成的成本和收益。方法宜支持从经济数据中得出资产建议，具有以下能力：——集成工作量估计；——使用决策过程（例如头脑风暴、名义组技术（NGT）、德尔菲）对资产方案做出决策；——验证决策。工具宜支持从经济数据中得出资产方案，具有以下能力：——文档化资产方案；——在图形用户界面中显示资产方案；——使用输入数据和预定义的成本效益函数提供自动计算；——突出显示开发作为领域资产所必需的资产列表；——允许使用资产方案来追溯估计和实际成本/效益结果之间的差距。6领域需求工程GB/TXXXXX—XXXX/ISO/IEC26551:2016在领域需求工程中，识别和记录功能性和非功能性需求以及这些需求外部可变性。领域需求工程应遵循产品线范围界定阶段产生的资产方案中定义的特征。这些特征是领域需求的关键来源。其他领域和应用工程过程将参考已定义的领域需求。领域需求工程有五个基本的子过程。——领域需求获取。该子过程的目的是将产品线范围界定阶段定义的特征分解为原始需求，并从利益相关方和领域专家那里获取附加需求和派生需求。同时，该子过程还从领域利益相关方那里明确地捕获产品线成员的预期变化。——领域需求分析。该子过程的目的是基于所获取的领域需求，找到共性并识别可变性，以实现产品线的预定重用目标。应更深入地分析领域需求，以找出更多的共通需求并减少独特需求，从而提高经济可行性和效益。产品线范围是确定产品线边界的主要输入。——领域需求规格说明。该子过程的目的是文档化领域需求，这些需求规范包括共性需求和可变需求。领域需求规格的可变性受产品线中特定成员产品的约束。——领域需求验证和确认。该子过程的目的是验证和确认产品线需求是正确的、完整的、一致的，并且适用于每个产品，而产品特定的需求应在应用需求验证和确认子过程中进行验证和确认。——领域需求管理。该服务的目的是管理领域需求的可追溯性和变更。由于产品线具有双重性质，并且领域资产在多个应用中通用，可追溯性和变更管理的复杂性较高，因此应制定有效对策以应对这些复杂性。6.1领域需求获取6.1.1目的领域需求获取的目的是在产品线范围界定结果的基础上，分解、发现、评审和理解利益相关方需求以及与产品线平台相关的约束。6.1.1.1输入该子过程的输入如下所述：——领域利益相关方的信息；——产品线范围内的资产方案；——产品线范围内的高级特征集合；——现有资产清单。6.1.1.2输出该子过程的输出如下所述：——维护领域信息（每个应用的目标、问题定义、当前和潜在用户、需求、利益相关方等——建立领域信息源链接；——定义上下文关系图；——产生细化的共性和可变特征集；——产生分类的领域需求（原始的共性需求和可变需求集）。6.1.1.3任务该子过程的任务如下所述。——绘制上下文关系图。产品线的上下文关系图获取高级别实体和实体关系（例如产品线用户、物理环境或与产品线相关的其他系统）。GB/TXXXXX—XXXX/ISO/IEC26551:2016——收集领域信息。通过举办研讨会、检查当前系统以及访谈领域和应用工程师，获取领域信息。——确定原始领域需求。领域需求工程师评审收集的领域信息，并从用户的角度确定原始的领域需求。更详细地修订产品线范围内产生的高级特性集合（包括共性需求和可变需求）。对可变性进行细化，并将其链接到其他过程开发的相关模型中。——评审获取的原始领域需求。检查获取的原始领域需求，看它们是否违反了产品线的范围和利益相关方的需求。必要时进行修订（包括与资产方案进行比较）。确定领域需求获取的代表和利益相关方（例如潜在的客户和其他利益相关方，比如领域专家和应用工程师）。利益相关方包括对客户、竞争对手、市场趋势和产品线成员产品有了解的人。注：获取需求的技术示例：目标问题度量（GoalQuestionMetric，GQM）、质量功能展开（QualityFunctionDeployment，QFD）、卡诺6.1.2绘制上下文关系图上下文关系图描述了领域环境与产品线成员之间的关系，同时也描述了产品线成员之间的关系。该任务旨在提取产品线内的对象及其相互作用。方法宜支持绘制上下文关系图，具有以下能力：——识别每个产品线成员现有的上下文关系图；——分析领域环境（领域用户、利益相关方、外部系统等）；——分析业务环境；——分析产品系列与已识别的领域实体之间的关系；——绘制领域上下文关系图。工具宜支持绘制上下文关系图，具有以下能力：——提供文档模板，用于记录产品线成员与已识别的领域实体之间的关系；——提供检查单，用于识别领域实体；——绘制领域上下文关系图。6.1.3收集领域信息领域信息是通过分析各种来源收集的，例如：产品线内的应用目前满足的需求；利益相关方在当前应用中面临的问题，以及应用尚待处理的更改请求。方法宜支持收集领域信息，具有以下能力：——确定领域信息源（例如产品组合、高级别生产计划、领域定义、范围界定资产提案、使用无上下文问题的访谈和调查，以及需求获取研讨会和会议）；——确定产品线利益相关方；——收集领域信息（产品线目标、利益相关方、现有产品线成员的目标和需求、新应用解决的问题和目标等）；——验证收集的领域信息。工具宜支持收集领域信息，具有以下能力：——将领域信息导入所述领域需求获取工作空间；——提供模板，用于文档化收集到的领域信息；——提供存储库（或注册表），用于保存领域信息；——维护领域信息及其来源之间的跟踪链接。6.1.4识别原始领域需求该任务的目标是从产品线利益相关方处获取原始需求。GB/TXXXXX—XXXX/ISO/IEC26551:2016方法宜支持识别原始领域需求，具有以下能力：——评审收集的领域信息；——将高级特征细化为较低级特征；——确定与特征相关的需求；——收集产品线内新应用的其他需求；——描述领域需求（例如：运行场景、目标模型、用例图、特征方式）；——从“利益相关方”的角度开发领域使用场景。工具宜支持识别原始领域需求，具有以下能力：——提供关于领域信息的浏览、评审和评论环境；——提供模板，用于记录提取出的领域需求；——从利益相关方的角度对提取的需求进行建模。同时，工具允许用户执行以下操作：——描述领域需求；——描述领域使用场景。6.1.5评审获取的原始领域需求评审获取的原始领域需求，以确保其完整性和正确性。方法宜支持评审获取的原始领域需求，具有以下能力：——在获取的需求和来源之间建立可追溯性；——验证获取结果的完整性和正确性；——评审产品线内应用之间的冲突；——解决领域需求问题（记录未解决的冲突，以便在需求分析阶段进行分析和解决——文档化获取并分类的需求。工具宜支持评审获取的原始领域需求，具有以下能力：——保持获取需求与其来源之间的可追溯性；——提供文档化获取的领域需求的模板；——维护验证的检查单。6.2领域需求分析6.2.1目的该子过程的目的是定义功能需求、非功能需求和需求风险，并分析其可行性。在需求分析的同时，对可变性模型进行完善，与之前的模型保持一致，需求过程可变性和领域需求分析同时实施，从而对可变性模型进行一体化管理。6.2.1.1输入该子过程的输入如下所述。——获取的领域需求。——高级领域需求模型（例如用例模型、特征方式、上下文关系图）。——共同和可变特征的原始集合。——共同和可变需求的原始集合。6.2.1.2输出GB/TXXXXX—XXXX/ISO/IEC26551:2016该子过程的输出如下所述。——建立功能性和非功能性领域需求（包括约束、依赖关系和优先级）。——改进并建立领域需求模型（通过细化在需求获取阶段产生的用例模型、特性模型和上下文关系图，来建立共性模型）。——确定与可变性相关的信息。定义领域需求层面的可变性（包括可变性、依赖性、约束）。——进行技术/经济可行性分析，并产生分析结果。——定义评审检查单。——为领域需求制定概念性的测试用例和场景。6.2.1.3任务该子过程的任务如下所述。——分类和平衡原始领域需求。原始领域需求被分为功能、质量属性、约束和其他非功能需求。通过将高级别需求分解为低级别需求、将细化的需求聚合为更高级别的需求，来平衡原始领域需求的颗粒度。——分析共性和可变性。对产品族的共性需求进行分析，分析各应用之间存在系统性差异（可变性）的需求。可变性分析包括识别变化点、变体和依赖性。——建模领域需求。以高度抽象的方式可视化领域需求及其相互依赖关系，以发现不正确、不一致、缺失和多余的需求。领域需求模型应处理可追溯到领域可变性模型的共性和可变性。——创建原型并分析可行性。原型用于从多个角度（例如可接受的成本和性能）评估实现某些关键需求的可行性，同时理解和确定与需求相关的风险和优先级。——开发验收测试中概念性的测试用例和场景。根据验收测试需求，推导出概念性的测试用例和场景。这些测试用例和场景通常适用于产品系列的所有成员。这些场景和用例可来源于需求模型，比如用例图。——评审领域需求。评审领域需求以识别和纠正不完整和不正确之处。6.2.2对原始领域需求进行分类和平衡该任务用于对原始领域需求进行分类和平衡。将目标、业务规则、功能需求、质量属性、约束等按其共性和可变性特征进行分类，并将颗粒度、不正确和有矛盾之处协调一致，以便进一步分析。方法宜支持对原始领域需求进行分类和平衡，具有以下能力：——为平衡原始需求的抽象层次定义指导方针；——将高级别原始领域需求分解为较低级别的原始领域需求；——将低级别原始领域需求聚合为较高级别的领域需求；——识别原始领域需求之间的不一致。工具宜支持对原始领域需求进行分类和平衡，具有以下能力：——能够将获取的原始领域需求和相关信息导入到领域分析工作空间中；——提供编辑环境，以支持对原始领域需求的分解或聚合；——能够区分共性的和可变性的原始需求；——提供文档模板，用于描述分类的原始领域需求。6.2.3分析共性和可变性在该任务中，分析共性和可变性需求，定义可变性、变体、绑定时间、依赖性和约束。方法宜支持分析共性和可变性，具有以下能力：——分析原始的共性和可变性需求（例如通过将需求映射到特征、通过使用产品线的建模概念GB/TXXXXX—XXXX/ISO/IEC26551:2016——对需求进行详细分析，以确定所有应用的共性和可变性需求（例如通过将领域需求与成员产品的需求进行映射，以及通过应用组织规则来确定共性和可变性）；——确定共性和可变性需求；——分析可变性需求的属性特征（例如绑定时间、变化点及其变体和类型）；——为共性和可变性的需求决策提供依据和假设（如有必要）；——验证共性和可变性（包括可变性之间的一致性）。工具宜支持分析共性和可变性，具有以下能力：——提供分析工作空间，以确定共性和可变性；——提供文档模板，用于描述需求级别共性和可变性；——将相关信息导入领域分析工作空间；——显示已定义的相关共性和可变性信息。6.2.4建模领域需求需求建模确保所识别领域需求的完整性和可行性。方法宜支持领域需求建模，具有以下能力：——建模需求（通过使用文本、自然语言或可视化建模）；——分析需求模型，确保其完整性、正确性、可行性和可验证性；——细化功能需求（比如从场景、用例中细化）；——细化非功能需求。工具宜支持领域需求建模，具有以下能力：——支持领域需求建模或提供与建模工具交互的接口；——允许跟踪领域需求；——提供文档模板，用于文档化领域需求模型。6.2.5创建原型并分析可行性针对那些模糊不清或存在技术困难的需求建立原型，基于原型进行可行性分析。方法宜支持创建原型和分析可行性，具有以下能力：——对领域需求进行优先级排序；——选择需要创建原型的需求；——决定收集哪些信息；——进行原型设计；——从设计和使用原型的利益相关方那里收集反馈和其他必要信息；——使用原型设计结果分析可行性。工具宜支持创建原型和分析可行性，具有以下能力：——生成和存储用户定义的或工具提供的、用于多样性分析的检查表或模板（多样性分析如：技术、经济和业务分析）；——存储和管理可行性分析的理由；——与外部工具交换有关原型设计的信息。6.2.6开发验收测试的概念性测试用例和场景该任务将开发验收测试中使用的测试用例和场景。对于无法开发测试用例的需求，在该任务之前进一步澄清。方法宜支持为验收测试开发概念性测试用例和场景，具有以下能力：GB/TXXXXX—XXXX/ISO/IEC26551:2016——基于领域需求（领域需求模型或规范）开发验收测试中使用的概念性测试用例和场景（概念性测试用例和场景应处理可变需求）；——在应用需求工程中生成可重用的概念性测试用例和场景；——为每个测试用例和场景分配唯一标识符。工具宜支持开发验收测试的概念性测试用例和场景，具有以下能力：——支持从领域需求中自动/半自动地派生；——允许概念性测试用例和场景中存在可变性，以便后续在每个成员产品中进行绑定；——提供文档模板，用于记录派生测试用例和场景；——允许用户查找和访问相关信息（例如功能性和非功能性需求、可变性模型——从领域需求半自动/自动生成测试用例。6.2.7评审领域需求该任务确保领域需求清晰明确，包括所有利益相关方的需求，且评审共性和可变性，以确保共性需求的正确性、经济和技术可行性以及完整性。方法宜支持评审领域需求，具有以下能力：——识别不明确或无法验证的需求；——与利益相关方一起分析这些需求，并提出修改建议；——分析修改建议对领域需求的影响；——必要时修订需求。工具宜支持评审领域需求，具有下列能力：——导入领域需求分析结果；——提供通过网络评审和评价领域需求的环境。6.3领域需求规格说明6.3.1目的领域需求规格说明以一种一致的、可访问的和可评审的方式，清晰而精确地记录功能性和非功能性需求和约束。规格说明宜与相关的可变性模型建立跟踪链接，以管理需求、可变性及其变更。6.3.1.1输入该子过程的输入如下所述：——功能性和非功能性领域需求（包括约束、依赖关系和优先级）；——领域需求模型；——可变性模型（来自需求可变性）；——领域需求的概念性测试用例和场景；——技术或经济可行性分析结果；——软件需求规格说明（SoftwareRequirementsSpecification，SRS）模板。6.3.1.2输出该子过程的输出：建立领域需求的SRS。领域需求规格说明（即产品线的SRS）应区分产品线中所有成员产品和应用特定部分的常用需求。建立从需求到来源的跟踪链接。6.3.1.3任务GB/TXXXXX—XXXX/ISO/IEC26551:2016该子过程的任务如下所述。——识别领域需求的来源，以确保所有利益相关方都知道SRS中每个需求的方式和原因，以便于进一步的澄清需求，并追溯每个需求的起源。——通过详实的跟踪链接在需求源到领域需求之间建立可追溯性。领域需求之间、领域需求和其他领域制品（例如领域范围界定）之间需要建立跟踪链接。在需求过程可变性中建立管理可变性的跟踪链接。——文档化领域需求。使用SRS模板记录领域需求。——评审领域需求规格说明。评审领域需求规格说明，以确保文档的完整性和正确性。6.3.2识别领域需求的来源识别领域需求的来源，以建立跟踪链接，并对需求进行管理。方法宜支持识别领域需求的来源，具有以下能力：——分析领域需求的属性；——确定所有领域需求的来源；——分析领域需求和其他领域制品之间的关系。工具宜支持识别领域需求的来源，具有以下能力：——查找和引用在其他过程中生成的信息（从产品线范围界定到领域需求分析——提供具有预定义属性的模板，用于系统地记录领域需求的相关信息；——文档化和维护所识别的领域需求源信息。注：需求属性示例：——决定共性或可变性；——决定的理由；——与每种可变性有关的产品；——从产品线范围界定中得出的相关特征。6.3.3建立可追溯性为产品线建立跟踪链接通常比为单个应用建立跟踪链接更复杂，因为与单个应用开发环境相比，在产品线环境中有更多的信息源（例如：利益相关方、现有产品、市场）、更多的领域制品、更多的相互依赖性和更多制品的有效配置。因此，工具在产品线环境中扮演着特别重要的角色。方法宜支持建立可追溯性，具有以下能力：——建立从领域需求到需求源的正向和反向跟踪链接，反之亦然；——建立需求制品（包括范围界定制品）之间跟踪链接；——建立跟踪列表。工具宜支持建立可追溯性，具有以下能力：——展示领域需求和其来源之间的后向和前向跟踪链接；——明确定义跟踪链接的类型，以确定两个制品之间的依赖关系是否为强制性的（即产品中选择需求X，则应选择需求Y）、可选的（即产品中选择需求X，可以选择需求Y，但不是必需的或是互斥的（即产品中选择需求X，则无法选择需求Y）；——以图形方式展示需求制品之间的跟踪链接以及相关的共性和可变性信息；——提供具有预定义可追溯性属性的模板，用于文档化可追溯性信息。6.3.4文档化领域需求该任务制定一个结构良好的领域需求规格说明，其中包含所有必要的信息。GB/TXXXXX—XXXX/ISO/IEC26551:2016方法宜支持文档化领域需求，具有以下能力：——通过区分共性需求和可变性需求，为每个需求提供唯一标识符；——定义可重复使用的SRS模板，用于文档化每个产品；——对领域需求进行优先级排序；——将领域级业务规则（包括公司政策、政府法规和计算算法）与SRS分开记录。工具宜支持文档化共性和可变性需求，具有以下能力：——提供文件模板（包括区分共性需求和可变性需求）；——从建模工具导入需求模型用于文档化；——通过拼写检查、数据字典、缩略语表等方式检查文件质量和一致性；——将SRS和相关领域需求存储在（集中式的）存储库中。6.3.5评审领域需求规格说明该任务确定领域需求规格说明的完整性、正确性、明确性和可追溯性。方法宜支持评审领域需求规格说明，具有以下能力：——确保领域需求规格说明包括所有必要的内容；——确认领域需求规格说明可以容易地被重用，以推导出应用需求规格说明；——分析和修订领域需求规格说明。工具宜支持评审领域需求规格说明，具有以下能力：——导入和浏览领域需求规格说明；——为评审、讨论和评论需求规格说明提供环境。6.4领域需求验证和确认6.4.1目的该子过程的目的是确保产品线需求完整、正确、一致且清晰。领域需求确认宜与可变性模型确认一同进行，以保持需求和可变性之间的一致性。6.4.1.1输入该子过程的输入如下所述：——领域需求规格说明；——概念性测试用例和场景；——评审检查单。6.4.1.2输出该子过程的输出如下所述。——验收测试的概念性测试用例和场景。这些验收标准通常用于推导特定产品的验收标准。——基线化的领域需求。评审、检查和确认从需求获取、分析、规格说明、可追溯性、测试和需求模型中产生的文档，确定领域需求的基线。6.4.1.3任务该子过程的任务如下所述。GB/TXXXXX—XXXX/ISO/IEC26551:2016——验证领域需求。识别出模糊或不可验证的领域需求，并检查领域需求模型（如SRS、用例、测试用例和原型在领域需求获取、分析和说明子过程中产生的其他文档。使用在领域需求分析过程中产生的概念性测试用例来验证领域需求。——确认领域需求。确认领域需求（包括功能和非功能领域需求）是否完整且正确。——确认概念性测试用例和场景。确认概念性测试用例和场景用于基于需求的系统测试或验收测试是否合适。——基线化领域需求。该任务建立了所有成员产品共同认可的和批准的一套共性需求。当该项任务完成后，领域需求管理中所有需求都将受到严格的变更和配置控制。——启动变更管理过程。在该任务中，启动适当的变更管理过程和配置管理系统，以便在确定需求基线后对领域需求的变更进行妥善管理。6.4.2验证领域需求该任务确保领域需求清晰、易于理解且可测试。方法宜支持验证领域需求，具有以下能力：——验证指定的单领域需求制品；——识别模糊或无法验证的需求；——提供验证检查单；——验证共性和可变性需求的优化。工具宜支持验证领域需求，具有以下能力：——指导验证过程；——展示指定的领域需求和相关信息；——支持多用户同时编辑同一文档；——提供团队评审、标记和评论领域需求的环境；——提供记录验证结果的文档模板（包括评审结论的理由以及采取的纠正措施——通知利益相关方验证状态。6.4.3确认领域需求该任务确保领域需求的完整性和正确性。方法宜支持确认领域需求，具有以下能力：——确认是否存在缺失或相互矛盾的领域需求；——提供确认检查单；——检查领域需求的完整性和正确性；——确认所定义的可变性，包括其变体和依赖关系。工具宜支持确认领域需求，具有以下能力：——指导确认过程；——展示指定的领域需求和相关信息；——支持多用户同时编辑同一文档；——提供团队评审、标记和评论领域需求的环境；——提供记录确认结果的文档模板（包括评审结论的理由和采取的纠正措施——通知利益相关方确认状态。6.4.4确认验收测试的概念性测试用例和场景GB/TXXXXX—XXXX/ISO/IEC26551:2016对产品线中所有应用常用的概念性测试用例和场景进行确认，以确保其足以确认成员产品的完整性和正确性。在应用需求工程中，会基于领域验收标准来定义应用特定的测试用例和场景。方法宜支持确认验收测试的概念性测试用例和场景，具有以下能力：——定义概念性测试用例和场景的验证标准；——确认概念性测试用例和场景可变性是否结构良好；——确认是否能从概念性测试用例和场景中推导出用于验收测试的应用特定测试用例和场景。工具宜支持确认验收测试的概念性测试用例和场景，具有以下能力：——浏览和访问领域需求资产，以确认概念性测试用例和场景；——访问领域需求资产、可变性模型和已定义的概念性测试用例和场景之间的跟踪关系；——允许半自动/全自动化地生成确认报告。6.4.5建立领域需求基线在该任务中创建并发布领域需求基线，通过变更管理对基线的更改进行控制和管理。方法宜支持建立领域需求基线，具有以下能力：——为领域需求建立正式协议；——为已批准的领域需求建立基线；——管理基线领域需求的配置。工具宜支持建立领域需求基线，具有以下能力：——提供变更与配置管理系统交互的接口；——将基线化的领域需求导出到变更和配置管理系统的存储库中。6.4.6实施变更管理在实施需求管理中定义的变更管理之前，实施本变更管理。方法宜支持实施变更管理，具有以下能力：——建立变更管理环境（例如变更管理流程和支持性变更管理信息系统）；——建立一个变更管理信息系统和支持性的配置管理系统。建立一个变更管理信息系统和支持性的配置管理系统以支持实施变更管理，具有以下能力：——建立领域需求基线后，原始化领域需求库，以存储基线化的领域需求；——建立与变更管理信息系统和配置管理系统交互的接口。6.5领域需求管理6.5.1目的领域需求管理的目的是在产品线和产品线成员开发过程中，对领域需求工程过程（获取、分析、记录和确认）进行计划、协调和文档化，并有效地处理利益相关方的变更请求。6.5.1.1输入该子过程的输入：领域需求的变更请求（来自领域工程或应用工程）。6.5.1.2输出该子过程的输出如下所述：——建立领域需求文档的新基线和版本；——文档化的影响分析结果（包括对领域需求和应用需求的影响）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——维护每个领域需求的变更历史。——更新后的领域需求跟踪链接；——建立状态统计和报告；——领域需求工程过程资产；——记录可变性模型的变更请求（在需求可变性的可变性演化子过程中处理）。6.5.1.3任务该子过程的任务如下所述。——管理领域需求变更。跟踪对领域需求的变更，并将批准的更改传达给所有受影响的利益相关方。——管理可追溯性。可追溯性管理使利益相关方能从正向和反向两个方向追踪需求从起源到实现的整个生存周期。——管理领域需求的版本。管理在领域需求工程中产生的制品或制品的版本。——记录并报告状态（状态统计）。记录并报告受控的领域需求基线状态和历史管理记录。状态报告应包括领域需求的变更数量以及在领域需求工程中产生的最新制品版本。——管理过程改进。评估和评审领域需求工程及其信息系统，以了解所实施过程的优点和缺点。基于评估实施改进。——管理反馈。管理和解决来自其他领域和应用工程过程的反馈。在需求可变性过程中，对产品线中成员产品之间的可变性需求进行变更，以反映可变性的变化。6.5.2管理领域需求变更产品线变更管理是复杂的，因为领域需求的变更请求来自应用工程和领域工程。由于领域需求与产品线多个应用相关，因此相比单产品环境，在产品线环境中对所请求的变更进行影响分析更困难。因此，配套的工具和方法至关重要。方法宜支持管理需求变更，具有以下能力：——获取领域需求的变更请求；——分析对其他领域需求相关变更的影响；——分析对其他应用相关变更的影响；——批准变更；——跟踪变更请求的状态直至结束。工具宜支持需求变更管理，具有以下能力：——建立请求变更的渠道；——上传变更请求；——保存有关变更请求来源的信息；——通知利益相关方变更请求的状态；——维护变更历史（例如谁变更了需求，何时以及为何进行变更）。6.5.3管理可追溯性产品线跟踪链接比单产品的跟踪链接复杂，这是因为产品线中存在着领域工程跟踪链接、应用工程跟踪链接以及领域工程与应用工程之间的跟踪链接。该任务涵盖了产品线特定的工具和方法能力，以处理复杂性。方法宜支持管理可追溯性，具有以下能力：——分析变更请求对可追溯性的影响；——修订跟踪链接（例如领域需求和来源之间）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——确认跟踪链接。工具宜支持管理可追溯性，具有以下能力：——维护用于恢复的需求跟踪链接的版本；——更新跟踪链接；——当利益相关方请求时，向特定的利益相关方显示可追溯性信息。6.5.4管理领域需求版本应用工程可以共享多个版本的领域需求制品。应提供工具来应对这些复杂性。方法宜支持管理领域需求版本，具有以下能力：——指定领域需求制品基线的最新版本；——描述领域需求制品基线之间的差异；——管理历史版本以便在故障时进行恢复。工具宜支持领域需求的版本管理，具有以下能力：——自动生成版本号；——提供恢复机制；——提供用于管理历史版本的仓库；——跟踪版本控制下的相关制品（需求、模型等）；——随着时间的推移控制领域需求制品基线的版本。6.5.5记录和报告状态在领域需求管理过程中，持续记录和报告受控制品的状态和修订历史，以便供所有应用参考。方法宜支持状态记录和报告，具有以下能力：——管理需求管理记录和状态报告，以展示受控制品的状态和修订历史；——记录领域需求制品的内容和状态，以便在必要时恢复制品的先前版本；——必要时修改每件制品的状况和历史；——报告领域需求制品的状态。状态报告应包括需求变更数量、领域需求制品的最新版本、发布标识符以及版本的数量与比较。工具宜支持状态信息的记录和报告，具有以下能力：——维护领域需求制品的内容和状态；——根据分配给用户角色的权限和责任来控制用户的访问；——维护领域需求制品的修订历史（管理记录和状态报告）。6.5.6管理过程改进该任务专门处理改进领域需求工程生存周期过程。请注意，产品线技术管理的工具和方法中提到了整体产品线过程改进。方法宜支持管理过程改进，具有以下能力：——收集过程改进请求；——评估所实施的领域需求工程过程的优缺点；——基于过程改进请求和评估结果，提出领域需求工程过程改进建议；——制定行动计划，以实施领域需求工程过程改进；——管理在领域需求工程过程实施中提出的问题。工具宜支持管理过程改进，具有以下能力：——维护领域需求工程过程资产（例如过程描述、过程制品）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——为领域需求工程过程评估提供模板；——为领域需求工程过程改进的行动计划提供模板。6.5.7管理反馈需要从各种来源收集与领域需求相关的反馈，例如其他领域需求工程服务和应用需求工程服务。该任务应能够处理来自所有相关来源的各种反馈，并向提供反馈的来源通报所采取或计划采取的应对措施。方法宜支持从反馈中学习，具有以下能力：——识别反馈来源；——评估反馈的可行性；——处理反馈（如果可对领域需求进行更改，则建立并处理明确的变更请求——返回反馈处理结果。工具宜支持管理反馈，具有以下能力：——建立收集反馈的渠道；——获取和保存反馈以及关于反馈来源的信息；——更新反馈状态；——将反馈处理结果通报给反馈源。7需求工程可变性管理需求可变性管理过程宜与领域需求工程并行实施，因为可变性模型会随着领域和应用需求逐渐澄清和修改。可变性建模始于领域需求获取子过程，并在整个产品线生存周期中不断演化。该过程建立并维护产品线的外部可变性，但部分内部可变性可能会被指定。需求工程可变性管理具有以下子过程：——文本需求可变性旨在使用自然语言表达和文档化需求可变性，使其明确化；——需求模型可变性旨在通过将可变性整合到需求模型中来文档化可变性；——需求可变性机制旨在对需求可变性机制进行分类；——需求可变性与可变性模型之间的可追溯性旨在建立和维护需求可变性文档与单独定义的可变性模型之间的链接。7.1文本需求可变性文本需求可变性管理的目的是使用自然语言表达和文档化需求可变性，并使其明确化。即使使用特定的关键字或短语来表达文本需求，文档化需求可变性仍然为模糊性保留了空间。7.1.1.1输入该子过程的输入：文本需求文档。7.1.1.2输出该子过程的输出：定义明确表达需求可变性的文本需求文档。7.1.1.3任务该子过程的任务如下所述。GB/TXXXXX—XXXX/ISO/IEC26551:2016——使用文本需求定义需求可变性，以说明当需求用自然语言表达时的需求可变性。应明确描述可变点及其变体，包括对其他可变性的影响。——使用文本需求文档化需求可变性，以增加可变性的结构和关系信息。应文档化需求可变性，以提供在应用需求工程中选择或处理变体的方法。7.1.2使用文本需求定义需求可变性该任务的目标是通过特定的关键字来表达可变性。应通过添加额外的注释来明确可变点及其变体。方法宜支持使用文本需求定义需求可变性，具有以下能力：——明确文本需求的可变性；——明确表达可变点及其变体；——描述可变性的影响。工具宜支持使用文本需求定义需求可变性，具有以下能力：——突出显示可变需求，使其便于区分；——提供明确表达需求可变性的符号。7.1.3使用文本需求文档化需求可变性这个任务的目标是以文本形式文档化可变性的结构和关系信息。宜提供在应用需求工程中选择或处理变体的方法。方法宜支持使用文本需求文档化需求可变性，具有以下能力：——为文本需求可变性添加结构信息，以便选择或处理可变性，例如：变体的唯一标识符；——在文本需求可变性之间添加关系信息；——结构化需求可变性，以便处理；——验证需求可变性文档的可读性。工具宜支持使用文本需求文档化需求可变性，具有以下能力：——使能来自单独定义的可变性模型的跟踪链接；——提供唯一地识别每个变体的能力。7.2需求模型可变性需求模型可变性管理的目的是明确文档化需求模型可变性。可变性宜用各种类型的需求模型来表示，包括特征模型、用例模型、状态转换模型、序列模型、数据模型等。7.2.1.1输入该子过程的输入：需求模型。7.2.1.2输出该子过程的输出：定义明确表达需求可变性的需求模型。7.2.1.3任务该子过程的任务如下所述。——使用需求模型定义需求可变性，以明确地表达需求模型需求可变性。在需求模型中描述可变点及其变体和约束。GB/TXXXXX—XXXX/ISO/IEC26551:2016——使用需求模型文档化需求可变性，以详细说明需求模型中需求可变性的相关信息，并提供对需求模型中可变性的清晰理解。7.2.2使用（需求）模型定义需求可变性该任务的目标是通过特定的关键字或短语来表达可变性。通过增加额外的表达来明确可变点及其变体。方法宜支持使用（需求）模型定义需求可变性，具有以下能力：——明确需求模型需求可变性；——明确表达可变点、其变体和变体的约束；——分别表示功能性或非功能性需求的可变性。工具宜支持使用（需求）模型定义需求可变性，具有以下能力：——提供建模符号以明确表达需求可变性；——提供用于区分功能性和非功能性需求可变性的符号。7.2.3使用需求模型文档化需求可变性该任务的目标是在需求模型文档中详细描述需求可变性，以便将需求可变性整合到需求模型文档中。通过使用不同的需求模型，例如特征模型、用例模型、状态转换模型、序列模型、数据模型等，来文档化需求可变性。方法宜支持使用需求模型文档化需求可变性，具有以下能力：——添加对需求模型中需求可变性的详细说明；——建立以不同方式文档化的相同需求可变性之间的关联关系；——添加支持与可变性模型链接的粘接器；——整合以不同需求模型文档化的需求可变性文档；——验证需求可变性文档，以确保文档的无歧义性。工具宜支持使用需求模型文档化需求可变性，具有以下能力：——使能来自单独定义的可变性模型的跟踪链接；——支持整合以不同类型需求模型文档化的需求可变性文档。7.3需求可变性机制该子过程的目的是对适用于所关注领域的可变性机制进行分类，以指导需求中可变性机制的选择，并对分类的可变性机制进行管理。在各种需求模型和文本需求中，通过扩展/包含、原型、标签或标记等可变性机制表达需求子过程可变性，在需求阶段绑定的可变性大多是外部可变性，但也有部分内部可变性可以在需求阶段绑定。该子过程涉及与可变性机制相关的需求工程特定的方法和工具的能力。7.3.1.1输入该子过程的输入如下所述：——定义所关注的领域；——需求中可变性机制的目录；——原始可变性模型；——原始决策表。7.3.1.2输出GB/TXXXXX—XXXX/ISO/IEC26551:2016该子过程的输出如下所述：——对需求中使用的可变性机制进行分类；——在需求中使用可变性机制的指南已形成文档；——验证需求中选定的可变性机制；——进行可变性机制改进；——生成添加了需求特定可变性机制信息的可变性模型；——生成添加了需求特定可变性机制信息的决策表。7.3.1.3任务该子过程任务如下所述：——识别需求可变性机制，即从需求可变性机制目录中对合适的可变性机制进行分类；——指导需求中可变性机制的使用，为在需求中精确使用可变性机制提供文档化的指南；——验证需求中可变性机制的使用情况，旨在监控可变性机制的使用状态，以提高机制选择的准确性；——改进需求可变性机制，旨在改进可变性机制的使用和使用支持，使其能够在需求模型和文本需求中使用。7.3.2识别需求可变性机制这项任务的目标是评审和发现适用于需求和需求制品可变性机制。方法宜支持识别需求可变性机制，具有以下能力：——识别可用于需求制品可变性机制；——对需求和需求制品可变性机制进行分类；——识别添加到原始可变性模型的需求特定可变性机制信息；——识别添加到原始决策模型的需求特定可变性机制信息；——验证需求中已分类可变性机制的适用性。工具宜支持识别需求可变性机制，具有以下能力：——按类别显示需求可变性机制；——可对需求可变性机制进行目录管理；——可修改可变性模型，以添加需求特定的可变性机制信息；——可修改决策模型，以添加需求特定的可变性机制信息。7.3.3指导需求可变性机制的使用该任务的目的是为选择可变性机制和执行成员产品配置和绑定提供指导。总指南见ISO/IEC26557。这项任务支持具体的指南，其中包含需求工程的具体实践。方法宜支持指导需求可变性机制，具有以下能力：——为需求工程专门定制可变性机制的指导（见ISO/IEC26557）；——开发可变性机制的使用范例，以确保在需求中准确使用可变性机制。工具宜支持指导需求可变性机制，具有以下能力：——文档化准确使用需求中可变性机制的指南；——提供需求可变性机制的使用范例。7.3.4验证需求可变性机制的使用情况该任务的目标是验证需求中可变性机制的有效性和效率。GB/TXXXXX—XXXX/ISO/IEC26551:2016定义用于验证可变性机制使用情况的度量标准，并对使用状态进行测量，适当分析结果，以提供有价值的反馈。方法宜支持验证需求中可变性机制的使用情况，具有以下能力：——衡量需求中可变性机制分类的有效性和效率；——评审可变性机制的计划与实际使用状态；——制定和跟踪纠正措施。工具宜支持验证需求中可变性机制的使用情况，具有以下能力：——可自动/半自动收集测量数据；——与相关参与者分享可能的纠正措施。7.3.5改进需求可变性机制该任务的目标是改进在需求制品中使用的、已建立的可变性机制，并支持在需求阶段绑定的可变性。根据其使用状态的分析结果，可以重新组织并改进按分类识别的、实现可变性机制。方法宜支持改进需求可变性机制，具有以下能力：——识别需求中可变性机制的改进项；——实施已识别的改进项；——跟踪改进项的状态。工具宜支持改进需求可变性机制，具有以下能力：——文档化改进项；——与相关参与方分享改进成果。7.4需求可变性与可变性模型之间的可追溯性该子过程的目的是在需求可变性文档和单独定义的可变性模型之间建立链接。7.4.1.1输入该子过程的输入如下所述：——包括需求可变性的需求模型或文本需求文档；——可变性模型。7.4.1.2结果该子过程的输出：定义了需求可变性包括其与可变性模型的跟踪链接。7.4.1.3任务该子过程任务：定义需求可变性与可变性模型之间的明确链接。建立并保持需求文档中需求可变性与单独可变性模型的跟踪链接。7.4.2定义需求可变性与可变性模型之间的明确链接该任务的目标是在需求可变性与可变性模型之间建立明确的跟踪链接。方法宜支持定义需求可变性与可变性模型之间的明确链接，具有以下能力：——确定可变性模型与需求文档需求可变性之间的链接；——确认需求可变性是否与可变性模型一致；GB/TXXXXX—XXXX/ISO/IEC26551:2016——检查需求文档中需求可变性的不同定义是否是一致的。工具宜支持定义需求可变性与可变性模型之间的明确链接，具有以下能力：——导入并浏览可变性模型；——存储需求可变性与可变性模型之间的链接；——支持需求可变性与可变性模型之间的偏差评估。8需求工程资产管理在需求工程的资产管理中，领域需求工程所产生的制品构成领域资产。需求可变性与共性都作为领域资产进行管理。此外，应用需求工程中具有较高可重用性的制品也可被定义为领域资产。在需求管理中，资产管理为制品增加或开发额外的详细