软件产品设计-功能请求示例和模板

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

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

重要的是产品的功能。

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

1. 产品开发中的功能需求有哪些？

功能需求是关于产品（例如系统、子系统、系统组件、设备或软件程序）必须执行的功能的陈述。功能需求的类型包括（请指定）：

2.功能需求与非功能需求的区别

功能需求与非功能需求是两个相辅相成的概念，以下是功能需求与非功能需求的定义及示例：

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

非功能性要求：产品的属性、构造方式以及设计或操作的限制。例如：系统子系统之间的串行数字通信应通过 MIL-STD-1553B 总线实现。

功能要求

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

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

非功能性需求

非功能性需求指定了对产品设计和构造的限制。它们通常由合同或监管要求决定，包括但不限于：

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

3.功能需求的格式和示例

功能需求可以采用多种形式。但是软件产品设计，有些形式比其他形式更好。有一种通用的需求工程 (RE) 最佳实践，即尽可能清晰简洁地编写需求。

这就是Alistair Mavin发明的“需求语法简易方法EARS”，他确定了五种需求原型和对应的简易模板，几乎涵盖了实际操作中所有的功能需求规范，能够更加清晰简洁地描述功能需求。

1. 一般要求

系统运行过程中需要满足的功能需求，不受事件或输入调用的影响，适用于系统所有运行状态软件产品设计，而不仅仅是某一特定状态下的需求。

模板：应该 xxx

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

2. 国家驱动的要求

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

模板：在 xxx 情况下 xxx 应该 xxx

示例：当飞机飞行且发动机运转时，控制系统应将发动机燃油流量保持在 xx 磅/秒以上。

3. 事件驱动的要求

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

模板：当xxx时，xxx应该xxx

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

4. 可选功能要求

可选功能功能要求描述了当可选功能启用时系统应如何响应并提供相应的功能。这些要求仅适用于可选功能作为系统的一部分存在的情况吉祥物设计，并且仅适用于特定的配置或设置。关键词是“在以下条件下……”

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

例如：若控制系统具有超速保护功能，则控制系统应在飞机起飞前测试超速保护功能的有效性。

5. 异常行为要求

异常行为要求关注系统在异常或错误情况下应如何运行。这包括系统应如何处理错误、如何从错误中恢复以及如何将错误通知用户或其他系统。良好的设计可以预测和处理这些异常情况，并减少对系统的不利影响。

当系统状况不佳或出现异常情况时，通常需要定义异常行为需求。异常行为需求描述系统应如何响应触发事件以处理异常情况。在 EARS 方法中，它以“如果，那么……”为标记，以减轻异常行为需求的影响。

模板：“如果 xxx，则 xxx”、“应该 xxx”

例如：如果没有计算空速，则控制系统应使用模型空速

6. 复杂的要求

很多时候，触发特定事件需要满足一个或多个特定前提条件，这些前提条件可以是系统状态或可选功能。只有满足这些前提条件后表情包设计，系统才能对事件做出相应的响应。EARS 模板由一组关键字标识。

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

模板：（异常行为）在…的情况下，当…时，如果…应该…

示例：当飞机在地面时，控制系统应在收到反推力命令时启动反推力装置。

编写功能需求的技巧

编写清晰、准确的功能需求是一项宝贵的工程技能，需要经过一些练习才能掌握。这就是为什么许多工程组织都会制定编写需求的指南，例如国际系统工程理事会 (INCOSE) 发布的《编写需求指南》。虽然详细列出这些指南超出了本文的范围，但以下是在编写功能需求时需要牢记的 5 个重要提示：

1. 使用唯一的 ID 号或代码来识别每个需求。

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

事实上，需求标识符往往本身就是一个需求。例如，在大多数政府采购系统中，客户与供应商签订合同所采购的系统通常是按照公认的行业标准（如IEEE/EIA 12207）作为合同要求来开发的。此类标准通常要求每个需求文档中的每个需求都标有项目唯一标识符（PUI）。

为需求分配唯一的标识符对于系统开发人员来说具有显著的好处。

使用 PUI 标记每个需求可简化并促进连续设计级别的需求与验证它们的测试之间的可追溯性。

为每个需求赋予一个简短的唯一标识符有助于创建一种“可追溯性表”，其中每个需求都明确链接到更高级别文档中的前一个需求以及用于验证它的特定测试。有了这样的表格，向客户和内部利益相关者展示系统是如何根据原始顶级需求开发的，并被证明满足这些需求变得更加直观和简单。这在需求管理和验证阶段非常重要。

自动化需求管理工具通常包括自动分配唯一标识符的方法，从而使该过程更加简化。

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

警惕包含单词“和”以及多个情态动词的长而复杂的需求描述。

当我们试图定义一个复杂的特性时，我们可能会试图把所有内容放在一个段落或一句话中。但这可能会导致混乱，因为这么长的句子可能包含多个要求。这句话建议我们分析长需求陈述，看看它是否包含单词“and”或多个情态动词，如“shall”，因为这些可能暗示该陈述实际上包含多个要求。为了让每个要求更清晰、更容易理解，我们应该把复杂的长句分解成多个短需求陈述，每个短需求陈述只包含一个“shall”，也就是一个要求。然后，给每个短需求陈述一个唯一的标识符，以便于跟踪和管理。