如何编写一个项目开发文档

项目开发过程中为了增加程序的可读性和程序的健壮性, 方便后期程序的调试和维护,所以需要在开发过程中统一技术规范,一般会在项目初期确定好相关文档作为这一统一的规范。不同公司会对文档做不同要求,划不同的分类,但一般来说(或者拿自己的经验说)大致可以分为需求文档、接口文档、流程图(可以单独作为一份文件可以作为附件附在文档中)、变更文件等。

一、需求文档

在项目启动之后,项目的目标已经明确了,那么就要开始着手干活了,但是在干活之前,需要对整个项目分析透彻。那么,如何对业务进行分析呢,看以下的建议。

首先,开发人员要有随意转换身份的意识和能力。

A、明确产品功能

在分析业务时,站在用户的角度上,思考要做的产品能实现什么功能。把所有的功能点列出来!

B、分析某一功能点的流程

在罗列了所有的功能之后,需要站在开发者的角度分析每一个功能点,考虑从客户端到后台操作数据库的整个流程,可以从是什么、为什么、在哪、怎么做、谁来做、做完如何反馈、反馈给谁、上传到哪、服务器用什么数据库、数据库需要什么表、表里有什么字段、每个字段的属性及意义等等。比如,我要要做一个软件中个人头像上传的功能,首先明确我做的是上传功能;为什么要上传?因为个人资料需要头像;怎么做上传?通过网络I/O实现;这个功能在什么位置?软件有个个人中心模块,个人中心里有个个人信息子模块,在这个模块里可以上传头像;谁上传?已经登录的用户;上传完之后如何反馈?弹窗提示上传成功;反馈给谁?客户端已登录的用户;上传到哪?服务器上;用什么数据库?MySQL;需要什么表?(存到)用户表;表里有什么字段?用户信息的基本字段;每个字段的属性及意义?略。在思考完这些问题之后,可以把一个功能点串成一条完整的从前端到数据库的线。

C、整合各个功能点--明确分工

在串完所有的功能点之后,站在一个高一层次的角度,把每个功能点之间的联系理清楚,按照相互的联系分工合作,优化其中的细节问题。

D、撰写需求文档

分工完成之后,按照第二步分析的内容,每个人把自己负责的功能整理成文档,最后合并文档,作为统一的需求文档。

E、绘制业务流程图

需求文档确定之后,绘制整个项目的业务流程图,这时候的流程图只需要包含前端的业务流程,后台实现的流程图不需要在需求文档中体现,而是放在后面的接口文档中。

二、接口文档

不同公司对接口文档的要求也不尽相同,但包括的内容却是大同小异的。封面、标题、审批页、修订历史以及格式字体等等风格迥异的次要内容不做赘述,只讲干货!干货!干货!

A、请求地址

需要哪个线上地址就写哪个。注意不要反低级错误,比如写错某个字母或者大小写问题。

B、接口信息

说明请求方式,是POST还是GET。

C、功能描述

清晰地描述接口功能,要求言简意赅,不要写太多废话,也不要遗漏任何细节。

D、接口参数说明

声明参数的名称,严格要求与调用一致,包括大小写;

简单说明参数的含义;

参数的数据类型,是string 、int 还是long等(例如参数为@RequestParam("appKey") String appKey, @RequestParam("randomId") Integer randomId);

备注部分,说明参数值是需要哪个公司提供,并详细说明参数怎么生成的,例如时间戳,是哪个时间段的;参数是否必填,一些参数是必须要有的,有些是可选参数,一定要注意写清晰。

E、返回值说明

有一个模板返回值,并说明每个返回参数的意义。提供一个真实的调用接口,真实的返回值。

F、接口调用限制

为了安全,双方采用一个一致的加密算法,保证接口调用的安全。

G、文档维护

文档维护时,修改内容部分需要有修改人、修改日期、版本号的信息。

三、流程图

流程图可以单独作为一份文件,也可以作为附件附在对应的文档中,具体执行按要求来。

业务流程图

程序结构图

程序流程图

四、变更文件

在开发过程中如果出现与预期计划、文档不一致的地方,则视为发生变更,此时大致需要提供以下信息:

A、版本历史(版本号、基本信息)

B、变更前现状

C、变更内容

D、影响评估

E、审批

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181224G0TQ5B00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券