系统分析项目总结1
本次迭代本人所承担的任务
其实这一次迭代的任务很简单，编码主要就是针对设计好的接口，完成增删改查功能并进行数据的传递；至于接口设计，由于现阶段的课程还停留在需求阶段，因此接口设计和数据库设计则完全是拍脑袋的决定了，并无太多参考价值，只能确保系统可以运作起来而已，因此在接下来的内容中，将不会对设计阶段的工作进行过多介绍
文章内容
首先会介绍代码编写中发现的值得参考的点与问题，之后便是关于需求设计阶段的一些个人理解，最后是一些总结性的内容
代码编写
数据库的增删改查
其实也没有太多需要注意的点，上学期在系分课程上，老师仿照java的数据库访问，并结合golang的接口，手动实现了一个数据库的访问库，而考虑到各种问题，我还是选择了使用现成的使用了反射技术编写的数据库访问接口，由于这里是一个实战项目，因此并不指望对各处细节优化那么好，因此xorm足矣
测试遇到的问题
由于这里使用了第三方的mux，因此在测试的时候，暂时还没办法利用原生的httptest来对代码的一个一个handler进行测试，因此计划在之后集成github的CI时，直接对已经运行起来的服务器进行黑盒测试。
需求分析
虽然需求分析并不是由我完成，但是作为项目的负责人，在课上听老师说了一些关于需求分析阶段相关的内容，这里想进行一个总结归纳，从而为之后的迭代提供指导
需求分析的频率
原本以为需求分析是在每次的迭代都需要做一次的，因为所理解的RUP过程，觉得每次迭代都是对上次迭代的内容进行补充，但是在课上听完讲解之后，自己有两个理解，一个就是上面说的，每次迭代开头进行一次需求分析，然后这一次迭代围绕这个需求分析开展；另外一个想法就是先做一个需求分析，然后在完成设计之后，对任务进行分解，再分多个阶段去完成，换言之，就是每次的需求分析针对一个或场景进行，而这并不一定可以在一次迭代中完全完成，而是要经过多次迭代去进行任务的分解从而完成，例如每次迭代完成一个步骤或一个子场景等类似方式。
需求分析的内容
在项目刚开始时候我就致力于找各种模板，什么国家标准啊，什么国际标准啊，致力于把文档内容规格化，但是后来思考了一下，觉得这些根本没必要，只是表面上的内容而已，真正重要的是如何去做一个需求，真正把要做的内容做出来，如果真的要模板什么的，直接套上去就可以了，并不是首要任务。
因此，以我个人的理解来看，需求分析就是站在一个普通用户的角度，或者说使用这个平台的人的角度来看，他们到底要在怎么样的一个场景下，利用这个平台，去完成自己想要完成的任务，这时候就轮到用例出场了。用例是一组相关的成功或失败场景的集合，用来描述参与者如何使用系统来实现其目标。不考虑后面的用例的几个约束条件，我们单纯从定义出发，就应该直到，要想去找到合适的用例，就应该从场景去出发，例如运动记录软件，我考虑用户打卡这一项功能的时候，就应该把用户打卡这一个场景作为一个用例，而不是把某一项步骤，例如提交留言作为用例，因为后者只是一个步骤，没有目的可言。维基百科说，用例也就是
谁可以用系统做什么，因此，结合这几点，一个用例的粒度也就可以很好地划分出来。用例只是用来帮助理解用户需求的，你需要从用户的角度出发，才能理解用户的需求，而这毕竟是一个大的场景的集合，因此，确定完用例之后，你还需要对这个用例进行完整的分析，你可以用完整的用例文本来进行，当然，这个也是最全面的，从各个角度说明了这个用例满足的一切条件；另外你也可以结合设计图进行步骤的阐述，除此之外你也可以用一个流程图的方式去进行讲解。总之让别人能看懂用户想做什么就可以了。
总结
皮一下，没有总结~
算了，还是总结一下吧，虽然对需求分析有了一个大致的概念，但是还是有很多东西存在理解上的问题，希望可以在之后的学习中更加深入理解吧。