从需求分析看软件开发的挑战

从需求分析看软件开发的挑战

前言

​ 岁月不居，时节如流，转眼已是学期过半。上周结束了需求评审会，也是时候对过去一段时间的学习做一做总结了。

​ 我们小组的选题是《社区疫情防控追踪系统》，旨在建立一个轻量级易用的追踪系统，满足对生活社区的疫情防控需要，可以追踪社区每天进出的个人、每个人的状态，并能在社区间共享相关信息以实现风险评估和预警传播。并以个人使用的程序（如微信小程序）的形式展现。

领域分析

​ 本科修软件工程课程时，并没有接触过领域分析，所以任务下来，组长给我们分配任务时，多多少少有点摸不着头脑。查了一些资料还是有些似懂非懂，就按着自己的理解写了自己的部分。

​ ……结果果然被批得很惨，很多知识点拿捏得都不准确，文档几近推翻重写。主要的问题有：

• 对领域系统的理解有误，是指领域中已经存在的“系统”（IT系统或者人工系统）

  状态指领域系统的运行状态，需要考虑应对不同级别的疫情的运行模式和状态区别
  流程指领域系统运行时，不同角色之间的交互流程

  领域分析不涉及系统的设计考虑，应专注于领域层次的知识

• 系统的价值如何体现？

  一方面体现在对疫情防控追踪的效率上
  另一方面体现在降低社区防疫人员的工作负荷和提高工作效率上

• 补充：

  从分析来看，似乎描述的是“全国健康宝”，能够实现的是全国范围内的跨社区追踪，功能也非常丰富，不仅包括人员的登记管理，还包括类似“所在地区风险查询”之类的数据分析类功能，系统的边界过大

​ 拿到老师分析的意见后，大家火速在微信群里进行了讨论，总结出我们主要的问题出在定位上，不仅是对领域分析文档的定位问题，大家没有弄懂领域分析是对已有系统，而写成了对我们要做的系统的分析。除此之外，还包括对系统的定位问题（但当时并没有意识到对后者巨大的定位偏差…也直接导致了第一次需求分析展示的惨况）。大家针对老师所提的建议一一分析，认领问题所对应的各自的章节，进行修改。

​ 至此，仅谈领域分析文档部分，大家还是收获颇丰，也算是理解了领域分析文档的意义和写法。

需求分析

​ 选题第一周我们团队便进行了第一次线下会议，简短的认知过后便开始了讨论，并形成了一个简单的分析及任务分工文档。第一次需求分析的分档及领域分析都是基于这个文档所完成的。

​ RUCM也是一个从前没有接触过的东西，为了方便大家版本统一，辛勤的组长为我们准备了安装包放在大家的共享OneDriver里，减少了很多重复的工作。

​

​ 第一次的RUCM作业，我们组做的是“注册用户”、“填报进入信息”这两个用例。在老师的“火眼金睛”下，gank了我们许多的问题，不得不感慨——看懂和真的理解还是有很大的差距——尽管大家在做的时候都仔细看过PPT、教程等资料，但实际做出来的成果还是有许多的问题的，也通过这次机会加深了对RUCM的理解，规避了后续很多的问题。

​ 一步不敢放松，在组长的push下，又进行了新一轮的分工。因为任务较重，团队又进行了一次线上会议，讨论分工，和一些项目细节上的问题。讨论结果是大部分工作一人负责一整块（需求分析是什么、RUCM修改、类图、活动图、顺序图）和部分工作按功能点分工一人汇总（用例图），并继续开展工作。前文中也提到了，我们当时对系统的理解与定位是有巨大的偏差的。我们当时对系统的定位仍是一个【针对全国】社区的防疫追踪系统。在展示时，老师指出了我们对类图的错误理解——缺乏必要的抽象，这个类和代码实现中的类是有区别的，同时犀利地提出了许多细节上的问题，例如：

• 防和控如何体现？

• 不同类型的人员权限？

• 发生疫情时如何定位高风险住宅楼？

• 数据如何上报？

• ……

​ 经过组长和老师的交流，我们才恍悟——原来之前一直理解错了，我们要做的是针对【单个/少量】社区的防疫追踪系统。并在周末进行了新的需求整理，对于新需求中的一些细节（例如不同类型人员划分）疯狂battle，敲定了新的文档，并几近重做了之前的设计。

​ 评审会来临，靠着一波预期管理（手动狗头，第一次展示实在太水辣），这次终于得到了老师的认可：“进步很多！”，大家愉悦地整理新的建议和细节指导，并开始为设计做准备（前期开发的简略demo面临大改…开发人员默默落泪）。

总结

​ 理解需求：需求变更管理是重要的研究方向。从我们之前对需求的理解偏差一事就能看出，面临需求变更时，我们的文档、设计一顿大改，几近推翻重来，大家都多少感到任务艰巨而焦虑。这是因为目前的需求变更管理较弱，主要还是基于人工经验理解变更原因来修改需求文档，生成新版本需求。笔者认为，在建立需求的阶段，可以对需求分析的功能点之间建立关联关系，以便发生变更时对需求变更所影响的范围进行精准更新。

​ 沟通交流：非常必要。就算是同一份文档，不同人读完都会对一些细节有自己的理解，如果不进行沟通交流，就会导致最后的偏差。我们组采取的方式是，队长整理出来的新需求文档，我们每个人读完后复述一遍，对于理解不一致的地方进行讨论。线下讨论也非常地有必要，微信中沟通与反馈不够及时。

感谢

​ 感谢Onedriver！我们的文档撰写以及课程相关模型都保存在OneDriver中，协作工作非常方便！（一波OneDriver硬广哈哈哈哈）
​ 感谢每次都提前很久拿着鞭子疯狂push我们的组长，团队每次都能有相对充裕的时间修改及应付突发状况，以及感谢靠谱认真严谨的队友们（鞠躬）。