对于前端来讲，需求分3类：
1. 需求文档。包括整个产品的逻辑，详细的交互图，整体流程图等。
2.UI设计图。要按照一定的规范来出设计图。
3.后台接口。
一、需求文档
-
整体的APP实现方向有一个大致的说明，说明这个APP或者某个大的模块主要是追对什么设计的，方便开发时更详细的理解需求。
-
按具体功能对界面进行划分，分成具体几个功能模块并说明每个功能模块由那些界面组成。
-
对每个功能点进行详细的功能描述，包括可能出现的逻辑结构的描述。
-
针对整体的功能，要有一个详细的交互图，方便对整个产品进行详细的了解。
-
对每个功能模块出一套流程图，将每个界面或是功能点能够串起来，方便设计与优化。
二、UI设计图
-
要有一套完整的设计规范。例如一级标题是什么颜色，字体的大小，要统一给一个规范，这样既方便UI设计，也方便前端代码整合。
-
详细的标注。详细的标注是指大到每个界面的宽高，小到每个控件的宽高、颜色，要有详细的标注，若宽高相同的布局可以只标注一个，但是标注要详细，完整。例如：一个控件不能只给距离左边的距离和宽，同样要给出距离顶部的距离及高度。
-
特殊布局的控件要给出不同设备上适配比例或者显示宽高，否则容易造成开发App与设计稿不一致的情况出现。
-
字体、颜色规范。跟第一点相似，就是把APP中常用的字体及常用的颜色统一给一套规范，设计图也一并严格按照此规范设计，这样就可以定义全局的颜色分类，每次用哪个取哪个即可，也不会出现改一次APP色调，动好多地方的颜色设置，只需修改统一的颜色即可，即缩短了工作量又避免遗落修改的错误。
-
设计图稿要严格按照设计时间出图。且一旦出图只允许做小幅度的调整，定稿之后尽量不要做大幅度的修改，以免进行重复的工作量，若有大幅度的修改，请提交给下一版本，避免循环开发没有结点。
三、接口设计
-
请求网址，前面的一部分是固定的，每个接口改变的是后面的方法名和请求的参数。
-
也可以双方规定一些错误代码，例如111111代表成功，222222代表token失效，3333333代表参数出错等等，这样有的时候就可以直接定位是因为前端请求出错，还是后台的方法出错，省去寻找错误的时间。
-
后台字段一旦与前端确定，轻易不要修改，如有修改请及时告知前端，避免因字段更改造成界面数据显示的错误。
-
若时间允许可出一份详细的接口文档，包括接口的地址，用途，请求参数（必须 or 非必须），返回参数，返回格式都写在一个文档中，这样就可以直接看文档，省去很多交流推脱的时间。
四、数据库设计 （分为后台做的和前端需要做的）
- 后台要做的，这关系到一些表与表的关联，逻辑删除，真实删除，逻辑修改等等。
2 如果有一些变动性很小又会经常用到的数据，前端可会用数据库或是本地存储来存一些必要的信息。主要是根据实际的数据来进行存储，不会有复杂的功能，只有基本的增删改查。
网友评论