需求可行性分析要回答的是：这条需求在给定约束下能否实现、能否产生预期价值。判断依据可以归为五类——需求意图与边界、业务价值、技术实现条件、资源与时间约束、风险与合规要求。做法是把每条需求拆成可判断的问题，逐项取证，最后给出“可行、有条件可行、不可行、待澄清”的结论，并记录依据来源和待验证项。
要点总览（TL;DR）
- 需求可行性分析围绕四类问题展开：价值、技术、资源、风险合规；对应五类依据：需求意图与边界、业务价值、技术实现、资源与时间、风险与合规。
- 每类依据都要写清来源并标注可信度：访谈和文档属于间接依据，原型验证、依赖方确认和书面排期可信度更高。
- 结论分四级——可行、有条件可行、不可行、待澄清；有条件可行必须把前提写成可核验的条件。
- 关键依据缺失时不得给出“可行”结论，应列为待澄清或条件项，指定负责人和完成时间后再移交评审。
- 分析负责人牵头汇总，但技术、资源、合规结论分别由对应角色出具，依据记录要能追溯到原始材料。
先明确可行性要回答哪几个问题
可行性分析针对单条需求或一组相关需求，回答“在现有条件下做不做、怎么做才成立”。它发生在需求被理解之后、正式评审之前，产出的是判断依据和结论，为后续评审提供输入。结构化建模、原型设计、正式评审流程属于其他环节，本文不展开。
把笼统的“能不能做”拆成四类问题，分析才有落点：
- 价值问题：这条需求解决谁的什么问题，预期带来什么可观察的变化，不做会怎样。
- 技术问题：现有架构和依赖系统能否支撑，需要哪些改造，关键技术点是否已验证。
- 资源问题：需要多少人、多少预算、多长时间，交付窗口是否匹配。
- 风险合规问题：涉及哪些法规、安全、数据要求，外部依赖是否可控。
四类问题各自对应一组待答项。例如价值问题下的待答项包括“目标指标是什么”“影响哪些用户或流程”“有无更简单的替代方案”；技术问题下的待答项包括“涉及哪些系统”“接口能力是否满足”“有无类似实现可参考”。问题清单确定后，后续取证才有明确目标，也便于判断哪些问题已经回答、哪些仍然悬空。
五类依据及其取证方式
可行性结论的可信度取决于依据的质量。每类依据都要写清来源，并标注可信度：来自实际验证的结论可信度高，来自访谈和文档的属于间接依据，需要交叉印证。
| 依据类别 | 具体内容 | 取证方式 | 可信度标注 |
|---|---|---|---|
| 需求意图与边界 | 原始诉求、使用场景、验收期望、明确不做的范围 | 与提出方访谈、查阅原始工单或反馈记录、确认验收口径 | 访谈记录为间接依据，需提出方书面确认 |
| 业务价值 | 目标指标、影响范围、替代方案对比、不做的后果 | 历史数据分析、同类需求效果回溯、与业务负责人确认目标 | 有数据支撑的为较强依据，口头判断需标注 |
| 技术实现 | 现有架构约束、依赖系统能力、关键技术点验证结论 | 架构文档查阅、依赖方接口确认、原型或小规模技术验证 | 验证结论可信度最高，文档与口头确认为间接依据 |
| 资源与时间 | 人力投入、预算、交付窗口、与其他工作的冲突 | 资源排期表、预算审批记录、项目管理者确认 | 以书面排期和审批为准 |
| 风险与合规 | 适用法规、安全要求、数据范围与流向、外部依赖风险 | 合规角色确认、安全评估、依赖方协议与承诺 | 合规与安全结论需由对应角色出具 |
取证时有两个常见问题值得注意。一是把“提出方说很重要”直接当作价值依据，缺少目标指标和影响范围，结论就站不住；二是把“技术上应该可以”当作实现依据，没有经过验证或依赖方确认，风险会在开发阶段暴露。对每类依据标注来源和可信度，能让评审者快速看出结论建立在什么基础上。
操作步骤：从需求到可行性结论
以下五步构成一次完整的可行性分析，每步都有明确的输入、动作、输出和完成标志。
步骤一：拆解需求，形成待判断问题
输入是需求描述和原始诉求材料。动作是把需求按四类问题拆成待答项，逐条写成可以回答“是/否/需要什么条件”的问句。输出是可行性问题清单。完成标志是每条待答项都能对应到具体的取证对象，没有“再看看”“评估一下”这类无法验证的表述。
步骤二：按五类依据收集证据，标记缺失项
输入是问题清单。动作是逐项收集证据，填写来源和可信度，对暂时拿不到的依据明确标注“缺失”。输出是依据记录表。完成标志是每个待答项都有状态：已取证、部分取证或缺失，且已取证项写明了来源。
步骤三：对缺失项安排澄清或小规模验证
输入是缺失项清单。动作是判断每项缺失的影响程度：影响结论方向的，安排访谈、依赖方确认或原型验证；影响较小的，记录为待验证项并指定负责人和时间。输出是澄清与验证计划。完成标志是关键缺失项都有了明确的处理方式和时限。
步骤四：给出结论分级并写明条件
输入是依据记录和验证结果。动作是按四级给出结论：
- 可行：五类依据均有来源，无关键缺失。
- 有条件可行：主体成立，但依赖特定前提，如某项技术验证通过、某个依赖方按期提供接口、预算获批。
- 不可行：存在无法满足的硬约束，如法规禁止、架构无法支撑且改造成本超出范围。
- 待澄清：关键依据缺失，尚不足以判断。
输出是带条件的结论。完成标志是“有条件可行”的每条前提都写成可核验的条件，而不是模糊的“后续再看”。
步骤五：记录依据来源与待验证项，移交评审
输入是完整的依据记录和结论。动作是整理成一份可追溯的记录，附上原始材料出处、待验证项清单及负责人。输出是可行性依据记录，作为正式评审的输入材料。完成标志是评审者能仅凭记录复现判断过程。
在团队协作中，这份记录需要和需求本身放在一起流转，待验证项要有状态和负责人。ONES 的需求工作项与 Wiki 文档可以承载这类记录：需求描述、依据记录、结论和待验证清单在同一上下文中留存，评审时可直接追溯。ONES Assistant 可围绕 PRD 质量检查和需求澄清提炼要点与待澄清问题，帮助团队在拆解阶段更快形成问题清单；其回答基于项目、工作项和 Wiki 页面等真实上下文，输出过程可追踪。具体可用范围以实际部署和权限配置为准。
角色分工与交付物
可行性分析由分析负责人牵头，但依据来自不同角色，任何一方缺位都会导致某类依据悬空。
| 角色 | 提供的依据 | 交付物 |
|---|---|---|
| 需求提出方 | 需求意图、使用场景、验收期望、价值目标 | 书面确认的诉求说明与目标指标 |
| 技术负责人 | 架构约束、依赖系统能力、技术验证结论 | 技术评估意见或验证报告 |
| 资源与项目管理者 | 人力、预算、交付窗口、排期冲突 | 资源与排期确认 |
| 风险与合规角色 | 适用法规、安全要求、数据合规结论 | 合规与安全评估意见 |
| 分析负责人 | 汇总各类依据、给出结论分级、维护待验证清单 | 可行性依据记录与结论 |
分工的关键是让每类依据都有明确的出具人。分析负责人不替技术负责人下技术结论，也不替合规角色判断合规性，其职责是组织取证、检查依据完整性并形成结论。待验证清单由分析负责人维护，但每项的关闭责任在对应的出具人。
示例：一条需求的可行性依据记录
以下为演示情景，用于说明记录如何填写。
需求描述：客户希望订单列表页支持按自定义标签批量筛选并导出结果。
待判断问题：目标用户是谁、使用频率如何；现有列表接口能否支撑标签筛选；导出数据量上限是多少；涉及哪些客户数据；交付窗口内能否完成。
| 依据类别 | 填写内容 | 来源与可信度 |
|---|---|---|
| 需求意图与边界 | 面向运营人员，按标签筛选后导出用于线下对账；本期不做标签的批量编辑 | 与提出方访谈并书面确认，间接依据 |
| 业务价值 | 预计覆盖三个高频对账场景，减少人工整理时间；不做则继续手工导出 | 历史工单统计，较强依据 |
| 技术实现 | 列表接口已支持标签字段，筛选需新增索引；导出复用现有导出服务，需确认单次上限 | 技术负责人评估，导出上限待验证 |
| 资源与时间 | 后端约五人日，前端约三人日，可排入下个迭代 | 排期表确认，书面依据 |
| 风险与合规 | 导出内容含客户联系方式，需走数据导出审批并记录操作日志 | 合规角色确认，待补充审批流程细节 |
结论：有条件可行。条件为：导出服务单次数据量上限验证通过；数据导出审批流程在开发前确认。若上限不满足，需拆分为分批导出并重新评估工作量。
待验证项：导出上限验证由技术负责人负责，三个工作日内完成；审批流程细节由合规角色在两个工作日内补充。两项关闭后结论转为可行，移交评审。
完成检查：判断依据是否充分
分析结束前逐项核对以下检查项，全部通过才可移交评审：
- 五类依据是否都有来源，或已明确标注缺失并说明影响。
- 结论是否写明条件与适用范围，“有条件可行”的每条前提是否可核验。
- 待验证项是否都有负责人和完成时间。
- 每条依据是否能追溯到原始材料，如访谈记录、文档、验证报告或数据来源。
- 结论分级是否与依据状态一致，没有用“可行”覆盖尚未回答的关键问题。
其中有一条阻断规则：关键依据缺失时不得给出“可行”结论。所谓关键依据，是指缺失会直接改变结论方向的那一类，例如技术验证未通过、合规结论未出具、预算未获批。遇到这种情况，结论应写为“待澄清”或“有条件可行”，并把缺失项列入待验证清单，指定负责人和时限。检查通过后，依据记录连同结论一并进入正式评审，评审中的争议也能回到具体依据上讨论，而不是停留在印象判断。
常见问题
如果需求提出方催得紧，关键依据还没拿到，能不能先给“可行”结论？
不建议。关键依据缺失时给出“可行”，等于把风险推到开发阶段。更稳妥的做法是先写“待澄清”或“有条件可行”，把缺失项列入待验证清单，写明负责人和完成时间，再移交评审。评审时各方看到的是条件而不是结论，讨论也能落在具体依据上。
如果业务确实需要先启动，可以把结论写成“有条件可行”，前提是某项验证通过或某个依赖方按期承诺，并约定条件不成立时的回退方案。
访谈得到的结论和文档记录不一致时，以哪个为准？
两者都属于间接依据，出现不一致时不要直接选一个，而是把差异本身作为待澄清项。可以回到提出方做一次书面确认，明确场景、范围和验收口径；涉及技术能力的，安排一次小规模验证或依赖方书面确认。确认结果更新到依据记录中，并注明替代了哪条旧依据，保证记录可追溯。
小团队没有专职合规角色，风险与合规依据怎么处理？
可以由承担该职责的人兼任，例如负责数据或法务对接的成员，关键是明确谁对这类结论负责，而不是默认跳过。若团队内部确实无法判断，可先标注“缺失”并说明影响范围，把外部确认列为待验证项，在结论中写成条件。涉及数据导出、个人信息等场景时，建议在开发前完成确认，避免返工。
可行性依据记录需要多细，才够评审使用？
判断标准是评审者能否仅凭记录复现判断过程。每条依据应包含内容、来源和可信度，结论要写明条件与适用范围，待验证项要有负责人和时间。不必把访谈全文贴进去，但要能指向原始材料，例如工单编号、文档链接或验证报告。记录过粗会让评审反复追问，过细则增加维护成本，按“能复现结论”这条线把握即可。
可行性结论在评审后被推翻，之前的依据记录还有用吗？
有用。评审推翻结论通常是因为出现了新依据或对某条依据的判断不同，这时可以回到记录上定位分歧点：是来源不可靠、条件没写清，还是遗漏了某类依据。把新证据补充进记录并更新结论分级，下一次分析就能复用这套结构。保留历史版本也有助于后续回溯为什么当时判断为可行或有条件可行。
