需求可行性分析是在需求进入方案设计和排期之前，从技术、业务、经济和合规四个维度判断这条需求是否值得做、能否做成、代价是否可接受。四个维度各自给出可核验的结论，需求才适合进入后续的建模与评审。本文说明每个维度要看什么、需要哪些证据，以及结论如何形成。
要点总览（TL;DR）
- 需求可行性分析在方案设计和排期之前进行，从技术、业务、经济、合规四个维度判断需求是否值得做、能否做成、代价是否可接受。
- 技术维度看架构承载、关键依赖、团队技能、可维护性与风险；业务维度看真实问题、目标一致性和使用场景；经济维度看成本构成、收益口径与机会成本；合规维度看数据隐私、资质许可与合同约束。
- 结论分为可行、有条件可行、不可行三种，有条件可行必须把前提条件写清楚，并附上判断依据和关键假设。
- 可行性分析回答“要不要做、能不能做”，需求建模回答“如何结构化表达”，需求评审回答“表达是否完整、一致、可验收”，三者依次衔接。
- 只做技术判断、把合规留到上线前、把可行性当成拍板，是三种常见偏差，返工代价通常高于前期多花几天做判断。
需求可行性分析是什么，判断到哪一步为止
需求可行性分析是在投入开发资源之前，对一条需求做“可做性”与“值得做”的评估。它的分析对象是需求本身及其约束条件：需求想解决的问题、期望的结果、已知的时间与资源限制、涉及的数据和外部依赖。它不负责给出完整解决方案，也不负责把需求写成规格说明。
这项分析的结论通常有三种形态。第一种是可行，四个维度均无实质障碍，可以进入后续流程。第二种是有条件可行，需求本身成立，但需要满足某些前提，例如先完成某项技术改造、先取得某类资质、先确认某个数据源可用。第三种是不可行，某个维度存在无法绕过的障碍，或者投入与收益明显不匹配。无论哪种结论，都应附上判断依据和关键假设，便于他人复核。
需要划清的边界有两条。把需求结构化表达、编写用例和规格说明，属于需求建模的工作；对需求文档做完整性、一致性、可验收性的正式检查，属于需求评审的工作。可行性分析回答的是“要不要做、能不能做”，它发生在建模和评审之前，产出的是一份带依据的推进判断，而非设计方案或验收标准。
四个维度各自回答什么问题
四个维度分工明确，缺一项就可能出现“技术能做但没人用”“有人用但算不过账”“都合适但数据不能这么用”的情况。下表把每个维度的判断问题、关键证据和常见结论形式并列呈现。
| 维度 | 判断问题 | 关键证据 | 结论形式 |
|---|---|---|---|
| 技术 | 现有架构和团队能否实现并长期维护？关键依赖是否具备？ | 架构评估、依赖方接口文档或可用性确认、团队技能盘点、性能与安全风险清单 | 可行 / 有条件可行（附改造或依赖前提）/ 不可行 |
| 业务 | 是否解决真实问题？与产品目标是否一致？谁会使用？ | 用户访谈或反馈记录、使用场景描述、目标指标、现有替代方案对比 | 值得做 / 需缩小范围 / 不建议做 |
| 经济 | 投入多少？收益如何衡量？机会成本是什么？ | 人力与采购估算、运维成本、收益口径与测算、同期其他需求的投入对比 | 投入产出可接受 / 需调整范围 / 暂缓 |
| 合规 | 数据与隐私、资质许可、合同与监管是否允许这么做？ | 数据清单与流向、相关资质要求、合同条款、行业监管规定 | 合规 / 有条件合规（附整改项）/ 不可行 |
这张表的作用是让四个维度平行受检，避免某一维度被跳过。实际执行时，各维度的判断深度可以不同：高风险需求在合规维度投入更多精力，创新型需求在业务维度需要更扎实的用户证据。
技术可行性要看哪些具体项
技术维度最容易停留在“应该能做”的印象判断上。把它拆成可核对的检查点，每项都要求具体证据，结论才有支撑。
- 现有架构与系统承载能力。看这条需求涉及的系统是否需要改造数据结构、接口或部署方式。证据是架构说明和受影响模块清单，以及改造工作量的初步估算。需要大范围改造时，结论往往是“有条件可行”，条件写清楚改造范围。
- 关键依赖是否具备。第三方接口、数据源、算法能力或硬件设备，任何一项缺失都可能让需求无法落地。证据是依赖方的接口文档、可用性确认或试用结果。依赖尚未确认时，不宜直接判为可行。
- 团队技能与工期匹配度。看团队是否具备相关技术经验，工期是否覆盖学习与试错成本。证据是技能盘点与排期估算。需要外部支持时，把支持方式和到位时间写成条件。
- 可维护性与演进成本。需求上线后由谁维护、后续变更是否方便。证据是对运维负担的评估。引入新技术栈或临时方案时，这一项尤其要写清楚。
- 性能、稳定性与安全风险。看需求是否带来新的性能压力或攻击面，缓解方式是否明确。证据是风险清单与对应的缓解措施，未缓解的风险要标注为条件。
每项检查的完成标志是：有证据、有结论、有遗留条件。三项齐全，技术维度才算判断完毕。
业务、经济与合规三个维度分别看什么
只做技术判断就下结论，是可行性分析最常见的偏差。技术可行只说明“能做”，业务、经济、合规回答的是“该不该做”。
业务维度看三件事：目标用户与使用场景是否清晰，需求是否与产品目标一致，现有替代方案是否已经够用。证据来源包括用户访谈、反馈记录、使用数据和对现有方案的对比分析。责任人通常是产品负责人。业务判断的常见结论是“值得做”“需缩小范围”或“不建议做”，缩小范围时要写明保留哪部分场景。
经济维度看成本构成、收益口径和机会成本。成本包括人力投入、采购费用和上线后的运维支出；收益要给出衡量口径，例如节省的工时、减少的差错或带来的收入，并说明回收周期。机会成本指同一批人力和预算投入其他需求可能带来的结果。证据来源是估算表和历史项目数据，责任人通常是项目负责人或业务负责人。
合规维度看数据与隐私、资质许可、合同与监管约束。个人信息如何收集和使用、数据是否跨境、业务是否需要特定资质、合同是否限制数据处理方式、行业监管是否有额外要求，都需要逐项核对。证据来源是数据清单与流向说明、法务或合规人员的意见、相关资质要求文件。责任人通常是法务或合规负责人。
任一维度不通过时的处理方式应当事先约定：技术不可行可以考虑替代实现路径；业务证据不足可以补充调研后再判；经济不划算可以缩小范围或暂缓；合规不通过则必须调整方案或放弃，不能以“上线前再补”的方式绕过。把处理方式写进结论，比只写一个“不通过”更有用。
可行性结论形成后，需要被记录、流转并带入评审。在 ONES 中，需求可以作为工作项承载这些信息，把四个维度的判断依据和遗留条件随需求一起流转；ONES Assistant 可围绕用户反馈、会议记录和文档提炼要点与待澄清问题，帮助团队在澄清阶段更快形成判断材料，具体可用范围以实际部署与配置为准。
和需求建模、需求评审有什么区别
三个概念常被混用，它们回答的问题和所处阶段各不相同。
| 活动 | 回答的问题 | 主要产物 | 先后位置 |
|---|---|---|---|
| 可行性分析 | 要不要做、能不能做、代价是否可接受 | 带依据的推进判断与遗留条件 | 最先进行 |
| 需求建模 | 需求如何结构化表达 | 用例、流程、规格说明等结构化描述 | 可行性通过之后 |
| 需求评审 | 表达是否完整、一致、可验收 | 评审意见与确认结论 | 建模完成之后 |
三者的衔接点在于结论的传递。可行性分析给出的条件，例如“需先完成接口改造”“需取得数据使用授权”，应作为建模的输入约束，并在评审时作为检查项核对是否已被满足。把可行性结论带入评审，评审就不只是检查文字质量，还能确认需求的前提是否成立。反过来，如果跳过可行性分析直接建模，评审阶段才发现某条需求在合规上走不通，前面的建模工作就要返工。
一个例子：同一需求在四个维度上的判断
以下为演示情景，用于说明判断过程，不代表真实项目。某内部管理系统提出需求：接入外部征信数据，在客户建档时自动核验企业信息，减少人工查询。
技术维度。现有系统需要新增外部接口调用和结果缓存，架构上属于常规改造，团队有类似集成经验。关键依赖是外部数据服务商的接口，需要确认调用频率限制和返回字段是否满足核验要求。结论为有条件可行，条件是接口联调通过并确认限流方案可接受。
业务维度。人工查询目前每单耗时较长，建档环节确实存在等待。目标用户是客户经理和审核人员，使用场景清晰，与系统“提升建档效率”的目标一致。结论为值得做。
经济维度。成本包括接口调用费用、开发人力和后续运维；收益按每单节省的查询工时折算，并考虑差错减少带来的返工下降。测算显示回收周期在可接受范围内，但调用量超出预估时费用会上升。结论为投入产出可接受，条件是设置调用量监控。
合规维度。征信数据属于敏感信息，需要确认数据使用的授权基础、传输与存储方式是否符合要求，以及合同是否允许该用途。这一项在初期未确认，结论为有条件合规，条件是取得法务确认并完成数据流向说明。
综合结论是“有条件可行”，条件写清楚为：接口联调通过、调用量监控上线、法务确认数据使用方式。三个条件分别对应技术、经济、合规维度，任何一项未满足，需求都不进入开发。
这个例子也暴露了几种常见误解。只做技术判断，会得出“能做所以做”的结论，忽略调用费用和数据授权。把合规留到上线前处理，可能导致方案推倒重来。把可行性分析当成拍板，则会让结论缺少依据，后续无法复核。这些误解带来的返工代价，往往比前期多花几天做判断高得多。
常见问题
四个维度都要做吗，能不能只做技术判断？
四个维度建议都过一遍，但判断深度可以按需求风险调整。技术可行只说明“能做”，业务维度回答“有没有人用”，经济维度回答“划不划算”，合规维度回答“允不允许”。只做技术判断，容易得出“能做所以做”的结论，忽略调用费用、数据授权或使用场景不足的问题。高风险需求可以在合规维度投入更多精力，创新型需求在业务维度需要更扎实的用户证据。
结论是“有条件可行”时，条件应该写到什么程度？
条件要具体到可核对、可关闭。写清楚需要满足什么、由谁负责、以什么证据作为满足标志，例如“接口联调通过并确认限流方案可接受”“法务确认数据使用方式并完成数据流向说明”。条件与对应维度挂钩，任何一项未满足，需求就不进入开发。把条件写进结论并随需求流转，后续评审时才能逐项核对是否已被满足。
合规维度发现问题，能不能先上线再补？
不建议。合规不通过通常意味着方案本身需要调整或放弃，例如数据使用的授权基础不具备、合同不允许该用途、业务缺少必要资质。这类问题留到上线前处理，可能导致方案推倒重来。更稳妥的做法是在可行性阶段就请法务或合规人员给出意见，把整改项写成条件，条件满足后再推进。
可行性分析的结论怎么带到后续的建模和评审？
结论中的条件应作为建模的输入约束，例如“需先完成接口改造”“需取得数据使用授权”，在编写用例和规格说明时一并考虑；评审时把这些条件作为检查项，核对是否已被满足。可行性结论形成后需要被记录和流转，在 ONES 中，需求可以作为工作项承载四个维度的判断依据和遗留条件，随需求一起进入后续环节，具体可用范围以实际部署与配置为准。
需求可行性分析和需求评审是什么关系，能合并做吗？
两者回答的问题不同。可行性分析判断“要不要做、能不能做”，发生在建模之前；需求评审检查表达是否完整、一致、可验收，发生在建模完成之后。合并做会让评审同时承担方向判断和文档检查，容易两头都不到位。更合理的做法是先完成可行性判断，把条件带入建模，再在评审中核对条件是否满足、表达是否达标。
