编译什么都队需求心得分析

 

前言

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。在我们小组获取需求的过程中，遇到了不少困难，也得到了一些经验教训，现将心得总结如下：

需求分析过程

第一次需求分析

我们组的任务是搭建一个IOT管理平台来作为整个IOT项目的一部分，在项目初期，我们第一次找老师谈话，老师以自己所参与开发的中大IOT平台给我们举例，大致介绍了IOT的现状和问题，给我们展示了中大IOT平台的一些功能。作为第一次需求获得，因为没有经验，我们就以老师所介绍的平台作为我们的目标来搭建原型，同时老师也给我们列了一份IOT的需求分析，如下：

 

 

于是我们根据这一份清单，按照自己的想法构建了原型，再次去找老师确认时才发现千疮百孔，举个例子：在上图中出现了终端管理和终端接入两个需求，但是我们作为初次接触IOT的人，并未完全了解这两个词的含义，我们以自己的理解，认为：终端管理是在逻辑端对终端进行增、删、改、查，终端连接是在物理层面接入终端，但是这样的理解是经不起推敲的：如果作为真实的项目，逻辑端的增加和物理端的增加是不可能分离的。我们也是带着疑惑完成了第一版的原型。

第二次需求分析

第二次找老师继续完成需求分析时才发现我们的想法和老师的想法截然不同：终端管理就是终端的增、删、改、查，而终端接入指的是终端与传感器的一对多关系。而我们所做的完全就是两码事，经过一番讨论后，我们整理到了V2版本的需求清单，并以此来完成需求分析文档初稿和数据库分析设计

 

 

第三次需求分析

第三次涉及到需求分析的方面，是我们完成数据库设计以及α版本设计文档找指导老师确认时讨论得到的，经过一个多月的开发和文档写作，我们也逐步有了一下经验，不会傻乎乎的指着网页或文档来给老师讲我们的想法，我们做了一份IOT流程图去找老师确认，如下： 

这份图的效果非常好，我们可以指着这些图的每一层，对老师说我们在某一层做到了什么什么，某些层的联系又是怎么怎么样的。但是这次讨论我们还是发现了很多问题，老师又提出了新的要求：报警信息应该做成地图，比如湖大综合楼出现异常，在地图上综合楼就应该出现闪烁的气泡，而这是这几次讨论中第一次出现的要求，这也充分体现了需求分析的多样性。

除此以外，我们的API设计也不满足用户（老师）的需求： 首先我们因为是一个大项目抽出的小项目，而老师也不可能给我们真实的传感器和终端作为接入，因此这些都是我们自己模拟出来的，API的目的是用户通过调用API，可以实现这个IOT平台上的一些功能，我们一开始想的是，因为这些设备都相当于是我们模拟出的，相当于是事先存在并定好的，因此不需要做到增删改，所以API我们最初的设想是只需要实现查找功能，但是老师提出了意见：API需要做到增删改查，我们经过讨论才得出方案：事先写好一些不连入IOT的模拟终端，这样可以通过API模拟设备的接入。

 

 

 

心得体会

1.从第一次需求分析的问题可以看到需求分析的一大难点：信息不对称，对于一些名词，程序员的理解可能和用户的理解完全不一致，对一些比较生僻的名词还好，如果这些不易理解的名词，程序员会和用户及时进行沟通，最值得注意的是那些人们认为理所应当的名词，比如对于终端接入，我们当时的想法就是字面意思：终端在物理层面的接入，但其真实的意思是传感器接入终端。从这里我们可以看到，在讨论需求时，最好将每一个点都讨论清楚

2.需求的多样性，第三次需求讨论中，出现了之前没有提到的报警地图闪烁，我个人认为，这个需求应该不是老师临时起意想到的，在前几次的讨论中，我们的原型和功能都和老师的想法有较大出入，因此老师（用户）的注意力大多数都放在了给我们纠错身上，而在第三次的讨论中，确认没有大的问题后，老师才提出了之前忘掉的需求，我觉得这也是大多数需求分析场合的情景：人们的注意力是：错误>新增的，这当然不是说新增需求不重要，相反为了满足用户需要我们应该尽量满足用户的新增需求，所以我们得到的经验教训是，在完成纠错后，也要整个项目给用户展示一遍，而不是单纯的展示修改的部分，因为用户在这个过程中可能会想起曾经忘掉的需求或想到新的需求

3.千万不要想当然,正如我们的API出现的问题一样，在设计产品时，一定不能按照程序员的想法来做，要尽量按照用户的每一个细化的要求去完成项目的设计，不能保有诸如：“这么设计并不方便，还是按我的想法来吧”这类的观念，说到底，最后给钱（分）的，还是我们的用户

存在问题

经过这一段时间，我发现我们组仍然存在以下问题： 我们的开发和文档写作都是尽快投入工作的模式：大家讨论确定出一个大致的框架后便开始分工，针对一些小的，细节的，不影响大局的问题先不做处理，每次想着最后再做细化润色。这样虽然可以保证可以很快的进行开发，但是我们却没有很好的完成以下两点： （1）及时记录细节问题 （2）更新不及时，没有做到及时更改原型或文档 我们往往会留到下一次工作时才会发现之前留下的一些问题还亟待解决，但是因为下一次的开发任务又要开始，因此往往想着再留着之后解决，然而最后的结果是问题越积越多。在之后的开发中，我们一定要改正这个问题