需求：功能性与非功能性

admin管理员组

文章数量:1441147

需求：功能性与非功能性

1. 简介

我们可以将计算机科学视为通过计算解决现实世界问题的艺术。因此，计算机科学家或广义上的软件开发人员的相关能力之一是将现实世界抽象为能够解决特定问题的计算模型。

反过来，抽象模型是基于与开发中软件的利益相关者一起定义的一系列需求构建的。这些需求定义了输入和输出之间的所需关系，确定了最终产品质量期望的计算过程。

在本教程中，我们将研究软件开发中的需求。首先，我们将检查需求的定义及其类别。因此，我们将详细了解什么是功能性和非功能性需求。接下来，我们将看到一些用于定义需求的技术。最后，我们将回顾所研究的概念，同时在系统摘要中进行比较。

2. 需求

简而言之，根据著名的商业分析知识体系（BABOK），需求是要求或期望的表示。因此，在软件开发环境中，我们将需求视为软件产品必须执行的一组需求。

但是，需求适合多个上下文并具有多个类别。其中最相关的是：

• 业务：包括有关组织问题和目标的高级陈述，例如增加收入或削减支出
• 利益干系人：指选定的利益干系人群体（如最终用户或组织高管）对产品的期望。它将业务需求与解决方案联系起来
• 解决方案：确定产品必须具有的特定特征，包括功能（实际功能）和非功能（产品的一般属性是什么）方面
• 转换：指定利益相关者从当前场景迁移到采用开发产品的场景的操作，例如是否需要特定培训来操作它

在本教程的上下文中，我们将通过探索解决方案需求的函数类和非函数类来重点调查解决方案需求的类别。

3. 功能需求

功能需求是编程团队在开发软件产品时实现的功能。更具体地说，我们可以将功能需求视为软件解决方案完成的计算以及它使用、处理和生成数据的方式：它们描述了软件的作用。

定义功能需求是软件开发过程的强制性阶段。此类需求通常来自开发中解决方案的未来运营商建立的用例。因此，开发团队分析这些情况，将它们映射到软件功能并确定必要的实现技术。

有几类功能需求。其中，有必要突出以下几类：

• 身份验证：关于在开发的解决方案和系统中识别操作员的方式，甚至是信息。
• 授权级别：与应用于操作员的异构特权和限制有关。例如，它指定谁可以对解决方案执行 CRUD（更改、读取、更新或删除）操作
• 外部接口：与解决方案的外部接口有关的问题，这些接口使其能够与其他解决方案、系统和用户进行通信
• 事务处理：关于分析和操作事务的方法，例如输入、修改、删除和取消
• 合规性：与软件解决方案将要工作的组织必须遵守的法律、法规和策略相关
• 数据库：指要存储的数据以及执行此操作的格式规则

当然，还有其他类别的功能需求，如备份、恢复、审核、归档等。但是，它们用于具有需要它们的特定特征的系统。顺便说一下，没有绝对强制性的功能需求类别;我们应该根据每个软件项目的必要性来定义它们。

4. 非功能性需求

总之，非功能性需求是指表示软件解决方案质量期望的属性和属性。非功能性需求集在很大程度上取决于软件提交到的特定执行方案。

指定非功能性需求根本不是强制性任务。我们只能通过一组功能需求来开发软件。但是，该软件解决方案将在尽力而为的模型中工作，而不考虑任何性能参数期望。

但是，当我们谈论性能期望时，我们指的是哪些参数？

我们可以考虑多个参数。这些参数与不同的非功能性需求类别相关。因此，让我们检查最常见的类别及其参数：

• 可用性：关于使用该软件的学习曲线有多尖锐。此类别包括感知工作负载、使用效率和直观性等参数
• 安全性：与软件解决方案如何保护数据有关。此类别的参数包括攻击情况下的权限策略、健壮性和复原能力
• 可靠性：关注软件解决方案如何避免和解决故障。示例参数是我们在给定执行时间的情况下承认组件中发生故障的最大概率
• 性能：在用户与软件交互时关注软件的响应能力。在这种情况下，参数的最常见示例是请求的每个操作的最大允许响应时间
• 可用性：与软件解决方案可供使用的总时间有关。参数是最大维护时间和恢复潜在错误场景的最长时间
• 可扩展性：与增加或减少软件功能有关，而不会影响其性能。定义支持的最小和最大用户数是可伸缩性参数的一个示例

最后，我们按需定义非功能性需求。因此，我们没有最小或最大类别和参数集。

5. 需求规范策略

我们在名为软件需求规范 （SRS） 的文档中指定软件解决方案需求。SRS 可以包括功能性和非功能性需求，并将作为开发团队的指南。

我们可以仅基于纯文本编写SRS文档，甚至可以使用额外的资源，例如用例图和用户故事。无论如何，SRS最相关的是，从未来的用户到技术团队，参与软件开发的所有人都应该可以访问和解释它。

SRS 文档必须至少包含三个部分：

• 目的，包括所需软件解决方案的通用概述以及任何背景信息和以前的定义
• 描述，介绍系统采用的假设、约束和策略
• 需求，包含功能和非功能需求的规范以及有关它们的详细信息

让我们在以下小节中简要了解 SRS 文档中用于描述软件及其需求的一些常用资源。

5.1. 用例图

用例图经过定制，用于确定软件解决方案与其操作员和管理员的交互。我们在这些图中有三个主要实体：

• 参与者：软件解决方案的操作员和管理员的代表
• 系统：将功能需求表征为软件解决方案的预期行为
• 目标：描述参与者与系统交互的目的

用例图最常见的表示形式是在定义先前呈现的实体之间关联的图表上。下图显示了此类关系图的示例：

5.2. 用户故事

用户故事还旨在确定所需的软件解决方案。但是，它侧重于最终用户视角，定义他们想要执行的内容以及他们必须在解决方案中访问哪些数据。

用户情景由自由文本组成，但他们通常考虑如下所示的格式：

我，作为一个<类型的用户>，目标是<目标>以便<理由>。

此外，每个用户故事都可以与验收标准列表相关联，该列表提供了利益相关者在软件解决方案中实现用户故事所需的特征。验收标准也被定义为自由文本;最佳验收标准列表非常简洁且可测试，可作为开发人员的清单。

6. 系统总结

功能性和非功能性需求是任何软件开发团队的基本资源。功能需求决定了所有必要的功能，而非功能需求提供了这些功能在软件解决方案中必须如何工作的性能参数。

考虑到前面的定义，我们可以说定义功能需求是一个强制性的过程。另一方面，非功能性需求定义是可选的，但强烈建议使用以保证最终产品的质量。

正如我们在本教程中看到的，我们有不同的功能和非功能需求类别，每个类别都有不同的目的和目标。大型软件项目可能包含所有类别的需求，但普通项目通常只定义一个子集。

下表总结并比较了功能和非功能需求的一些相关特征：

7. 结论

在本教程中，我们研究了功能性和非功能性需求。最初，我们简要回顾了有关需求的一般概念，特别是调查功能性和非功能性需求。因此，我们看到了一些创建需求文档的技术。最后，我们概述了功能和非功能需求的主要特征，并在系统总结中进行了比较。

我们可以说，需求是设计软件产品并指导其开发的关键资源。因此，分析师和开发人员必须花时间定义和解释需求，从而获得涵盖所有利益相关者技术需求的最佳最终产品。

本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。 原始发表：2023-02-15，如有侵权请联系 cloudcommunity@tencent 删除前往查看解决方案软件系统架构教程

本文标签： 需求功能性与非功能性