1. 引言
我们可以将计算机科学视为通过计算解决现实问题的艺术。因此，对于广义上的软件开发人员而言，一项关键能力就是将现实世界抽象为能够解决问题的计算模型。
而这些抽象模型的建立，依赖于与项目干系人共同定义的一系列需求。这些需求明确了输入与输出之间的关系，以及最终产品质量的预期。
在本教程中，我们将深入探讨软件开发中的需求类型，重点分析功能性需求（Functional Requirements）与非功能性需求（Non-functional Requirements）。接着，我们会介绍一些定义需求的常用方法，并通过系统性总结对比两者之间的区别与联系。
2. 需求概述
根据著名的《业务分析知识体系》（Business Analysis Body of Knowledge，简称 BABOK），需求是对某种“需求”的表达。在软件开发语境中，需求是一组软件产品必须满足的条件或能力。
需求的分类多种多样，常见的包括：
- 业务需求（Business Requirements）：组织层面的问题或目标陈述，例如提高收入或降低成本
- 干系人需求（Stakeholder Requirements）：特定干系人（如用户或高管）对产品的期望，连接业务需求与解决方案需求
- 解决方案需求（Solution Requirements）：描述产品必须具备的功能与非功能特性
- 过渡需求（Transition Requirements）：用于从当前状态迁移到新状态的需求，例如是否需要培训来使用新系统
本教程将聚焦于解决方案需求，特别是功能性与非功能性需求。
3. 功能性需求
功能性需求是开发团队在构建软件产品时所实现的功能特征。 更具体地说，它们描述了软件的输入、处理和输出逻辑，即软件“能做什么”。
定义功能性需求是软件开发流程中不可或缺的一环。这些需求通常来源于未来用户定义的用例，开发团队通过分析这些用例，将其映射为具体功能，并决定实现所需的技术方案。
常见的功能性需求类别包括：
✅ 认证（Authentication）：识别用户或数据的方式
✅ 授权级别（Authorization）：不同用户权限的划分，如谁可以执行增删改查操作
✅ 外部接口（External Interfaces）：软件与外部系统或用户交互的接口
✅ 事务处理（Transaction Processing）：事务的录入、修改、删除等操作
✅ 合规性（Compliance）：软件需遵循的法律、法规或政策
✅ 数据库（Database）：存储的数据结构与格式规则
当然还有其他如备份、恢复、审计、归档等功能性需求，但它们通常只适用于特定类型的系统。功能性需求的种类并不固定，应根据项目实际需求灵活定义。
4. 非功能性需求
非功能性需求描述的是软件解决方案的质量属性和性能期望。 它们决定了软件“如何工作”，而非“做什么”。
非功能性需求的设定并非强制性的。你可以仅基于功能性需求开发出一个软件，但它在性能、安全、可用性等方面可能无法满足用户期望。
常见的非功能性需求类别包括：
✅ 可用性（Usability）：用户学习和使用软件的难易程度
✅ 安全性（Security）：软件保护数据的能力，如权限控制、抗攻击能力
✅ 可靠性（Reliability）：系统应对故障的能力，如组件故障概率上限
✅ 性能（Performance）：响应时间、并发处理能力等
✅ 可用性（Availability）：系统可访问的时间比例，如最大维护时间
✅ 可扩展性（Scalability）：系统在用户数量变化时保持性能的能力
非功能性需求是根据具体场景定义的，没有统一的最小或最大集合。
5. 需求规格说明策略
功能性与非功能性需求通常记录在一份称为软件需求规格说明书（Software Requirements Specification, SRS）的文档中。它是开发团队的重要参考。
一份完整的 SRS 至少应包含以下三个部分：
- 目的（Purpose）：概述软件目标与背景信息
- 描述（Description）：列出系统假设、限制与策略
- 需求（Requirements）：详细列出功能与非功能需求
以下是一些常用于 SRS 的描述工具。
5.1. 用例图（Use Case Diagram）
用例图用于描述软件与用户之间的交互关系。主要包括以下元素：
- 角色（Actor）：代表用户或管理员
- 系统（System）：代表软件功能
- 目标（Goal）：角色与系统交互的目的
用例图常见形式如下图所示：
5.2. 用户故事（User Stories）
用户故事从终端用户角度出发，描述他们希望实现的功能。格式通常为：
我作为 <某种用户>，希望 <实现某个目标>，以便 <达到某种目的>。
例如：
我作为注册用户，希望可以修改我的个人资料，以便更新我的联系方式。
每个用户故事通常附带一组验收标准（Acceptance Criteria），用于明确该功能实现的具体条件。
6. 系统性总结
| 对比维度 | 功能性需求 | 非功能性需求 |
|---|---|---|
| 定义 | 软件“能做什么” | 软件“如何工作” |
| 必要性 | ✅ 必须定义 | ⚠️ 推荐定义 |
| 结果 | 实现具体功能 | 提升产品质量 |
| 关注点 | 用户需求 | 用户期望 |
| 来源 | 用户与干系人 | 干系人与技术团队 |
功能性需求是软件开发的基础，而非功能性需求则是提升产品竞争力的关键。大型项目可能涵盖所有类型的需求，而一般项目则只需根据实际需要定义部分。
7. 总结
本文我们系统地介绍了软件开发中功能性需求与非功能性需求的概念、分类与定义方法，并通过对比总结帮助读者更好理解两者的区别与联系。
需求是软件设计与开发的基石。无论是分析师还是开发人员，都应投入足够时间去定义和理解需求，以确保最终产品能够全面满足干系人的技术期望。