团队作业2-《需求规格说明书》
| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 团队作业2-《需求规格说明书》 |
码云仓库：https://gitee.com/chiguozi666/ruangongdemo
团队博客: https://www.cnblogs.com/gdutmingyuan/p/13887686.html
一.需求规格说明书
1.1 引言
1.1.1编写目的
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
1.1.2产品说明
- 产品名称：帮帮
- 产品类型：微信小程序
- 界面语言：简体中文
- 使用人群：大学生
- 产品功能：提供一个社交平台，用户能够发布任务，能够接受人家发布的任务。
1.2 项目阐述
1.2.1产品功能
提供一个社交平台，用户能够发布任务，能够接受人家发布的任务。提供信誉保证。
1.2.2面向的用户分析
(1).用户画像：
因为身体原因不方便的同学,忙碌的同学，懒得下楼拿东西的同学，宅在宿舍的年轻人群体。总结：“不方便”,“懒”。
(2).为什么他们需要别人帮忙（用户的需求）
1.年轻人群体的拿快递，拿外卖，打印需求很多，当这些需求多的时候，肯定存在一部分人不想去干，或者确实不能去干。
2.宅文化在年轻人群体中流行，尤其是大学生，除了上课都想足不出户。
(3).用户数量级：
| 阶段 | 用户数量 |
|---|---|
| 广东工业大学的学生 | 2k以下 |
| 小谷围岛 | 15k以下 |
| 未定 | 未定 |
1.2.3用户可能使用的情景
1.体测完腿脚不便，不合适爬楼梯这种人群。
推广下就是运动过度或者意外受伤而又不想麻烦舍友的人群可以考虑。2.不想下楼拿外卖。
3.人在工一，没想到团委要收东西，叫人去打印，然后给团委。
4.到了期末了，宿舍东西太多了，搬宿舍要拿下楼。
1.2.4真实性
代跑腿的群确实存在，并且每天的需求量很多。
1.2.5可用性
构建一个微信小平台，轻松满足用户的需求。
1.2.6独特性
暂时还没有校园类平台实现这样的功能
1.2.7产品的逻辑分析（后续流程图优化）
1.用户在平台发布任务，并且提交任务的“赏金”（没有人接单将会退还）。
2.根据接单人的信誉值判定他是否能接受任务。
3.接单人完成任务。
4.发布人检查用户是否完成，完成的话平台将“赏金“给接单人，没完成的话，
应该先由两个人自行商议，商议失败后，提交材料给平台，平台进行审核。（信誉分扣除）。
1.2.8价值所在
是给用户需要跑腿的行为提供一个平台，并且提供一个信誉保障。
能给代跑腿的用户一个平台接单，并且提供第三方的审核，缓解纠纷。
1.3产品的需求分析
1.3.1功能需求分析
(1).满足用户“随叫随到”的需求，体验出产品对客户需求完成的及时性。
用户发出任务后，能够及时的被接单，同时任务也能及时被完成。
(2).满足用户“有求必应”的需求，体现出产品对客户需求完成的响应性。
用户发出任务后，任务大概率不会没人接。
(3)满足用户“安全完成”的需求，提现出产品对客户需求完成的安全性。
用户发出任务后，任务能被安全的完成，保证不会有财物损失。
(4)满足用户“有单能接”的需求，让用户能有机会去接单，能拿到外快。
保证接单的人，能够在完成任务以后，拿到应得的酬劳。
1.3.2技术需求分析
前端技术
| 技术项 | 具体技术 |
|---|---|
| 编程语言 | JavaScript、WXML、WSS |
| 开发框架 | 原生微信小程序 |
| 代码版本控制 | git |
| 运行环境 | Android微信客户端、iOS微信客户端 |
| css预编译语言 | WXSS |
后台技术
| 技术项 | 具体技术 |
|---|---|
| 编程语言 | Java |
| 通信协议 | HTTP |
| JDK版本 | 1.8 |
| 数据库 | MySQL 8.0，Redis 6.0.8 |
| 代码版本控制 | git |
| web服务器 | Tomcat 9.0.29 ， |
| 服务器技术 | docker |
| 技术框架 | springboot 2.2.2，mybatis-plus 3.3.2，Maven 3 |
二、团队计划和分工
2.1团队计划
2.1.1修正前团队计划
| 周次 | 开发内容 |
|---|---|
| 6 | 确定团队成员，各成员自由选题 |
| 7 | 1.团队开会确定选题，完成团队介绍博客 |
| 2.进行需求分析，写需求文档 | |
| 3.原型设计，设计第一版UI，队员估计任务难度并学习必要的技术 | |
| 4.确定编码规范、平台环境搭建完成、初步架构搭建 | |
| 5.确定前后端接口文档 | |
| 8 | 1.查看原型是否要进行改进 |
| 2.前后端继续编程，继续完善功能 | |
| 3.制订测试计划 | |
| 9、10 | 1. 团队项目Alpha任务分配计划 |
| 2.连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 11 | 1.用户反馈+测试计划改进 |
| 2. 团队Alpha阶段个人总结 | |
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 |
2.1.2修正后团队计划
| 周次 | 开发内容 |
|---|---|
| 6 | 确定团队成员，各成员自由选题 |
| 7 | 1.团队开会确定选题，完成团队介绍博客 |
| 2.进行需求分析，写需求文档 | |
| 3.原型设计，设计第一版UI，队员估计任务难度并学习必要的技术 | |
| 4.确定编码规范、平台环境搭建完成、初步架构搭建 | |
| 8 | 1.团队协作交流，学习git知识 |
| 2.根据功能需求，进一步确定需求文档 | |
| 3.UI确定小程序主页面样式 | |
| 4.结合前端队员设计第二版UI | |
| 5.前端对已经敲定的UI画面进行代码实现 | |
| 6.后端队员建立团队github仓库，并建立相应的分支 | |
| 7.根据需求文档初步设计数据库表 | |
| 8.后端成员初步发布任务以及 | |
| 9 | 1.前端队员和UI确定好页面样式，实现前端页面开发。 |
| 2.后端成员完成发布任务和接取任务的功能实现，并且规范接口。 | |
| 3.根据功能实现进度，商量项目二次功能优化和开发，并确定需求文档 | |
| 10 | 1. 团队项目Alpha任务分配计划 |
| 2.根据上周的需求文档，进行工作分配，进行为期7天的敏捷开发 | |
| 3.连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 11 | 1.用户反馈+测试计划改进 |
| 2. 团队Alpha阶段个人总结 | |
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 |
2.2 本周分工情况
| 任务 | 关键内容 | 负责人 |
|---|---|---|
| git相关知识学习 | 学会代码的提交和下载。 | 全体成员 |
| 前端学习 | 完成小程序的学习。 | 刘志鸿，詹栩丹。 |
| 后台学习 | 完成后台的学习。 | 郭裕霖，刘世轩。 |
| 测试学习 | 完成测试的学习。 | 丁科文。 |
| 项目的基本搭建 | 配置好项目的基本环境，确定好分包和使用的技术，部署服务器。 | 郭裕霖。 |
| 初步代码实现 | 尝试初步实现用户信息的管理。 | 郭裕霖，刘世轩。 |
| 完成与感想汇报 | 汇报这周的完成情况 | 全体成员 |
2.3 Issue情况
三、团队感受
| 名字 | 关键内容 |
|---|---|
| 刘志鸿 | 想到是作为团队的一员而不是自己一人做项目就会有一种期待的感觉. |
| 詹栩丹 | 无论怎样，这是一个让自己学习新知识和了解团队合作的机会，要继续努力。 |
| 丁科文 | 没有什么事情是生来就会的，都是要通过尝试、学习，一步一步地体验下来，才能得到经验教训。希望学习的技术能派上用场，减轻团队的负担，为团队作业的完成作出更多的贡献。 |
| 刘世轩 | 我会加油的。 |
| 郭裕霖 | 做pm真的太幸福了。 |