需求规格说明书

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

1. 引言

1.1 编写目的

为明确软件需求、规划项目、确认进度、组织软件开发并测试而撰写本文档。本文分别介绍了产品的用户功能及运行环境，系统的功能的具体描述。同时，详细分析项目总体需求，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。

• 本文档面向多种读者对象：
  （1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。
  （2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。
  （3）程序员：了解系统功能，编写《用户手册》。
  （4）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。
  （5）用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。
• 在阅读本文档时，了解产品的功能概貌后，可根据个人需求对每个功能进行适当的了解。

1.2 背景

本次待开发的软件为“必备记”iOS软件。
用户通过该软件在iOS终端上完成对日记本、备忘录、账本、待办事项的记录。用户注册并登录进入该软件，登录后的数据将全部存储于个人账户里，方便用户在集成四个功能的软件中完成对日常生活的记录及管理。

1.3 定义

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 典型用户

1. 林慧慧：工作任务繁重的白领

   名字	林慧慧
   性别、年龄	女，26
   职业	某大型上市公司的小员工
   知识层次和能力	大学，MBA，熟练使用电脑操作各办公软件，手机使用毫无问题
   生活/工作情况	经济独立，在外租屋居住，进入公司两年因能力突出被领导培养中
   动机，目的，困难	领导下发工作任务繁重，记录下容易忘记的任务和工作细节。困难：忘性大，工作太多产生焦虑，因经济独立需管理好每月支出。
   用户偏好	逛淘宝，刷剧，生活和工作要有条理
   用户比例	40%
   典型场景	会议后整理领导提点的细节，把各工作提上日程
   典型描述	时间管理大师，都市丽人，做什么都有规划

2. 陈印：勤工俭学的大学生

   名字	陈印
   性别、年龄	男，19
   职业	大学学生，数学专业，兼职家教老师
   知识层次和能力	大学在读，电脑高手，热爱刷机
   生活/工作情况	家庭经济一般，大学后自己主动做兼职赚取学费和生活费
   动机，目的，困难	记好收入和支出，控制自己每月花销。困难：想要有一点积蓄买喜欢的东西
   用户偏好	打王者，steam老玩家，常驻B站
   用户比例	50%
   典型场景	兼职的工作发工资了、生活日常花销
   典型描述	勤工俭学的好孩子，有一些花钱的小爱好，精打细算

3. 李敏：对生活事物比较敏感的人

   名字	李敏
   性别、年龄	女，14
   职业	学生
   知识层次和能力	大学，MBA，
   生活/工作情况	正值青春期，不太敢于表达自己，比较在意一些发生的事
   动机，目的，困难	有时不想朋友分享，选择悄悄记下来。困难：害怕自己写的东西被人随意打开阅览
   用户偏好	将自己在意的事情记下来
   用户比例	10%
   典型场景	记录发生的事，给自己的日记上锁
   典型描述	心思敏感的青少年，害怕家长查手机

2.3.3.2 典型用户场景

• 场景一

因此，我们可以概括出此用户的大致使用场景

• 场景二

因此，我们可以概括出此用户的大致使用场景

• 场景三

因此，我们可以概括出此用户的大致使用场景

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 后端技术需求

3.2.2 iOS客户端技术需求

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

修改后的需求规格说明书

原文：https://www.cnblogs.com/yyyy118/p/12925851.html