需求分析中的“状态”到底该如何分析？5分钟给你说清楚！

一般来说，和流程相关的状态都是有限状态机。

有限状态机首先就是状态的数量是有限的。

以下图为例，

动作和状态的命名之间容易产生混淆。

为了避免混淆建议把状态变为“过去式”，而动作采用动词原形，这样就可以明确的区分状态和行为了。

比如：状态改名为

开 —>  已打开

关 —>  已关闭

另外有一种情况，就是在状态的命名中，采用了“待”和”中“。

比如：待审批，审批中。

这些都是不好的命名方式。这会导致真实的状态理解不正确。

这样的命名，也会产生对一个状态进行多次命名，导致了状态的冗余的问题。

比如说，申请 - 审批两个节点的流程。

命名状态为：

未申请，待审批，审批中，审批完成

其中的 待审批和审批中其实是同一个状态。

而这两个状态的重复的产生的原因就是对于状态的命名没有规则造成的。

如果改为：

未申请，已申请，审批已通过，审批已驳回

则不会产生上述问题。也不至于产生误解。

因为待和中本身并不能表明真实的发生的事件，而真实的发生事件却能够明确的表明真实的状态。

但这并不表示从来都不能用中和待来向用户展示，向用户展示的文字和系统内存储的状态可以不一致。

甚至可以发生，多种内部状态对应同一种文字展示给用户。

比如说，贷款审批手续进行中，ATM取钱的逻辑等，内部要详细记录准确的状态，而对外给用户展示就是一个“贷款审批中”，“出钞中”就可以了。

内部状态可以用于实际的日志分析等用途。而无需将细节展示给用户。

有的时候流程分为主流程和子流程。

主流程的状态是主状态，子流程的状态是子状态。

主状态的值受子状态的值的影响。

比如说，出国申请手续。

员工申请了出国，领导审批通过了，员工还需要进行机票购买，酒店预定，签证办理等各个手续。

每个手续都完成之后，主状态才是达到了出国手续完成状态，中间过程都是出国手续办理中状态。而在这之后，万一发生了机票退订，酒店退订或者签证注销等各种事项，也一样会影响主状态，而不是仅仅一次完成就之后不再变化。