software-design-demand-survey-methodology

# Demand Survey Methodology ## Overview This is the `architect` profile's **需求调研阶段方法论 skill**. It is the correct entry point when the architect must start from the original business problem rather than from an already-approved design package. ## When to Use Use when: - the business problem is still vague - there is no reliable demand-research document yet - the architect needs to clarify current state, target state, benefits, risks, red lines, and ROI before solution design starts ## Canonical Stage Doctrine (Full Preservation) # 一、需求调研 **时间**：需求或者问题发生并提出时 **输入**：业务方&各参与方问题、需求与痛点 **输出**：业务需求调研文档 **过程**： 需求承接过程中，另外一个目的是**帮业务方解决问题而不仅仅是回答问题**，多聊几句多往前走几步，了解其核心诉求、前因后果后进行全局规划。一些无脑需求需要让需求方梳理清楚**现状是什么样的、希望做成什么样、能够带来哪些收益**，由此进行开发工作量评估与ROI确认。 |角色|阶段|类型|问题|答案| |---|---|---|---|---| |业务方|- 需求了解 **基于什么背景有什么问题，想要我们做什么**（我们能做什么）|who|什么团队、做什么业务？|| |||why|业务背景是什么？|| ||||现状是什么/有什么问题（核心诉求）？|| ||||希望做什么改变并带来哪些收益？|| ||||这个需求是否涉及资金安全、权限、合规、审计、外部监管或其他高风险场景？|| |研发|- 需求评估 基于问题和期望，**评估哪些能解决**、哪些不能解决|what|评估哪些能解决？ _**用什么方案解，收益是什么**_|| ||||评估哪些不能解决？ _有没有其他方式解，业务能否接受_|| ||||这件事情的业务红线是什么？哪些结果是绝对不能接受的？|| ||||如果方案失败，失败成本是什么？影响范围、影响对象、恢复要求分别是什么？|| ||||开发工作量评估与ROI确认|| ||- 方案梳理 不用一上来就满足所有诉求，避免投入没有产出|how|面向业务方可理解的解决方案是什么？ _提供结果预期，给出衡量指标_|| ||||推进策略是什么？ _优先满足当前最迫切、最能给解决问题的部分_|| ||||有哪些todo事项、跟进人是谁、截止日期是什么时候？|| ||结果交付||业务需求调研文档 _包括需求背景、需求评估、方案确认、调研总结等_|| ## Architect Execution Layer ### What this stage really accomplishes This stage converts business complaint / wish / requirement into a designable...