引言 软件需求知识域涉及软件需求的获取、分析、规格说明和确认。在软件工业界，人们广 泛认为，如果这些活动完成得不好，软件工程项目很容易上失败。 软件需求表达了施加在要解决真实世界问题的软件产品上的要求和约束[K0t00]。 术语“需求工程”在需求中被广泛使用，表示系统地处理需求。但是出于一致性，本指 南将不使用它，正如本指南要避免使用术语“工程”来表示除了软件工程活动以外的活动一 样。 基于同样原因，本指南也不使用出现在一些文献中的术语“需求工程师”，我们使用“软 件工程师”，有时也使用“需求专家”，后一个术语表示问题中的角色通常由个人完成，而 不是软件工程师完成。但是，这并不表示软件工程师不能去完成这个任务。 知识域的结构分解与IEEE12207中关于需求活动一节广泛兼容(IEEE12207.1-96)。 在我们提出的结构分解中有一个固有风险：隐含了类似瀑布模型的过程。为澄清这一点， 我们设计了子域2（需求过程）来给出需求过程的高层视图，它确定过程进行需要的资源和 约束，以及使其具有一定形式而需要的行动。 另外一个可能的分解是使用基于产品的结构（系统需求、软件需求、原型、用况等）。 基于过程的分解结构反映了一个事实：需求过程要成功，就必须作为一个涉及复杂、紧密耦 合的多个活动组成的过程考虑，而不是作为在软件开发项目开始就进行的离散的、单个的活 动组成的过程来考虑。 软件需求知识域与软件设计、软件测试、软件维护、软件配置管理、软件工程管理、软 件工程过程和软件质量等的知识域紧密相关。 软件需求主题的结构分解 1.软件需求基础 1.1.软件需求定义 软件需求的最基本含义是一个为了解决真实世界问题而必须展示的特性。指南将需求与 软件联系起来，因为需求涉及的是软件要解决的问题。因此，软件需求是一个为解决特定问 题而必须由被开发或被修改的软件展示的特性。这个问题可能是使用软件的某人的任务中的 一个自动化部分，或是支持委托开发软件的组织的业务过程，或修正当前软件的缺点，或是 控制一个设备等等。用户、业务过程和设备的功能通常很复杂，因此，特定软件的需求在外 延上通常是来自一个组织不同层次的不同人员的需求和来自软件将要在其中运行的环境的 需求的复杂组合。 所有软件需求的一个基本特性就是：可验证。验证某些软件需求可能很困难或则成本很 高，例如，验证呼叫中心的吞吐量需求就需要开发模拟软件。软件需求和软件质量人员都必 须保证，可以在现有的资源约束下，需求可以被验证
引言 软件需求知识域涉及软件需求的获取、分析、规格说明和确认。在软件工业界，人们广 泛认为，如果这些活动完成得不好，软件工程项目很容易上失败。 软件需求表达了施加在要解决真实世界问题的软件产品上的要求和约束[Kot00]。 术语“需求工程”在需求中被广泛使用，表示系统地处理需求。但是出于一致性，本指 南将不使用它，正如本指南要避免使用术语“工程”来表示除了软件工程活动以外的活动一 样。 基于同样原因，本指南也不使用出现在一些文献中的术语“需求工程师”，我们使用“软 件工程师”，有时也使用“需求专家”，后一个术语表示问题中的角色通常由个人完成，而 不是软件工程师完成。但是，这并不表示软件工程师不能去完成这个任务。 知识域的结构分解与IEEE12207中关于需求活动一节广泛兼容(IEEE12207.1-96)。 在我们提出的结构分解中有一个固有风险：隐含了类似瀑布模型的过程。为澄清这一点， 我们设计了子域2（需求过程）来给出需求过程的高层视图，它确定过程进行需要的资源和 约束，以及使其具有一定形式而需要的行动。 另外一个可能的分解是使用基于产品的结构（系统需求、软件需求、原型、用况等）。 基于过程的分解结构反映了一个事实：需求过程要成功，就必须作为一个涉及复杂、紧密耦 合的多个活动组成的过程考虑，而不是作为在软件开发项目开始就进行的离散的、单个的活 动组成的过程来考虑。 软件需求知识域与软件设计、软件测试、软件维护、软件配置管理、软件工程管理、软 件工程过程和软件质量等的知识域紧密相关。 软件需求主题的结构分解 1. 软件需求基础 1.1. 软件需求定义 软件需求的最基本含义是一个为了解决真实世界问题而必须展示的特性。指南将需求与 软件联系起来，因为需求涉及的是软件要解决的问题。因此，软件需求是一个为解决特定问 题而必须由被开发或被修改的软件展示的特性。这个问题可能是使用软件的某人的任务中的 一个自动化部分，或是支持委托开发软件的组织的业务过程，或修正当前软件的缺点，或是 控制一个设备等等。用户、业务过程和设备的功能通常很复杂，因此，特定软件的需求在外 延上通常是来自一个组织不同层次的不同人员的需求和来自软件将要在其中运行的环境的 需求的复杂组合。 所有软件需求的一个基本特性就是：可验证。验证某些软件需求可能很困难或则成本很 高，例如，验证呼叫中心的吞吐量需求就需要开发模拟软件。软件需求和软件质量人员都必 须保证，可以在现有的资源约束下，需求可以被验证
软件需求 软件需求 需求过程 需求获取 需求分析 需求规格 需求确认 实际考虑 基础 说明 十软件需求 ◆过程模型 ◆需求来源 需求分类 系统定义 ◆需求评审 ◆需求过程 定义 文档 ◆建造原型 的 ◆产品与过 ◆过程参与 广获取技术 ·概念建模 ◆系统需求 迭代本质 程需求 者 ·体系结构 规格说明 ◆模型确认 ◆变更管理 功能与非 ◆过程支持 设计和 ◆软件需求 ◆接收测试 ·需求属性 功能需求 与管理 需求分配 规格说明 ·需求追踪 笑发特性 ◆过程质量 ◆需求协商 ◆需求度量 ◆定量需求 与改进 ◆系统需求 与 软件需求 图1软件需求知识域主题的结构分解 除了其表达的行为特性外，需求还有其它的属性。普遍的例子是一个优先级别，以便在 资源有限时进行权衡，或者一个分情况的价值，以便监控项目的进展。通常，软件需求要唯 一地标识，才能在整个软件生命周期中，进行软件配置控制和管理[Kot00:Pf101;Som05: Tha97]。 1.2产品和过程需求 可以区别产品参数与过程参数，产品参数是需要开发的软件上的需求（例如，“软件应 该验证一个学生在注册一门课程时，已经满足了所有的前提条件”)，过程参数本质上是对 软件开发的约束（例如，“软件应该用Ada编写”），过程参数有时也叫过程需求。 些软件需求可以产生隐含的过程需求，一个例子就是选择验证技术，另外一个例子可 能是要求使用特别严格的分析技术（如形式化规格说明方法）来减少可能导致不适当可靠性 的故障。开发组织、客户或第三方（如安全管理人员）也可能直接提出过程需求[Kot00: Som97]。 1.3功能与非功能需求 功能需求描述软件要执行的功能，例如，将某些文本格式化或调制一个信号，功能有时 叫做能力。 非功能需求是限制解决方案的需求，非功能需求有时叫做约束或质量需求，可以进一步 划分为：性能需求、可维护性需求、安全性需求、可靠性需求，以及其它类型的软件需求， 这些主题也在软件质量知识域中讨论[Kot00:Som97]
系统需求 规格说明 软件需求 软件需求 基础 需求规格 说明 需求过程 需求获取 需求分析 软件需求 定义 过程参与 者 软件需求 规格说明 系统需求 与 软件需求 产品与过 程需求 过程模型 过程质量 与改进 过程支持 与管理 需求来源 获取技术 需求分类 系统定义 文档 需求评审 模型确认 接收测试 建造原型 图 1 软件需求知识域主题的结构分解 需求确认 功能与非 功能需求 定量需求 突发特性 实际考虑 变更管理 需求过程 的 概念建模 迭代本质 体系结构 设计和 需求分配 需求协商 需求属性 需求追踪 需求度量 除了其表达的行为特性外，需求还有其它的属性。普遍的例子是一个优先级别，以便在 资源有限时进行权衡，或者一个分情况的价值，以便监控项目的进展。通常，软件需求要唯 一地标识，才能在整个软件生命周期中，进行软件配置控制和管理[Kot00; Pfl01; Som05; Tha97]。 1.2 产品和过程需求 可以区别产品参数与过程参数，产品参数是需要开发的软件上的需求（例如，“软件应 该验证一个学生在注册一门课程时，已经满足了所有的前提条件”），过程参数本质上是对 软件开发的约束（例如，“软件应该用Ada编写”），过程参数有时也叫过程需求。 一些软件需求可以产生隐含的过程需求，一个例子就是选择验证技术，另外一个例子可 能是要求使用特别严格的分析技术（如形式化规格说明方法）来减少可能导致不适当可靠性 的故障。开发组织、客户或第三方（如安全管理人员）也可能直接提出过程需求[Kot00; Som97]。 1.3 功能与非功能需求 功能需求描述软件要执行的功能，例如，将某些文本格式化或调制一个信号，功能有时 叫做能力。 非功能需求是限制解决方案的需求，非功能需求有时叫做约束或质量需求，可以进一步 划分为：性能需求、可维护性需求、安全性需求、可靠性需求，以及其它类型的软件需求， 这些主题也在软件质量知识域中讨论[Kot00;Som97]
1.4突发特性 一些需求表现了软件的突发(Emergent)特性，即，这些需求不能由单个组件完成，根 据其满足程度，依赖于所有软件组件之间的互操作。例如，呼叫中心的吞吐量需求可能依赖 于电话系统、信息系统和接线员在实际运行条件下的相互作用。突发特性特别依赖于系统体 系结构[SomO5]。 1.5定量需求 软件需求应尽可能清楚地无二义性地陈述，可能时，应该定量地陈述。避免含糊和不 可验证的需求非常重要，因为这些需求依赖于主观判断的解释(“软件应该可靠”、“软件 应该用户友好”)。这对于非功能性需求特别重要。下面是两个定量需求的例子：呼叫中心 软件必须增加20%的吞吐量：在运行的任一小时内，系统产生致命错误的概率应该小于 1.0*10。吞吐量需求是一个高层次的需求，可以导出许多详细需求，可靠性需求将紧密约 束系统体系结构[Dav93;SomO5]。 1.6系统需求与软件需求 在这个主题中，系统的含义是“多个元素相互作用的组合，以实现为其定义的目标，元 素包括：硬件、软件、固件、人员、信息、技术、设施、服务和其它支持元素”，这是国际 系统工程理事会的定义(INC0SE00)。 系统需求是对整个系统的需求，在包含软件组件的系统中，软件需求是从系统需求中导 出的。关于需求的文献有时将系统需求称为“用户需求”。本指南将“用户需求”严格定义 为系统客户或终端用户的需求。这样，系统需求包括：用户需求，其它干系人的需求（如管 理层)，以及没有可标识的人类来源的需求。 2需求过程 本节介绍软件需求过程，它面向剩余的5个子域，说明软件需求过程如何与总的软件工 程过程吻合[Dav93:SomO5]。 2.1过程模型 这个主题的目的是提供对需求过程的如下理解：(1)需求过程不是软件生命周期中的 一个离散的从头到尾(front-end)的活动，而是一个过程，开始于项目的起始阶段，并在 整个生命周期中需要持续精化。(2)需求过程要将软件需求标识配置项，并使用与其它软 件生命周期过程的产品相同的软件配置管理实践来管理软件需求。(3)需求过程需要与组 织和项目上下文保持适应。 这个主题也包括为需求过程提供输入的活动，如市场和可行性研究等[Kot00:Rob99: Som97:Som05]。 2.2过程参与者 这个主题介绍参与需求过程的人员的角色。需求过程本身是交叉学科的需求专家需要在 干系人和软件工程师之间进行协调。除了需求专家外，有许多人员参与，每个人都与软件有 某种干系。随项目不同，干系人也不同，但总是包括：用户/操作人员和客户（二者可以不 同)[G0g93]。软件干系人的典型例子包括（但不局限于）：(1)用户：这个群体由将要操 作软件的人员组成，通常是一个杂合群体，包含有不同角色和需求的人员。(2)客户：这 个群体由委托软件开发的人员和代表软件的目标市场的人员组成。(3)市场分析师：大众 市场产品不止一个委托方，因此需要市场营销人员来确定市场的要求和作为代理客户。(4)
1.4 突发特性 一些需求表现了软件的突发（Emergent）特性，即，这些需求不能由单个组件完成，根 据其满足程度，依赖于所有软件组件之间的互操作。例如，呼叫中心的吞吐量需求可能依赖 于电话系统、信息系统和接线员在实际运行条件下的相互作用。突发特性特别依赖于系统体 系结构[Som05]。 1.5 定量需求 软件需求应尽可能清楚地无二义性地陈述， 可能时，应该定量地陈述。避免含糊和不 可验证的需求非常重要，因为这些需求依赖于主观判断的解释（“软件应该可靠”、“软件 应该用户友好”）。这对于非功能性需求特别重要。下面是两个定量需求的例子：呼叫中心 软件必须增加20%的吞吐量；在运行的任一小时内，系统产生致命错误的概率应该小于 1.0*10-8 干系人和软件工程师之间进行协调。除了需求专家外，有许多人员参与，每个人都与软件有 某种干系。随项目不同，干系人也不同，但总是包括：用户/操作人员和客户（二者可以不 同）[Gog93]。软件干系人的典型例子包括（但不局限于）：（1）用户：这个群体由将要操 作软件的人员组成，通常是一个杂合群体，包含有不同角色和需求的人员。（2）客户：这 个群体由委托软件开发的人员和代表软件的目标市场的人员组成。（3）市场分析师：大众 市场产品不止一个委托方，因此需要市场营销人员来确定市场的要求和作为代理客户。（4） 。吞吐量需求是一个高层次的需求，可以导出许多详细需求，可靠性需求将紧密约 束系统体系结构[Dav93; Som05]。 1.6 系统需求与软件需求 在这个主题中，系统的含义是“多个元素相互作用的组合，以实现为其定义的目标，元 素包括：硬件、软件、固件、人员、信息、技术、设施、服务和其它支持元素”，这是国际 系统工程理事会的定义(INCOSE00)。 系统需求是对整个系统的需求，在包含软件组件的系统中，软件需求是从系统需求中导 出的。关于需求的文献有时将系统需求称为“用户需求”。本指南将“用户需求”严格定义 为系统客户或终端用户的需求。这样，系统需求包括：用户需求，其它干系人的需求（如管 理层），以及没有可标识的人类来源的需求。 2 需求过程 本节介绍软件需求过程，它面向剩余的5个子域，说明软件需求过程如何与总的软件工 程过程吻合[Dav93; Som05]。 2.1 过程模型 这个主题的目的是提供对需求过程的如下理解：（1）需求过程不是软件生命周期中的 一个离散的从头到尾（front-end）的活动，而是一个过程，开始于项目的起始阶段，并在 整个生命周期中需要持续精化。（2）需求过程要将软件需求标识配置项，并使用与其它软 件生命周期过程的产品相同的软件配置管理实践来管理软件需求。（3）需求过程需要与组 织和项目上下文保持适应。 这个主题也包括为需求过程提供输入的活动，如市场和可行性研究等[Kot00; Rob99; Som97; Som05]。 2.2 过程参与者 这个主题介绍参与需求过程的人员的角色。需求过程本身是交叉学科的需求专家需要在
管制人员：许多应用领域，如银行和公共运输，是被政府管制的，这些领域的软件必须遵从 管制当局的需求。(5)软件工程师：这些人员对从软件开发中通过复用其它产品的组件而 获利感兴趣，在这种情形下，如果特定产品的用户有复用组件的特殊需求，软件工程师必须 权衡自身的利益和客户的利益。 满足所有干系人的需求，通常是不可能的，软件工程师的任务就是协调各种权衡，使之 能被主要的干系人接受，并能满足预算、技术、管制规则和其它约束。作到这一点的前提是， 己经标识了所有干系人，分析了他们的利益本质，获得了他们的需求[Dav93:Kot00:Rob99: Som97:You01]。 2.3过程支持与管理 这个主题介绍需求过程需要和消耗的管理资源，它为软件工程管理知识域的第一个子域 (启动和范围定义)建立上下文，它的主要目的是建立2.1中标识的过程活动与成本、人力 资源、培训和工具等问题之间的联系[Rob99:Som97:You01]。 2.4过程质量与改进 这个主题涉及需求过程的质量评定和改进，其目的是强调需求过程在软件产品的成本和 准时性方面、客户对需求过程的满意度方面所起的关键作用[Som97]。它有助于需求过程适 应软件和系统的质量标准和过程改进模型。过程质量和改进与软件质量知识域和软件工程过 程知识域都密切相关，特别是软件质量属性和度量的问题，以及软件过程定义的问题。这个 主题覆盖下列问题：(1)过程改进标准和模型覆盖的需求过程范围：(2)需求过程度量与 基准：(3)改进的计划与实现[Kot00:Som97;You01]。 3需求获取[Dav93:Gog93;Lou95;Pf101] 需求获取涉及软件需求来自何方，软件工程师如何收集它们。这是理解需要软件解决的 问题的第一阶段，这是本质是一个人类活动，活动中要标识干系人，建立开发小组与客户之 间的联系。需求获取又称为“需求捕获”、“需求发现”和“需求获得”。 良好的软件工程的一个基本原则就是，软件工程师与软件用户之间有良好的沟通。在开 发活动开始前，需求专家必须为这个沟通建立渠道，他们必须协调软件用户（及其它干系人） 的业务领域和软件工程师的技术领域。 3.1需求来源Dav93:Gog93:Pf101] 在典型的软件中，需求有许多来源，有必要标识所有潜在的来源，并评价其对软件的影 响。设计这个主题是为了促进对软件需求的各种来源的意识和管理这些来源的框架的意识。 要点如下： (1)目标：术语“目标”（有时称为“业务关注”或“关键成功因素”）指的是软件 总体的、高层次的目标。目标为软件提供了动机，但通常被含糊地表达。软件工程师需要特 别注意评定目标（相对与优先权）的价值和成本，一个低成本的评定方法是可行性研究 [Lou95]。 (2)领域知识：软件工程师需要获得或具有关于应用领域的知识，这样，能够推导出 干系人没有清楚说明的隐性知识，能够评定相互矛盾的需求之间的必要的权衡，并作为“用 户”支持者。 (3)千系人（参见2.2过程参与者）：由于过分强调了一部分干系人的需求而牺牲了其 它干系人的需求，许多软件的结果不令人满意。因此，交互的软件难以使用，或违反了客户 组织的文化或政策结构。软件工程师需要标识、描绘和管理很多不同类型的干系人的视点
管制人员：许多应用领域，如银行和公共运输，是被政府管制的，这些领域的软件必须遵从 管制当局的需求。（5）软件工程师：这些人员对从软件开发中通过复用其它产品的组件而 获利感兴趣，在这种情形下，如果特定产品的用户有复用组件的特殊需求，软件工程师必须 权衡自身的利益和客户的利益。 满足所有干系人的需求，通常是不可能的，软件工程师的任务就是协调各种权衡，使之 能被主要的干系人接受，并能满足预算、技术、管制规则和其它约束。作到这一点的前提是， 已经标识了所有干系人，分析了他们的利益本质，获得了他们的需求 [Dav93;Kot00; Rob99; Som97; You01]。 2.3 过程支持与管理 这个主题介绍需求过程需要和消耗的管理资源，它为软件工程管理知识域的第一个子域 （启动和范围定义）建立上下文，它的主要目的是建立2.1中标识的过程活动与成本、人力 资源、培训和工具等问题之间的联系[Rob99; Som97; You01]。 2.4 过程质量与改进 这个主题涉及需求过程的质量评定和改进，其目的是强调需求过程在软件产品的成本和 准时性方面、客户对需求过程的满意度方面所起的关键作用[Som97]。它有助于需求过程适 应软件和系统的质量标准和过程改进模型。过程质量和改进与软件质量知识域和软件工程过 程知识域都密切相关，特别是软件质量属性和度量的问题，以及软件过程定义的问题。这个 主题覆盖下列问题：（1）过程改进标准和模型覆盖的需求过程范围；（2）需求过程度量与 基准；（3）改进的计划与实现[Kot00;Som97; You01]。 3 需求获取[Dav93; Gog93; Lou95; Pfl01] 需求获取涉及软件需求来自何方，软件工程师如何收集它们。这是理解需要软件解决的 问题的第一阶段，这是本质是一个人类活动，活动中要标识干系人，建立开发小组与客户之 间的联系。需求获取又称为“需求捕获”、“需求发现”和“需求获得”。 良好的软件工程的一个基本原则就是，软件工程师与软件用户之间有良好的沟通。在开 发活动开始前，需求专家必须为这个沟通建立渠道，他们必须协调软件用户（及其它干系人） 的业务领域和软件工程师的技术领域。 3.1 需求来源[Dav93; Gog93; Pfl01] 在典型的软件中，需求有许多来源，有必要标识所有潜在的来源，并评价其对软件的影 响。设计这个主题是为了促进对软件需求的各种来源的意识和管理这些来源的框架的意识。 要点如下： （1）目标：术语“目标”（有时称为“业务关注”或“关键成功因素”）指的是软件 总体的、高层次的目标。目标为软件提供了动机，但通常被含糊地表达。软件工程师需要特 别注意评定目标（相对与优先权）的价值和成本，一个低成本的评定方法是可行性研究 [Lou95]。 （2）领域知识：软件工程师需要获得或具有关于应用领域的知识，这样，能够推导出 干系人没有清楚说明的隐性知识，能够评定相互矛盾的需求之间的必要的权衡，并作为“用 户”支持者。 （3）干系人（参见2.2过程参与者）：由于过分强调了一部分干系人的需求而牺牲了其 它干系人的需求，许多软件的结果不令人满意。因此，交互的软件难以使用，或违反了客户 组织的文化或政策结构。软件工程师需要标识、描绘和管理很多不同类型的干系人的视点
[Kot00]。 (4)运行环境：需求能够从软件将要运行的环境中导出。例如，实时软件的定时约束、 办公环境中的互操作约束。必须主动地寻找这些需求，因为它们可能对软件的可行性和成本 有重大影响，并限制设计的选择[Tha97]。 (5)组织环境：通常要求软件支持某个业务过程，业务过程的选择受组织的结构、文 化和内部策略的限制。软件工程师对这些事情应该敏感，因为，一般要求新的软件不能对业 务过程施加没有计划的变更。 3.2获取技[Dav93:Kot00:Lou95:Pf101] 一旦标识了需求来源后，软件工程师就开始从需求来源获取需求。这个主题主要是让人 类干系人清晰地表达他们的需求的技术。这是一个非常困难的领域，软件工程师需要记住这 个事实（例如）：用户可能难以描述他们的任务，可能遗漏重要的信息，可能不愿意或不能 够合作。特别重要的是，需要理解，获取不是一个被动的任务，即使干系人愿意合作并能清 晰表达其任务，软件工程师也必须努力工作，以获取正确的信息。有大量的需求获取技术， 下面是主要的几个[Gog93]。 (1)面谈：这是一个“传统”的获取需求的方法。了解面谈的优点和限制，以及如何 引导面谈，非常重要。 (2)场景：这是一个为获取用户需求提供上下文的有价值的工具，场景让软件工程师 为有关用户任务的问题提供一个框架，允许提出“如果…那么…”和“这是如何做的”之类 的问题。场景最普通的类型就是用况，这里提供一个到主题4.2（概念建模）的指示器，因 为用况和用况图等场景符号在概念建模中很普通。 (3)原型：这是一个阐明不清楚的需求的有价值的工具，原型与场景的作用类似，向 用户提供一个可以更好理解他们需要提供的信息的上下文。原型技术的范围很广，从纸面的 屏幕模拟设计到软件产品的B版本，原型用于需求获取和用于需求验证，二者之间有很多重 叠（参见主题6.2建立原型）。 (4)恳谈会：目的是试图达到一个综合效果，因为一群人对其软件需求的洞察比与向 单个人了解的要深，他们可以采用头脑风暴，精化其想法，这些想法是使用面谈难以得到的。 另一个优点是，相互冲突的需求出现得早，让干系人能认识到存在冲突。如果组织得好，这 个技术可以比其它技术得到更丰富更一致的需求。但是，需要仔细控制会议（因此，需要一 个推动者)，以避免出现小组中批判的能力被对团体的忠诚消蚀，或者出现赞同少数人说出 的需求而损害其他人员。 (5)观察：在组织环境中软件的上下文的重要性，导致修改观察技术来获取需求。软 件工程师通过将自己投入到环境中，观察用户如何与其软件交互或相互交互，来学习用户的 任务。这些技术成本相对高，但却是有益的，因为它们能阐明许多参与者不能轻易描述清楚 的微妙和复杂的用户任务和业务过程。 4需求分析[Som05] 这个主题涉及分析需求的过程，目的是：(1)检测和解决需求之间的冲突：(2)发现 软件的边界，以及软件与其环境如何交互：(3)详细描述系统需求，以导出软件需求。 需求分析的传统观点是：需求分析被精简为使用多个分析方法中的一个来进行概念建模，这 些方法包括：结构化分析与设计(Structured Analysis and Design Technique,SADT)。 尽管概念建模很重要，我们将需求分类也包括进来，以帮助需求之间的权衡的告知（需求分 类)和建立这些权衡的过程（需求协商）[Dav93]。 描述需求时，必须仔细，应该精确到能确认需求，验证需求的实现，估算需求的成本
[Kot00]。 （4）运行环境：需求能够从软件将要运行的环境中导出。例如，实时软件的定时约束、 办公环境中的互操作约束。必须主动地寻找这些需求，因为它们可能对软件的可行性和成本 有重大影响，并限制设计的选择[Tha97]。 （5）组织环境：通常要求软件支持某个业务过程，业务过程的选择受组织的结构、文 化和内部策略的限制。软件工程师对这些事情应该敏感，因为，一般要求新的软件不能对业 务过程施加没有计划的变更。 3.2 获取技术[Dav93; Kot00; Lou95; Pfl01] 一旦标识了需求来源后，软件工程师就开始从需求来源获取需求。这个主题主要是让人 类干系人清晰地表达他们的需求的技术。这是一个非常困难的领域，软件工程师需要记住这 个事实（例如）：用户可能难以描述他们的任务，可能遗漏重要的信息，可能不愿意或不能 够合作。特别重要的是，需要理解，获取不是一个被动的任务，即使干系人愿意合作并能清 晰表达其任务，软件工程师也必须努力工作，以获取正确的信息。有大量的需求获取技术， 下面是主要的几个[Gog93]。 （1）面谈：这是一个“传统”的获取需求的方法。了解面谈的优点和限制，以及如何 引导面谈，非常重要。 （2）场景：这是一个为获取用户需求提供上下文的有价值的工具，场景让软件工程师 为有关用户任务的问题提供一个框架，允许提出“如果…那么…”和“这是如何做的”之类 的问题。场景最普通的类型就是用况，这里提供一个到主题4.2（概念建模）的指示器，因 为用况和用况图等场景符号在概念建模中很普通。 （3）原型：这是一个阐明不清楚的需求的有价值的工具，原型与场景的作用类似，向 用户提供一个可以更好理解他们需要提供的信息的上下文。原型技术的范围很广，从纸面的 屏幕模拟设计到软件产品的β版本，原型用于需求获取和用于需求验证，二者之间有很多重 叠（参见主题6.2建立原型）。 （4）恳谈会：目的是试图达到一个综合效果，因为一群人对其软件需求的洞察比与向 单个人了解的要深，他们可以采用头脑风暴，精化其想法，这些想法是使用面谈难以得到的。 另一个优点是，相互冲突的需求出现得早，让干系人能认识到存在冲突。如果组织得好，这 个技术可以比其它技术得到更丰富更一致的需求。但是，需要仔细控制会议（因此，需要一 个推动者），以避免出现小组中批判的能力被对团体的忠诚消蚀，或者出现赞同少数人说出 的需求而损害其他人员。 （5）观察：在组织环境中软件的上下文的重要性，导致修改观察技术来获取需求。软 件工程师通过将自己投入到环境中，观察用户如何与其软件交互或相互交互，来学习用户的 任务。这些技术成本相对高，但却是有益的，因为它们能阐明许多参与者不能轻易描述清楚 的微妙和复杂的用户任务和业务过程。 4 需求分析[Som05] 这个主题涉及分析需求的过程，目的是：（1）检测和解决需求之间的冲突；（2）发现 软件的边界，以及软件与其环境如何交互；（3）详细描述系统需求，以导出软件需求。 需求分析的传统观点是：需求分析被精简为使用多个分析方法中的一个来进行概念建模，这 些方法包括：结构化分析与设计（Structured Analysis and Design Technique，SADT）。 尽管概念建模很重要，我们将需求分类也包括进来，以帮助需求之间的权衡的告知（需求分 类）和建立这些权衡的过程（需求协商）[Dav93]。 描述需求时，必须仔细，应该精确到能确认需求，验证需求的实现，估算需求的成本