2、需求工程基础：需求类型（功能/非功能）、需求获取方法（访谈、问卷、观察）、需求文档编写要点
需求工程是软件架构设计的起点，也是决定项目成败的关键环节。许多架构师在项目后期遭遇的返工、性能瓶颈或用户不满，往往可以追溯到需求阶段埋下的隐患。本章将系统讲解需求的核心分类、主流获取方法以及需求文档的编写规范，帮助你在架构设计之前，建立一份清晰、可验证、可追踪的需求基线。
上图展示了需求工程的核心闭环：需求类型定义了我们收集什么，获取方法决定了如何收集，而文档编写则确保收集到的信息能够被架构师、开发者和测试人员无歧义地理解和执行。三者相互支撑，共同构成架构设计的输入基线。
2.1 需求类型：功能需求与非功能需求
核心原理
功能需求描述系统必须提供的功能或服务，即“系统做什么”。例如，“用户可以通过邮箱和密码登录系统”就是一个典型的功能需求。非功能需求则描述系统的质量属性或约束条件，即“系统做得有多好”。例如，“系统在500并发用户下响应时间不超过2秒”属于性能需求；“系统需支持全年99.9%的可用性”属于可用性需求。非功能需求往往比功能需求更能影响架构决策——它们决定了你选择何种服务器架构、缓存策略、数据库方案以及容灾机制。
判断方法：从用户陈述中剥离两类需求
在实际沟通中，用户往往将两类需求混在一起表达。你可以使用以下判断路径：
- 问“系统做什么”：如果答案是某个具体操作或功能，则归为功能需求。
- 问“做得怎么样”：如果答案是速度、容量、安全性、易用性等质量描述，则归为非功能需求。
- 问“在什么条件下”：如果描述涉及特定环境或限制（如“必须使用国产数据库”），则归为约束条件。
案例拆解：电商订单系统的需求分类
假设你正在为一个电商平台设计订单服务。用户最初提出的需求是：“用户下单后要能看到订单状态变化。”这看似是一个功能需求，但深入挖掘后你会发现：
| 需求描述 | 类型 | 架构影响 |
|---|---|---|
| 用户提交订单后，系统生成订单号并展示 | 功能需求 | 订单模块、ID生成策略 |
| 订单状态变更后，用户端在5秒内可见 | 非功能（性能/一致性） | 消息队列、缓存失效策略 |
| 系统需支持每日100万订单量 | 非功能（容量） | 数据库分库分表、异步削峰 |
| 订单数据需保留至少3年 | 非功能（存储） | 冷热数据分离、归档策略 |
| 支付回调需保证幂等性 | 约束/业务规则 | 状态机设计、去重表 |
从这个案例可以看出，同一个业务功能会衍生出大量非功能需求。架构师必须在需求阶段就与用户逐条确认这些质量属性，否则设计出的系统可能在功能上正确，但在高并发、数据一致性或运维层面存在致命缺陷。
常见误区与总结
2.2 需求获取方法：访谈、问卷与观察
核心原理
需求获取的目标是挖掘用户的显性需求和隐性需求。显性需求是用户直接表达的，而隐性需求往往隐藏在用户的工作习惯、抱怨或对现有系统的“将就”中。单一方法很难覆盖全面，因此需要组合使用：访谈适合深度探索，问卷适合广度覆盖，观察适合发现真实行为与表述之间的差异。
操作流程：三种方法的适用场景与执行要点
| 方法 | 适用场景 | 关键操作 | 产出物 |
|---|---|---|---|
| 访谈 | 关键干系人少、问题复杂、需要挖掘动机 | 提前准备半结构化问题清单；多问“为什么”；记录原话 | 访谈纪要、用户故事 |
| 问卷 | 用户群体大、需要量化优先级或满意度 | 设计封闭式+少量开放式问题；避免引导性措辞；先小范围试填 | 统计报告、需求频次分布 |
| 观察 | 用户难以描述流程、现有系统操作复杂 | 现场跟岗、录屏分析、记录操作路径与卡点 | 用户旅程地图、痛点清单 |
实战场景：某物流系统的需求获取组合
我们曾为一个物流公司设计新的调度系统。项目经理最初只安排了两次访谈，但效果不佳——一线调度员在会议室里说的流程与实际操作差异很大。我们随后采用了“观察+访谈”的组合：
- 观察阶段：分析师在调度中心跟岗两天，记录调度员实际使用的Excel表格、电话沟通习惯以及异常处理路径。发现调度员经常需要手动计算车辆到达时间，且对“超时”的定义与业务方给出的文档不一致。
- 访谈阶段：基于观察结果，针对调度组长进行深度访谈，确认了“超时”的三种业务场景（客户原因、路况原因、系统原因），并明确了每种场景下的处理流程。
- 问卷阶段：向全国20个调度中心发放问卷，量化了“手动计算”这一痛点的发生频率（平均每天12次/人），为架构设计中的“自动ETA计算”功能提供了数据支撑。
最终，需求文档中不仅包含了功能清单，还明确了“调度员对ETA误差的容忍度不超过±15分钟”这一非功能指标。这个指标直接影响了后续算法选型和接口设计。
常见误区与总结
- 误区一：只访谈管理层。管理层的视角偏宏观，但一线操作细节往往决定系统是否好用。应确保访谈对象覆盖不同层级。
- 误区二：问卷设计过于开放。开放式问题过多会导致回收结果难以统计，应控制开放式问题比例在20%以内。
- 误区三：观察时干预用户操作。观察者应保持“隐形人”状态，避免因提问或建议而改变用户的自然行为。
2.3 需求文档编写要点
核心原理
需求文档是连接用户、架构师、开发与测试的契约。一份好的需求文档应当具备可读性、可测试性和可追踪性。可读性意味着业务人员能看懂业务规则，技术人员能提取技术要点；可测试性意味着每一条需求都可以被验证；可追踪性意味着从需求到设计、编码、测试的每一步都能回溯。
编写流程与结构模板
推荐采用以下结构组织需求文档：
- 引言：背景、目标、术语表、参考文档。
- 总体描述：产品视角、用户特征、运行环境、约束与假设。
- 功能需求：按模块或用户故事组织，每条需求有唯一编号（如FR-001）。
- 非功能需求：性能、安全、可用性、可维护性、兼容性等，每条同样有编号（如NFR-001）。
- 业务规则：领域逻辑、计算公式、状态流转规则。
- 验收标准：对应每条需求或用户故事的测试场景。
- 附录：调研问卷、访谈记录、分析模型等。
案例拆解：一条需求从模糊到可验收
初始描述：“系统要能导出报表。”——这条需求完全不可用。经过多轮沟通后，我们将其改写为：
FR-023：订单报表导出
描述：系统提供订单报表导出功能，支持按日期范围、订单状态、支付方式筛选。
输出格式：Excel（.xlsx）和CSV两种格式。
数据量：单次导出最大支持10万行，超过时提示用户分批导出。
性能：在测试环境（4核8G）下，导出10万行数据的时间不超过30秒。
权限：仅拥有“报表导出”角色的用户可操作。
验收标准：
1. 选择2024-01-01至2024-01-31，状态为“已支付”，导出CSV，文件可正常打开且数据准确。
2. 导出超过10万行时，系统给出明确提示且不崩溃。
3. 无权限用户看不到导出按钮。这条改写后的需求具备了可测试性，开发人员可以明确实现范围，测试人员可以设计具体用例，架构师也能据此评估是否需要异步导出或引入消息队列。
常见误区与总结
- 误区一：文档写成“流水账”。没有编号、没有优先级、没有依赖关系，导致后续变更管理混乱。
- 误区二：忽略需求来源。每条需求应记录来源（如“张三-运营部-2024-03-01访谈”），以便后期有疑问时追溯。
- 误区三：文档与代码脱节。需求文档应随着迭代持续更新，而不是一次性交付后束之高阁。建议将需求编号嵌入到代码提交信息中，实现端到端追踪。
需求工程不是一次性活动，而是贯穿项目始终的持续过程。架构师在完成本章学习后，应能够熟练区分功能与非功能需求，灵活运用多种获取方法，并编写出高质量的需求文档。这份文档将成为后续架构设计、技术选型和项目排期的核心依据。记住：需求上的一个小时的澄清，可能节省架构阶段一周的返工。