那么在讨论这个问题之前，要说清楚这个问题，就首先必要的说明，什么是需求建模。

什么是需求建模，怎么认识这个建模。首要的他就是一种行为，一个过程，一个建立模型的过程，其中的动作是建立，目标是模型，合并起来就是建立一个模型，那么需求建模，指的又是什么？“建立关于需求的模型”，可以这么理解，字面上的意思是这样的。也可以拓展到整个软件的生命周期中来，将需求建模，和需求获取，需求分析，需求建模，软件设计等后续流程一并的考虑进来，那么需求建模就是在对需求进行分析过后，使用分析后的信息，建立一个模型，这个模型是为了表达前面所做的工作，也就是这个需求要达到什么（参与者要得到什么，参与者之间的关系等等），同时这个模型能够为后来的软件设计做一个参考，以此来保证整个软件生命周期的活动是连续的，整个软件生命周期是由浅入深，由深到浅的V形。

那么细说软件周期中的需求建模，他是如何利用需求分析后的信息，以及如何建立模型的。需求分析为我们提供了一个规格说明书，其中说明了各个用列场景所发生的事情，以及其相关约束条件，这些信息就相当于砖块，他们的特征是零散的且相互独立的，需要在建模过程中将他们联系起来，作为一个软件系统的模型表达出来。而建立他们之间的联系就成为了首要工作。

1，如何建立各个用列之间的联系：基于场景的分析

用列在一定程度上已经表达了一些场景，但这些场景是分散的片段，他们之间的联系在系统和现实行为上是有关联的，比如系统界面的跳转和用户操纵之间的联系，他们之间的联系是操作，因为场景需要而必然发生的动作。所以通过场景的分析，能够将用列联系起来，甚至到最后能够将所有的用列联系到一个场景中来，当然这样的交叉看起来有点复杂，不利于查看，所以一般来说，场景分析的参与者限制在2-5个是最好的，这样一个场景的可变因素少一点，模型建立起来就简单点。一般我们使用活动图或者泳道图来表达整个需求模型。

基于这样的一种叙事方式，实际上已经能够表达需求模型了，但题目不是说得“行为状态”，那跟场景分析有什么关系。事件行为状态，是一组表达方式，这样的方式是以一种固定的被切割的块拼接一个场景。它的作用主要作为一种辅助表达。特别是当一个场景当中涉及到多种的状态变更的时候，比如我们的订单，他的状态有新建，支付中，已支付，发货中，已收货，退货中，已退货，退款中，已退款等，这里的状态有9种，而对于给予场景的分析来说，他只会对某一种状态建立模型，那么就会有九种不同的场景模型，那么这里事件行为状态就能够派上用场了。

2，行为状态

首先，这种表达方式在我的工作中出现了，并运行良好。

在日常生活中，怎么样表达一个主体他随着时间变化的过程，使得这个表达更准确可信以及具有数学意义，那么莫过于用数据库的acid理论来表达了。（什么？你问我acid是什么？实际上我也不知道是什么鬼）就是用一种严谨的数据科学来表达一个主体（至于数据科学是什么鬼我也不知道，不深究了，多半是我编的）。虽然我们不懂acid是什么，所以我们就可以在这上面做进一步的深究（瞎吹），acid中有两个概念，一个就是事件，一个就是状态。一致性原子性隔离性持久性，他们都是围绕着对于一个实体，他发生的事件以及他的状态来说的。

一个实体后者说一个订单，要从一个状态变成另外一个状态，他必然要经历一个事件，这个事件的发生，让这个状态发生了改变，现实当中的所有事件都是必然发生的，它只会导致一种状态而不会同时出现多种状态，但我们构思的事件是必然发生的，并且还有可能是可拆分的存在中间状态的情况（如果存在中间状态，那么就有必要再次拆分事件，已满足acid），为了表达这样一定会发生的情况，和我们预知情况的关系，出现了这样的一种表达方式。

表达方式：

在某某时刻，某某地点，某某因为某某事件发生而被新建，因为发生了某某事件而变成了另外一个状态等等，这样的描述方式。而之所以这是一种切块，就在于状态（表达一个实体在某个固定时间点持久不变的状态）是固定的，事件在这里也是一个连续固定的事件块，所以他们拼接起来就是时间的连续，而表现出了整个场景。