软件需求分析
1.1. 软件需求定义
软件需求的最基本含义是一个为了解决真实世界问题而必须展示的特性。指南将需求与软件联系起来，因为需求涉及的是软件要解决的问题。因此，软件需求是一个为解决特定问
题而必须由被开发或被修改的软件展示的特性。这个问题可能是使用软件的某人的任务中的
一个自动化部分，或是支持委托开发软件的组织的业务过程，或修正当前软件的缺点，或是
控制一个设备等等。用户、业务过程和设备的功能通常很复杂，因此，特定软件的需求在外
延上通常是来自一个组织不同层次的不同人员的需求和来自软件将要在其中运行的环境的
需求的复杂组合。
所有软件需求的一个基本特性就是：可验证。验证某些软件需求可能很困难或则成本很
高，例如，验证呼叫中心的吞吐量需求就需要开发模拟软件。软件需求和软件质量人员都必
须保证，可以在现有的资源约束下，需求可以被验证。
1.2 产品和过程需求
可以区别产品参数与过程参数，产品参数是需要开发的软件上的需求（例如，“软件应该验证一个学生在注册一门课程时，已经满足了所有的前提条件”），过程参数本质上是对
软件开发的约束（例如，“软件应该用Ada编写”），过程参数有时也叫过程需求。
一些软件需求可以产生隐含的过程需求，一个例子就是选择验证技术，另外一个例子可
能是要求使用特别严格的分析技术（如形式化规格说明方法）来减少可能导致不适当可靠性
的故障。开发组织、客户或第三方（如安全管理人员）也可能直接提出过程需求
1.3 功能与非功能需求
功能需求描述软件要执行的功能，例如，将某些文本格式化或调制一个信号，功能有时
叫做能力。
非功能需求是限制解决方案的需求，非功能需求有时叫做约束或质量需求，可以进一步
划分为：性能需求、可维护性需求、安全性需求、可靠性需求，以及其它类型的软件需求，
这些主题也在软件质量知识域中讨论
1.4 突发特性
一些需求表现了软件的突发（Emergent）特性，即，这些需求不能由单个组件完成，根
据其满足程度，依赖于所有软件组件之间的互操作。例如，呼叫中心的吞吐量需求可能依赖
于电话系统、信息系统和接线员在实际运行条件下的相互作用。突发特性特别依赖于系统体
系结构[Som05]。
1.5 定量需求
软件需求应尽可能清楚地无二义性地陈述， 可能时，应该定量地陈述。避免含糊和不
可验证的需求非常重要，因为这些需求依赖于主观判断的解释（“软件应该可靠”、“软件
应该用户友好”）。这对于非功能性需求特别重要。下面是两个定量需求的例子：呼叫中心
软件必须增加20%的吞吐量；在运行的任一小时内，系统产生致命错误的概率应该小于
1.0*10-8。吞吐量需求是一个高层次的需求，可以导出许多详细需求，可靠性需求将紧密约
束系统体系结构
1.6 系统需求与软件需求
在这个主题中，系统的含义是“多个元素相互作用的组合，以实现为其定义的目标，元
素包括：硬件、软件、固件、人员、信息、技术、设施、服务和其它支持元素”，这是国际
系统工程理事会的定义(INCOSE00)。
系统需求是对整个系统的需求，在包含软件组件的系统中，软件需求是从系统需求中导
出的。关于需求的文献有时将系统需求称为“用户需求”。本指南将“用户需求”严格定义
为系统客户或终端用户的需求。这样，系统需求包括：用户需求，其它干系人的需求（如管
理层），以及没有可标识的人类来源的需求。
1.4 突发特性
一些需求表现了软件的突发（Emergent）特性，即，这些需求不能由单个组件完成，根
据其满足程度，依赖于所有软件组件之间的互操作。例如，呼叫中心的吞吐量需求可能依赖
于电话系统、信息系统和接线员在实际运行条件下的相互作用。突发特性特别依赖于系统体
系结构[Som05]。
1.5 定量需求
软件需求应尽可能清楚地无二义性地陈述， 可能时，应该定量地陈述。避免含糊和不
可验证的需求非常重要，因为这些需求依赖于主观判断的解释（“软件应该可靠”、“软件
应该用户友好”）。这对于非功能性需求特别重要。下面是两个定量需求的例子：呼叫中心
软件必须增加20%的吞吐量；在运行的任一小时内，系统产生致命错误的概率应该小于
-8
1.0*10。吞吐量需求是一个高层次的需求，可以导出许多详细需求，可靠性需求将紧密约
束系统体系结构[Dav93; Som05]。
1.6 系统需求与软件需求
在这个主题中，系统的含义是“多个元素相互作用的组合，以实现为其定义的目标，元
素包括：硬件、软件、固件、人员、信息、技术、设施、服务和其它支持元素”，这是国际
系统工程理事会的定义(INCOSE00)。
系统需求是对整个系统的需求，在包含软件组件的系统中，软件需求是从系统需求中导
出的。关于需求的文献有时将系统需求称为“用户需求”。本指南将“用户需求”严格定义
为系统客户或终端用户的需求。这样，系统需求包括：用户需求，其它干系人的需求（如管
理层），以及没有可标识的人类来源的需求。
1.4 突发特性
一些需求表现了软件的突发（Emergent）特性，即，这些需求不能由单个组件完成，根
据其满足程度，依赖于所有软件组件之间的互操作。例如，呼叫中心的吞吐量需求可能依赖
于电话系统、信息系统和接线员在实际运行条件下的相互作用。突发特性特别依赖于系统体
系结构[Som05]。
1.5 定量需求
软件需求应尽可能清楚地无二义性地陈述， 可能时，应该定量地陈述。避免含糊和不
可验证的需求非常重要，因为这些需求依赖于主观判断的解释（“软件应该可靠”、“软件
应该用户友好”）。这对于非功能性需求特别重要。下面是两个定量需求的例子：呼叫中心
软件必须增加20%的吞吐量；在运行的任一小时内，系统产生致命错误的概率应该小于
-8
1.0*10。吞吐量需求是一个高层次的需求，可以导出许多详细需求，可靠性需求将紧密约
束系统体系结构[Dav93; Som05]。
1.6 系统需求与软件需求
在这个主题中，系统的含义是“多个元素相互作用的组合，以实现为其定义的目标，元
素包括：硬件、软件、固件、人员、信息、技术、设施、服务和其它支持元素”，这是国际
系统工程理事会的定义(INCOSE00)。
系统需求是对整个系统的需求，在包含软件组件的系统中，软件需求是从系统需求中导
出的。关于需求的文献有时将系统需求称为“用户需求”。本指南将“用户需求”严格定义
为系统客户或终端用户的需求。这样，系统需求包括：用户需求，其它干系人的需求（如管
理层），以及没有可标识的人类来源的需求。
2.1 过程模型
这个主题的目的是提供对需求过程的如下理解：（1）需求过程不是软件生命周期中的
一个离散的从头到尾（front-end）的活动，而是一个过程，开始于项目的起始阶段，并在
整个生命周期中需要持续精化。（2）需求过程要将软件需求标识配置项，并使用与其它软
件生命周期过程的产品相同的软件配置管理实践来管理软件需求。（3）需求过程需要与组
织和项目上下文保持适应。
2.2 过程参与者
这个主题介绍参与需求过程的人员的角色。需求过程本身是交叉学科的需求专家需要在
干系人和软件工程师之间进行协调。除了需求专家外，有许多人员参与，每个人都与软件有
某种干系。随项目不同，干系人也不同，但总是包括：用户/操作人员和客户（二者可以不
同）[Gog93]。软件干系人的典型例子包括（但不局限于）：（1）用户：这个群体由将要操
作软件的人员组成，通常是一个杂合群体，包含有不同角色和需求的人员。（2）客户：这
个群体由委托软件开发的人员和代表软件的目标市场的人员组成。（3）市场分析师：大众
市场产品不止一个委托方，因此需要市场营销人员来确定市场的要求和作为代理客户。（4）
管制人员：许多应用领域，如银行和公共运输，是被政府管制的，这些领域的软件必须遵从
管制当局的需求。（5）软件工程师：这些人员对从软件开发中通过复用其它产品的组件而
获利感兴趣，在这种情形下，如果特定产品的用户有复用组件的特殊需求，软件工程师必须
权衡自身的利益和客户的利益。
满足所有干系人的需求，通常是不可能的，软件工程师的任务就是协调各种权衡，使之
能被主要的干系人接受，并能满足预算、技术、管制规则和其它约束。作到这一点的前提是，
已经标识了所有干系人，分析了他们的利益本质，获得了他们的需求
2.3 过程支持与管理
这个主题介绍需求过程需要和消耗的管理资源，它为软件工程管理知识域的第一个子域
（启动和范围定义）建立上下文，它的主要目的是建立2.1中标识的过程活动与成本、人力
资源、培训和工具等问题之间的联系
2.4 过程质量与改进
这个主题涉及需求过程的质量评定和改进，其目的是强调需求过程在软件产品的成本和
准时性方面、客户对需求过程的满意度方面所起的关键作用[Som97]。它有助于需求过程适
应软件和系统的质量标准和过程改进模型。过程质量和改进与软件质量知识域和软件工程过
程知识域都密切相关，特别是软件质量属性和度量的问题，以及软件过程定义的问题。这个
主题覆盖下列问题：（1）过程改进标准和模型覆盖的需求过程范围；（2）需求过程度量与
基准；（3）改进的计划与实现
3 需求获取
需求获取涉及软件需求来自何方，软件工程师如何收集它们。这是理解需要软件解决的
问题的第一阶段，这是本质是一个人类活动，活动中要标识干系人，建立开发小组与客户之
间的联系。需求获取又称为“需求捕获”、“需求发现”和“需求获得”。
良好的软件工程的一个基本原则就是，软件工程师与软件用户之间有良好的沟通。在开
发活动开始前，需求专家必须为这个沟通建立渠道，他们必须协调软件用户（及其它干系人）
的业务领域和软件工程师的技术领域。
3.1 需求来源
（1）目标：术语“目标”（有时称为“业务关注”或“关键成功因素”）指的是软件
总体的、高层次的目标。目标为软件提供了动机，但通常被含糊地表达。软件工程师需要特
别注意评定目标（相对与优先权）的价值和成本，一个低成本的评定方法是可行性研究
[Lou95]。
（2）领域知识：软件工程师需要获得或具有关于应用领域的知识，这样，能够推导出
干系人没有清楚说明的隐性知识，能够评定相互矛盾的需求之间的必要的权衡，并作为“用
户”支持者。
（3）干系人（参见2.2过程参与者）：由于过分强调了一部分干系人的需求而牺牲了其
它干系人的需求，许多软件的结果不令人满意。因此，交互的软件难以使用，或违反了客户
组织的文化或政策结构。软件工程师需要标识、描绘和管理很多不同类型的干系人的视点
（4）运行环境：需求能够从软件将要运行的环境中导出。例如，实时软件的定时约束、
办公环境中的互操作约束。必须主动地寻找这些需求，因为它们可能对软件的可行性和成本
有重大影响，并限制设计的选择[Tha97]。
（5）组织环境：通常要求软件支持某个业务过程，业务过程的选择受组织的结构、文
化和内部策略的限制。软件工程师对这些事情应该敏感，因为，一般要求新的软件不能对业
务过程施加没有计划的变更。
3.2 获取技术
一旦标识了需求来源后，软件工程师就开始从需求来源获取需求。这个主题主要是让人
类干系人清晰地表达他们的需求的技术。这是一个非常困难的领域，软件工程师需要记住这
个事实（例如）：用户可能难以描述他们的任务，可能遗漏重要的信息，可能不愿意或不能
够合作。特别重要的是，需要理解，获取不是一个被动的任务，即使干系人愿意合作并能清
晰表达其任务，软件工程师也必须努力工作，以获取正确的信息。有大量的需求获取技术，
下面是主要的几个[Gog93]。
（1）面谈：这是一个“传统”的获取需求的方法。了解面谈的优点和限制，以及如何
引导面谈，非常重要。
（2）场景：这是一个为获取用户需求提供上下文的有价值的工具，场景让软件工程师
为有关用户任务的问题提供一个框架，允许提出“如果…那么…”和“这是如何做的”之类
的问题。场景最普通的类型就是用况，这里提供一个到主题4.2（概念建模）的指示器，因
为用况和用况图等场景符号在概念建模中很普通。
（3）原型：这是一个阐明不清楚的需求的有价值的工具，原型与场景的作用类似，向
用户提供一个可以更好理解他们需要提供的信息的上下文。原型技术的范围很广，从纸面的
屏幕模拟设计到软件产品的β版本，原型用于需求获取和用于需求验证，二者之间有很多重
叠（参见主题6.2建立原型）。
（4）恳谈会：目的是试图达到一个综合效果，因为一群人对其软件需求的洞察比与向
单个人了解的要深，他们可以采用头脑风暴，精化其想法，这些想法是使用面谈难以得到的。
另一个优点是，相互冲突的需求出现得早，让干系人能认识到存在冲突。如果组织得好，这
个技术可以比其它技术得到更丰富更一致的需求。但是，需要仔细控制会议（因此，需要一
个推动者），以避免出现小组中批判的能力被对团体的忠诚消蚀，或者出现赞同少数人说出
的需求而损害其他人员。
（5）观察：在组织环境中软件的上下文的重要性，导致修改观察技术来获取需求。软
件工程师通过将自己投入到环境中，观察用户如何与其软件交互或相互交互，来学习用户的
任务。这些技术成本相对高，但却是有益的，因为它们能阐明许多参与者不能轻易描述清楚
的微妙和复杂的用户任务和业务过程。
4 需求分析
这个主题涉及分析需求的过程，目的是：（1）检测和解决需求之间的冲突；（2）发现
软件的边界，以及软件与其环境如何交互；（3）详细描述系统需求，以导出软件需求。
需求分析的传统观点是：需求分析被精简为使用多个分析方法中的一个来进行概念建模，这
些方法包括：结构化分析与设计（Structured Analysis and Design Technique，SADT）。
尽管概念建模很重要，我们将需求分类也包括进来，以帮助需求之间的权衡的告知（需求分
类）和建立这些权衡的过程（需求协商）[Dav93]。
描述需求时，必须仔细，应该精确到能确认需求，验证需求的实现，估算需求的成本。
4.1 需求分类[Dav93; Kot00; Som05]
需求可以在多个维度上分类，下面是一些例子：
（1）需求是功能性的还是非功能性的（参见主题1.3功能与非功能需求）。
（2）需求是从一个或多个高层次需求或突发性特性（参见主题1.4突发特性）导出的，
还是由干系人或其它来源直接施加在软件上的。
（3）需求是针对产品的还是过程的。对过程的需求可以约束合同商的选择、软件工程
过程的采用、要遵循的标准。
（4）需求的优先性。一般，优先性越高，需求对于满足软件的总体目标就越基本。通
常用固定尺度进行分类，如：强制的、特别需要的、需要的、可选的。优先性通常要与开发
和实现的成本进行平衡。
（5）需求的范围。范围指的是需求影响软件和软件组件的程度。一些需求，特别是一
些非功能性需求，具有全局范围，因为对这些需求的满足不能分配到某一个离散的组件。因
此，全局性需求可能强烈地影响软件的体系结构和许多组件的设计，范围小的需求对于满足
需求没有多少影响。
（6）易变性/稳定性。一些需求在软件生命周期内将发生变化，甚至在开发过程本身中
发生变化。估计需求可能发生的变化概率，是有用的。例如，在银行应用中，对客户帐户计
算和除息功能的需求可能比支持特定类型的免税帐户的需求更稳定，前者反映了银行领域的
一个基本特征（帐户可以有利息），后者可能由于政府的法规而被废止。标记潜在的易变需
求，有助于软件工程师建立一个更容许变化的设计。
也可以采用其它适当的分类，这取决于组织的平常实践和应用本身。
需求分类和需求属性之间有较大的重叠 。
4.2 概念建模
开发真实世界问题的模型是软件需求分析的关键，模型的目的是帮助理解问题，而不是
启动方案的设计。因此，概念模型由来自问题域的实体模型组成，实体模型反映了它们的真
实世界联系和依赖。可以开发几类模型，包括：数据和控制流、状态模型、事件追踪、用户
交互、对象模型、数据模型，以及其它模型。影响模型选择的因素有：
（1）问题的本质：一些类型的软件要求某些方面的分析特别严格，例如，控制流和状
态模型对于实时软件来说，就比管理信息软件重要得多，后者通常使用数据模型。
（2）软件工程师的技能：采用软件工程师有经验的建模符号或方法，具有更高的生产
率。
（3）客户的过程需求：客户可能要求使用其喜欢的符号或方法，或者禁止使用其不熟
悉的方法。这个因素与前面一个因素是冲突的。
（4）方法和工具的可用性：尽管适合于某些特定的问题，培训和工具不常支持的符号
或方法可能不被广泛接受。
注意，几乎所有情况下，从构造软件的上下文模型开始，是有用的。软件上下文提供了
打算开发的软件与其外部环境之间的联系，这对于理解软件运行环境中的软件上下文，对于
标识软件与环境的接口，都很关键。
建模问题与方法紧密联系，对于实用目的，方法是由引导符号应用的过程支持的一个符号（或
一组符号）。几乎没有经验迹象表明一个符号对另一个符号的优越性。但是，特定方法和符
号的广泛接受可能导致工业界的技能和知识的聚集，这就是目前UML（统一建模语言）情况
(UML04)。
4.3 体系结构设计与需求分配
在某些时候，必须导出方案的体系结构。体系结构设计是需求过程与软件或系统设计重
叠时进行的，这说明将二者截然分开是不可能的。本主题与软件设计知识域的软件
结构与体系结构子域紧密联系。在许多情况下，软件工程师要作为软件体系结构师，因为分
析和详细阐明需求的任务，要求标识负责满足需求的组件。这是一个需求分配：将满足需求
的责任分配到组件上。
分配对于需求的详细分析很重要，例如，一旦将一组需求分配给一个组件，就可以进一
步分解单个需求，以发现有关组件需要如何与其它组件交互以满足分配的需求的更深入的需
求。在大型项目中，分配刺激新一轮的对子系统的分析，例如，对轿车的特定刹车性能的需
求（刹车距离、恶劣驾驶条件下的安全性、应用的平滑性、需要的踏板压力等），可以分配
给刹车硬件（机械和液压组件）和一个反锁定的刹车系统（ABS）。只有在标识了一个反锁
定的刹车系统，并将需求分配给它后，才能使用ABS的能力、刹车硬件和突发特性（如轿车
重量）等来标识详细的ABS软件需求。
体系结构设计与概念建模差不多，从真实世界领域实体到软件组件的映射并不总是显然
的，因此将体系结构设计标识为一个独立的主题。对于概念建模和小、体系结构设计，二者
对于符号和方法的需求广泛地相同。
4.4 需求协商
本子主题中另一个普遍使用的术语是“解决冲突”。这涉及需求冲突的问题，冲突发生在两
个干系人需要不兼容的特征，或者发生在需求与资源之间A，或者在功能与非功能需求之间
。多数情况下，软件工程师作出单边的决定是不明智的，与干系人协商达成
适当的权衡，就有必要。从合同的原因上，这样一个决定应该追溯到客户。我们将需求协商
分类为一个软件需求分析主题，是因为问题是作为分析的结果出现的。但是，也可以将其作
为需求确认的一个主题。
5 需求规格说明
对于许多工程职业，术语“规格说明”指的是将数值或限制分配给产品的设计目标(Vin90)。
一般的物理系统的值的数目相对少，而通常软件却有大量的需求，在完成数量化和管理大量
需求的复杂的相互作用之间有相同的重点。在软件工程术语中，“软件需求规格说明”一般
指产生一个文档或其电子版本，以便系统地评审、评价和批准。对于复杂的系统，特别是涉
及许多非软件组件的系统，最多要产生3类文档：系统定义、系统需求和软件需求。对于简
单的软件产品，只需求软件需求文档。下面描述所有3类文档，需要指出，它们应该适当组
合。
5.1 系统定义文档
这个文档（有时称为用户需求文档或操作概念）记录系统的需求，它从领域角度，定义
高层系统需求，其读者包括系统用户/客户代表（对于市场驱动的软件，市场人员可以担任
这些角色），因此，它的术语必须采用领域术语。文档需要列举系统需求，以及有关系统总
体目标的背景信息、系统的目标环境，以及对约束、假设和非工程需求的陈述。它也可以包
括设计用于说明系统上下文的概念模型、使用场景和主要的领域实体，还包括数据、信息和
工作流。
5.2 系统需求规格说明
开发包含许多软件和非软件组件的系统（例如，现代民航客机）的人员，通常将系统需
求描述与软件需求描述分开。按这个观点，首先规格说明系统需求，软件需求从系统需求导
出，然后为每个软件组件的需求进行规格说明。严格地讲，系统需求规格说明是一个系统工
程活动，不属于本指南的范围。IEEE1233标准是一个开发系统需求的指南(IEEE1233-98)。
5.3 软件需求规格说明[Kot00; Rob99]
软件需求规格说明为客户和合同商或供应商（对于市场驱动的项目，这些角色可以有市
场人员和开发部门担任）之间达成的一致建立了基础：软件产品要做什么，软件产品不应该
做什么。对于非技术领域读者，除了软件需求规格说明文档，通常还需要软件需求定义文档。
软件需求规格说明允许在设计开始之前，对需求进行严格的评定，以减少以后的重新设
计工作，它也为估算产品的成本、风险和进度提供一个现实的基础。组织结构也可使用软件
需求规格说明文档来更有效地开发自己的确认和验证计划。
软件需求规格说明为将软件产品传递到新用户或新机器提供了一个信息基础。最后，它
为软件的增强也提供一个基础。
软件需求通常用自然语言编写，但是对于软件需求规格说明，需要用形式化或半形式化
描述离开补充。选择适当的符号，可以更精确更简明地描述软件体系结构的特定需求和特定
方面。一般的规则是，使用的符号应该尽可能简明地描述需求，这对于某些安全性要求很高
的软件，以及某些对其依赖性强的软件，特别重要。但是，符号的选择通常受培训、技能和
文档的作者与读者的限制。
已经有了大量的质量指标，用于将软件需求规格说明的质量与产品的其它属性联系起
来，诸如成本、可接收性、性能、进度、可重现性等。单个软件需求规格说明语句的质量指
标包括：祈使语气、引导语句、弱短语、选项和连续性。整个软件需求规格说明文档的指标
包括：篇幅、可读性、规范、深度和文本结构(Ros98)。
6 需求确认
需求文档需要经过确认和验证过程。确认需求以保证软件工程师已经理解了需求，验证
需求文档遵从公司标准，并且是可理解的、一致的和完备的，也很重要。形式化符号在（严
格地说，至少）证明后面两个特性方面具有很强的优点。不同的干系人，包括客户和开发人
员代表，应该评审文档。需求文档与软件生命周期过程中其它可交付产品一样，要由软件配
置管理来管理(Bry94, Ros98)。
通常需要在需求过程中明确一个或多个点，以进行需求的确认。目标是分配资源给需求
之前，发现存在的问题。需求验证涉及检查需求文档，以保证它确实定义了正确的软件（即，
这是用户期望的软件）。
6.1 需求评审[Kot00; Som05; Tha97]
最普通的确认手段可能就是检查或评审需求文档，分配一组评审人员简要地检查是否存
在：错误、不正确的假设、阐述不清楚、与标准不一致等。引导评审的小组的组成很重要（例
如，对于市场驱动的产品，至少应该包括一个来自客户的代表），小组可以提供检查清单中
应该出现的内容。
在系统定义文档、软件需求规格说明文档、新发布版本的基线规格说明或过程中任何其
它步骤完成时，应该进行评审。IEEE1028标准提供了如何进行评审的指导(IEEE1028-97) 。
6.2 建立原型[Dav93; Kot00; Som05; Tha97]
原形是确认软件工程师对软件需求的解释、获取新需求的常用手段。就获取需求而言，
有大量的原型技术，在过程中也有大量的检查点可以使用原型确认。原型的一个优点是：它
使得解释软件工程师的假设变得容易，并能在需要的时候，给出有用的反馈，说明一些假设
为什么不正确。例如，使用动画原型比文本描述或图形模型，能更好地理解用户界面的动态
行为。但是，原型也有缺点。由于原型的外观或质量问题，它可能将用户的注意力从基础的
核心功能转移到其它方面。因此，一些人推荐不使用软件的原型，例如基于翻动图表的模拟。
开发原形的成本可能会高。但是，如果原型能够避免由于试图满足错误的需求而浪费的资源，
这些成本也是值得付出的。
6.3 模型确认[Dav93; Kot00; Tha97]
在分析时，通常有必要确认开发的模型的质量。例如，在对象模型中，进行静态分析，
验证对象之间存在通信路径（在干系人领域，就是交换数据），就有用处。如果使用了形式
化规格说明符号，就有可能使用形式化推理来证明规格说明特性。
6.4 接收测试[Dav93]
软件需求的一个本质特性就是，应该能够确认完成的产品满足需求。不能被确认的需求
实际上仅仅是“愿望”。因此，一个重要的任务就是计划如何确认每个需求，在多数情况下，
设计接收测试来完成这个任务。标识和设计非功能需求（参见主题1.3功能与非功能需求）
的接收测试可能比较困难，为了确认它们，必须分析它们，用定量的形式描述它们。
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]。ISO/IEC的标准和
其它标准描述了特定的FSM方法。
