团队作业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截图

image-20200502002344219

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 平台环境搭建

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. 队长十分负责任,责任分数拉满。
posted @ 2020-05-02 01:05  Yuchao_Huang  阅读(392)  评论(0编辑  收藏