当我们购买新的手机、电视或电脑时，我们真的关心它是什么吗？当然不是。我们购买它是为了它能为我们做什么。

同样，当公司或政府购买新的系统或新的企业软件产品时，他们对产品本身并不太在意。他们关心的是这些产品如何帮助他们实现目标，使他们更有效率，并对他们的底线或预算使用产生积极影响。

重要的是产品能做什么。

通常，确定产品功能，也就是它的功能需求的第一步就是确定其功能需求。那么，什么是功能需求？在产品开发中，它们的角色是什么？在本文中，我们将回答这些问题，提供典型的功能需求和需求类型的示例，并提供编写良好的功能需求和功能需求规格的建议。

一、在产品开发中，功能需求是什么？

功能需求是对产品（如系统、子系统、系统组件、设备或软件程序）所必须实现的功能的阐述。功能需求的类型包括（规定）：

• 产品必须执行的操作和工作流（即产品特性的功能细节）
• 产品所接受的输入数据的格式要求，以及产品生成的输出数据的格式和有效性要求。
• 产品用户界面的行为和交互细节。
• 数据完整性和数据安全要求。
• 产品必须符合的安全和监管标准
• 验证用户的身份和权限，以控制其对系统的访问和修改

二、功能需求和非功能需求的区别

功能需求与非功能需求是两个互补的概念。以下是功能需求与非功能需求的定义以及示例：

功能需求：对于产品（如系统、子系统、设备或软件程序）所需实现的功能的描述。例如：控制系统应防止发动机超速。

非功能需求：关于产品的属性、构造方式，以及设计或运行的限制性约束。 示例：系统子系统之间的串行数字通信应通过 MIL-STD-1553B 总线完成。

功能需求

功能需求是关于产品必须执行的任务的描述。换句话说，功能需求定义了产品的操作方式，说明了当给定一组输入时，产品应该如何处理这些输入并生成相应的输出。

随着设计流程的进展，功能需求会逐步细化为更具体的需求。这些细化的需求可以通过各种功能测试（如软件测试、集成测试等）来验证和确认。功能需求是强制性的，也就是说除非需求发生变更，产品必须满足这些功能需求。

非功能需求

非功能需求规定了对产品设计和构造的约束。它们通常受到合同或监管要求的规定，包括但不限于：

• 标准化要求
• 兼容性要求
• 在服务支持要求
• 使用寿命结束时的处置要求

因为非功能性需求通常描述的是产品或系统的性质或属性（如性能、可靠性、安全性等），而不是具体的功能或行为。因此，它们通常不会像功能性需求那样细化为更具体的需求。非功能性需求的验证通常是通过检查产品的设计、实现和操作，以及与之相关的文档（如设计文档、用户手册、运维手册等）。如果产品或系统需要遵守的合同或法规中有明确的非功能性需求（如必须符合某种安全标准），那么这些需求就是强制性的。在消费品开发中，非功能性需求可能更多地来自于公司内部的目标或考虑，如要求产品具有特定的美观度、易用性等。这些需求虽然重要，但通常不是强制性的。

三、功能性需求的格式和示例

功能需求可以有许多形式。然而，有些形式比其他形式更好。有一种普遍的需求工程（RE）最佳实践，它尽可能清晰、简洁地写出需求。

这就是 Alistair Mavin 发明的“简洁需求句法”(Easy Approach to Requirements Syntax EARS) ，他确定了五种需求原型及对应的简单模板，几乎涵盖了实际操作中的所有功能需求规范，可更清晰简洁地描述功能需求。

1.通用性需求

在系统的运行过程中都需要满足的功能需求。它们不受事件或输入调用影响，适用于系统的所有操作状态，而不仅仅是某个特定状态下的需求。

模板：应xxx

示例：控制系统应防止发动机超速。

2.状态驱动需求

状态驱动的功能需求，在定义的状态下都保持为真的整个时间内都处于活动状态。在Mavin的EARS方法中，状态驱动的需求用关键词WHILE标识。

模板：在xxx情况下xxx应xxx

示例：当飞机处于飞行状态且发动机在运行的情况下，控制系统应保持发动机燃油流量高于xx磅/秒。

3.事件驱动需求

事件驱动的需求描述了系统在特定事件发生时应该如何响应和处理。在Mavin的EARS方法中，事件驱动的需求使用关键字“当…时”来标识

模板：当xxx时xxx应xxx

示例：当飞行器发出连续点火指令时，控制系统应启动连续点火。

4.可选性功能需求

可选特性功能需求描述了系统在可选特性启用时，应该如何响应和提供相应的功能。这些需求仅在可选特性作为系统的一部分存在时才适用，并且只有在特定的配置或设置下才会生效。关键字是“在…条件下”

模板：在……条件下..应…

示例：在控制系统具有超速保护功能的条件下，在飞机起飞前，控制系统应测试超速保护功能的有效性。

5.异常行为需求

异常行为需求关注的是系统在异常或错误条件下应如何运行。这包括系统应如何处理错误，如何从错误中恢复，以及如何通知用户或者其他系统关于错误的信息。优秀的设计可以预测并处理这些异常情况，减少对系统的不良影响。

在系统状况不佳或发生异常情况时，通常需要定义异常行为需求。异常行为需求描述了系统应该如何响应触发器（trigger）以处理异常情况。在EARS方法中用“如果，然后…”标记，旨在减轻异常行为需求带来的影响。

模板：“如果xxx，那么xxx”，“应该xxx”

示例：如果计算空速不可用，那么控制系统应使用模型空速

6.复杂需求

在许多情况下，特定事件的触发需要满足一组或多组特定的先决条件，这些条件可以是系统状态或可选功能。只有在这些先决条件被满足之后，系统才能对事件做出相应的响应。EARS模板用一组关键字来标识。

模板：（期望行为）在…情况下…，当…时…, 当…时…应

模板：（异常行为）在…情况下, 当…时…, 如果…应..

示例：当飞机位于地面的情况下，当收到反推力指令时，控制系统应启动反推力装置。

四、编写功能需求的诀窍

编写清晰、准确的功能需求是一项宝贵的工程技能，需要一些实践来发展。这就是为什么许多工程组织编制写作需求的指南，比如由国际系统工程委员会（INCOSE）出版的《编写需求指南》。但是详细列出这些指南超出了本文的范围，但在撰写功能需求时，以下5个重要提示需要记住：

1.使用唯一的ID号或代码对每个需求进行标识。

需求标识符是为了在需求管理过程中识别和追踪特定需求而设定的一种标签或代码。每一个需求都会有一个唯一的标识符，以便在开发过程中追踪需求的状态，以及在后续的维护阶段管理需求变更。

事实上，需求标识符本身往往就是一个需求。例如，大部分政府采购系统的情况下，根据客户和供应商之间的合同购买的系统，通常会按照被接受的行业标准（如IEEE/EIA 12207）进行开发，这是合同的一个规定。这样的标准通常要求每个需求文档中的每个需求都要标上一个项目唯一标识符（PUI）。

为需求分配唯一的标识符对系统开发者有很大的好处。

为每个需求标上一个PUI，可以简化并方便在连续设计级别的需求和验证它们的测试之间的可追溯性。

为每个需求赋予一个简短的独特标识符，有助于创建一种“可追溯性表格”。在这张表格中，每个需求都会与它在更高级别文档中的前序需求以及用于验证它的特定测试明确链接在一起。有了这样的表格，向客户和公司内部的利益相关者展示系统是如何根据最初的顶级需求进行开发，并已经证实符合这些需求的过程就变得更加直观和简单了。这在需求管理和验证阶段是非常重要的。

自动化的需求管理工具通常包括一种自动分配唯一标识符的方法，这使得这个过程变得更加流线化。

2.每个需求描述只写一个需求

要警惕包含”和”字和多个情态动词的长且复杂的需求描述。

当我们试图定义一个复杂的功能时，我们可能会试图将所有的内容都写在一个段落或者一句话里。但这可能会导致混乱，因为这样的长句可能包含多个需求。这句话建议我们将长的需求声明进行分析，看是否包含“和”字或者多个”shall”等情态动词，因为这些可能暗示着这个声明实际上包含了多个需求。为了使每个需求更清晰易懂，我们应该将复杂的长句分解成多个简短的需求声明，每个需求声明只包含一个”shall”，即一个需求。然后，给每个简短的需求声明赋予一个唯一的标识符，以便于追踪和管理。

3.尽可能简洁地写需求声明

分析并重写长的需求的另一个原因，即使那些只有一个”shall”的需求，也是因为长的需求比短的、简洁的需求更可能被误解。

好的SE/RE实践是尽可能简洁地写需求。使用需求模板，比如前面描述的EARS模式，可以在达成这个目标上提供很大的帮助。

用简单明了的语言描述需求，避免使用模糊或专业术语，确保所有相关人员都能理解。

4.确保每个需求都是可测试的

每次你写一个新的功能需求时，你应该问自己以下问题：这个需求的成功实施将如何被验证？

以特定的测试场景为目标编写需求，有助于确保设计工程师和测试工程师理解他们需要做什么。具体的测试用例会影响需求需要的详细程度。高级需求通常通过检查或用户测试来测试，因此可能范围广泛。

通过软件测试或系统集成测试验证的低级需求必然需要更细致的规定。例如，确保可测试性的最佳实践是指定软件必须对特定输入条件产生的任何输出的最大反应时间，如下例：3.8.5.3.1：当等于或超过215° F时，发动机监视器应在0.5秒内将设为TRUE。

5.将需求描述与背景和其他解释区分开

在需求规格书中，所包含的需求的背景、与其他需求的关系，以及为开发者和测试者提供上下文的其他解释是有用的。

上下文可以帮助防止误解，消除可能的模糊性。它可以帮助他人充分理解需求的意图，并提供反馈，帮助精细化需求，使其更加明确。

但是，上下文信息不应包含在需求声明本身。将两者区分开来是很重要的，因为可以保持需求本身的清晰和简洁，并避免使附加信息成为实施和测试的对象。将上下文实现放在不包含唯一标识符的单独段落中是最佳实践。

好的功能需求文档模板或需求管理工具可以使这个目标更容易实现。

五、什么是功能需求文档（FRD）？

功能需求文档（FRD）也称为功能需求规范、功能规范或功能规范文档，它是对更高级别的产品需求文档（PRD）的更技术详细的后续文档。

FRD描述了系统用户所需的内容，通常以系统的输出作为其输入的函数来描述。它旨在在分析和分解PRD中的需求后，提供精确的功能需求以及对开发人员和测试人员的指导。

FRD并未定义要开发的系统的内部工作方式或如何实施系统的功能。相反，它关注的是各种外部代理（用户、外围设备、其他系统或子系统）在与系统交互时应观察到的内容。它传达的信息有：

• 对开发人员：他们需要构建什么
• 对测试人员：他们需要进行什么测试
• 对利益相关者：他们将得到什么的详细描述

对于高度复杂的系统，功能需求可以通过一系列功能规范进行分解，其中可能包括：

• 系统规格说明
• 子系统规格说明
• 系统组件规格说明
• 软件需求规范

在某些行业和组织中，功能规格说明通常是规格说明的其中一部分，包含系统或子系统的非功能需求。然而，非功能性需求通常与功能性需求分开。

六、编写FRD的建议

编写好的FRD不是一件容易的事，以下是一些指南：

1.用层级结构组织文档

用层次结构组织文档有助于理解和使用。层次结构可以包括以下内容：

• 任务/阶段/功能
• 功能/子功能
• 功能/用例

层级结构有以下几个好处：帮助参与者专注于需要解决的每个特定领域、当向现有系统添加功能时，帮助参与者轻松找到需要修改的区域、帮助用户（开发人员、测试人员）快速定位到他们正在寻找的确切功能区域。

2.标准化需求描述

口语中很多多义词，根据上下文，这些词会引发细微的意义差异。虽然这对自我表达非常有利，但这种宽泛的灵活性在规定和解读需求时可能会导致混淆和分歧。

减少需求的不明确和误解的一个好方法是标准化一些用于表达需求的语言。在需求文档的开头就创建一个标准化术语的词汇表。在这个词汇表中，明确定义在文档本身中如何使用某些术语，以及在文档引用的非需求文档中找到这些术语时应如何解释。

严格定义术语并严格遵守你的定义，不仅会减少那些负责解读你的需求的人之间的混淆；随着实践，使用标准化语言也会节省你写需求的时间。

3.使用好的 FRD 模板或专用的需求管理（RM）平台

对于构建任何类型的文档，从一个经过验证的模型开始是明智的，功能需求文档也不例外。

好的模板一般都包括标准化的部分，例如：

• 情态动词使用指南
• 标准化术语表
• 记录需求的指南
• 管理需求文档的指南
• 其他准则

标准化部分，或“样板”有助于保持不同项目之间的的一致性，即使不同项目甚至不同公司，这部分都不会有太大差异。随着方法改进和经验收集，一个组织所使用的模版也会有相应改进和升级。总之，模版可为需求开发、员工教育以及与客户的沟通提供一个稳定的平台。

网络上有很多通用的 FRD 模板。如果贵公司所开发的是商业产品，可以根据以下产品对公司的实践和程序进行定制：

• https://almooc.com/downloads/FRDTemplate.doc
• https://doit.maryland.gov/SDLC/Documents/func_req_doc.doc
• https://www.sampletemplates.com/business-templates/functional-requirement-document.html

七、使用模版的缺点

需要注意，通用文档平台上所使用模板都存在一定缺陷。首先，将需求记录在Word、Excel或腾讯文档中往往会影响协作，因为这些平台没办法提供需求可追溯性。

据Gartner的研究，需求规范一般都缺乏可见性和可追溯性，其中一个主要原因是很多公司都使用通用文档软件而不是协作需求管理平台来管理需求。

根据Gartner 的研究，“通用文档软件（如Microsoft Office或Google Docs）成本较低，便于使用，且广为熟知，仍然在需求工具中占比最大，占市场的40%至50%。使用通用文档很容易导致需求管理不善，最终消除工具本身所具有的任何成本效益。用各种文档和电子表格并辅之以非托管版本的便利贴管理需求时，需求无法被追溯或重用，用户验收测试周期的成本更高。无论是执行期间还是后期发现问题，解决成本都要高得多。”

成功开发、验证和确认好的功能需求对产品成功至关重要。为了实现这些目标，系统、软件、硬件、测试和集成团队必须密切合作，以确保项目的功能需求、非功能需求、测试用例和验证/确认程序都得到了充分定义。可见性和追踪性在此过程中至关重要。

优秀的需求管理（RM）平台可以提供字段、格式和结构关系，有利于：

• 样板部分在不同项目间复用
• 需求定义和识别
• 对更高级别（父）和更低级别（子）需求的可追溯性
• 测试用例的可追溯性

除了这些基本功能，最先进的需求管理平台还会通过允许所有用户访问您的最新需求基线和所有待处理的更改，促进团队协作。这使得需求跟踪、追踪和测试覆盖保证比使用文档或电子表格更容易实现。

了解更多关于PingCode如何简化需求跟踪和追踪的信息。

需求管理指南： 

需求管理： 需求管理主要内容  |  需求管理的重要性  |  采用敏捷方法进行需求管理  | 如何克服需求管理的 5 大挑战  |  更多 

需求编写： 功能需求的示例和模板  |  采用 EARS 方法来改进需求工程  | 如何编写一份优秀的产品需求文档（PRD） |  功能性需求与非功能性需求的区别  | 有效需求的特征  |  更多 

需求收集和管理流程： 需求工程概述  |  产品团队的需求分析指南  | 敏捷产品团队的 11 种需求收集技巧  |  定义和实施需求基线  |  更多  需求的可追溯性：什么是需求可追溯性  |  可追溯性在现代产品和系统开发中的关键作用  | 如何创建和使用需求追溯矩阵  |  更多 

需求确认和验证： 产品团队的需求验证和确认  |  更多