团队做业2：需求规格说明书（歪瑞古德小队）

目录

• 1、需求规格说明书
  • 1.1 引言
    • 1.1.1 编写目的
    • 1.1.2 适用范围
    • 1.1.3 术语定义
  • 1.2 项目阐述
    • 1.2.1 产品功能
    • 1.2.2 预期用户量
    • 1.2.3 真实性
    • 1.2.4 可用性
    • 1.2.5 产品价值
    • 1.2.6 产品情怀
  • 1.3 面向用户分析
  • 1.4 功能需求分析
    • 1.4.1 功能结构图
    • 1.4.2 系统数据流图
    • 1.4.3 具体功能列表
  • 1.5 技术需求分析
    • 1.5.1 开发技术选型
    • 1.5.2 性能需求
• 2、团队计划和分工
  • 2.1 团队Github仓库
    • 2.1.1 仓库地址
    • 2.1.2 issue截图
  • 2.2 修正前的团队计划
  • 2.3 修正后的团队计划
  • 2.4 矫正计算方法
  • 2.5 团队分工
• 3、本周进展和总结
  • 3.1 本周分工状况
  • 3.2 本周工做进展
    • 3.2.1 学习必要的技术
    • 3.2.2 平台环境搭建
  • 3.3 总结和感想

Author：歪瑞古德小队

Project：海岛漂流

1、需求规格说明书

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、团队计划和分工

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、本周进展和总结

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. 队长十分负责任，责任分数拉满。