团队作业三

需求改进&系统设计

一、需求&原型改进

1.1. 修改选题及需求

问题1：日记本想要通过选择日期进行检索。

修改1：加上检索功能。

问题2：日记本想要增加涂鸦功能。

修改2：在日记本里增加涂鸦功能。

问题3：备忘录想要提醒功能。

修改3：在备忘录中加入邮箱提醒功能。

问题4：日记想要图文编辑功能。

修改4：在备忘录中加入图文编辑功能。

问题5：日记需要草稿保存功能

修改5：在日记中加入了草稿保存功能。

1.2. 需求文档改进完善

1.2.1 完善内容

（1）引言部分加入编写背景、定义，且将本文档的读者融入编写目的中。
（2）项目概述部分加入用户场景，其中包括典型用户和典型的用户场景，便于用户通过这些例子较快了解如何使用几个相联系的功能，解决用户问题。同时加入一般约束、假设与依据部分的内容。
（3）加入外部接口需求、性能需求、属性这几部分的内容。
（4）将收集而得的需求加入我们的功能需求表中。

1.2.2 修改后的需求规格说明书链接

https://www.cnblogs.com/yyyy118/p/12925851.html

1.3. 功能分析的四个象限

功能需求	外围功能	杀手功能
必要需求	日记本、账本、备忘录的增删改	备忘录设置邮箱提醒功能，很好的起到备忘录的作用
辅助需求	日记本可对日期进行检索，方便用户快速找到目标	日记中的涂鸦功能可以记录随时所想

1.4. WBS及相应的项目进度计划

1.4.1 wbs图

1.4.2 相应的项目进度计划

根据团队项目的实际进度及产生的误差，结合收集而得的需求，对原项目进度计划的时间安排进行了部分修改并加入了一些新的功能。

序号	模块	具体功能	负责人	时间安排
1	UI设计	对每个功能页面的UI进行设计，逐步优化原型设计	刘珮琳、高明莹	4.28-4.30
2	登录注册	(1)用户使用邮箱号注册账号 (2)用户凭借注册的账号登录进入程序 (3)用户选择忘记密码，通过邮箱号的方式找回密码	古梓欣、魏宇峰	5.9-5.13
3	日记本	(1)新建日记: 用户可在此选择新建一个日记 (2)查看日记: 用户可以点击日记列表中的日记查看已经写过的日记 (3)修改日记: 用户可以点击列表中的日记进行修改 (4)删除日记: 用户可以选择删除一个日记列表中的日记 (5)多选删除日记: 用户可以选择多选，从而从列表中删除多个日记	陈起廷、魏宇峰	5.14-5.17
4	备忘录	(1)新建备忘录: 用户可在此选择新建一个备忘录 (2)查看备忘录: 用户可以点击备忘录列表中的备忘录查看已经写过的备忘录 (3)修改备忘录: 用户可以点击列表中的备忘录进行修改 (4)删除备忘录: 用户可以选择删除一个备忘录列表中的备忘录 (5)多选删除备忘录：用户可以选择多选，从而从列表中删除多个备忘录	陈起廷、魏宇峰	5.18-5.23
5	账本	(1)账本设置: 用户可以在设置中选择月起始日期，月收入，以及选择账本类别 (2)新建账单: 用户可以新建一个账单，选择收入或者支出，选择分类名称，填写备注，输入账单金额 (3)修改账单: 用户可以通过点击已保存的账单进行修改 (4)删除账单: 用户可以从账单列表中删除一个账单 (5)多选删除帐单：用户选择多选可同时删除多个账单	陈起廷、古梓欣、魏宇峰	5.24-5.27
6	功能测试	测试已有模块，将测试过程中出现的bug及时反馈给对应功能的负责人	刘珮琳、高明莹、古梓欣	每个功能实现后2天内
		对所有模块进行功能测试	陈起廷、魏宇峰、刘珮琳、高明莹、古梓欣	5.27-5.28
7	补充需求
		日记本涂鸦功能	陈起廷、魏宇峰、古梓欣	5.17-5.18
		日记本检索功能	陈起廷、魏宇峰	5.19-5.21
		日记图文编辑功能	陈起廷、魏宇峰、高明莹	5.18-5.23
		备忘录邮箱提醒功能	陈起廷、魏宇峰	5.24-5.26

二、系统设计

2.1 C/S架构设计

• 基于IOS的客户端架构，对界面和数据渲染，让用户体验良好
• 基于Java的服务器端架构，对数据进行处理，屏蔽一些非法操作并正确返回
• 解耦的实现：在进行开发的过程中，从我要到我有的全面性开发存在一定的必要性，解耦的关键在于交互设计文档的规范，这点在之前的文章中有所说明，此处不再细述，详情请看https://www.cnblogs.com/yyyy118/p/12848954.html

2.2 后端数据库设计

根据规范来设计数据库，遵循数据库三大范式，设计如下图所示

三、Alpha任务分配计划

3.1 Product Backlog

3.2 Sprint Backlog及认领情况

3.3 甘特图

四、 测试计划

4.1 引言

4.1.1 项目背景

日常生活中用户忙于事务，无法手写日记或者记录消费，必备记集账本、备忘录、日记于一体，为用户提供直观的每日花销数据及当日事务管理，记录生活的点滴。

4.1.2 参考资料

《构建之法》

4.2 任务概述

为了使应用与用户的交互尽可能地覆盖各个方面，测试时要尽量覆盖到各类情况，检查是否有足够的检错、提示信息，防止应用奔溃的情况发生。

4.2.1 测试范围

• 登录功能，即是用户登录时是否会出现信息匹配错误。
• 上传失败
• 快速切换检查是否有奔溃或者刷新问题
• 编辑中途退出应用，检查是否保存草稿（应用非正常退出）
• 动画效果是否顺滑
• 逻辑跳转是否正常
• 测试API的可用性

4.2.2 测试目标

• 用户登录时是否会出现信息匹配正确，同一账号仅能申请一次
• 确保数据成功上传
• 保证快速切换无奔溃或者刷新问题
• 保证编辑中途非正常退出应用能保存草稿
• 动画效果是否顺滑
• 确保逻辑跳转正常
  
  

4.3 测试策略

4.3.1 测试人员及分工

测试方面暂时安排三人进行，到后期测试量变大再增加人员。

4.3.2 测试方法

• 模拟器运行
• 真机调试

4.3.3 测试阶段计划（工作内容、人员安排、起止时间等）

工作内容	人员安排	起止时间
登录模块	魏宇峰	根据进度同步跟进
提醒功能测试	魏宇峰	根据进度同步跟进
自我评价功能测试	魏宇峰	根据进度同步跟进
其他功能测试	魏宇峰 /根据系统完成情况安排人员	根据进度同步跟进

4.4．测试资源

4.4.1硬件资源需求

• iPhone
• iPad

4.4.2软件资源需求

• Mac上测试需Xcode11及以上版本

4.4.3测试环境需求

• 系统版本于iOS13.0及以上

4.4.4测试人员需求

• 考虑周全，测试尽可能地覆盖所有情况
• 对UI界面有一定了解，清楚Bug最容易出现的地方，进行集中测试
• 能生成清晰可靠的测试文档，方便开发人员进一步完善软件
  
  

4.5．风险评估

4.5.1 人力方面

• 业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透侧、理解错误等。
• 定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的。
• 疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试显示出倦意和缺乏兴趣。
• 同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出发的测试观察点。

4.5.2 时间方面

• 软件的开发测试同步进行，排除软件开发遇到瓶颈的情况
• 测试时间不足：里程碑之间留给测试的时间无法满足全测试要求

4.5.3 环境方面

• 被测软件版本不统一：没有有效的配置管理，这种情况及易出现
• 测试软件环境不一致：测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。
• 测试硬件环境不一致：测试员之间或和开发的设备不一致，如CPU频率，内存大小等。
  测试硬件未及时到位

4.5.4 资源方面

可能出现硬件资源不足，测试人员的手机操作系统不一致等等。