在需求文档完成后，测试人员以及开发人员应该分别开始了自己的工作。测试人员开始按照需求文档编写修改Case，并制定合适的测试计划，评估自动化测试的可行性等。开发人员根据职位的不同开展各自的工作。
作为普通程序员：
一.掌握核心业务流程：在前期项目中 编写需求文档 这段时间中，应该对项目有一个基本的了解，并对项目的核心业务有一个明确的认识。往往我对核心业务掌握的不够全面，导致后期代码编写过程中，会出现一些意想不到的意外，导致工作量增加。例如：业务功能不全，业务逻辑不清楚，最糟糕的是业务流程走不通，那才是悲剧。
二. 深入分析数据结构：数据库中每个字段都应该是有意义的，而且都应该会被使用到（除非是备用字段），所以要了解每个字段的含义，是用来干什么的！其次，要时刻注意业务中需要的字段，一定不能缺少，由于数据库设计不够全面，到后期发现数据库设计逻辑有缺陷，那真的会衍生出很多问题以及Bug，但是这也是最不容易被发现的地方，只有后期做到这一步才会被发觉。
三. 编写接口文档：在充分了解业务流程，以及数据库结构后，就开始编写接口文档了。对业务了解的越透彻，写出的接口才会越合理。在写接口文档的时候，需要考虑的事情很多：
a.最基本的：前端需要传来的参数，返回的数据格式
b.合适的名字：返回的数据要有合适的名字，清晰明了，能让前端人员大致明白数据代表的含义
c.最小数据：无论前端数据渲染，后端数据操作，多余的冗余字段会影响项目的性能，所以应该尽量保持数据的冗余程度较低。
下面是一个接口文档的示例：
---------------------------------------------------------------------------------------------------
水井水量
1) URL地址：class/water.api
2) 请求方式：get/post
3) 请求参数：
|
参数名 |
参数类型 |
参数长度 |
参数说明 |
必填 |
|
group |
字符串 |
|
水井编号 |
Y |
4) 接口返回：
A:成功：
{
"resultCode": 1,
"success": true,
"data": {
"waterOne": {
"waterName": "水一",
"todayWater": {
"water_01": "01点水量",
"water_02": "02点水量",
"water_03": "03点水量",
"water_04": "04点水量",
........
}
}
"waterTwo":{
"waterName": "水二",
"todayWater": {
"water_01": "01点水量",
"water_02": "02点水量",
"water_03": "03点水量",
"water_04": "04点水量",
........
}
}
}
}
B:失败
{"resultCode": "-1","resultMsg": "内部异常"}
--------------------------------------------------------------------------------------------------
这是一个简单关于水井水量的api，除了一些基本的信息，例如 接口名，接口访问路径，请求方式，请求参数，返回数据等，还应该注意接口中应该简化的地方，例如，用water_01表示一点时水井水量的字段，有大量重复数据，可以直接改成01，02，03，04.....这样能节省一点就节省一点。当然还要考虑其他的因素。
在前段时间我总觉得写接口文档没有什么用处，因为即使写了，到后期，总会因为需求变更，或者因为以前没考虑到的地方而重新设计接口文档，往往到最后，最终接口与最初的接口文档完全不一样，这样写接口文档有什么用处呢?然后，与前端人员聊天的时候，他们跟我说，写接口文档给他们前端人员是很有用处的。然后自己仔细想了想，确实写接口文档是有益的。
1）能让前端人员心中大致有数，这些数据的格式是怎么样的。并可以制造类似的假数据直接进行前端开发
2）写接口文档，能让自己对业务有一个更清晰的认识与总结，对以后的代码编写有一定规划
3）要想写出合适的接口，必须对业务逻辑以及数据结构有很深的认识。