功能性需求与非功能性需求

---

---

软件开发中需求概述

功能性需求

定义系统应该做什么。它们定义系统必须具备的特定行为、特性和功能，以满足用户的需求。这些需求通常表示为系统应执行的操作或任务。

示例

• 用户身份验证 - 系统必须允许用户使用用户名和密码登录。

• 数据处理 - 系统必须实时处理和验证用户输入。

• 报表 - 系统必须每月生成销售报表。

非功能性需求

定义系统应该如何执行。它们定义系统必须遵守的质量属性、性能标准和约束。这些需求侧重于可用性、可靠性、安全性、可扩展性等方面。

示例

• 性能 - 系统必须能够处理多达1000个并发用户，响应时间小于2秒。

• 安全性 - 系统必须确保所有敏感信息的加密。

• 可用性 - 系统必须易于使用，并且残疾用户也能访问。

功能性需求的类型

• 用户界面需求 - 与UI组件、布局和设计相关的需求（例如，搜索栏）。

• 业务需求 - 描述业务规则和策略（例如，系统应根据位置应用税率）。

• 数据管理需求 - 定义系统应如何处理数据输入、存储和处理。

• 管理需求 - 系统管理的功能，例如用户角色管理或访问控制。

用例示例

描述一个功能性需求示例以及它如何帮助实现业务目标。

非功能性需求的类型

性能需求

• 响应时间 - 系统对给定输入或请求做出反应所需的时间。

• 吞吐量 - 指系统在给定时间段内可以处理数据或完成任务的速率。

• 延迟 - 指用户操作与系统相应响应之间的时间延迟。

示例

响应时间 - 对于93%的用户，页面应在2秒内加载。

可扩展性需求

系统处理数据量、用户或事务增长能力。

示例 - 系统应支持多达10,000个并发用户。

安全需求

数据保护、加密和访问控制的需求。

示例 - 密码必须在存储之前进行哈希和加盐处理。

可用性需求

与系统易用性和可学习性相关的需求。

示例 - 所有核心功能都应在不超过三次点击的情况下即可访问。

可靠性和可用性需求

定义系统的预期正常运行时间和容错能力。

示例 - 系统应具有99.9%的正常运行时间。

可维护性和可移植性

易于维护、调试和迁移的需求。

示例 - 代码应遵循已记录的标准以确保可维护性。

法律和合规性需求

系统必须遵守的法规和标准（例如，GDPR - 通用数据保护条例）

示例 - 用户必须同意根据GDPR使用数据。

收集需求的技术

与利益相关者和用户面谈以了解预期。

调查问卷收集来自广大受众的反馈。

研讨会和头脑风暴会议用于协作需求收集。

观察和跟班以了解现实世界中的用户互动。

文档分析现有系统和策略。

原型和模型以可视化需求并收集反馈。

记录功能性和非功能性需求

需求文档

• 软件需求规格说明书 (SRS) 文档 - 用于详细捕获功能性和非功能性需求。

• 敏捷用户故事和验收标准 - 定义每个需求的“完成”状态。

使用图表

• 用例图 - 可视化功能性需求。

• 流程图和序列图 - 用于流程流和系统交互。

非功能性文档

• 质量属性场景 - 在场景中描述非功能性需求（例如，“如果服务器发生故障，系统应在3分钟内恢复”）。

• 最佳实践 - 确保需求清晰、可测试且具有优先级。

管理功能性和非功能性需求的挑战

• 模糊性和误解 - 模糊的需求会导致误解。使用清晰具体的语言。需求变更：需求可能会频繁变更；使用敏捷方法来提高灵活性。

• 功能性目标和非功能性目标之间的冲突 - 可能需要权衡（例如，安全与可用性）。

• 优先级问题 - 可能会忽略高优先级的非功能性需求（如安全性）。

• 利益相关者一致性 - 确保所有利益相关者都同意优先级和定义。

管理和验证需求的最佳实践

• 让利益相关者参与 - 定期获得利益相关者的反馈，确保需求与预期相符。

• 对需求进行优先级排序 - 根据业务重要性对功能性和非功能性需求进行排名。

非功能性需求测试

负载测试用于性能需求。

可用性测试用于用户体验。

安全审计用于安全和合规性需求。

迭代审查和改进，定期检查需求的完整性和相关性。

使用自动化，使用JIRA、Confluence和Trello等工具实时跟踪需求的可追溯性。

总结

对功能性和非功能性需求采取平衡的方法对于构建强大、以用户为中心的软件系统至关重要。本文重点介绍了这些需求的定义、类型以及收集、记录和验证这些需求的方法，确保软件项目与用户的期望和技术标准相符。