之前我们聊过了需求分析的输入-处理-输出模型，以及核心业务对象的识别，今天继续深化一下：
核心对象
到底什么是核心对象？比如设定某个设备周定时任务，定时任务是核心的对象吗？不是。周定时任务作用的对象是设备，核心对象是设备。这样的感知导致的结果是应该将设备从周任务分离出来，而不是周任务的一部分。最初设计的是周定时任务有一个mac地址属性，会将设定的设备使用“，”分割，这样设计设备是作为周定时的一部分；后来因为需要校验周定时的时间重复性，所以需要将新任务最后能够指定的mac地址（多个）到数据库中检索，和时间相匹配，然后在逐个比较mac地址，因为mac地址是使用“，”分割的，所以十分不方便。如果识别出核心对象是设备，并以设备为主体，周定时任务是主体的一个属性，那么就可以规避这个问题。
所以讲到核心对象不要觉得需求讲到什么，就是什么，关键是要看需求最终操作的是谁。
对象组
之前我们主要讲了分析核心业务对象的理念，其实识别核心对象是远远不够的，还要识别其他的业务对象，对于识别对象其实是一个对象组。因为对于业务的驱动是核心业务对象，但是如果你要分析关系就是要分析业务对象组，其实识别出核心对象，然后以它（们）为核心再来发现对象组。比如在周定时的业务中，核心业务对象就是周定时的任务，但是还有客户端（APP），因为这里有一个问题：一个手机客户端和周定时任务是什么关系，1：n还是1:1还是其他？分析关系是识别对象组一个重要方面。
基于对象组的分析
识别对象组之后还有一个作用就是：考虑对象的计算和存储。比如在电量推送的过程，分析出核心对象时每月电量，平均设置温度，用电时间等，对象组是设备，用户以及消息，关系如下图所示：
然后我们一次考虑各个对象的获取过程以及存储方式，对于用电时间，我们就需要考虑他的处理机制是命令服务器记录开机关机时间，然后通过计算时间差来获取用电时间，其实对于输入-输出-处理模式，这对象组分析这里已经将一部分的和行为无关的前置“处理”分析出来了。那么对于这些信息的记录的表结构已久应运而生：mac地址，开机时间，关机时间，时间差，更新时间…，对于对象组的分析还有一个很重要的一点：就是对于物理存储（数据结构）的分析和设计。对于物理存储的分析也是从两方面进行：一个对象本身的存储，还有就是关系的存储。对于wo和wp的存储分析，我们就识别出来其实还是需要将每个月的电量保存起来，因为后来环比/同比的时候是需要这些数据的。然后再挨个关系对象过，设备，是equipment表，设备和电量的关系就是刚才说的需要新建一张表来保存；设备和用户的关系很明确，是userappliance表；至于用户消息，则是内存建立一个list历史保存即可，或者得到一条消息，就发送一条消息，总之用户和消息的关系是不需要持久化的。但是这是老空调，对于黑水晶而言，因为如果用户不在线消息是要存储起来的，所以我们就考虑将用户和消息的关系持久化了。
行为
触发时机：行为是什么时候时候的，是基于时间还是基于事件；
行为的描述：做了什么事情；
输入-处理-输出：不多说了。
约束：需求分析行为的时候还有一个点需要注意：约束。比如XX曲线的命名修改，这样的行为其实隐含了一个约束，就是不能重名。所以在分析过滤每一个行为（功能）的时候，一定要有一个分析约束的意识，这样会使得你的分析更加健壮，对于开发更有指导意义。
约束也是分为很多种类：一类是权限约束，就是对业务对象操作的时候（围绕对象进行分析，这里其实也不仅仅是核心对象了），是否有权限控制，比如修改周定时，只能是修改自己的设备上面绑定的周定时任务，如果因为某种情况下修改的、删除的不是自己权限范围内的对象，需要加上校验，但是对于平台推送的功能而言就没有权限约束；其他的比如上面提到的重命名校验则是业务类别的约束。
行为组
今天我们说一下需求分析行为组：设定行为组和目标行为组。
起因：需求是客户要在手机端实现如下功能，对XX设备设定周定时，可以指定设备在某个时间点（周+时间）的状态。客户给出的需求一般都是比较直观的需求，最初提炼出来的功能点是手机页面初始化的时候获取“周定时”信息，以及对于周定时信息的修改。
后来发现还是远远不够，因为还有周定时的删除功能以及轮询定时信息，时间到了后执行设定状态的功能。
这里引入了一个需求分析的方式：识别出需求的设定行为和目标行为，又因为这两类行为其实是很多个行为，所以称之为设定行为组和目标行为组。在周定时这个功能点中，设定行为组概念可以理解为对于目标行为的配置和查询（增删改查，查询功能是在分析前期比较容易被忽略的行为，需要在分析的时候注意），这里目标行为时间到了（通过轮询实现）执行设备配置的信息（所以目标行为的对象其实是一个“时间-设定”状态这样的键值对）。提出这样的两个行为组的目的就是当我们识别出需求功能/行为的时候要有意识的来全面识别需求行为（功能），比如我们想到了周定时的设定，就是一个设定行为，那么就应该想到它属于的组是设定行为组，那么这个组里面还有什么行为（比如删除），需要分析识别；目标行为于此类似，同样的，当你分析完毕了设定行为组，一定要考虑目标行为组（时间点到了执行对设备的自动操作），因为你的设定行为其实是为目标行为服务的，下一步就需要分析目标行为组。
这种分析的维度其实是和核心业务对象息息相关的，比如“XX曲线名称修改”，在这里核心业务对象就是曲线名称，对于名称而言是没有删除行为的。所以对于行为组的分析一定是基于业务对象来进行的。
关于输入-处理-输出和行为组分析的关系是：IHO（Input-Handle-Output，输入-处理-输出）是对单一行为的分析，所以IHO的进行是在行为组分析之后进行的，后者是交替进行的。
小节
需求分析的基本过程是：识别核心业务对象，识别业务对象组，识别行为组，进行IHO分析，约束分析。其实各个节点都是交替进行的。