2、系统需求基础：需求的定义、分类（功能/非功能）、来源、层次（业务/用户/系统）及常见问题

在软件工程实践中，需求是系统设计与开发的起点，也是验收与交付的基准。许多项目失败并非源于编码能力不足，而是需求定义模糊、分类混乱或层次错位。本章将系统梳理需求的定义、分类、来源与层次，并结合典型场景剖析常见问题，帮助读者建立一套可操作的需求分析框架。

上图展示了系统需求基础框架的核心要素。需求定义是中心，向外辐射出分类、来源与层次三个维度，而常见问题则作为底部警示。下面我们将逐一展开每个维度的具体内容。

2.1 需求的定义与本质

核心原理：需求（Requirement）是系统必须实现的能力或必须遵守的约束。它回答两个问题：系统要“做什么”（功能）和“做得怎么样”（质量与约束）。IEEE 标准将需求定义为：用户为解决问题或达到目标所需的条件或能力；系统或系统组件为满足合同、标准、规范或其他正式文档所必须满足的条件或能力。

需求不是简单的“用户想法”，而是经过分析、验证、确认后的正式化描述。它应具备可测试性、唯一性、完整性和一致性。一个合格的需求条目通常包含：标识符（唯一编号）、描述（行为或约束）、优先级（Must/Should/Could）、来源（干系人或文档）、验收标准（如何验证）。

2.2 需求分类：功能需求与非功能需求

判断方法：功能需求描述系统“做什么”，是行为性的；非功能需求描述系统“做得怎么样”，是质量属性或约束条件。两者缺一不可，但非功能需求往往被忽视，导致系统上线后性能、安全、可用性不达标。

非功能需求可进一步细分为：性能（吞吐量、延迟）、安全（认证、授权、数据加密）、可用性（MTBF、故障恢复时间）、可维护性（模块化程度、日志完备性）、可扩展性（水平/垂直扩展能力）、合规性（GDPR、等保要求）等。

2.3 需求来源：从干系人到业务规则

操作流程：需求来源的识别是需求工程的第一步。常见的来源包括：

1. 干系人：用户、客户、产品经理、运营人员、技术支持、管理层。不同干系人关注点不同，需交叉验证。
2. 业务规则与法规：行业标准（如 ISO 26262）、法律法规（如数据保护法）、公司内部制度。
3. 现有系统与竞品：遗留系统的功能缺陷、竞品的功能亮点、用户反馈。
4. 技术约束：硬件平台限制、第三方接口协议、网络环境。

在收集需求时，建议采用“多源采集、交叉验证”策略。例如，用户访谈发现“希望查询更快”，而日志分析显示“90% 的查询集中在最近 7 天数据”，则可将需求细化为“对最近 7 天数据建立索引，查询响应时间 < 100ms”。

2.4 需求层次：业务、用户与系统

核心原理：需求层次模型（业务需求→用户需求→系统需求）是需求分析的核心框架。业务需求描述组织“为什么做”；用户需求描述用户“想做什么”；系统需求描述系统“具体怎么做”。三层之间是逐步细化和映射的关系。

• 业务需求：高层级的目标，通常由管理层或产品负责人提出。例如：“提升客户订单处理效率 30%”。
• 用户需求：用户执行任务时的具体诉求。例如：“客服人员能够在一个界面完成订单查询、修改和备注”。
• 系统需求：对软件系统的具体功能和非功能要求。例如：“系统提供订单查询接口，支持按订单号/客户手机号模糊查询，响应时间 < 200ms”。

2.5 常见问题与应对策略

总结复盘：需求阶段最常见的四类问题及其应对策略如下：

以需求歧义为例，某项目描述“系统应支持批量导入”，但未说明“批量”的数量级和格式。开发人员实现为一次导入 100 条 Excel，而业务方期望一次导入 10 万条 CSV。最终通过明确“单次导入最大 10 万条，支持 .xlsx/.csv 格式，错误行跳过并生成日志”解决了歧义。

本章内容为后续的软件分层映射奠定了需求基础。只有清晰定义需求，才能合理地将需求分配到不同的软件层次（如接口层、业务逻辑层、数据层），确保每个层次职责明确、可测试、可维护。在实际项目中，建议使用需求管理工具（如 JIRA、Polarion）建立需求条目与设计、测试用例的追溯关系，实现全生命周期管理。