云适应问题
描述：
设备每隔5秒上报状态，会冲毁云适应（因为云适应只认特殊SN，设备上报的SN都是随机生成的）；于是对此改为每次修改状态都会保存，每次上报都会对比，如果不同，就下发当初云适应上报的命令；貌似没问题，但是如果是关机或者切换设备，如果这些操作之前是云适应，那么APP就会出现盲等的情况；原来这些情况下，APP会下发一个非云适应的指令，同样SN是随机生成，但是服务器那边下发当初云适应的命令，导致了SN不匹配，APP一直处于等待状态。
分析：
这次问题陷阱在于我们假象了一个条件：设备处于云适应之后就会一直下去，除非状态变化。但是忽略了一种情况：云适应情况下，APP可能会下发查询指令（除了改变状态之外的指令，开机以及设备切换都会下发一个查询指令）；这种情况的忽略一部分是因为对于场景的构建不完全，因为整个场景中其实是有手机-业服-命服-模块；对于手机可变性的考虑不足。问自己一个问题：什么情况下场景会有变化或者不成立；
攻略：
我们对于任何分析都是基于一种场景，需要对场景进行分析，是否只有这一种场景，并且描绘一下整个场景的架构图；
空气质量的1：*的关系
描述：
空气质量报表，在Review需求的时候忽略了一个账户绑定多个APP的情况，导致在去北京的时候没有和一平就这个问题搞了深入讨论；
分析：
其实你会发现如何才能够深入的进行交流其实取决于你对于问题理解的深度和层次；而理解的深度和层次取决于你的角度和分析点：角度是你看待问题的思维方式，分析点是从哪些方面来理解感觉事物。你的角度决定了你的分析点。
攻略：
需求分析其实有几个点，之前的文章中都有描述，这几个点或者说模型构成了你角度，勾勒你的对于需求的理解和认知，没有模型，就没有成型的思路来分析。
和卢声晓讨论拉去信息
描述：
关于同步老平台用户到新平台，当时我给出的方案是一次性把所有的用户信息都同步到新平台，之后每次有新的用户注册，我都同步推到新平台；感觉琐碎的很；卢声晓的方案是用户登录到新的app之后便拉去信息，一次性把设备的绑定信息都给出；
分析：
对于同步的方案有两种：一种是推，一种拉，需要都有考量。
攻略：
同分析动作.
物联网的保存状态
描述：
物联网机器是200万台，备份机器怎么地也需要几十万台。和孙兄聊天，谈到了服务器保存状态的问题，如果宕机的话，如何来保证这台机器的状态同步到备份机器？谈到这话题是因为谈及和oracle架构师讨论性能提及的内存化的问题；
分析：
对于云端分析问题，有几个点，就是故障处理，就像看足球比赛看草坪一样，是骨灰级的人儿考虑的问题，如果你能够想到这个问题，那么你也是骨灰级的人物。
电量问题延续
描述：
电量关机掉线不算开关机时间和电量问题解决了和长时间，这里有两个问题：1. 开关机和电线开始只做了电量不算，没有做时间的不统计；2. 增加了时间的不统计，测试没有充分，只是确定如果上报关机状态的情形下；对于掉线的情况没有做测试；SessionClose方法没有走；
分析/攻略：
对于需求分析很重要的一个方面就是分析出来某个需求里面的核心对象，核心对象里面的关键属性都有哪些，对于需求的每个场景都要对这些关键属性进行分析；比如对于电量而言，核心的属性就是电量值和时间；那么对于各种情况：1.断网断电；2关机；3.不支持各种场景下的情况都需要对电量和时间进行分析，做到没有遗漏；
对于第二个问题，实现的功能点一定要做到测试之后才能发布，或者发布完之后（有些场景确实只能是在测试环境中才有条件，比如此次只有正式的机器才有定时上报关机状态的设备），实现的点一定要测到，对于开发人员所讲的"应该没有问题"一定要杜绝；开发之初就和他们一起把测试的Case整理出来，让他知道要实现的内容是什么；这是一个开发经理所需要做的事情。
离家提醒和1：*问题
描述
根据绑定设备是上传的坐标，APP动态进行调用后台接口，进行分析离家距离（离绑定设备）；隐忧：如果绑定多台设备的话，怎么确定按照哪台设备来进行分析（如果多台设备地点不一致）；
分析/攻略
对象的唯一性是需要关注的；任何分析、操作的对象都要拷问是否具有唯一性，如何获取唯一性标志，获取的唯一性标志是否可能为多个，那么就需要确定规则如何判定优先级；这个问题其实和上面的空气质量报表一样，分析的对象可能是多个的时候，就需要确认一下唯一性问题。
操作的全面性
描述
和海尔的接口人讨论离家、回家逻辑的时候，提到了取配置的接口，对方马上反应到还需要提供设置配置的接口；
分析-攻略
对于有的操作都是成批出现，比如增加-就对应删除和修改；所以客户可能只是应景的想到了一个场景，你要自动补全并联想。
有效性的一致问题
描述
电量之前计算有问题，于是真个存储结构都变了，这里存在一个历史数据问题，曾经纠结了一段时间。后来，想到了本来电量计算就是一个有问题的结构，历史计算也是不准确的，保留这部分数据没有太多的意义；于是讨论结论：历史数据删掉，但是发消息通知用户即可。
问题定位有时效性问题
contractNo不存在，我一直在jsp上面找；但是其实这个错事报在sql上面；我先改的sql（增加了if判断），然后改了jsp，把contractNo（json）变为了sapMatrn，之后出现了问题，我主管认为是因为最后改的json导致的，但其实是sql改到导致的；
执行顺序问题
写了一个共通的脚本，创建菜单、资源数据；根据幂等原则，在创建之前，要先把数据删掉；其中有一个是取得当前某个父级菜单orderNo最大（插入的数据的orderNo是最大值+1）；我是先设置orderNo，后删除数据在插入，问题发生了：要创建的记录可能以及存在，而且最大值可能就是这条已经存在的记录；这意味着获取orderNo+1可能会出现断层情况；只有是先删除记录，再获得Max的orderNo，才有可能准确，或者首先校验是否已经存在，如果存在就是用当前值；
关联性
到货未发货编辑页面；采购工程师如果没变，就没有ID，当时第一个反应时数据库中添加字段；但是后来细细想来:如果ID为空，就意味着数据没有变，因为采购工程师变了，那么一定有数据；如果没变，那么没有数据也可以不予以处理；