需求分析心得——4班凌云天际网络工作室

一、团队

团队名称：凌云天际网络工作室

团队成员：陈啸天、李匡源、雷明、钱靖熹、王敬懿

二、团队项目信息

1. 项目信息

1. 项目名称：大国工匠活动报名小程序

2. 项目指导老师：陈浩

2. 项目描述

1. 2020年12月，“中国少数民族用品协会民族工艺美术分会”在厦门成立，在实体拓展及平台搭建方面取得切实成效，为进一步深化巩固成果，激发广大会员的参与合作热情，获得归属感和荣誉感，繁荣民族工艺美术，特策划举办2021“民族好礼、民族工美视窗、民族工美英才”推选活动。本活动将在专家评审委员会指导下开展工作，同时与中国轻工业协会旗下“大国工匠”的推荐评选相关联。
2. 本项目开展目的是收集推选活动的线上报名信息，为各行各业各地区的活动参与者提供报名信息，便利活动参与者与评审方的信息传递，同时也为评审方及相关部门收集并筛选报名信息提供技术支持。

三、需求分析

1. 需求分析原理

1. 需求分析，是开发人员经过分析，理解用户和项目的功能、性能、可靠性等要求，把用户对待开发软件提出的“要求”或“需要”， 包括软件的一些非功能性需求，进行分析与整理，形成描述完整、清晰与规范的文档的过程。需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节。
2. 需求分析阶段工作分为四个方面：问题识别、分析和综合、制定规格说明、评审。
3. 问题识别是从系统角度来理解软件，确定开发软件的要求，需求的实现条件，达到需求的标准。
4. 分析和综合是逐步细化软件的功能，找出各功能之间的联系，分析功能是否满足需求。
5. 指定规格说明是制定需求规格说明书。
6. 评审是对功能实现面对需求进行评价。

2. 需求分析过程

1. 在需求分析过程中，首先通过与老师交流了解到项目所需功能点
2. 之后，我们建立了项目微信群，并与专门负责该项目的研究生学姐共同讨论
3. 在对活动策划书进行详细分析后，我们画出总用例图如下：
   
4. 之后与其他组员以及老师、学姐的讨论中，我们分析出了一些不合理的需求，如对于初次未评审的作品，管理员不能直接评分，应该先由评委先评分后，给管理员提供可以修改的功能。
5. 最后我们详细书写了需求分析文档，部分截图如下：
   

四、心得体会

1. 关于团队合作

1. 在大国工匠报名评审小程序的需求分析过程中，整个团队成员都积极参与。
2. 首先，PM组织团队成员与客户（由老师邀请）交流意见及各项要求后，在团队每周会议上，大家共同讨论，列出该项目的需求；再查找多个小程序补充了参考信息；最后大家多次开会讨论、多次与项目老师进行沟通，确定了基本的需求，包括注册、登录、修改密码、查询、报名、评审等基本需求。
3. 接着大家根据基本的需求制作UI原型。在制作UI原型的过程中，考虑到用户的交互友好，再次对项目需求进行修改和补充。主要由负责前端的同学进行原型绘制。原型让所有团队成员对于项目实现目标有了清晰且统一的认识，推动了项目进展。

2. 关于UML图

1. 为了使小程序功能在需求文档中展示直观，我们绘制了UML用例图，会议中成员之间也有争论，对于include和extend的关系，大家都有自己的看法，我们经过上网搜索、借鉴案例以及沟通，最后大家对概念的理解达成了共识。
2. 同时，我们对于用例粒度大小、内容增减也展开了讨论，最后大家将想法进行汇总和筛选，挑出相对较好的方案作为最后的解决方案。在需求讨论阶段成员之间意见分歧是一定会有的，但也恰恰说明大家都积极参与了项目构建，此时要做的就是将大家的看法进行筛选和保留。
3. 另一方面，在争论和协商的过程中，成员间增加了交流，对项目也有更深的了解，有了更明确且统一的目标。成员间的坦诚交流，遇到问题时积极解决的态度，合作时的相互理解和信任，这些让我们避免了冲突。

3. 关于文档

1. 以上任务完成后，我们为需求文档做到了较为充足的准备，开始编写需求文档，PM规划好了提交文档的时间，由团队全体成员分工编写，提前截止日期两天形成需求文档。
2. 接下来大家又对需求文档进行了一定的加工、润色，在截止日有条不紊地完成文档上交。
3. 提取UML用例图、活动图、顺序图、类图等，又是对需求的再一次检验。
4. 同样，项目需求是不断变更的，因此每一次的讨论都是对上一次结果的重塑，且现在所完成的需求文档也可能并不是最终实现的项目的需求。我们也做好开发过程中不断讨论、不断更改的准备。

4. 关于分工

1. 在完成这些工作时，仍然有许多不同的问题需要解决，每个人都很忙，但是合理规划时间、合理分工、各成员的合力高效都为我们自己争取了交流和进步的时间和空间。
2. 可以看到，需求文档的编写为成员之间相互磨合提供了很好的体验机会。

5. 小组特色

5.1 持续集成

1. 使用gitee进行代码版本控制
2. gitee上的代码开发分支尽可能每日提交，主分支确保每周汇总合并
3. 确保每次提交的版本，程序可以正常运行
4. 如下截图为gitee前后端代码仓库：
   
   

5.2 API接口规范

1. 在需求分析基本完成后，由于我们是前后端分离的项目，前后端是独立开发，需要规定好API接口
2. 通过腾讯在线文档，我们制订了小组内部的公共API文档
3. 前后端的数据交互必须严格遵守此文档
4. 由于有API文档，前后端独立开发，大大降低了后续的开发成本，开发速度也显著提高
5. 如下为部分API接口文档截图：
   
6. 我们也通过该文档，可以定量定人，详细指导每周的开发任务，十分便捷有效