从需求分析看软件开发的挑战----谈最近的学习感想

        截止到12月10日，我通过高级软工课程的学习，系统的回顾了一下软件系统中的各种设计、建模思想，并用UML、Contract、OCL等去表达出来。虽然自己之前有一些开发、架构的经验，然而这些方面还是欠缺的。其实不单单是像我这样已经离开学校好多年的，上周帮实验室研三的几个师弟review他的毕业论文，发现其实很多同学对于系统的各种模块、交互应该如何表达，还是非常模糊的。画得图都非常随意，每个人的论文中，系统流程图都好多种制式。考虑到大部分硕士同学都是要做系统而不是纯算法、研究性质，所以建议他们都需要选修下软件工程这门课。用实验室老师的话说，软件工程的标准相当于是共识，用共识去描述自己的系统，才能让别人更好的了解自己的论文工作。

      我们组选的项目是社区疫情防控系统。先谈谈之前工作中做需求分析的经历：

1、如果是做To B类的系统需求，都是要和客户的业务人员进行沟通，并反复多轮地确认需求。很多业务人员其实也不太能确认系统应该有哪些功能模块、具体采用什么形式来交互。所以一般产品经理会根据初步的沟通，并结合自己的理解画系统原型图（高保真），完成之后会再和客户沟通，让他们在高保真原型系统中进行二次确认。确认好之后，产品经理会将原型图和PRD（Product Requirements Document）文档交给研发团队，研发团队再基于需求进行设计、开发。

2、如果是To C的产品，首先是产品经理做一个MVP（Minimum Viable Product）需求交给研发，研发3,4人的小团队，基本上不会做太多设计，直接开发上线，并让运维同学切1/100或者1/200流量到新产品上。之后会抓取用户的行为，做用户行为分析；也会邀请目标用户到公司的生理实验室中，结合眼动测试等对产品进行使用、访谈等，已这些为依据持续迭代产品，一般一周一个迭代（当然前提是一段时间后客户存留等相关指标特别好，才会继续优化产品，否则可能就说明这个方向其实只是伪需求，用户并不感兴趣，产品就会被砍掉）。产品经理也会和线上运营、架构师等一起评估未来用户的增长曲线，据此要求研发把单体系统按服务进行拆分做成微服务架构，以应对大流量高并发的用户场景。

        课程大作业中的社区疫情防控系统，是个to B的系统，但是并没有实际的用户能提需求，需要大家发挥想象力，站在用户的角度上去想需求，然后根据需求设计用例、细化模块、流程等等工作。我们开始的时候有些畏首畏尾，因为这个系统需要做代码实现，所以很多场景如果考虑的太过周详，后面系统开发的工作量大家评估了下，就不能在寒假前完成了。后来通过和老师沟通，了解到前期模型设计完之后，最后可以找一些关键的用例来做实现，而不用完全把前期的设计全部实现。了解到这些之后，我们组才放开思路去考虑系统中的详细需求。

        下一个遇到的问题就是大家领域知识的匮乏，对社区的管理流程、国家对于基层疫情防控的要求都不了解。然而这两方面的领域知识，对这个社区疫情防控系统的需求分析又是非常必要的。我们进行了一部分资料的搜集和学习，不过临阵磨枪可能考虑的还不是那么周详，只能后续再持续迭代和完善。

        最后遇到的问题就是，如何把系统的功能、流程等等使用UML图的方式表达出来。这个也是大家欠缺的，对各种图的表示方式不是很了解，很多场景用语言能表达清楚，但是转化成活动图、时序图就不知道怎么描述了，即使最后画出来了，很多想到的点也无法在图中很明确的表达出来。这个也是我们需要持续联系、提高的地方。

        老师12月10号的课讲了contract和OCL的一些知识，我们下一步就利用这两个标准来继续丰富我们的设计。希望大家在完成这门课的时候都可以有所提高。