团队作业2：需求规格说明书（歪瑞古德小队）
Author：歪瑞古德小队
Project：海岛漂流
一、需求规格说明书
1.1 引言
1.1.1 编写目的
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
1.1.2 适用范围
- 产品名称：海岛漂流
- 适用环境：Android 5.0 +
- 界面语言：中文（简体）
- 适用年龄：12岁以上人士
- 产品功能：提供一个社交平台，允许用户通过写信，树洞，时间胶囊，海岛等多种方式进行社交活动。
1.1.3 术语定义
| 术语 | 解释 |
|---|---|
| 信件 | 本系统中的信件是指以信件的格式书写的计算机文本， 通过互联网在本系统中的用户之间传递信息 |
| 树洞 | 本系统中的树洞是指一个匿名的公共空间，用户以匿名 的方式在此空间留言 |
| 时间胶囊 | 本系统中的时间胶囊是指用户书写的信件可以设定一个 未来的时间开启。 |
| 海岛 | 本系统中的海岛是指每个用户拥有的一个个人空间， 用户可以在个人空间中发布自己的动态 |
1.2 项目阐述
1.2.1 产品功能
用户在这里互相通过写信的方式交流，不仅可以结交笔友，还可以让信件随机发给某个用户。此外，还有树洞，时间胶囊，海岛漂 流等多种多样的社交玩法。
1.2.2 预期用户量
考虑到我们的推广渠道有限，系统预期的用户量为2000
1.2.3 真实性
人们的日常生活离不开社交，各种社交产品成千上万，本产品的真实性不言自明
1.2.4 可用性
本产品面向广大的年轻用户群体而开发，这一用户群体数量庞大，对新事物接受程度高，同时也是在随着互联网发展而成长起来的一代人，早已熟悉QQ，微信，微博等各类社交应用，因此这些用户对本产品的学习成本很低，对于这种新鲜的游戏化社交应用，也具有很大的好奇心和使用需求。
1.2.5 产品价值
在这样一个信息爆炸的时代，人们在互联网中任何一个地方，几乎都避免不了各种广告信息的侵袭，各种精心包装的标题之下毫无营养的软文，各种”大V“和”脑残粉“之间唾沫横飞的论战撕逼。身处这样一个嘈杂的时代，人们需要一款远离喧嚣，专注于内心真实的情感，纯粹的文字表达的社交应用，本产品的价值就在于此。
1.2.6 产品情怀
本产品的切入点是”信件“这样一种原始的交流方式，看似不便，实际上这种具有仪式感的写作方式，更加能够让用户表达自己真实的情感。同时，发送信件的方式，类似于当年微信漂流瓶的方式，这也是一代人的年代回忆。当然，我们也致力于解决微信漂流瓶信息泛滥的弊端，从而给用户呈现一个更完美的产品。
1.3 面向用户分析
本产品的目的在于提供一个更加纯粹的社交平台，促进人们用文字去表达自己最真实的感情。主要面向的是15到30岁之间，希望寻找一个更好社交平台的年轻互联网用户。
1.4 功能需求分析
1.4.1 功能结构图
1.4.2 系统数据流图
1.4.3 具体功能列表
| 功能 | 详细描述 |
|---|---|
| 登录注册 | 用户使用账号密码登录 用户注册一个账号 用户选择忘记密码 |
| 用户信息管理 | 用户修改密码 用户修改头像 用户修改笔名 用户修改邮箱 用户修改签名 |
| 我的邮票 | 用户可以查看自己拥有的邮票列表 |
| 通知 | 用户收到新信件时进行提醒 用户看完通知之后信件状态改变 |
| 书写信件 | 书写新的信件 选择信件的信纸（背景） |
| 发送信件 | 随机选择笔友 选择一个发送的笔友 选择一张使用的邮票 系统根据两边距离计算发信所需时间 发信消耗一张邮票 |
| 草稿箱 | 用户查看草稿 用户编辑草稿 用户更新草稿 用户发送草稿 |
| 笔友 | 用户可以把另一个添加为笔友（不需要对方同意） 用户可以看到笔友列表 用户点击笔友可以看到两人之间来往的信件 用户可以给笔友写信 |
| 个人海岛 | 每个用户有一个自己的海岛 用户可以设置自己海岛的背景 |
| 他人海岛 | 用户可以看到他人海岛的动态 动态可以看到内容，发送时间，发送者，浏览量 用户可以在动态下面评论和回复 |
| 进入海岛 | 漂流：用户可以随机到达一个海岛 用户可以根据海岛名称搜索海岛 到达一个海岛后有一定几率获得邮票和时间胶囊 |
| 海岛列表 | 用户可以看到自己标记过的海岛列表 用户可以在自己的海岛发动态 用户可以标记他人的海岛 |
| 数据统计 | 发送了多少信件 受到过多少信件 在信件中写过多少文字 路过多少个海岛 |
| 创建树洞 | 用户可以创建一个树洞，填写树洞名称，树洞内容 用户最多只能创建5个树洞 其他用户可以查看树洞内容 其他用户可以在树洞下面留言（只能给树洞留言，不能互相回复） |
| 修改树洞 | 修改已经创建的树洞 |
| 删除树洞 | 删除已经创建的树洞 |
| 时间胶囊 | 用户书写一封信 用户可以指定在将来某个时间打开这个胶囊 用户一开始只有3个胶囊 把一封信放进胶囊会消耗一颗胶囊 |
1.5 技术需求分析
1.5.1 开发技术选型
前端技术选型：
| 技术项 | 具体技术 |
|---|---|
| 编程语言 | JavaScript,HTML,CSS |
| 开发框架 | Vue + Router + Vuex + jquery |
| 打包技术 | Weex，webpack |
| 测试环境 | nodeJs + chorme浏览器 |
| 实际运行环境 | Android 5.0 + |
| css预编译语言 | eless |
后端服务器技术选型:
| 技术项 | 具体技术 |
|---|---|
| 编程语言 | Java |
| 通信协议 | HTTP |
| JDK | 1.8.0_202 |
| 数据库 | MySQL 5.7 , Redis 5.0.8 |
| Web服务器 | Nginx 1.17.8 |
| 代码版本控制 | Git |
| 技术框架 | springboot 2.6.0，mybatis-plus 3.0，Maven 3.0 Freemarker |
| 外部接口 | 高德开放平台API |
1.5.2 性能需求
- 系统的平均响应时间应该在500ms以内
- 系统的平均吞吐量应该达到300TPS以上
- 系统应该至少能够承载10万以上的总用户量
- 系统应该支持300以上的并发用户数
二、团队计划和分工
2.1 团队Github仓库
2.1.1 仓库地址
https://github.com/gdut-very-good
2.1.2 issue截图
2.2 修正前的团队计划
| 序号 | 功能 | 功能详情 | 时间安排（开始到完成） |
|---|---|---|---|
| 一 | 登录注册 | 4.30-5.2 | |
| 1. | 用户使用账号密码登录 | 使用账号密码登录 | 4.30-5.1 |
| 2. | 用户注册一个账号 | 进行注册操作 | 5.1-5.2 |
| 3. | 用户选择忘记密码 | 进行忘记密码并修改密码操作 | 5.2-5.2 |
| 二 | 用户信息管理 | 4.30-5.2 | |
| 1. | 修改密码 | 修改密码操作 | 4.30-5.1 |
| 2. | 修改头像 | 修改个人资料操作 | 5.1-5.2 |
| 3. | 修改笔名 | 修改个人资料操作 | 5.1-5.2 |
| 4. | 修改邮箱 | 修改个人资料操作 | 5.1-5.2 |
| 5. | 修改签名 | 修改个人资料操作 | 5.1-5.2 |
| 三 | 信件模块 | 4.30-5.8 | |
| 1. | 书写新的信件 | 写信，选择书信背景 | 4.30-5.1 |
| 2. | 发送信件 | 1. 随机选择笔友 2. 选择一个发送的笔友 3.选择一张使用的邮票 4. 系统根据两边距离计算发信所需时间 5. 发信消耗一张邮票 | 5.2-5.8 |
| 四 | 草稿箱模块 | 5.3-5.4 | |
| 1. | 用户可以看到所写的未发送信件列表 | 可以看到未发送的信件列表 | 5.3-5.3 |
| 2. | 用户可以查看草稿，编辑草稿，更新草稿 | 1. 查看草稿 2. 编辑草稿 3. 更新草稿 | 5.3-5.4 |
| 3. | 用户可以将草稿发送出去 | 发送草稿 | 5.4-5.4 |
| 五 | 笔友 | 5.2-5.3 | |
| 1. | 用户可以将另一个人添加为笔友 | 不需要对方同意，将对方添加为笔友 | 5.2-5.2 |
| 2. | 用户可以看到笔友列表 | 查看笔友列表 | 5.2-5.3 |
| 3. | 点击笔友查看两人来往信件 | 查看两人来往信件 | 5.3-5.3 |
| 4. | 用户可以给笔友写信 | 发送信件 | 5.3-5.3 |
| 六 | 我的邮票 | 5.8-5.8 | |
| 1. | 用户可以查看自己拥有的邮票列表 | 查看邮票列表 | 5.8-5.8 |
| 七 | 海岛模块 | 5.3-5.8 | |
| 1. | 个人海岛 | 1. 设置海岛背景 2. 发表海岛动态 | 5.3-5.5 |
| 2. | 他人海岛 | 1. 查看他人海岛动态 2. 看到动态内容，发送时间，发送者，浏览量 | 5.5-5.5 |
| 3. | 进入海岛 | 1. 随机漂流进入海岛 2. 根据海岛名称进入海岛 3. 到达海岛后随机获得邮票和时间胶囊 | 5.5-5.7 |
| 4. | 海岛列表 | 查看自己所到达过的海岛 | 5.7-5.8 |
| 八 | 测试 | 对已开发的功能进行测试 | 5.1-5.8 |
2.3 修正后的团队计划
团队计划的整体时间安排分为三个迭代计划：
| 版本名称 | 开始时间 | 发布时间 |
|---|---|---|
| Alpha 1.0 | 2020年4月30日 | 2020年5月09日 |
| Alpha 2.0 | 2020年5月09日 | 2020年5月16日 |
| Alpha 3.0 | 2020年5月16日 | 2020年5月23日 |
每个版本包含的功能如下：
| 功能 | 功能详情 | 所属版本 |
|---|---|---|
| 登录注册 | 用户使用账号密码登录 用户注册一个账号 用户选择忘记密码 |
Alpha 1.0 |
| 用户信息管理 | 修改密码 修改头像 修改笔名 修改邮箱 修改签名 |
Alpha 1.0 |
| 我的邮票 | 用户可以查看自己拥有的邮票列表 | Alpha 1.0 |
| 通知 | 用户收到新信件时进行提醒 用户看完通知之后信件状态改变 |
Alpha 1.0 |
| 书写信件 | 书写新的信件 选择信件的信纸（背景） |
Alpha 1.0 |
| 发送信件 | 随机选择笔友 选择一个发送的笔友 选择一张使用的邮票 系统根据两边距离计算发信所需时间 发信消耗一张邮票 |
Alpha 1.0 |
| 草稿箱 | 查看草稿 编辑草稿 更新草稿 发送草稿 |
Alpha 1.0 |
| 笔友 | 用户可以把另一个添加为笔友（不需要对方同意） 用户可以看到笔友列表 用户点击笔友可以看到两人之间来往的信件 用户可以给笔友写信 |
Alpha 1.0 |
| 个人海岛 | 每个用户有一个自己的海岛 用户可以设置自己海岛的背景 |
Alpha 2.0 |
| 他人海岛 | 用户可以看到他人海岛的动态 动态可以看到内容，发送时间，发送者，浏览量 用户可以在动态下面评论和回复 |
Alpha 2.0 |
| 进入海岛 | 漂流：用户可以随机到达一个海岛 用户可以根据海岛名称搜索海岛 到达一个海岛后有一定几率获得邮票和时间胶囊 |
Alpha 2.0 |
| 海岛列表 | 用户可以看到自己标记过的海岛列表 用户可以在自己的海岛发动态 用户可以标记他人的海岛 |
Alpha 2.0 |
| 数据统计 | 发送了多少信件 受到过多少信件 在信件中写过多少文字 路过多少个海岛 |
Alpha 3.0 |
| 创建树洞 | 用户可以创建一个树洞，填写树洞名称，树洞内容 用户最多只能创建5个树洞 其他用户可以查看树洞内容 其他用户可以在树洞下面留言（只能给树洞留言，不能互相回复） |
Alpha 3.0 |
| 修改树洞 | 修改已经创建的树洞 | Alpha 3.0 |
| 删除树洞 | 删除已经创建的树洞 | Alpha 3.0 |
| 时间胶囊 | 用户书写一封信 用户可以指定在将来某个时间打开这个胶囊 用户一开始只有3个胶囊 把一封信放进胶囊会消耗一颗胶囊 |
Alpha 3.0 |
2.4 矫正计算方法
-
将项目的需求划分了三个版本，为项目的整体搭建预留更多的时间，做出更好的方案
-
根据“先核心功能再次要功能，先易后难“的原则，为核心的书信功能预留更多开发时间，把树洞，时间胶囊的功能放在了第三版
-
考虑到五一劳动节大家的游玩，因此将海岛模块（原第七点）的开发移动至第二阶段，增加了通知模块（第七点），工作量相对减少。
2.5 团队分工
| 职责 | 参与成员 |
|---|---|
| UI设计 | 丘丽珊 |
| 前端开发 | 张文俊，余圣源 |
| 后端开发 | 陈宇，黄煜淇，丘丽珊，黄钰朝 |
| 测试 | 陈宇，黄煜淇，丘丽珊， 张文俊，余圣源，黄钰朝 |
| 文档和复审 | 黄煜淇，黄钰朝 |
三、本周进展和总结
3.1 本周分工情况
可以查看详细安排
| 任务 | 关键结果 | 负责人 | 时间 | 重要程度 |
|---|---|---|---|---|
| 设计第一版UI | 设计出包含第一版 功能的UI界面 |
丘丽珊 | 4月30号中午前 | ！！！ |
| 预估难度 学习必要技术 |
1.仔细阅读项目需求 2.预估项目难度 3.学习必要技能 参考以下学习清单 |
全员 | 本周内 | ！！ |
| 建立接口文档 | 前后端开会讨论 并编写接口文档 |
全员 | 暂定4月30号 下午16点30分 |
！！！ |
| 团队博客 | 编写团队博客 | 黄钰朝 | 5月1号晚前 | ！！ |
| 数据库 初步设计 |
根据需求初步设计数据库 | 黄煜淇，陈宇，黄钰朝 | 本周内 | ！！ |
| 团队计划 | 1.给出原有安排和 校正后的安排 2.给出矫正计算方法 3.将团队的任务计划 添加到GitHub的团队 项目issues里面（参考） |
黄煜淇，陈宇 | 5月1号晚前 | ！！ |
| 编码规范 | 编写团队编码规范 和git使用规范 |
黄钰朝 | 本周内 | ！ |
| 完成情况和感想 | 每个人在共享文档中 填写自己这周做了哪 些工作，进度如何， 这周的感想 |
全员 | 5月1号晚前 | ！ |
3.2 本周工作进展
3.2.1 学习必要的技术
| 学习内容 | 学习成员 |
|---|---|
| Weex | 余圣源，张文俊 |
| UI设计相关知识 | 丘丽珊 |
| 敏捷开发和scrum框架 worktile的使用 Postman的使用 Restful API设计原则 |
全员 |
| Mybatis-plus | 黄煜淇，陈宇，黄钰朝 |
3.2.2 平台环境搭建
- 建立Github组织和仓库：https://github.com/gdut-very-good
- 建立开发数据库
- 建立worktile团队
- 制定编码规范：歪瑞古德小队编码规范
- 制定Git使用规范：歪瑞古德小队Git使用规范
3.3 总结和感想
| 成员名称 | 工作内容 | 目前进度 | 本周感想 |
|---|---|---|---|
| 黄钰朝 | 1.学习相关知识 2.制定编码规范 3.参与建立接口文档 4.参与设计数据库 |
100% | 1.需求还是要明确可行，如果存在模糊和 分歧的地方，工作就难以进行。同时也应该 考虑合理性 2.作为PM去分配工作时要明确，如果没有 描述清楚任务，就会使得接受任务的队员 不知道如何执行，也会降低团队的效率，这是 需要改进的地方 3.工作任务分配之后不应该随意改动，这会 给执行者造成很大的负担 |
| 黄煜淇 | 1. 参与建立接口文档 2. 参与设计数据库 3. 制定一部分工作安排表 4. 参与添加issue到仓库 |
100% | 1. 本周团队组织了一次线上会议，主要讨论了 接口文档的制定以及工作计划的修改 2. 本周暂未开始编码工作，主要都是在进行项目 开始前的安排，方便了接下来的编码工作 3. 队长认真负责，多次督促队员完成任务 |
| 陈宇 | 1. 参与建立接口文档 2. 参与设计数据库 3.参与添加issue到仓库 |
100% | 1.了解了issue在仓库中可以用来跟踪bug,提出 意见等功能 2.每个人及时完成分配到的任务，才能使团队 合作更高效 3. 队长认真负责，多次督促队员完成任务 |
| 余圣源 | 1.建立app项目 2.根据任务要求完成第一版的UI 3.参与建立接口文档 |
50% | 1.初建了一个前端项目准备转为安卓app， 踩了不少的坑 2.体会了一次真正按照规范的团队协作，感觉 步骤略为繁琐，不是拿到就干，让我不是很舒服。 3.队长十分负责任，责任分数拉满。 |
| 丘丽珊 | 1.原型设计 2.参与建立接口文档 |
100％ | 1.画图比写代码费眼一百倍 2.增加了奇怪的Axure技能 3.求求需求文档写清晰一点，不然设计人员容易误会 4.会继续做好团队的泥石流 5.大家都说队长认真负责，只有我想揍队长一顿 |
| 张文俊 | 1. 进行项目搭建和依赖的完善 2. 学习开发知识 |
90％ | 1. 使用了新的开发工具，坑很多，脑壳疼 2. 在开发初期进行了很多的开发前准备，比如沟通文档和需求，比之前的项目开发专业不少 3. 队长十分负责任，责任分数拉满。 |
