团队项目3-需求改进&系统设计
团队作业三———需求改进&系统设计
目录
一、需求&原型改进
1、针对课堂讨论环节老师和组内的问题及建议，对修改选题及需求进行修改
（1）是否支持“收信广场”背景图片自定义？
我们小组讨论后，觉得这一项不太适合我们界面设计观念，但可以作为可选项参考
（2）“收信广场”是否能按时间排序？
这项功能在我们的规划范围内，我们在计划中收信广场仅显示用户最新的十条收信数据。
（3）信件是否做出相应的标识？
团队在设计过程中考虑到对收信和写信进行分开处理，并且在收信的信件还分别做了已读和未读标识。
（4）是否考虑另外做一个广场让用户分享心情，供所有人可见？
我们会进一步讨论并考虑将其作为小程序扩展功能
（5）是否会考虑笔友联系人功能？
有机会会增加笔友功能，但是仅作为让用户遇到知心友人并能进行信件联络，但不提供私聊功能
（6）回信方式的途径选择？
1、如果用户是自己写信的话，没写完，用户可以把这封信存到草稿箱，草稿箱有其笔名、信件的内容、信封的样式、保存草稿的时间。
2、如果是用户回信没写完保存草稿，除了相应的笔名、信件内容、信封样式等外，还会保存他所要回信的人的id。
3、草稿箱里面的信件，如果信件后面写完发送了，那么从草稿箱消失，（也就是可以有个标记去判断草稿信件的状态，逻辑和物理删除都行），未写完如果内容变更了就保存最新一次的状态。
总而言之，用户点进去首页的信件，再点击里面的回信按钮，我后端根据这封信件的写信人和收信人去草稿箱数据表里面检索与之匹配的最后一次内容修改(也就是最新的)那一条信件记录信息，然后把信息返回给前端，前端再呈现出来给用户
2、修改完善上周提交的需求规格说明书
具体功能列表
| 功能 | 详细描述 |
|---|---|
| 登录注册 | 用户进入小程序，获取用户的微信信息，并根据用户微信名确定用户笔名 |
| 用户信息管理 | 用户之间并不能查看彼此的信息，在用户信息管理中只允许用户更改笔名 |
| 通知 | 用户收到新信件时进行提醒，用户看完信件后状态发生改变 |
| 书写信件 | 书写新的信件，选择信件的信纸和信封的样式 |
| 发送信件 | 系统随机为用户匹配一名收信的笔友，并记录信件发送的时间 |
| 收信广场 | 展示用户最新收到的10封信件 |
| 发信箱 | 用户删除信件、用户发送新信件 |
| 草稿箱 | 用户查看草稿、用户编辑草稿、用户更新草稿、用户发送草稿 |
| 收件箱 | 用户删除信件、用户查看信件、用户回复信件 |
| 数据统计 | 使用平台多少天、发送多少信件、接收多少信件 |
新增功能列表
| 功能 | 详细描述 |
|---|---|
| 信件阅读情况 | 对于用户收到的信件，我们为其分配一个标识以确定信件阅读的状态，并在前端页面通过不同的图标显示 |
| 选择信件 | 考虑到用户写信的体验，在用户写信前，让用户自由选择信封和信纸样式 |
| 消息提醒功能 | 用户收到来信，除了在收信广场新增信件外，在收件箱会有红点提醒 |
3、功能分析的四个象限
我们按照急需程度以及重要程度*对我们当前的功能需求分为四个象限：
- 急需程度高 + 重要程度高
- 重要程度高 + 急需程度低
- 急需程度低 + 重要程度低
- 急需程度高 + 重要程度低
二、系统设计
1. 系统架构设计
- 开发策略：
- 前端的开发原则：尽量减少冗余代码，实现组件化开发，多考虑功能的拓展性和共用性
- 后台开发设计原则：面向用户和切面开发，使用框架减少代码耦合度，增强代码的封装性，减低代码的冗余。
2.架构设计
此小程序项目采用前后端分离开发。
| 详细描述 | |
|---|---|
| 小程序(前端)页面 | 与用户进行交互的直接平台 |
| 后端程序 | 负责对用户请求进行处理和响应，为前端页面展示提供用户想要的数据 |
a) 项目架构图
- 前端页面架构
- 后端系统架构
b) 前端页面设计
- 团队负责UI式设计的同学，让项目实现一个优质简洁的前端页面，尽可能使页面具有设计感，风格简洁，符合大众审美。
- 前端开发中使用了vant组件库，代替了微信小程序原生的组件，使得页面更具设计感，风格简洁，效果呈现更佳。
c) 后台系统设计
- 为减小开发成本，我们选择使用Java做为后台开发语言。
- 使用SpringBoot这一款轻量级的Java框架，该框架简化了Spring框架繁琐的配置，提供自动配置功能，实现开包即用。大部分的中间件都可以与SpringBoot进行整合，大大地减轻了开发人员的工作，使开发人员能专注于业务逻辑代码的实现。
- 结合二级缓存Redis来提升响应速率。
3.数据库设计
项目数据库表的相关说明（临时数据库表）
| 表名 | 表的说明 |
|---|---|
| user_info | 含有用户的id及笔名，存放用户个人信息 |
| send_mail | 发件箱信件信息 |
| recevie_mail | 收件箱信件信息 |
| temp_mail | 草稿箱中新建信息 |
| envelope | 信封与信纸格式 |
三、Alpha任务分配计划
1.Product Backlog
2.Sprint Backlog
3.甘特图
四、测试计划
1. 有关项目人员组成
刘奕池、谢智杰、谭嘉明、王博誉、郭子芊、陈漫婷
2. 测试范围
| 测试范围 | 具体测试 |
|---|---|
| 功能测试 | 小程序中的各个功能的测试 |
| 兼容性测试 | 在不同屏幕大小的手机测试页面的适配情况 |
| 压力测试 | 测试可承受1的用户访问量 |
3.测试任务及分工
| 测试任务 | 测试人员 | 测试时间 |
|---|---|---|
| 页面屏幕适配 | 郭子芊、王博誉 | 所有页面设计后 |
| 项目功能测试 | 刘奕池、谢智杰、谭嘉明、陈漫婷 | 所有基本功能完成后进行整体测试、每完成一个功能进行一次简单测试 |
| 压力测试 | 刘奕池、谭嘉明 | 小程序基本功能开发完成后 |
4.测试方法
- 手动测试
- 白盒测试/黑盒测试
- 压力测试
5.测试环境
- 微信开发者工具
- 微信ios版本&微信安卓版本
- JMeter压力测试工具
