功能需求与非功能需求：示例和类型

缺乏数据、粗略的需求、不确定的业务目标是软件开发项目失败的原因。但是，您绝对有能力解决这些问题。

明确定义项目的功能和非功能需求至关重要，因为这可以让您改进软件开发过程。

在这篇博文中，我们分享了有关编写更好的项目需求如何降低风险和项目成本、提高生产力和取悦客户的信息

让我们开始吧！

软件需求的概念似乎很简单：您选择您的项目将要解决的任何问题，仔细考虑，然后提出相当多的软件需求。

看起来一切都很简单，对吧？但事实并非如此。有很多问题需要讨论：

• 你如何收集需求？

• 您如何评估利益相关者群体的需求和期望？这些要求是否有任何技术限制？

• 您如何确定工作已完成？

这份清单似乎无穷无尽。

在考虑这些时，您会发现软件需求是一个相当广泛的专业领域。这涉及定义需求、需求分析、规范和验证的过程，以及在整个软件开发周期中管理需求的过程。

一些组织雇用一名需求收集人员。但开发需求的责任通常分配给完全不同的专家。业务分析师、产品所有者、经理和开发人员可能会参与此过程。

需求的定义

需求的定义涉及需求的收集和制定。有些要求可以由消费者决定。另一个可以由正在为其开发产品的系统或活动领域定义。

对于项目管理，需求的定义是必不可少的一点。它使您能够确定项目量并设置优先级以满足客户的需求。

什么会影响要求？

您可以使用各种来源收集需求。例如：

• 业务目标；

• 领域知识;

• 利益相关者；

• 商业规则;

• 操作环境。

但请注意，通过确定要求，您应该：

• 特别注意目标。确定需求的优先级并确定实现项目目标的最合理方法。

• 为深入的需求分析模拟真正的挑战。

• 找出不同利益相关者的观点。要求可能相互冲突或重叠。找出不同利益相关者的需求至关重要，尤其是在项目初步规划期间。

• 考虑操作环境。这将取决于组织结构、文化和内部政策。

需求如何影响软件开发过程？

未记录的需求是沟通不畅的常见原因，这会导致返工、更改和错误修复。通常，这会导致截止日期中断和成本急剧增加。

请注意，每个团队成员都应该以相同的方式理解所有项目开发部分。如果您将软件开发外包给不熟悉您的业务的团队，这一点尤其重要。使用软件需求规范，您将确保开发人员能像您一样看到所有功能。

为什么规格和要求很重要？

错误最小化

准确定义的产品需求使开发人员能够在产品开发的早期阶段识别并修复错误。结果，这导致错误和迭代次数的减少。

缩短价值实现时间

减少错误可以减少完成项目和实现投资有效性所需的时间。在竞争激烈的环境中，这可能是一个重要的好处。

削减开发成本

如果时间和材料合同是您选择的选项，那么清晰概述的需求列表可能是一个宝贵的优势。

更好的用户体验

可靠的产品需求使您能够构建一个解决方案，为所有利益相关者带来额外的商业价值。尝试包括用户正在等待的功能。

亚马逊提供对其AVS 产品要求的开放访问，因为 Alexa 的技能开发人员应该熟悉用户期望和产品的关键功能。亚马逊告诉完整的功能性和非功能性需求指南将使开发人员能够提供最佳的用户体验。此外，这可以为所有使用 Alexa 产品的开发人员制定相同的政策和标准。

如果我们没有任何需求管理系统怎么办

没有必要应用特定的系统。您可以采用问题跟踪程序、项目管理工具或版本控制系统来记录您的需求。

但是，如果您根本不写下要求，那么您就是在冒险。

例如，某些功能可能会被省略或未按照您想要的方式实现。

让我们考虑另一个例子。由于您的业务增加，您的软件也将增长。因此，建议在某个地方注意预期的项目持续时间并保持时间安排。

需求分类

需求类别

项目需求通常分为三个主要类别：业务、解决方案和涉众需求。

• 业务需求包括有关客户目标、目标用户和产品总体需求的信息和内容。此时，您应该找出客户希望通过产品实现的目标。由于所有决定都将基于此信息，因此这些要求应尽可能详细。

• 涉众需求假设用户需要什么才能获得良好的产品体验。在此阶段，您应该规划产品地图、布局线框、考虑到达的设备和用例。请注意，利益相关者的需求可能很难竞争。如果管理不当，这会对项目的进度、预算和范围产生负面影响。

• 在解决方案需求阶段，你之前决定的一切都应该根据当前可用的系统进行规划。这种类型的需求包括功能需求和非功能需求。

• 功能需求描述了产品或服务需要做的事情。

• 非功能性需求描述了系统应该如何运行。

什么是功能性和非功能性要求？

清晰的功能和非功能需求可让您降低应用程序开发成本并节省时间。简而言之，功能性和非功能性需求的区别如下：

• 功能需求驱动系统的应用架构，而非功能需求驱动系统的技术架构。这意味着功能需求包括您未来项目的所有功能以及用户参与其中的方式。然而，非功能性需求描述了系统如何工作。

• 通常，功能性需求以“系统必须执行<requirement>”的形式表达，而非功能性需求则以“系统应该是<requirement>”的形式表达。

• 功能需求很容易定义。要识别非功能性需求，您需要分析产品的性能。

Karl E. Wiegers 的下图显示了功能需求和非功能需求之间的关系

什么是功能要求

功能需求定义了软件的内部工作。简而言之，它们描述了应该由网络和应用程序开发人员实现的产品功能。例如，这可以为用户提供通信通道或将数据从一种格式传输到另一种格式。

例如，对罐子的功能要求是它能容纳液体，并有一个带螺纹的盖子顶部以密封果酱以更好地保存

通常，功能需求包括一个唯一的名称和编号、一个简短的描述，以及对需要这些需求的原因的描述。

对于软件开发公司和利益相关者而言，描述应该清晰准确。如果产品不符合功能要求，通常意味着该产品质量低劣。

暂时从阅读切换到视频，看看由华盛顿大学和威斯康星大学创建的功能需求的一些很好的例子。

请注意，即使未满足非功能性要求，也可以认为满足功能性要求。

功能需求部分应包括以下数据：

• 设计范围。由于并非所有项目阶段都同时完成，因此设计范围可能会有所不同。每个开发阶段可能有自己的设计范围。您可以应用的最佳意见之一是用例图。

• 系统功能。要定义所需的系统功能，请考虑用户如何与软件交互以及系统提供什么样的响应。这些东西经常写在用例和 UI 规范文档中。

• 数据定义。您应该定义允许值和默认值、字段长度等。

• 用户类。将使用该软件的人群：客户、访客、员工、管理层或组织的代表。

• 用户界面。屏幕摘要、报告布局和方案。请注意，您应该详细解释每个屏幕的操作方式。

功能需求的主要类型

这些需求可能会出现在功能需求的规范文档中。本文档重点介绍了该软件的主要特性和功能。它可以仅涉及功能需求，也可以涉及用户故事或用例等其他类型。

通常，规范由以下部分组成：

• 目标。在本节中，您应该指定背景、关键定义和系统概述。

• 描述。本节假定了主要功能、产品愿景、业务规则和假设的大纲。例如，您可以定义将用于数据处理的工具并简要描述产品改进策略。

• 具体要求。在这里，我们建议您描述功能、系统属性、数据库特性、连接等。

• 用例。用例定义人机交互的功能和有价值的方面。描述如何在系统中开始工作，它将如何响应用户操作，并概述每个功能用例的场景。

用例规范模板

用例文档通常包括以下几个部分：

• 
  

• 演员。这些用户将与您的软件进行交互。参与者可以是人或系统。但请注意，它们不是系统的一部分。例如，在学习管理系统中，这些参与者可以是访客、学生、员工或管理员。

• 系统。这是描述产品预期行为的功能列表。

• 功能。功能需求指定了每个用户组和系统之间交互所必需的功能。

• 协会。这部分定义了系统的不同特性和相关参与者之间的关系。

• 用户故事。与用例相比，用户故事从用户的角度定义交互。本文档通过考虑所有用户的动机和期望来概述可能的交互。用户故事文档通常采用以下结构：

作为一个<role>，我想要<goal/desire>，这样<benefit>

但较短的版本也很常用：

作为一个<role>，我想要<goal/desire>

示例：作为用户，我想从商店下载应用程序，然后注册/登录、按人名搜索照片、查看照片和更新、设置喜欢以及上传媒体文件。

请注意，有时用例与用户需求不相关。在这种情况下，清晰的用户故事文档使您能够决定哪些用例是必要的。

敏捷开发团队在直观、可视化的积压工作中组织用户故事，也称为用户故事地图。这使人们能够了解系统的功能，并找出差距和遗漏。

• 功能分解或工作分解结构 (WBS)。功能分解是一种可视化文档，可让您将复杂的流程划分为更小的部分。因此，您可以有效地理解和管理复杂的开发流程。此外，您可以更准确地估算项目时间表和成本。或者，如果出现问题，该结构可以让您找出系统的哪一部分出现故障。

各个部分及其层次结构通常以功能分解图的形式呈现，其中包含总体功能和所需的子任务。

功能分解的例子

• 软件原型使您能够阐明项目愿景和开发过程中的主要挑战。原型概述了您的解决方案将如何运行并提供用户与解决方案交互的示例。

原型有两种一般形式：

• 一次性原型。这样的原型是直观地表示需求的快速且廉价的选择。

• 
  

• 增量或一次性原型。这是一个更加复杂和强大的原型，将不断完善和重建。尽管进化原型可能不具备用户计划的所有功能，但它们是功能性系统，甚至可以变成 MVP。

您如何确定功能要求？

在定义功能需求时，我们建议您：

• 描述您需要的功能，而不是您计划应用的工具。

• 请记住用户与系统的交互。

• 关注外观的详细表示，而不是代码设计和实现。

但是，请记住，在记录功能需求时，请使您的语言足够详细。因此，您的开发团队将清楚地了解所需的解决方案以及实施它的所有其他方法。您还应该避免使用技术术语与主题专家建立有效的沟通。

什么是非功能性需求？

非功能性需求指定您的项目、系统或流程的行为方式。这些需求将随着业务需求的变化而创建、更改和调整。

通常，非功能性需求是通过使用类别来组织的：操作性、修订性或过渡性。

这使您能够评估项目的成功、定义重要的用户期望并控制产品质量。

非功能性需求的替代术语是“约束”、“质量属性”、“质量目标”和“服务质量需求”

下面我们将仔细查看基本的非功能性需求列表。

可用性

可用性已被 ISO 定义为在特定的使用环境下，特定用户可以使用产品以达到特定目标的有效性、效率和满意度的程度。简而言之，可用性是用户使用您的产品完成给定任务的难易程度。可用性是基于扎实的研究和测试做出的选择的结果。

请注意以下事项：

• 您的产品应该清晰直观。因此，用户将在第一次交互时熟悉它。

• 产品应该快速引导用户实现他们的目标。

• 仔细执行某些可用性原则可以让您设计出有效、高效且令人愉悦的产品。

法律或监管要求

根据您感兴趣的领域和您的业务重点，可能会有各种法规和法律义务。请注意，违反这些规定可能会受到法律处罚。

法律或法规要求使您能够描述产品对法律的遵守情况。但是您应该熟悉您的产品必须遵守的行业法律。此外，您应该拥有地方当局要求的所有许可证。

例如，在美国，医疗移动应用程序必须符合 HIPAA 要求。基于欧洲的医疗应用程序必须符合通用数据保护条例 (GDPR)。在英国，主要的监管立法是新的数据保护法或 DPA 2018。

可靠性

可靠性是您产品的一项重要的非功能性需求。这通常指定产品是否可以在多次交易或特定时期内无故障运行。

要概述有效的可靠性要求列表，您应该：

• 定义您希望解决方案执行的一致性以及您需要哪些维护和支持以确保它保持这种状态。

• 探索相关解决方案、它们的弱点和功能。

• 分析技术报告、新闻、新行业观点和见解以考虑安全风险。

• 在选择合适的技术堆栈时考虑技术堆栈的常见问题。

表现

性能概述了您的解决方案在各种用户交互场景中的表现。这指定了并发用户数、系统或查询响应时间、系统在内存、磁盘空间和数据量方面的容量。

牛奶包装的 NFR 可以是“一个包装的生产成本不应超过 0.20 美分”

您应该注意的主要挑战清单

• 主观意见。非功能性需求可以由不同的用户以不同的方式定义。确保您的文档包含说明和示例。

• 不一致。非功能性需求可能直接相互矛盾。它们通常会对整个系统产生显着影响。

• 术语不清。混淆定义可能会导致对非功能性需求缺乏理解。

• 假设这个要求是显而易见的。当您创建具有非功能性需求的文档时，有些要点似乎是显而易见的。例如，统计数据应由 Google Analytics 跟踪。通常，许多这些“显而易见”的要求几乎会立即被遗忘。

如何定义非功能性需求

要定义非功能性需求，我们建议您尽早采用最佳实践。您将在下面找到非功能性需求文档的必须实施操作列表。

• 使用定义的分类。这些要求通常分为三组：操作、修订和过渡。

• 使用一组预定义的问题。这使您能够提高开发团队的工作效率并节省时间。

• 与开发团队合作。持续的沟通可以让您与开发团队达成共识。您应该促进需求文档计划会议并安排对话。此外，我们建议您记录并分享您的笔记，并将最终草稿放在文档中。

• 让利益相关者参与进来。尽早与所有相关方讨论非功能性需求。

• 使用模板。比较非功能性需求时，软件产品有很多共同点。因此，收集以前的需求来构建完整的项目图一定会让您受益。特别是如果您的企业专注于电子商务或电子学习应用程序开发。确定您可以在何处重新调整某些需求文档的用途，以将其模板化以供将来在其他项目中使用。

• 考虑用户的反馈。用户的反馈使您能够指定新的功能需求或发现您的一些需求是不相关的。

• 使用最先进的工具。应用自动化测试工具，例如 Selenium、TestComplete、Robot Framework、Xamarin.UITest、Espresso、XCUITest 和 Appium。这些工具将有助于更快地检查您的产品性能并揭示更多非功能性需求。

• 通过开发、测试、维护和扩展过程重新考虑需求。此外，您可以用 1 到 10 的等级评估每个要求。

• 假设利益相关者一无所知。尽可能多地定义。对于每一点，问“为什么”5 次，以确保您编写了正确且合乎逻辑的要求。

笔记。“系统应该易于使用”不是一个合适的可用性要求。您应该通过应用特定指标来指定易于使用的术语。

功能与非功能需求示例

通过真实世界的经验和案例，将更方便地找到功能需求和非功能需求之间的差异。现在，让我们看一下流行的平台和应用程序，考虑如何编写它们的功能和非功能需求。

功能需求和非功能需求之间的区别

上面的信息应该已经满足了你的基本好奇心。为了以最方便的方式找出功能性和非功能性需求之间的区别，让我们仔细看看下表。

简而言之

功能需求和非功能需求之间的区别并不是那么重要。但请注意，应考虑这两种类型。

但我们的经验表明，客户主要考虑的是功能需求。如果他们过去有过糟糕的体验，则非功能性需求已被考虑在内。