软件需求工程与uml建模 项目记录(4)

本周工作进展

本周我们小组在周四下午进行了小组会议。经过我们的讨论，我们进一步更新了需求以及画出了我们小组项目北理校车的状态图，具体如下：
对于之前提到的每辆车为老师预留五个座位，具体的实行措施就是如果校车每趟校车由5个教师专用位和其他的普通座位组成，如果老师预约成功，则教师专用位减一个，如果教师专用位5个满员（即有五位教师预约成功），则剩余的普通座位老师和学生的优先级相同，如果一辆车的预约者都为学生，那么在只剩余最后5个教师专用位的时候学生不再有预约的权利。
为了方便用户及时反馈自己的意见以及给用户带来更好的体验，我们经过讨论开放了留言功能，以方便我们及时对不足的地方做出一些改正，用户可以在留言区发表自己的意见以及对我们的一些建议，我们的管理人员也会及时阅读以及回复，用户也可以查询自己的留言信息以及留言状态。
新增选座界面

状态图

项目后期计划

第五周：交于甲方验收，确保实现功能

小组成员分工

冯毅伟：组长，负责与甲方沟通交流，绘制状态图
刘泽鑫：负责博客内容以及博客的管理
王流洋：负责项目文档的编写
徐柏麟：负责总结小组的工作
沈洪宇：绘制状态图，编写文档

工作小结

这次项目需求我们一共有三次汇报展示，四次的项目文档的完成。每一次的工作都是由易到难，由简单到复杂。但是经过了整个完整的一次需求分析，认识到了需求的获取和需求的分析并不是那么看似简单的。任何一个需求都需要按照那样的标准的过程才能够真正的了解到一个项目究竟他的需求是是什么。
首先便是需求的获取。我们了解到需求的获取并不是简单的。作为软件的开发人员，所想所知和用户是有很大的区别的，用户往往不能够以专业的眼光去看待一个需求是什么样的，他们大概会说这个要怎么样，那个要怎么样，我们很难从他们的语言中分析得出准确的东西，这就要求我们和用户之间建立良好的沟通关系，并且要注重交流方式在需求获取中的作用，更加的了解到用户对于需求的期望等等，在这个过程中，又不免会产生很多问题，例如需求的范围，或者需求的完备性等等。为了更好的解决这些，我们在整个的需求分析中，采用了线上线下结合的方式，并且保持一个和用户的畅通而且长期的交流。
其次便是在对需求有了一定的了解之后，便会容易的发现在需求中，一些问题并不是明确的，仅仅是通过和用户的交流并不能解决问题。这需要我们对于问题的分析。例如这次我们对于校车项目的工作，我们收集了关于同学或老师们使用校车的一系列数据，并且通过问卷的形式了解他们对于校车的需求。这时我们发现问题会越来越复杂和精细。往往考虑得越多，就会发现之前的问题的需求越不完善，这时又要回到同用户的交流才能解决这些更加明确更加精细的问题。
经过这次的校车的需求的分析，我们学会了很多。在对需求的获取上，方法论的思想是很重要的，这不仅仅是需要硬数据的收集，也需要我们自己的分析，细化，对其中数据建模，对其过程建模。对于一个需求，要整体加上细节，两者要齐头并进，整体是我们对于整个需求的前景和范围等等的把控，细节是我们对于问题的明确，对于数据的采集等等。包括一系列的建模方式，这些都是一个需求分析的方法论的基础。其次便是一个团队的合作。这次的需求分析有多小的内容，一个人的话，很难的有限的时间里完成这些细节。包括对于项目文档的管理，对于博客的管理等等。于是，这个时候我们就了解到了团队合作的重要性。