什么是业务场景，为什么脱离场景写需求很危险

一句话提醒

没有业务场景，需求就会退化成抽象功能名词；同一句需求放进不同场景里，含义和优先级可能完全不同。

为什么今天看它

• 它能把需求分析从抽象功能名词拉回真实上下文，减少‘要一个功能’但其实没想清楚谁在用、何时用、为何用的偏差。
• 它适合在需求讨论已经开始围着功能转时，逼着大家先补人物、时机、目标和痛点。

留一个问题

我现在说的这条需求，已经有清楚的业务场景了吗，还是只是一个脱离上下文的功能名词？

参考思路

1. 1.先补人物和时机。明确是谁在什么条件下发起这个需求，而不是只写功能动作。
2. 2.再补目标和痛点。说清楚为什么要做、当前怎么处理、哪里真的在痛。
3. 3.最后再判断功能形态。同一个功能放进不同场景，意义和优先级都会变，所以场景先于方案。

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