需求规格说明书
修改内容：
（1）引言部分加入编写背景、定义，且将本文档的读者融入编写目的中。
（2）项目概述部分加入用户场景，其中包括典型用户和典型的用户场景，便于用户通过这些例子较快了解如何使用几个相联系的功能，解决用户问题。同时加入一般约束、假设与依据部分的内容。
（3）加入外部接口需求、性能需求、属性这几部分的内容。
（4）将收集而得的需求加入我们的功能需求表中。
1. 引言
1.1 编写目的
为明确软件需求、规划项目、确认进度、组织软件开发并测试而撰写本文档。本文分别介绍了产品的用户功能及运行环境，系统的功能的具体描述。同时，详细分析项目总体需求，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。
- 本文档面向多种读者对象：
（1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。
（2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。
（3）程序员：了解系统功能，编写《用户手册》。
（4）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。
（5）用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。 - 在阅读本文档时，了解产品的功能概貌后，可根据个人需求对每个功能进行适当的了解。
1.2 背景
本次待开发的软件为“必备记”iOS软件。
用户通过该软件在iOS终端上完成对日记本、备忘录、账本、待办事项的记录。用户注册并登录进入该软件，登录后的数据将全部存储于个人账户里，方便用户在集成四个功能的软件中完成对日常生活的记录及管理。
1.3 定义
| 序号 | 缩写 | 定义 |
|---|---|---|
| 1 | app | 应用程序，application的缩写，一般指手机软件。 |
| 2 | iOS | iOS是由苹果公司开发的移动操作系统，属于类Unix的商业操作系统。最初是设计给iPhone使用的，后来陆续套用到iPod touch、iPad上。 |
2. 项目概述
2.1 产品描述
本产品集账本、备忘录、日记以及待办事项于一体，通过开发基于iOS平台的app“必备记”，节省用户于各相关应用之间的切换时间，为用户提供直观的每日花销数据及当日事务管理，记录生活的点滴。
2.2 产品功能
“必备记”app致力于通过移动iOS平台便捷快速地记录日常生活，大大减少切换app并进行记录造成的时间上的浪费。
2.3 用户分析
2.3.1 适用范围
本产品主要面向拥有一定经济独立性，学习或工作事项繁多的青年用户群体。
2.3.2 预期用户数量
考虑到前期推广渠道有限，预计的用户量为三百到五百人。
2.3.3 用户场景
2.3.3.1 典型用户
-
林慧慧：工作任务繁重的白领
名字 林慧慧 性别、年龄 女，26 职业 某大型上市公司的小员工 知识层次和能力 大学，MBA，熟练使用电脑操作各办公软件，手机使用毫无问题 生活/工作情况 经济独立，在外租屋居住，进入公司两年因能力突出被领导培养中 动机，目的，困难 领导下发工作任务繁重，记录下容易忘记的任务和工作细节。困难：忘性大，工作太多产生焦虑，因经济独立需管理好每月支出。 用户偏好 逛淘宝，刷剧，生活和工作要有条理 用户比例 40% 典型场景 会议后整理领导提点的细节，把各工作提上日程 典型描述 时间管理大师，都市丽人，做什么都有规划 -
陈印：勤工俭学的大学生
名字 陈印 性别、年龄 男，19 职业 大学学生，数学专业，兼职家教老师 知识层次和能力 大学在读，电脑高手，热爱刷机 生活/工作情况 家庭经济一般，大学后自己主动做兼职赚取学费和生活费 动机，目的，困难 记好收入和支出，控制自己每月花销。困难：想要有一点积蓄买喜欢的东西 用户偏好 打王者，steam老玩家，常驻B站 用户比例 50% 典型场景 兼职的工作发工资了、生活日常花销 典型描述 勤工俭学的好孩子，有一些花钱的小爱好，精打细算 -
李敏：对生活事物比较敏感的人
名字 李敏 性别、年龄 女，14 职业 学生 知识层次和能力 大学，MBA， 生活/工作情况 正值青春期，不太敢于表达自己，比较在意一些发生的事 动机，目的，困难 有时不想朋友分享，选择悄悄记下来。困难：害怕自己写的东西被人随意打开阅览 用户偏好 将自己在意的事情记下来 用户比例 10% 典型场景 记录发生的事，给自己的日记上锁 典型描述 心思敏感的青少年，害怕家长查手机
2.3.3.2 典型用户场景
- 场景一
| 典型用户 | 林慧慧 |
|---|---|
| 用户需求/迫切需要解决的问题 | 上班半天后，慧慧被领导带出去见客户，慧慧还有部分工作未完成 1.慧慧需要记下还没有完成的工作 2.慧慧需要把领导交代的客户信息记下来，方便以后看 3. |
| 假设 | 1.基于登录模块已经完成 2.基于待办事项已经完成 3..基于备忘录功能已经完成 |
因此，我们可以概括出此用户的大致使用场景
| 首先慧慧登录必备记app，在功能选项中选择了待办事项模块 |
|---|
| 慧慧点一下添加待办事项将还没完成的工作内容逐项写进去，回到待办事项主页面，在已完成的事项前的小圆圈里面打勾，点开早上写的待办事项，按修改键，慧慧根据已完成一部分的工作修改了这个待办事项的内容，点完成保存修改内容。 |
| 慧慧回到功能选项，点击备忘录，添加备忘录，写下了关于客户的重要信息，并上传一张自己做的客户信息笔记图片，以便之后和该客户洽谈工作前查看相关细节 |
- 场景二
| 典型用户 | 陈印 |
|---|---|
| 用户需求/迫切需要解决的问题 | 陈印的兼职工资发了，下个月老板答应给他涨工资，他开始要统计下个月的花销和收入 1.将工资记入账本的收入中 2.查看本月收支差额 3.查看本月各类花销 |
| 假设 | 1.基于登录模块已经完成 2.基于记账模块已经完成 3.基于备忘录功能已经完成 |
因此，我们可以概括出此用户的大致使用场景
| 陈印登录必备记app，在功能选项中选择了账本功能 |
|---|
| 陈印点击了新建账单，输入金额，选择日期，选择分类，将今日的出行及餐饮花费记录下来，在账本页面看到了自己本月的总收入、总支出，以及收支差额，还发现自己本月在娱乐类的花费比以往都多，下定决心要在之后克制自己在游戏方面的支出 |
| 陈印最近还开始谈恋爱了，约会有时候也会花一些钱，但他发现账本类别总没有这个选项，于是他在账本类别管理中添加了恋爱消费类，并保存 |
| 因为兼职工作涨了工资，陈印在账本设置中，重新设置了每月收入并保存，于是陈印下个月的账单会自动记入涨工资之后的收入 |
| 陈印打开备忘录功能，将自己下周的兼职和约会行程记在新的备忘录，方便查看和提醒自己行程 |
- 场景三
| 典型用户 | 李敏 |
|---|---|
| 用户需求/迫切需要解决的问题 | 李敏在周末和好朋友前往游乐园游玩，留下很多美好的回忆 1.将周末发生的事记录下来 |
| 假设 | 1.基于登录模块已经完成 2.基于待办事项模块已经完成 3.基于日记模块已经完成 4.基于备忘录功能已经完成 |
因此，我们可以概括出此用户的大致使用场景
| 李敏登录了必备记，打开待办事项模块，将和朋友外出游玩事项改为已完成 |
|---|
| 李敏选择日记模块，新建日记，选择时间、天气、心情、记录下了和朋友一起玩过山车的刺激感受，逛街时看到可爱的物件，吃饭时的美食，还上传了相关的照片，只要看到这些照片和这个日记，李敏就会想起这个愉快的周末。 |
| 李敏写完日记后，还打开了以前写的一些日记，看到半年前和班里的同学一起出去秋游的图片，还有当时发生的趣事，于是和班里的朋友约好在今年的秋天也要找一个地方去游玩，并把这件事写进备忘录中。 |
2.4 项目价值
2.4.1 真实性
日常生活中用户忙于事务，无法手写日记或者记录消费，手机一拿，随时可用。
2.4.2 可用性
一个人最好的习惯就是善于反思，而反思的根源来源于回忆，脑子做不到的，我们来存。
2.4.3 有情怀
小时候总以为遥遥无期，长大却发现过去就是一眨眼的事。若我们回想过去，有日记纪念过去的心情、事情，有记账回忆当初1块钱的快乐，有备忘让你所心心念念的都付诸实现，过去不可怕，可怕的是忘记。
2.4.4 价值
用户量定义价值，现在市面上的类似于记事本的手机app的功能缺少记账功能与云端联动的功能，这个好idea可以帮助扩展用户，定位准确。
2.5 一般约束
进行本软件开发工作的约束条件如下：
1.开发周期短：5周左右的开发时间需要开发者合理规划时间，做到多项任务并发。
2.所采用的方法与技术有限：项目团队成员的技术水平不够成熟，需要在开发中并发学习多种技术与能力。
2.6 假设与依据
本项目是否能够成功实施，主要取决于以下的条件：
（1）团队成员的积极合作配合，为了项目的开发和实施，对个人时间进行合理规划同时为团队做出合理牺牲，配合队友完成任务。
（3）团队掌握先进的能够适用于该项目的技术，这是系统的性能是否优化和项目能否成功的保证。
3. 具体需求
3.1 功能需求
本系统是集日记、账本、待办事项、备忘录等功能为一体的iOS程序，势必让使用者摆脱需要多个软件的烦恼，只需要下载该款ios程序，就可以实现多元化的功能。
3.1.1 功能结构图
3.1.2 具体功能列表与描述
| 功能 | 具体描述 |
|---|---|
| 登录注册 | 用户使用邮箱号注册账号 用户凭借注册的账号登录进入程序 用户选择忘记密码，通过邮箱号的方式找回密码 |
| 日记本 | 新建日记: 用户可在此选择新建一个日记 查看日记: 用户可以点击日记列表中的日记查看已经写过的日记 修改日记: 用户可以点击列表中的日记进行修改 删除日记: 用户可以选择删除一个日记列表中的日记 搜索日记: 用户可以选择日期检索当天的日记 上锁日记: 用户可对隐私的日记进行加密 |
| 备忘录 | 新建备忘录: 用户可在此选择新建一个备忘录 查看备忘录: 用户可以点击备忘录列表中的备忘录查看已经写过的备忘录 修改备忘录: 用户可以点击列表中的备忘录进行修改 删除备忘录: 用户可以选择删除一个备忘录列表中的备忘录 多选删除备忘录：用户可以选择多选，从而从列表中删除多个备忘录 |
| 账本 | 账本设置: 用户可以在设置中选择月起始日期，月收入，以及选择账本类别 新建账单: 用户可以新建一个账单，选择收入或者支出，选择分类名称，填写备注，输入账单金额 修改账单: 用户可以通过点击已保存的账单进行修改 删除账单: 用户可以从账单列表中删除一个账单 多选删除帐单：用户选择多选可同时删除多个账单 |
| 待办事项 | 新建待办事项: 用户可在此选择新建一个待办事项 查看待办事项: 用户可以点击列表中的待办事项,查看已经写过的待办事项 修改待办事项: 用户可以点击列表中的待办事项进行修改 删除待办事项: 用户可以选择删除列表中的待办事项 多选删除待办事项: 用户可以选择多选，从而从列表中删除多个待办事项 |
3.2. 技术需求
3.2.1 后端技术需求
| 技术项 | 具体技术 |
|---|---|
| 编程语言 | Java |
| 通信协议 | HTTP |
| JDK | 1.8 |
| 数据库 | MySQL 5.6.39 , Redis 5.0.8 |
| Web容器 | docker+nginx |
| 代码版本控制 | Git |
| 技术框架 | springboot 2.6.0，mybatis-plus 3.0，Maven 3.0 ,springSecurity |
3.2.2 iOS客户端技术需求
| 技术项 | 具体技术 |
|---|---|
| 编程语言 | Swift |
| 平台 | iOS13.0及以上 |
| 技术框架 | SwiftUI+Combine |
| 代码版本控制 | Git |
3.3 外部接口需求
3.3.1 用户接口
本系统采用C/S架构，所有界面使用app风格。
3.3.2 硬件接口
无特殊需求。
3.3.3 软件接口
无特殊需求。
3.3.4 通信接口
无特殊需求。
3.4 性能需求
3.4.1 精度需求
- 个人信息精度
用户名：即用户邮箱，符合邮箱的正则表达式。包含@字符。不可为空。
用户密码：至少10位，密码必须由数字与英文混合的形式组成。不可为空。
3.5 属性
3.5.1 可用性
（1）方便操作，操作流程合理。尽量从用户角度出发，以方便使用本产品。如：需要对备忘录的内容进行删除时，可以一键“多选”，通过一个动作实现删除多条记录的目的。
（2）容错能力。本app具有一定的容错和抗干扰能力，在非硬件故障或非通讯故障时，系统能够保证正常运行，并有足够的提示信息帮助用户有效正确地完成任务。
（3）操作完成时有统一规范的提示信息。如：删除操作时，app弹出警示框“确认要删除已勾选的xxx吗？一旦操作将无法撤销。”，用户点击确认后，软件才执行删除操作，删除后可直接返回相关界面。
3.5.2 安全性
- 用户独立性
本app在登录后才可对记录进行操作，用户之间具有独立性，保障信息安全。
4. 制定规范
4.1 后台编码规范
4.1.1 代码规范
遵循阿里巴巴开发手册
- 方法：遵循驼峰命名法，以动词开头，名词结尾，遵循增删查改命名原则
- 接口：必须有Javadoc说明文档，参数作用，返回值等
- 类：类名遵循驼峰，且首字母大写
- 包：遵循MVC架构，分包具体为controller、service、mapper、entity、constant、bo、vo、util
4.1.2 API接口规范
- 接口名遵循RESTfulAPI的风格
- HTTP响应状态码都是返回HTTP状态码200
- 统一返回的reponseHeader设置为application/json,后台开发者进行自定code，如下：
private Integer code;
private String msg;
private T data;
/**
* 功能描述 请求成功的返回数据
*
* @param data
* @author chenqiting
* @date 2020/2/9 13:13
*/
public Result(T data) {
this.data = data;
this.code = 200;
this.msg = "ok";
}
/**
* 功能描述
*
* @param msg 请求错误的响应信息
* @param code 请求错误的响应码
* @author chenqiting
* @date 2020/2/9 13:15
*/
public Result(Integer code, String msg) {
this.code = code;
this.msg = msg;
}
}
4.2 swift代码规范
- 使用驼峰命名而不是下划线命名。
- 命名清晰比简洁优先。
- 避免对可选类型强解包。
- 需要的时候才写上
self。 - 首选
struct而非classs。 - 除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
5. 原型设计
墨刀链接：https://free.modao.cc/app/60c2bfc953e8cdc975daf1a94bfe375f8f6c2015?simulator_type=device&sticky