软件定制开发立项前怎么做需求澄清
摘要：立项前的需求澄清不是提前写完全部功能，而是确认问题是否值得解决、谁有决策权、现状证据是否完整、首期边界是否可控，以及项目还依赖哪些人员、数据和环境。
这一步和“写需求文档”有什么区别
需求澄清解决“为什么做、由谁决定、现在是否具备启动条件”；软件需求文档解决“确定要做以后，怎样把角色、流程、功能、数据、接口和验收写成可执行范围”。如果立项问题尚未对齐，直接进入详细功能编写，往往会把尚未确认的假设固化成方案。
先确认要解决的问题，而不是先命名系统
不要只写“建设管理平台”。应记录当前流程怎样运行、在哪一步出现重复录入、等待、错漏或责任不清，影响哪些角色，以及为什么现在要处理。还要写明暂时不解决什么，避免一个问题不断扩展成覆盖所有部门的系统。需要把现状问题进一步转换为可衡量的流程改善目标时，可先阅读软件定制如何改善企业管理效率。
让正确的人参加澄清
| 角色 | 需要确认的事项 | 建议输出 |
|---|---|---|
| 项目发起人 | 目标、优先级、预算与是否继续立项。 | 目标和决策原则。 |
| 业务负责人 | 现状流程、规则、异常分支和首期范围。 | 流程草图与业务边界。 |
| 一线使用者 | 实际操作、表单、例外情况和高频问题。 | 场景样例与待改进点。 |
| 数据或系统负责人 | 数据来源、字段、接口、账号和责任。 | 数据清单与依赖项。 |
| IT、安全或部署负责人 | 网络、服务器、权限、审计和上线流程。 | 环境约束与审批事项。 |
| 验收负责人 | 什么结果能证明首期目标完成。 | 验收方向与确认人。 |
会前准备现状证据
- 现有表格、表单、报表、流程图和系统截图，敏感信息先脱敏。
- 典型业务样例，包括正常流程和驳回、撤回、超时等异常情况。
- 已有系统、接口、账号、数据样例及已知质量问题。
- 组织与角色关系、审批责任、数据可见范围和导出限制。
- 计划上线终端、网络、部署环境和必须遵守的内部流程。
没有完整资料也可以开澄清会，但应把缺失项记录为负责人明确的待办，不能用口头猜测替代。
一次澄清会应该回答哪些问题
- 当前问题发生在哪个流程，影响谁，现状如何被证明？
- 首期必须跑通的最小业务闭环是什么？
- 哪些角色有决策权，哪些角色只提供意见或数据？
- 哪些数据已经存在，哪些需要新录入或外部接口？
- 哪些假设、依赖和待确认事项会影响范围与时间？
- 什么条件满足以后才能进入原型、开发和正式验收？
怎样划定首期边界
优先保留能完成核心闭环的用户、动作、数据和必要接口，并建立四个清单：首期包含、本期不包含、待确认、后续候选。后续可能建设的数据大屏、更多报表、自动化规则或终端适配可以保留，但不应在没有范围和验收的情况下默认进入首期。
澄清结束后应形成什么
- 一页式项目目标、现状问题、首期边界和不包含项。
- 参与人、决策人、业务确认人、数据责任人和验收负责人。
- 现状流程、核心场景、资料索引和关键术语。
- 假设、风险、外部依赖、待确认问题及各自负责人。
- 进入需求文档与原型阶段所需的下一步资料和确认节点。
哪些情况下暂时不应进入开发
发起人和业务负责人对目标仍不一致、首期边界无法确认、核心数据无人负责、部署条件完全未知，或验收人尚未确定时，不宜直接进入完整开发。可以继续做访谈、流程梳理、样表和低保真原型，但要明确这些属于澄清工作，不是正式功能已经交付。