D、撰写需求文档
分工完成之后,按照第二步分析的内容,每个人把自己负责的功能整理成文档,最后合并文档,作为统一的需求文档。
E、绘制业务流程图
需求文档确定之后,绘制整个项目的业务流程图,这时候的流程图只需要包含前端的业务流程,后台实现的流程图不需要在需求文档中体现,而是放在后面的接口文档中。
二、接口文档
不同公司对接口文档的要求也不尽相同,但包括的内容却是大同小异的。封面、标题、审批页、修订历史以及格式字体等等风格迥异的次要内容不做赘述,只讲干货!干货!干货!
A、请求地址
需要哪个线上地址就写哪个。注意不要反低级错误,比如写错某个字母或者大小写问题。
B、接口信息
说明请求方式,是POST还是GET。
C、功能描述
清晰地描述接口功能,要求言简意赅,不要写太多废话,也不要遗漏任何细节。
D、接口参数说明
声明参数的名称,严格要求与调用一致,包括大小写;
简单说明参数的含义;
参数的数据类型,是string 、int 还是long等(例如参数为@RequestParam("appKey") String appKey, @RequestParam("randomId") Integer randomId);
备注部分,说明参数值是需要哪个公司提供,并详细说明参数怎么生成的,例如时间戳,是哪个时间段的;参数是否必填,一些参数是必须要有的,有些是可选参数,一定要注意写清晰。
E、返回值说明
有一个模板返回值,并说明每个返回参数的意义。提供一个真实的调用接口,真实的返回值。
F、接口调用限制
为了安全,双方采用一个一致的加密算法,保证接口调用的安全。
G、文档维护
文档维护时,修改内容部分需要有修改人、修改日期、版本号的信息。
三、流程图
流程图可以单独作为一份文件,也可以作为附件附在对应的文档中,具体执行按要求来。
至于图的细节,不说废话,上图举例(两个图不是同一模块功能的图)。
业务流程图
[attach]245056[/attach]
程序结构图
程序流程图
四、变更文件
在开发过程中如果出现与预期计划、文档不一致的地方,则视为发生变更,此时大致需要提供以下信息:
A、版本历史(版本号、基本信息)
B、变更前现状
C、变更内容
D、影响评估
E、审批
欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) | 黑马程序员IT技术论坛 X3.2 |