Day24-01｜5.2.1 需求获取：从“用户说了什么”走向“系统真正要解决什么”

本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.2.1“需求获取”。需求获取是通过访谈、观察、问卷、研讨会、原型、文档分析、场景分析和领域研究等方式，发现并理解利益相关者需要解决的问题、希望获得的价值以及受到的约束。系统架构设计师要特别关注那些会决定系统边界、质量属性、数据模型和技术路线的需求，避免把未经澄清的愿望直接变成架构。

一、学习目标与考试定位

完成本节后，应能够说明需求获取的目的、对象、来源和常见技术；能够识别利益相关者、显性需求、隐性需求、业务规则和约束；能够区分功能需求与非功能需求，提取架构驱动需求；能够处理不同角色之间的冲突和优先级；能够用原型、场景和验收条件验证理解；能够在案例题和论文中描述从需求获取到架构决策的完整过程。

软考高级题目常用一句模糊需求制造难点，例如“系统要高并发”“界面要简单”“数据要安全”“支持灵活扩展”。这些话不能直接作为设计依据。答题时要继续追问指标、场景、范围、角色、时限、数据量、峰值、故障后果和验收方式，把愿望转化为可理解、可讨论、可验证的需求。

二、需求获取的基本概念

需求是利益相关者对系统服务、质量、约束、业务规则和交付结果的需要或期望。需求获取不是单向收集，也不是把用户提出的每句话原样记录，而是通过沟通和分析发现真实目标，澄清术语和边界，识别冲突，确认优先级，并建立后续验证依据。

利益相关者包括最终用户、业务负责人、客户、管理层、运营人员、开发和测试人员、运维与安全人员、监管机构、供应商以及受系统影响的其他主体。不同角色看到的系统不同：业务负责人关心价值和规则，用户关心操作和效率，运维关心部署和恢复，安全人员关心身份和审计，管理层关心成本、风险和进度。只访谈最会说话的人，容易得到片面的需求。

需求获取可以概括为：

找到相关人 → 理解业务目标 → 采集场景和约束 → 澄清冲突 → 形成可验证需求 → 让相关人确认

三、需求来源与分类

需求来源包括组织战略和业务目标、现有系统和流程、用户反馈、法规和行业标准、竞争产品、运营数据、事故和投诉、技术环境以及未来发展规划。遗留系统中的行为也可能是需求来源，但现有行为不一定都是合理规则，必须区分业务约束、历史缺陷和偶然实现。

功能需求描述系统要做什么，例如注册、查询、审批、结算、报表和通知；非功能需求描述系统做得怎样，例如性能、可用性、安全、可靠性、可维护性、可扩展性、易用性和可移植性；约束需求描述系统必须遵守的技术、法规、组织或环境条件，例如必须部署在指定云平台、兼容已有协议或满足数据留存要求。

四、需求获取的常见技术

1. 访谈

访谈可以通过结构化、半结构化或开放式方式进行。结构化访谈便于比较不同对象，开放式访谈更容易发现未知问题。访谈前应明确目标、准备问题和背景材料，访谈中使用追问、复述和例子澄清，访谈后由受访者确认纪要。不要只问“你想要什么功能”，还要问当前如何完成、哪里最困难、什么情况算失败、谁负责、数据从哪里来和变化最频繁的是什么。

2. 观察与现场调查

观察用户实际工作能够发现口头描述中遗漏的步骤、临时表格、绕过流程和异常处理。用户可能已经习惯低效操作，不会主动说出问题；现场观察可以揭示真实流程、环境约束、设备限制和协作关系。观察需要尊重隐私和授权，不能只记录理想流程。

3. 问卷

问卷适合覆盖大量用户和收集偏好、满意度、使用频率等信息。问题要清晰、选项互斥且覆盖合理，避免诱导和专业术语。问卷数据能帮助发现趋势，但通常无法解释深层原因，需与访谈和数据分析结合。

4. 研讨会与联合需求分析

把业务、用户、技术、测试、安全和运维代表集中讨论，可以快速澄清术语、流程、边界和冲突。主持人要控制议题、记录决策、区分事实与意见，并明确未决问题和责任人。研讨会不是人数越多越好，关键角色缺席会导致结论无法落地。

5. 原型

原型通过界面、流程、数据或技术实验帮助参与者具体讨论。界面原型适合澄清交互和流程，技术原型适合验证性能、接口、算法和部署可行性。要标记原型的目的、范围、真实性和是否可直接生产化，避免用户把演示效果误认为全部需求已经满足。

6. 文档分析与领域研究

通过分析法规、合同、旧系统文档、数据库、报表、日志、工单、操作手册和接口协议，可以了解业务规则和历史约束。文档可能过期，必须与实际操作和相关人员交叉验证。领域研究能帮助架构师理解专业术语、流程和风险，避免把复杂业务简化成几个 CRUD 接口。

五、需求获取中的关键追问

对每项需求至少追问六个方面：谁需要它，为什么需要，什么时候发生，输入和输出是什么，异常如何处理，如何判断完成。对于质量属性，还要追问场景、刺激、环境、响应、响应度量和优先级。例如“系统要高可用”应进一步明确：哪项业务、在什么故障下、允许中断多久、允许丢失多少数据、谁负责切换、如何验证恢复。

对于“灵活配置”，要问哪些规则会变、由谁修改、是否需要审批、配置何时生效、如何回滚、是否需要版本和审计；对于“支持多租户”，要问租户数量、数据隔离、配置隔离、资源配额、密钥管理、管理员范围和租户退出处理。架构师的价值常常就在这些追问中。

六、架构驱动需求的识别

架构驱动需求是对系统总体结构和关键技术决策有显著影响的需求，通常包括高性能、高可用、强安全、复杂集成、大规模数据、严格实时性、可扩展性、可维护性、部署约束和法规要求。它们不一定是用户直接说出的功能，却可能决定系统采用什么架构风格、数据策略、通信方式和部署拓扑。

识别架构驱动需求可以检查：是否跨越多个模块或团队；是否需要在早期验证；是否改变系统边界和数据所有权；失败后果是否严重；是否需要专门基础设施；是否会限制未来演化。架构师应将它们写成质量属性场景和约束，并安排原型、评审、压测或安全验证。

七、冲突、优先级与需求协商

需求冲突很常见。业务希望流程灵活，审计要求严格留痕；用户希望页面简单，管理层要求字段全面；产品希望快速上线，安全团队要求完整防护；运维希望减少组件，业务希望高可用冗余。冲突不能靠架构师个人拍板，应明确目标、影响、约束和权衡依据。

优先级可以综合业务价值、紧迫性、风险降低、依赖关系、成本和不可逆程度判断。可以采用必须有、应该有、可以有、暂不考虑等分级，也可以按价值和风险建立排序。协商时要把不同方案的收益、成本、风险和验证方法说清楚，记录决策和未决问题。

八、需求确认与可测试性

需求应具有正确性、完整性、一致性、可行性、必要性、可追踪性和可验证性。模糊词语如“快速”“方便”“安全”“友好”“大量”“实时”必须转化为场景和指标。需求确认可以通过评审、原型演示、用例走查、模型检查、接口契约、数据样例和验收测试设计完成。

需求不是越详细越好。过早规定实现方式可能限制架构选择，过度细化尚未确定的业务会产生浪费。合理做法是对高风险、跨边界和架构驱动需求尽早澄清，对低风险细节允许在迭代中逐步细化，但必须保留优先级、责任和追踪关系。

九、案例分析：医院预约系统需求获取

某医院计划建设统一预约平台。院领导要求“提高服务效率”，医生希望减少爽约，患者希望操作简单，财务部门要求准确结算，信息科要求接入既有 HIS，安全部门要求保护病历和身份信息。项目团队直接根据院领导的要求设计了一个预约表单，试运行后发现退号、改期、号源锁定和第三方支付都无法处理。

改进应先识别利益相关者和完整业务场景，观察挂号、退号、改期、爽约、停诊、加号和异常支付流程；分析 HIS、支付和短信平台的接口、数据责任和失败处理；将“提高效率”拆成预约响应时间、号源一致性、人工处理量和患者完成率等指标；将身份、病历访问、审计、可用性和数据恢复识别为架构驱动需求；用原型澄清患者和医生交互，用技术原型验证号源锁定、支付回调和高峰并发；通过研讨会确认优先级和验收标准。

最终架构不能只围绕表单，而要考虑号源服务、预约状态机、幂等、缓存、消息、支付对账、权限、审计、灾备和接口隔离。需求获取越充分，后续返工和架构误判越少。

十、课后练习

练习一：单项选择

下列最能体现高质量需求获取的是（ ）。

A. 将用户提出的所有功能立即写入开发任务；B. 只访谈项目发起人；C. 通过访谈、观察、原型和文档分析理解目标、场景、约束并确认需求；D. 用技术方案替代需求讨论。

答案：C。需求获取需要多来源、多角色和多种技术，并通过确认把愿望转化为可验证需求。

练习二：简答题

请说明如何把“系统要高性能”转化为可验证需求。

参考答案：明确业务场景和接口，说明并发用户、请求速率、数据量、峰值和运行环境；定义响应时间、吞吐量、资源使用率、成功率和可接受退化；说明性能目标适用的时间窗口和优先级；识别缓存、异步、分片、读写分离或扩展等架构影响；制定基准测试、压力测试和峰值测试方案，并由业务和技术共同确认。

练习三：案例分析

某企业项目有业务、财务、安全和运维四方需求，彼此存在冲突。业务要求快速上线，安全要求强制多因素认证，运维要求减少组件，财务要求全过程审计。请说明需求获取和协商方法。

参考答案：识别四类利益相关者的目标、约束和影响，分别访谈并组织联合研讨；用业务场景和风险场景明确快速上线、身份安全、运维复杂度和审计的具体指标；将多因素认证、审计和权限作为架构驱动需求，评估不同实现的成本和上线影响；可以采用分阶段交付，先保证高风险角色和关键操作的强认证与审计，再逐步覆盖普通场景；通过原型验证用户体验，通过安全和运维评审验证可行性；记录优先级、取舍理由、责任人、未决问题和验收条件，并在变更时重新评估。

十一、论文素材

论文可写：项目启动阶段，我首先识别业务负责人、最终用户、运营、财务、安全、运维和外部系统等利益相关者，结合访谈、现场观察、历史文档、运行日志和原型演示获取需求。对“高性能、高可用和安全”等模糊表述，我进一步转化为并发量、响应时间、恢复目标、数据保留、访问范围和审计要求，并识别出对总体架构影响最大的架构驱动需求。针对多方冲突，通过联合研讨、场景走查和方案权衡确定优先级；对关键技术使用原型和压测验证，对确认后的需求建立追踪和验收标准。

十二、今日复盘

需求获取不是记录愿望，而是理解目标、角色、场景、约束和质量要求。要从多类利益相关者和多种来源获取信息，用访谈、观察、研讨会、原型和文档分析交叉验证；把功能、非功能和约束需求区分开，重点识别架构驱动需求；对模糊表述追问场景和指标，对冲突进行基于价值、风险和成本的协商，并形成可验证、可追踪的结果。下一篇进入 5.2.2 需求变更。