4.1需求分[Dav93:Kot00:Som05] 需求可以在多个维度上分类，下面是一些例子： (1)需求是功能性的还是非功能性的（参见主题1.3功能与非功能需求）。 (2)需求是从一个或多个高层次需求或突发性特性（参见主题1.4突发特性）导出的， 还是由干系人或其它来源直接施加在软件上的。 (3)需求是针对产品的还是过程的。对过程的需求可以约束合同商的选择、软件工程 过程的采用、要遵循的标准。 (4)需求的优先性。一般，优先性越高，需求对于满足软件的总体目标就越基本。通 常用固定尺度进行分类，如：强制的、特别需要的、需要的、可选的。优先性通常要与开发 和实现的成本进行平衡。 (5)需求的范围。范围指的是需求影响软件和软件组件的程度。一些需求，特别是一 些非功能性需求，具有全局范围，因为对这些需求的满足不能分配到某一个离散的组件。因 此，全局性需求可能强烈地影响软件的体系结构和许多组件的设计，范围小的需求对于满足 需求没有多少影响。 (6)易变性/稳定性。一些需求在软件生命周期内将发生变化，甚至在开发过程本身中 发生变化。估计需求可能发生的变化概率，是有用的。例如，在银行应用中，对客户帐户计 算和除息功能的需求可能比支持特定类型的免税帐户的需求更稳定，前者反映了银行领域的 一个基本特征（帐户可以有利息），后者可能由于政府的法规而被废止。标记潜在的易变需 求，有助于软件工程师建立一个更容许变化的设计。 也可以采用其它适当的分类，这取决于组织的平常实践和应用本身。 需求分类和需求属性之间有较大的重叠（参见主题7.3需求属性）。 4.2概念建模[Dav93:Kot00:Som05] 开发真实世界问题的模型是软件需求分析的关键，模型的目的是帮助理解问题，而不是 启动方案的设计。因此，概念模型由来自问题域的实体模型组成，实体模型反映了它们的真 实世界联系和依赖。可以开发几类模型，包括：数据和控制流、状态模型、事件追踪、用户 交互、对象模型、数据模型，以及其它模型。影响模型选择的因素有： (1)问题的本质：一些类型的软件要求某些方面的分析特别严格，例如，控制流和状 态模型对于实时软件来说，就比管理信息软件重要得多，后者通常使用数据模型。 (2)软件工程师的技能：采用软件工程师有经验的建模符号或方法，具有更高的生产 率。 (3)客户的过程需求：客户可能要求使用其喜欢的符号或方法，或者禁止使用其不熟 悉的方法。这个因素与前面一个因素是冲突的。 (4)方法和工具的可用性：尽管适合于某些特定的问题，培训和工具不常支持的符号 或方法可能不被广泛接受。 注意，几乎所有情况下，从构造软件的上下文模型开始，是有用的。软件上下文提供了 打算开发的软件与其外部环境之间的联系，这对于理解软件运行环境中的软件上下文，对于 标识软件与环境的接口，都很关键。 建模问题与方法紧密联系，对于实用目的，方法是由引导符号应用的过程支持的一个符号（或 一组符号)。几乎没有经验迹象表明一个符号对另一个符号的优越性。但是，特定方法和符 号的广泛接受可能导致工业界的技能和知识的聚集，这就是目前L(统一建模语言)情况 (UL04)。 可以追溯到逻辑推理的、使用基于离散数学符号的建模，己经对某些特定领域产生影响
4.1 需求分类[Dav93; Kot00; Som05] 需求可以在多个维度上分类，下面是一些例子： （1）需求是功能性的还是非功能性的（参见主题1.3功能与非功能需求）。 （2）需求是从一个或多个高层次需求或突发性特性（参见主题1.4突发特性）导出的， 还是由干系人或其它来源直接施加在软件上的。 （3）需求是针对产品的还是过程的。对过程的需求可以约束合同商的选择、软件工程 过程的采用、要遵循的标准。 （4）需求的优先性。一般，优先性越高，需求对于满足软件的总体目标就越基本。通 常用固定尺度进行分类，如：强制的、特别需要的、需要的、可选的。优先性通常要与开发 和实现的成本进行平衡。 （5）需求的范围。范围指的是需求影响软件和软件组件的程度。一些需求，特别是一 些非功能性需求，具有全局范围，因为对这些需求的满足不能分配到某一个离散的组件。因 此，全局性需求可能强烈地影响软件的体系结构和许多组件的设计，范围小的需求对于满足 需求没有多少影响。 （6）易变性/稳定性。一些需求在软件生命周期内将发生变化，甚至在开发过程本身中 发生变化。估计需求可能发生的变化概率，是有用的。例如，在银行应用中，对客户帐户计 算和除息功能的需求可能比支持特定类型的免税帐户的需求更稳定，前者反映了银行领域的 一个基本特征（帐户可以有利息），后者可能由于政府的法规而被废止。标记潜在的易变需 求，有助于软件工程师建立一个更容许变化的设计。 也可以采用其它适当的分类，这取决于组织的平常实践和应用本身。 需求分类和需求属性之间有较大的重叠（参见主题7.3需求属性）。 4.2 概念建模[Dav93; Kot00; Som05] 开发真实世界问题的模型是软件需求分析的关键，模型的目的是帮助理解问题，而不是 启动方案的设计。因此，概念模型由来自问题域的实体模型组成，实体模型反映了它们的真 实世界联系和依赖。可以开发几类模型，包括：数据和控制流、状态模型、事件追踪、用户 交互、对象模型、数据模型，以及其它模型。影响模型选择的因素有： （1）问题的本质：一些类型的软件要求某些方面的分析特别严格，例如，控制流和状 态模型对于实时软件来说，就比管理信息软件重要得多，后者通常使用数据模型。 （2）软件工程师的技能：采用软件工程师有经验的建模符号或方法，具有更高的生产 率。 （3）客户的过程需求：客户可能要求使用其喜欢的符号或方法，或者禁止使用其不熟 悉的方法。这个因素与前面一个因素是冲突的。 （4）方法和工具的可用性：尽管适合于某些特定的问题，培训和工具不常支持的符号 或方法可能不被广泛接受。 注意，几乎所有情况下，从构造软件的上下文模型开始，是有用的。软件上下文提供了 打算开发的软件与其外部环境之间的联系，这对于理解软件运行环境中的软件上下文，对于 标识软件与环境的接口，都很关键。 建模问题与方法紧密联系，对于实用目的，方法是由引导符号应用的过程支持的一个符号（或 一组符号）。几乎没有经验迹象表明一个符号对另一个符号的优越性。但是，特定方法和符 号的广泛接受可能导致工业界的技能和知识的聚集，这就是目前UML（统一建模语言）情况 (UML04)。 可以追溯到逻辑推理的、使用基于离散数学符号的建模，已经对某些特定领域产生影响
客户或标准可能要求使用这些方法，并可能对某些关键功能或组件的分析提供引人注目的优 点。 本主题并不寻求“教授”一种特定的建模风格或符号，而是提供建模目的和意图的指南。 两个标准提供了可能在进行概念建模时有用的符号：IEEE1320.1功能建模的IDEF0标准和 IEEE1320.2信息建模的IDEF1X97(IDEF对象)标准。 4.3体系结构设计与需求分LDav93:Som05] 在某些时候，必须导出方案的体系结构。体系结构设计是需求过程与软件或系统设计重 叠时进行的，这说明将二者截然分开是不可能的[Som01]。本主题与软件设计知识域的软件 结构与体系结构子域紧密联系。在许多情况下，软件工程师要作为软件体系结构师，因为分 析和详细阐明需求的任务，要求标识负责满足需求的组件。这是一个需求分配：将满足需求 的责任分配到组件上。 分配对于需求的详细分析很重要，例如，一旦将一组需求分配给一个组件，就可以进一 步分解单个需求，以发现有关组件需要如何与其它组件交互以满足分配的需求的更深入的需 求。在大型项目中，分配刺激新一轮的对子系统的分析，例如，对轿车的特定刹车性能的需 求（刹车距离、恶劣驾驶条件下的安全性、应用的平滑性、需要的踏板压力等），可以分配 给刹车硬件（机械和液压组件）和一个反锁定的刹车系统(ABS)。只有在标识了一个反锁 定的刹车系统，并将需求分配给它后，才能使用ABS的能力、刹车硬件和突发特性（如轿车 重量)等来标识详细的ABS软件需求。 体系结构设计与概念建模差不多，从真实世界领域实体到软件组件的映射并不总是显然 的，因此将体系结构设计标识为一个独立的主题。对于概念建模和小、体系结构设计，二者 对于符号和方法的需求广泛地相同。 IEEE1471-2000标准（软件密集系统的体系结构描述的推荐实践）建议使用多视点的途 径来描述系统的体系结构及其软件项(IEEE1471-00)。 4.4需求协商 本子主题中另一个普遍使用的术语是“解决冲突”。这涉及需求冲突的问题，冲突发生在两 个干系人需要不兼容的特征，或者发生在需求与资源之间A,或者在功能与非功能需求之间 [Kot00,Som97]。多数情况下，软件工程师作出单边的决定是不明智的，与干系人协商达成 适当的权衡，就有必要。从合同的原因上，这样一个决定应该追潮到客户。我们将需求协商 分类为一个软件需求分析主题，是因为问题是作为分析的结果出现的。但是，也可以将其作 为需求确认的一个主题。 5需求规格说明 对于许多工程职业，术语“规格说明”指的是将数值或限制分配给产品的设计目标(Wi90)。 一般的物理系统的值的数目相对少，而通常软件却有大量的需求，在完成数量化和管理大量 需求的复杂的相互作用之间有相同的重点。在软件工程术语中，“软件需求规格说明”一般 指产生一个文档或其电子版本，以便系统地评审、评价和批准。对于复杂的系统，特别是涉 及许多非软件组件的系统，最多要产生3类文档：系统定义、系统需求和软件需求。对于简 单的软件产品，只需求软件需求文档。下面描述所有3类文档，需要指出，它们应该适当组 合。对于系统工程的描述可以参见第12章“软件工程相关学科”。 5.1系统定义文档 这个文档（有时称为用户需求文档或操作概念）记录系统的需求，它从领域角度，定义
客户或标准可能要求使用这些方法，并可能对某些关键功能或组件的分析提供引人注目的优 点。 本主题并不寻求“教授”一种特定的建模风格或符号，而是提供建模目的和意图的指南。 两个标准提供了可能在进行概念建模时有用的符号：IEEE1320.1功能建模的IDEF0标准和 IEEE1320.2信息建模的IDEF1X97(IDEF对象)标准。 4.3 体系结构设计与需求分配[Dav93; Som05] 在某些时候，必须导出方案的体系结构。体系结构设计是需求过程与软件或系统设计重 叠时进行的，这说明将二者截然分开是不可能的[Som01]。本主题与软件设计知识域的软件 结构与体系结构子域紧密联系。在许多情况下，软件工程师要作为软件体系结构师，因为分 析和详细阐明需求的任务，要求标识负责满足需求的组件。这是一个需求分配：将满足需求 的责任分配到组件上。 分配对于需求的详细分析很重要，例如，一旦将一组需求分配给一个组件，就可以进一 步分解单个需求，以发现有关组件需要如何与其它组件交互以满足分配的需求的更深入的需 求。在大型项目中，分配刺激新一轮的对子系统的分析，例如，对轿车的特定刹车性能的需 求（刹车距离、恶劣驾驶条件下的安全性、应用的平滑性、需要的踏板压力等），可以分配 给刹车硬件（机械和液压组件）和一个反锁定的刹车系统（ABS）。只有在标识了一个反锁 定的刹车系统，并将需求分配给它后，才能使用ABS的能力、刹车硬件和突发特性（如轿车 重量）等来标识详细的ABS软件需求。 体系结构设计与概念建模差不多，从真实世界领域实体到软件组件的映射并不总是显然 的，因此将体系结构设计标识为一个独立的主题。对于概念建模和小、体系结构设计，二者 对于符号和方法的需求广泛地相同。 IEEE1471-2000标准（软件密集系统的体系结构描述的推荐实践）建议使用多视点的途 径来描述系统的体系结构及其软件项(IEEE1471-00)。 4.4 需求协商 本子主题中另一个普遍使用的术语是“解决冲突”。这涉及需求冲突的问题，冲突发生在两 个干系人需要不兼容的特征，或者发生在需求与资源之间A，或者在功能与非功能需求之间 [Kot00,Som97]。多数情况下，软件工程师作出单边的决定是不明智的，与干系人协商达成 适当的权衡，就有必要。从合同的原因上，这样一个决定应该追溯到客户。我们将需求协商 分类为一个软件需求分析主题，是因为问题是作为分析的结果出现的。但是，也可以将其作 为需求确认的一个主题。 5 需求规格说明 对于许多工程职业，术语“规格说明”指的是将数值或限制分配给产品的设计目标(Vin90)。 一般的物理系统的值的数目相对少，而通常软件却有大量的需求，在完成数量化和管理大量 需求的复杂的相互作用之间有相同的重点。在软件工程术语中，“软件需求规格说明”一般 指产生一个文档或其电子版本，以便系统地评审、评价和批准。对于复杂的系统，特别是涉 及许多非软件组件的系统，最多要产生3类文档：系统定义、系统需求和软件需求。对于简 单的软件产品，只需求软件需求文档。下面描述所有3类文档，需要指出，它们应该适当组 合。对于系统工程的描述可以参见第12章“软件工程相关学科”。 5.1 系统定义文档 这个文档（有时称为用户需求文档或操作概念）记录系统的需求，它从领域角度，定义
高层系统需求，其读者包括系统用户/客户代表（对于市场驱动的软件，市场人员可以担任 这些角色)，因此，它的术语必须采用领域术语。文档需要列举系统需求，以及有关系统总 体目标的背景信息、系统的目标环境，以及对约束、假设和非工程需求的陈述。它也可以包 括设计用于说明系统上下文的概念模型、使用场景和主要的领域实体，还包括数据、信息和 工作流。IEEE1362标准“操作文档概念”为准备这种文档的内容提出了建议(IEEE1362-98)。 5.2系统需求规格说Dav93:Kot00:Rob99:Tha97] 开发包含许多软件和非软件组件的系统（例如，现代民航客机）的人员，通常将系统需 求描述与软件需求描述分开。按这个观点，首先规格说明系统需求，软件需求从系统需求导 出，然后为每个软件组件的需求进行规格说明。严格地讲，系统需求规格说明是一个系统工 程活动，不属于本指南的范围。IEEE1233标准是一个开发系统需求的指南(IEEE1233-98)。 5.3软件需求规格说明Kot00:Rob99] 软件需求规格说明为客户和合同商或供应商（对于市场驱动的项目，这些角色可以有市 场人员和开发部门担任)之间达成的一致建立了基础：软件产品要做什么，软件产品不应该 做什么。对于非技术领域读者，除了软件需求规格说明文档，通常还需要软件需求定义文档。 软件需求规格说明允许在设计开始之前，对需求进行严格的评定，以减少以后的重新设 计工作，它也为估算产品的成本、风险和进度提供一个现实的基础。组织结构也可使用软件 需求规格说明文档来更有效地开发自己的确认和验证计划。 软件需求规格说明为将软件产品传递到新用户或新机器提供了一个信息基础。最后，它 为软件的增强也提供一个基础。 软件需求通常用自然语言编写，但是对于软件需求规格说明，需要用形式化或半形式化 描述离开补充。选择适当的符号，可以更精确更简明地描述软件体系结构的特定需求和特定 方面。一般的规则是，使用的符号应该尽可能简明地描述需求，这对于某些安全性要求很高 的软件，以及某些对其依赖性强的软件，特别重要。但是，符号的选择通常受培训、技能和 文档的作者与读者的限制。 己经有了大量的质量指标，用于将软件需求规格说明的质量与产品的其它属性联系起 来，诸如成本、可接收性、性能、进度、可重现性等。单个软件需求规格说明语句的质量指 标包括：祈使语气、引导语句、弱短语、选项和连续性。整个软件需求规格说明文档的指标 包括：篇幅、可读性、规范、深度和文本结构[Dav93:Tha97](Ros98)。 IEEE为软件需求规格说明的制作和内容发布了一个标准，称为IEEE830标准 [IEEE830-98]。另外，IEEE1465标准（类似IS0/IEC12119标准）是一个处理软件包中质量需 求的标准(IEEE1465-98)。 6需求确认[Dav93] 需求文档需要经过确认和验证过程。确认需求以保证软件工程师己经理解了需求，验证 需求文档遵从公司标准，并且是可理解的、一致的和完备的，也很重要。形式化符号在（严 格地说，至少)证明后面两个特性方面具有很强的优点。不同的干系人，包括客户和开发人 员代表，应该评审文档。需求文档与软件生命周期过程中其它可交付产品一样，要由软件配 置管理来管理(Bry94,Ros98)。 通常需要在需求过程中明确一个或多个点，以进行需求的确认。目标是分配资源给需求 之前，发现存在的问题。需求验证涉及检查需求文档，以保证它确实定义了正确的软件（即， 这是用户期望的软件)[Kot00]
高层系统需求，其读者包括系统用户/客户代表（对于市场驱动的软件，市场人员可以担任 这些角色），因此，它的术语必须采用领域术语。文档需要列举系统需求，以及有关系统总 体目标的背景信息、系统的目标环境，以及对约束、假设和非工程需求的陈述。它也可以包 括设计用于说明系统上下文的概念模型、使用场景和主要的领域实体，还包括数据、信息和 工作流。IEEE1362标准“操作文档概念”为准备这种文档的内容提出了建议(IEEE1362-98)。 5.2 系统需求规格说明[Dav93; Kot00; Rob99; Tha97] 开发包含许多软件和非软件组件的系统（例如，现代民航客机）的人员，通常将系统需 求描述与软件需求描述分开。按这个观点，首先规格说明系统需求，软件需求从系统需求导 出，然后为每个软件组件的需求进行规格说明。严格地讲，系统需求规格说明是一个系统工 程活动，不属于本指南的范围。IEEE1233标准是一个开发系统需求的指南(IEEE1233-98)。 5.3 软件需求规格说明[Kot00; Rob99] 软件需求规格说明为客户和合同商或供应商（对于市场驱动的项目，这些角色可以有市 场人员和开发部门担任）之间达成的一致建立了基础：软件产品要做什么，软件产品不应该 做什么。对于非技术领域读者，除了软件需求规格说明文档，通常还需要软件需求定义文档。 软件需求规格说明允许在设计开始之前，对需求进行严格的评定，以减少以后的重新设 计工作，它也为估算产品的成本、风险和进度提供一个现实的基础。组织结构也可使用软件 需求规格说明文档来更有效地开发自己的确认和验证计划。 软件需求规格说明为将软件产品传递到新用户或新机器提供了一个信息基础。最后，它 为软件的增强也提供一个基础。 软件需求通常用自然语言编写，但是对于软件需求规格说明，需要用形式化或半形式化 描述离开补充。选择适当的符号，可以更精确更简明地描述软件体系结构的特定需求和特定 方面。一般的规则是，使用的符号应该尽可能简明地描述需求，这对于某些安全性要求很高 的软件，以及某些对其依赖性强的软件，特别重要。但是，符号的选择通常受培训、技能和 文档的作者与读者的限制。 已经有了大量的质量指标，用于将软件需求规格说明的质量与产品的其它属性联系起 来，诸如成本、可接收性、性能、进度、可重现性等。单个软件需求规格说明语句的质量指 标包括：祈使语气、引导语句、弱短语、选项和连续性。整个软件需求规格说明文档的指标 包括：篇幅、可读性、规范、深度和文本结构[Dav93; Tha97] (Ros98)。 IEEE为软件需求规格说明的制作和内容发布了一个标准，称为IEEE830标准 [IEEE830-98]。另外，IEEE1465标准（类似ISO/IEC12119标准）是一个处理软件包中质量需 求的标准 (IEEE1465-98)。 6 需求确认[Dav93] 需求文档需要经过确认和验证过程。确认需求以保证软件工程师已经理解了需求，验证 需求文档遵从公司标准，并且是可理解的、一致的和完备的，也很重要。形式化符号在（严 格地说，至少）证明后面两个特性方面具有很强的优点。不同的干系人，包括客户和开发人 员代表，应该评审文档。需求文档与软件生命周期过程中其它可交付产品一样，要由软件配 置管理来管理(Bry94, Ros98)。 通常需要在需求过程中明确一个或多个点，以进行需求的确认。目标是分配资源给需求 之前，发现存在的问题。需求验证涉及检查需求文档，以保证它确实定义了正确的软件（即， 这是用户期望的软件）[Kot00]
6.1需求评审[Kot00:Som05:Tha97] 最普通的确认手段可能就是检查或评审需求文档，分配一组评审人员简要地检查是否存 在：错误、不正确的假设、阐述不清楚、与标准不一致等。引导评审的小组的组成很重要（例 如，对于市场驱动的产品，至少应该包括一个来自客户的代表)，小组可以提供检查清单中 应该出现的内容。 在系统定义文档、软件需求规格说明文档、新发布版本的基线规格说明或过程中任何其 它步骤完成时，应该进行评审。IEEE1028标准提供了如何进行评审的指导(IEEE1028-97)。 软件质量知识域中也覆盖了评审，参见主题2.3评审与审计。 6.2建立原型[Dav93:Kot00:Som05;Tha97] 原形是确认软件工程师对软件需求的解释、获取新需求的常用手段。就获取需求而言， 有大量的原型技术，在过程中也有大量的检查点可以使用原型确认。原型的一个优点是：它 使得解释软件工程师的假设变得容易，并能在需要的时候，给出有用的反馈，说明一些假设 为什么不正确。例如，使用动画原型比文本描述或图形模型，能更好地理解用户界面的动态 行为。但是，原型也有缺点。由于原型的外观或质量问题，它可能将用户的注意力从基础的 核心功能转移到其它方面。因此，一些人推荐不使用软件的原型，例如基于翻动图表的模拟。 开发原形的成本可能会高。但是，如果原型能够避免由于试图满足错误的需求而浪费的资源， 这些成本也是值得付出的。 6.3模型确认[Dav93:Kot00:Tha97] 在分析时，通常有必要确认开发的模型的质量。例如，在对象模型中，进行静态分析， 验证对象之间存在通信路径（在干系人领域，就是交换数据），就有用处。如果使用了形式 化规格说明符号，就有可能使用形式化推理来证明规格说明特性。 6.4接收测试[Dav93] 软件需求的一个本质特性就是，应该能够确认完成的产品满足需求。不能被确认的需求 实际上仅仅是“愿望”。因此，一个重要的任务就是计划如何确认每个需求，在多数情况下， 设计接收测试来完成这个任务。标识和设计非功能需求（参见主题1.3功能与非功能需求） 的接收测试可能比较困难，为了确认它们，必须分析它们，用定量的形式描述它们。 额外的信息可以在软件测试知识域的子主题2.2.4遵从性测试中找到。 7实际考虑 本知识域的第一级分解看起来描述的是线性的活动序列，这是一个过程的简化视图[Dav93]。 需求过程跨越了整个软件生命周期。在某个状态中的需求的变更管理和维护，是软件工程过 程成功的关键，它们精确地反映了待构造的软件或己经构造的软件[Kot00:Lou95]。 并非每个组织都有将需求文档话和管理需求的文化，在动态启动的公司中。受强烈的“产品 视觉”驱动和资源的限制，常常将需求文档看成是不必要的额外开销。但是，随着这些公司 的扩展、客户的增加、公司产品的进化，他们经常发现，自己需要恢复那些促进产品特征的 需求，以评定建议的变更的影响范围。这样，需求文档化和变更管理是任何需求过程成功的 关键。 7.1需求过程的送代本质[Kot00:You01] 软件工业的普遍压力是要求更短的开发周期，特别是竞争非常激烈的市场驱动的部门。 此外，许多项目多少受环境约束，很多是升级或修订给定了体系结构的现存软件。在实践中
6.1 需求评审[Kot00; Som05; Tha97] 最普通的确认手段可能就是检查或评审需求文档，分配一组评审人员简要地检查是否存 在：错误、不正确的假设、阐述不清楚、与标准不一致等。引导评审的小组的组成很重要（例 如，对于市场驱动的产品，至少应该包括一个来自客户的代表），小组可以提供检查清单中 应该出现的内容。 在系统定义文档、软件需求规格说明文档、新发布版本的基线规格说明或过程中任何其 它步骤完成时，应该进行评审。IEEE1028标准提供了如何进行评审的指导(IEEE1028-97) 。 软件质量知识域中也覆盖了评审，参见主题2.3评审与审计。 6.2 建立原型[Dav93; Kot00; Som05; Tha97] 原形是确认软件工程师对软件需求的解释、获取新需求的常用手段。就获取需求而言， 有大量的原型技术，在过程中也有大量的检查点可以使用原型确认。原型的一个优点是：它 使得解释软件工程师的假设变得容易，并能在需要的时候，给出有用的反馈，说明一些假设 为什么不正确。例如，使用动画原型比文本描述或图形模型，能更好地理解用户界面的动态 行为。但是，原型也有缺点。由于原型的外观或质量问题，它可能将用户的注意力从基础的 核心功能转移到其它方面。因此，一些人推荐不使用软件的原型，例如基于翻动图表的模拟。 开发原形的成本可能会高。但是，如果原型能够避免由于试图满足错误的需求而浪费的资源， 这些成本也是值得付出的。 6.3 模型确认[Dav93; Kot00; Tha97] 在分析时，通常有必要确认开发的模型的质量。例如，在对象模型中，进行静态分析， 验证对象之间存在通信路径（在干系人领域，就是交换数据），就有用处。如果使用了形式 化规格说明符号，就有可能使用形式化推理来证明规格说明特性。 6.4 接收测试[Dav93] 软件需求的一个本质特性就是，应该能够确认完成的产品满足需求。不能被确认的需求 实际上仅仅是“愿望”。因此，一个重要的任务就是计划如何确认每个需求，在多数情况下， 设计接收测试来完成这个任务。标识和设计非功能需求（参见主题1.3功能与非功能需求） 的接收测试可能比较困难，为了确认它们，必须分析它们，用定量的形式描述它们。 额外的信息可以在软件测试知识域的子主题2.2.4遵从性测试中找到。 7 实际考虑 本知识域的第一级分解看起来描述的是线性的活动序列，这是一个过程的简化视图[Dav93]。 需求过程跨越了整个软件生命周期。在某个状态中的需求的变更管理和维护，是软件工程过 程成功的关键，它们精确地反映了待构造的软件或已经构造的软件[Kot00; Lou95]。 并非每个组织都有将需求文档话和管理需求的文化，在动态启动的公司中。受强烈的“产品 视觉”驱动和资源的限制，常常将需求文档看成是不必要的额外开销。但是，随着这些公司 的扩展、客户的增加、公司产品的进化，他们经常发现，自己需要恢复那些促进产品特征的 需求，以评定建议的变更的影响范围。这样，需求文档化和变更管理是任何需求过程成功的 关键。 7.1 需求过程的迭代本质[Kot00; You01] 软件工业的普遍压力是要求更短的开发周期，特别是竞争非常激烈的市场驱动的部门。 此外，许多项目多少受环境约束，很多是升级或修订给定了体系结构的现存软件。在实践中
将需求过程实现为线性的、确定性的过程，是不现实的。在线性的、确定性的过程中，从干 系人获得需求，确定基线，分配需求，交付给软件开发小组，顺次完成。大型软件项目的需 求被完美理解或完美规格说明，这只是一个神话[Som97]。 相反，需求通常是反复地向一个详细和质量水平前进的，这个水平允许人们作出设计和 采购决定。在一些项目中，这样可能导致需求在所有其它特性被充分理解之间，被作为基线。 如果问题在以后的软件工程过程中出现，就会有推倒重来的高成本风险。但是，软件工程师 应该受项目管理计划的约束，并采取措施，确保需求的“质量”在给定的资源条件下，尽可 能高。例如，他们应该清楚说明所有支持需求的假设，以及其它任何已知的问题。 几乎在所有情况下，对需求的理解会随着设计和开发的进行而继续演化，这常常导致在 生命周期后期修改需求。也许，理解需求工程中最关键的一点是：相当大一部分需求将回改 变。有时，这是由于分析中的错误，但它经常是“环境”改变的一个不可避免的后果：例如， 客户的运行或业务环境、软件将要在其中销售的市场环境。无论什么原因，认识到变化的不 可避免性和采取措施来缓和它的影响，非常重要。必须管理这些变更，要求提出的变更必须 经过一个事先定义的评审和批准过程，并使用仔细的需求追踪、后果分析和软件配置管理（参 加软件配置管理知识域)。因此，需求过程不仅仅是软件生命周期中个一个简单的任务，而 是跨越整个软件生命周期。在一个典型的项目中，软件需求活动从获取到变更管理，都随时 间演化。 7.2变更管理[Kot00] 变更管理是需求管理的中心。这个主题描述了变更管理的角色、需要经过的程序、应该 对提出的变更进行的分析。它与软件配置管理知识域有较强的联系。 7.3需求的属性[Kot00] 需求不仅仅由需要的事物的规格说明组成，还包括帮助管理和解释需求的辅助信息。这 应该包括需求的各种不同的分类维度（参见主题4.1需求分类）和验证方法或接收测试计划。 它还可能包括每个需求的概要性原理、每个需求的来源、变更历史等附加信息。但是，最重 要的需求属性是一个标识符，它允许需求被唯一地和无二义地被标识。 7.4需求追踪Kot00] 需求追踪涉及恢复需求的来源和预测需求的效果。追踪是完成需求变更时的效果分析的 基础。一个需求应该能够追踪回溯到原始需求和提出需求的干系人（例如，从软件需求回溯 到其需要满足的系统需求)。一个需求还应能够向前追踪到满足的需求和设计实体（例如， 从系统需求追踪到详细描述它的软件需求，追踪到实现它的代码模块)。典型项目的需求追 踪将形成需求的一个复杂的有向无环图(DAG)。 7.5度量需求 作为一个实用问题，对于一个特定的软件产品，有一个需求的“量”的概念是有用的。 这个数在评价需求变更的“规模”、估算开发或维护任务的成本时，很有用，也可简单用于 其它度量的分母。功能规模度量(Functional Size Measurement,FSM)是评价功能需求体 系的规模的技术，IEEE14143.1标准定义了FSM的概念[IEEE14143.1-00]。IS0/IEC的标准和 其它标准描述了特定的FSM方法。 有关规模度量和标准的其它信息可以在软件工程过程知识域中找到。 主题与参考资料矩阵
将需求过程实现为线性的、确定性的过程，是不现实的。在线性的、确定性的过程中，从干 系人获得需求，确定基线，分配需求，交付给软件开发小组，顺次完成。大型软件项目的需 求被完美理解或完美规格说明，这只是一个神话[Som97]。 相反，需求通常是反复地向一个详细和质量水平前进的，这个水平允许人们作出设计和 采购决定。在一些项目中，这样可能导致需求在所有其它特性被充分理解之间，被作为基线。 如果问题在以后的软件工程过程中出现，就会有推倒重来的高成本风险。但是，软件工程师 应该受项目管理计划的约束，并采取措施，确保需求的“质量”在给定的资源条件下，尽可 能高。例如，他们应该清楚说明所有支持需求的假设，以及其它任何已知的问题。 几乎在所有情况下，对需求的理解会随着设计和开发的进行而继续演化，这常常导致在 生命周期后期修改需求。也许，理解需求工程中最关键的一点是：相当大一部分需求将回改 变。有时，这是由于分析中的错误，但它经常是“环境”改变的一个不可避免的后果：例如， 客户的运行或业务环境、软件将要在其中销售的市场环境。无论什么原因，认识到变化的不 可避免性和采取措施来缓和它的影响，非常重要。必须管理这些变更，要求提出的变更必须 经过一个事先定义的评审和批准过程，并使用仔细的需求追踪、后果分析和软件配置管理（参 加软件配置管理知识域）。因此，需求过程不仅仅是软件生命周期中个一个简单的任务，而 是跨越整个软件生命周期。在一个典型的项目中，软件需求活动从获取到变更管理，都随时 间演化。 7.2 变更管理[Kot00] 变更管理是需求管理的中心。这个主题描述了变更管理的角色、需要经过的程序、应该 对提出的变更进行的分析。它与软件配置管理知识域有较强的联系。 7.3 需求的属性[Kot00] 需求不仅仅由需要的事物的规格说明组成，还包括帮助管理和解释需求的辅助信息。这 应该包括需求的各种不同的分类维度（参见主题4.1需求分类）和验证方法或接收测试计划。 它还可能包括每个需求的概要性原理、每个需求的来源、变更历史等附加信息。但是，最重 要的需求属性是一个标识符，它允许需求被唯一地和无二义地被标识。 7.4 需求追踪[Kot00] 需求追踪涉及恢复需求的来源和预测需求的效果。追踪是完成需求变更时的效果分析的 基础。一个需求应该能够追踪回溯到原始需求和提出需求的干系人（例如，从软件需求回溯 到其需要满足的系统需求）。一个需求还应能够向前追踪到满足的需求和设计实体（例如， 从系统需求追踪到详细描述它的软件需求，追踪到实现它的代码模块）。典型项目的需求追 踪将形成需求的一个复杂的有向无环图(DAG)。 7.5 度量需求 作为一个实用问题，对于一个特定的软件产品，有一个需求的“量”的概念是有用的。 这个数在评价需求变更的“规模”、估算开发或维护任务的成本时，很有用，也可简单用于 其它度量的分母。功能规模度量（Functional Size Measurement，FSM）是评价功能需求体 系的规模的技术，IEEE14143.1标准定义了FSM的概念[IEEE14143.1-00]。ISO/IEC的标准和 其它标准描述了特定的FSM方法。 有关规模度量和标准的其它信息可以在软件工程过程知识域中找到。 主题与参考资料矩阵