用人物、时机、目标和痛点把功能名词还原为可判断的需求

一句话提醒

“支持批量上传”只是功能名词；补上谁在什么时候、为了什么以及当前遇到什么痛点，才能判断真正要解决的问题。

为什么今天看它

• 同一句功能需求放在不同人物、时机和目标下，可能代表完全不同的问题；没有场景，就难以判断需求含义与优先级。
• 把原始功能表达补成具体工作情境，可以看清当前流程的成本和风险，避免只按功能名词设计方案。

留一个问题

谁在什么条件下提出这项需求？他要达成什么目标、当前遇到什么痛点？如果不补齐这些场景信息，我们凭什么判断需求含义和优先级？

参考思路

1. 1.从功能名词或原始诉求中识别实际使用者及其角色。
2. 2.补充需求发生的时间、条件和触发情境。
3. 3.明确使用者要完成的目标，以及当前流程卡在哪里。
4. 4.描述现状带来的时间成本、遗漏风险或其他具体影响。
5. 5.把需求改写为“谁在什么场景下，为了什么目标，因为什么痛点，需要怎样的支持”，再评估方案与优先级。

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md