从前，当有系统分析师的角色时，系统分析师负责需求、逻辑分析和解决方案。
在产品经理时代，相当一部分系统分析师的工作统分析师的工作。产品经理的角色是：用户和开发人员不仅要了解客户和业务，还要了解一般的开发逻辑。这样，系统分析师的初级能力就可以尽可能接近。
从需求到的需求和业务计划需要哪些核心步骤和因素？我们以锁库为例解构这一过程，共同提取步骤和因素的要点。
- 原始需求：客户希望锁定库，销售核心保证订单，并在订单执行前锁定库。
- 总结分析:需求方向明确:锁库；需求细节模糊；没有完整的逻辑。
- 重点思考:如何应对方向明确、业务场景强、细节模糊、结构不完整的需求？分析以下五点:
一、产品经理需要明确理解
用户提供的需求往往是碎片化的。我们需要补充碎片：
- 业务逻辑：上下文（或前后相关业务）、岗位、职责、异常处理、设备载体（PC，手机，打印纸)
- 数据逻辑:角色、权限、状态机、数据动作、看门狗
- 泳道图：当需求涉及多个角色和多个状态时，业务流程最清晰地表达
- 流程图：程序处理的主逻辑
二、基于现有软件的逻辑分析
实现需求的前提必须基于现有软件系统的逻辑。
也就是说，我们不能与现有的逻辑或现有的术语、定义或操作习惯发生冲突，因此我们必须在熟悉当前软件数据结构的前提下做出可行的想法。
锁库的核心要求：在发货时，可以保护锁库的数量不会发出。两个可行的想法：
A：虚拟库方案：
- 建立虚拟仓库A，专门用于存放锁产品
- 锁仓时，所有锁仓产品都转移到仓库A
- 锁库产品出库时，从仓库A出库或转移到正常发货仓库
- 其他出库时，由于锁库产品在专用仓库，无需特殊验证
B：锁：
- 新的锁库明细表用于承载锁库数据
- 锁库创建锁库明细数据时
- 出库时，判断条件增加锁库数量
方案比较:在比较方案之前，需要将方案细化到具体的功能描述和数据结构，尤其是状态机。只有在方案层进行细化，才能避免在两套方案的细节之后遇到不可逾越的逻辑卡点。
A：虚拟库方案：
优点：无新表，基本上是原逻辑的组合；
缺点：虚拟库 分配过程比较复杂，从用户理解的角度来看会觉得不太直接。
B：锁：
优点:业务意义明确。虽然执行逻辑增加了验证，但整体理解更加顺畅；
缺点：新数据表：锁库明细。
摘要：该功能是为了解决用户问题。一般来说，我们会从用户的角度选择易于理解的解决方案，除非它是一个完全没有交互的背景功能。虽然锁库增加了物理表（除非有必要），但显然有必要进行比较。
三、根据经验补充完整的逻辑
在此，主方案思路确定：锁库明细表方案。继续完整的逻辑：
1)锁库有锁，需要解锁
2)解锁的情况很多
- 手工解锁，如取消订单；
- 发货解锁，已发货，无需继续锁定；
- 过期解锁，锁库不能没有期限，虽然手工解锁可以弥补，但加上期限自动化程度较高。
3)锁库的角色权限
- 销售锁库；
- 库管确认锁库；
- 库管可手工解锁。
四、根据场景业务推演，查漏补缺
补充完整逻辑后，需要总结业务功能的要点和场景:
1)销售根据订单明细申请锁仓，由库管确认；
2)仓库管理确认后的锁库将参与出库验证；
3)出库验证算法为:库存-锁总量 当前出库明细对应的锁库明细量。即：出库自动解锁当前锁库，因此在检查锁库数量时，需要去除当前锁库数量；
4)锁库超期自动解锁(粒度:X天）。
五、异常情况复盘，查漏补缺
上述主体结构已经比较完善，仍然需要根据所有步骤相关的数据表找异常数据情况做一遍复盘：
1)如果当前库存不足，是否允许锁定库存？
其业务逻辑是：虽然库里没有，但我需要提前锁定，因为这个客户重要。
2)如果当前库存不足以锁定所有库存，且当前库存有锁定库存，是否允许当前库存？
其业务逻辑是：库存不足以全部锁定库存，但足够我的单锁库数量，让我出去吗？
不难看出，上述问题出现在数据异常时（这里的异常是指不满足业务必要条件）；因此，在分析需求时，应特别注意不仅要考虑正常逻辑，还要考虑异常逻辑的处理和容错，这决定了软件的鲁棒性。
分析：
1)库存不足，提前锁定。-业务角度合理，应支持实现。
2)库存不足以锁定所有库存，但当前出库的锁定库是否允许发送？这背后是锁库的优先级：
这里的优先级应该由人们来判断。我们需要增加当前产品锁库的相关细节，而不是严格的逻辑约束，以应对各种可能性。因为锁库本身是出库的高优先级，如果增加内部优先级，会增加系统使用的复杂性，意义不大。
到目前为止，锁定库的需求分析和基本解决方案的确定。为了更容易显示这个过程的结构，中间省略了大量的细节文档。在实际工作中，细节文档的发展非常重要，整体可行性不能用粗线方案来确定。把80%的精力放在20%的关键事情上。一旦打开底层逻辑，程序员将需求转换为代码，可以大大减少不必要的试错！
