系统接口设计说明书_信息系统开发流程

一看就会，五千字拆解项目制需求文档（内含AI利用方法） 　　引言：如何快速交付一篇需求文档（prd）？本文将从产品思维的视角拆解快速完成一篇项目制的需求文档。愿对君有所裨益。 　　什么是PRD? 　　1. 文档目的： 　　常规需求文档的用途总体分为两类：一种是细化需求，用于给开发传达产品需求；另外一种，也是本文主讲的，适用于项目制交付给甲方，给客户传达业务需求，对内给开发传达产品需求。 　　2. 文档受众： 　　明确你的PRD有哪些读者，一般包括：项目参与人员（项目经理、前端、后端、测试、UI设计、产品经理），项目甲方（客户），市场人员 ，运营人员，领导或者老板。主要阅读受众的不同会决定整个文档的格式，文字情感色彩。给内部领导、政府、大型企业的客户交付，整体写作文案偏向概括与宏观，更多的“互联网黑话”；给小型客户，内部人员使用，就更接地气，偏向于常规的互联网文案基调更注重实用性。 　　3. 文档价值： 　　三个重点：专业性、易读性、可用性。对客户来说体现产品设计的专业度，既保证满足客户商业需求（比如演示，宣讲，内部存档入库）；对内部团队来说，能快速理解产品设计中的产品架构、业务规则、异常情况、特殊字段、交互流程、设计原则，同时文档易于不同人员查看理解，简洁精炼，降低团队内沟通成本。 　　4. 文档编辑工具 　　编辑文档工具不受限制，这里推荐在线软件，例如某企鹅的产品等，这类软件有个特点，在设置大纲级别特别方便，容易调整文档格式。 　　如何写好PRD? 　　事前准备（用产品思维思考）： 　　明确目标用户：明确你的PRD的目标用户，到底是谁看？（老板？业务方？团队？）确认用户需求与解决的问题：确认PRD读者的需求，哪类客户群体偏多，决定文档的结构与文档侧重点；PRD最根本的目的还是减少沟通成本符和各方人员查看需求说明。规划架构蓝图：先用思维导图罗列文档大纲，圈住写的范围与整体内容框架。做好具体细节准备：包括提前做好产品信息结构图，功能清单，核心业务流程图，原型设计等 　　1.命名与封面 　　常规命名公式：产品名称+功能模块+版本号，大部分甲方客户会有特殊格式要求比如:内部项目编号+产品名称+VX.Y（X.Y为版本号）封面常规格式：●企业名称（部门名称）+项目名称+项目编号+需求说明文档●文档编码或者文档总页数●签字方●文档修改记录根据具体要求进行调整，如果仅内部使用可以简化，文档修改记录不可删除，方便团队溯源。 　　2.文档结构 　　PRD文档内容结构包括：文档目的、名词解释（术语定义与缩略词）、文档编写规范、系统概述（产品背景、目的）、功能架构、功能清单、业务流程图、业务用例、全局说明（交互说明、全局规则等）、非功能性需求。如果有相关文档，附件说明。 　　文档目的 　　顾名思义写作本文档的目的是什么，前文有详写故此不做过多赘述 　　名词解释 　　产品中涉及的一些专业术语的定义，与特殊字段的解释与规则。例如在做政府的图书管理后台系统时（本文案例均来自此系统）涉及的名词如下：术语解释定义ISBN码国际标准书号（英语：International Standard Book Number，缩写为ISBN），是国际通用的图书或独立出版物（定期出版的期刊除外）代码。出版社可以通过国际标准书号清晰地辨认所有非期刊书籍。一个国际标准书号只有一个或一份相应的出版物与之对应。一本书的每一版皆能申请到一个新的国际标准书号架位号用于标识图书馆书籍货架的编码，由自定义的数字组成。方便管理员对图书货架进行管理；也等同于查询端页面所展示“馆藏位置”名词新增入库对图书的库存进行管理，能够快速增加图书的库存删除库存对该图书的库存数量进行管理，能够直接删除该图书的库存数量图书编号每本书籍的唯一标识编码，用于标记实体书本存储于系统数据库中借阅单据读者每次借阅书籍在系统生成的实体单据，用于记录该次借阅的详细信息借还管理用于在系统中操作对书籍的借阅、续借、归还。显示所有借阅信息SKU最小库存单位，本文用来指图书的库存，比如《红楼梦》库存10本，SKU为10SPU最小标准化单，本文用来指图书，比如《红楼梦》即为一个SPU 　　文档编写规范 　　整个文档的编写规范，对于格式要求比较严格甲方客户，一般需要进行说明，内部沟通可忽略。以下是常规的规范定义，可以根据自身写作习惯进行调整，能解释说明清楚，全文运用符号规范一致即可。名称约定说明按钮【】确定按钮，可简化为【确定】菜单项[]文件菜单，可简化为：[文件]文件或文件夹《》双击TEXT文件，可简化为：双击《TEST》连续选择菜单及子菜单——选择[基础功能管理]——[分类管理]窗体‘ ’弹出‘新建图书’弹窗窗体中选项<>‘图书详情’中选择对应<图书编号>提示信息“”提示“是否删除此数据”流程指向→从首页进入详情页：首页→详情页。 　　系统概述 　　主要是对整个产品的设计背景，解决的什么问题的描述。如果有条件利用chatgpt等一类AI平台，可以比较快速的总结出来宏观性的背景文案。如下：





　　这里涵盖两个方法：一个是写prompt（提示指令）的原则，给AI进行下定义，尽量走多角度，多定义，多素，写明自己需要咨询问题的前后要求与背景。二是提取数据的方法，所有AI生成的答案只是参考，需要将对应的结构化表述结合实际情况进行归纳整理。提取方法：抓取关键字+实际概念替换回答中通用性概念+结合实际业务做减法；如果需要更接地气背景目的可以详细描述产品的目的以及解决的实际问题，与预计带来的收益效果。再者，这部分也可以加入一些系统的规划蓝图，例如整个系统的蓝图，参考格式：应用层，业务层，技术层。

　　功能架构 　　整个产品的功能结构图，常用脑图形式进行展示，具体格式不限。包括系统层（具体系统应用表现形式）、业务层（具体功能模块与功能点）、权限结构。比如图书管理系统系统层就涉及用户端、管理端两个系统。对应系统对应不同的功能结构。参考如下：

　　功能清单 　　功能清单和功能架构是相辅相成的，架构设计完后立马可以根据对应功能编辑整个功能清单，清单必须包含：功能模块、子功能、功能描述、特殊规则或者字段统计。以下是示例

　　角色权限 　　可制作一份业务方角色的权限表格，包含角色名称，业务名称，是否有权限。 　　业务流程图 　　业务流程图可选取泳道图进行图示，主要体现用户在系统中的关键业务节点与操作流程，以及对应数据的流向。一般分为两个部分，一个是全局的流程图，一个是关键业务节点的流程图。可选的流程图类型有：业务流程图，状态流程图，时序图，数据流程图。 　　简要说下泳道图的编辑规范：头部为不同业务模块，下方是对应操作流程，如果角色众多，左侧可以对角色进行区分，以下是图书管理系统的管理员业务流程示例：

　　业务用例 　　业务用例（Business Use Case）是指通过场景、流程图、角色、业务规则等方式，描述用户在使用产品时的操作流程和业务逻辑。可以理解为，对功能点的详细描述，对字段的规则定义，对业务规则的描述。这里是整个文档的核心，也是开发人员需要重点的对象。内部沟通时，大部分开发没有耐心去看你的整个文档，所以建议重点维护此部分，将所有开发过程中需要注意的规则都写明写仔细，开发人员只需要查看此部分即可。业务用例同样也分为两个部分，全局业务用例（清单+用例图）和具体业务用例。 　　参考结构：用例概述+用例描述+业务流程（或者UML用例图）+页面原型+特殊说明 　　用例拆分原则：可以从后端接口设计的角度，或者功能点的角度进行拆分，最快捷的方式用增删改查的视角进行拆分，比如订单模块：新建订单，编辑订单，删除订单，订单查询。参考示例： 　　全局用例清单：

　　具体用例清单：用例名称：外借报表查询 　　●概述 　　管理员在[外借报表]列表页，查询图书外借信息，对外借图书进行维护与管理。序号模块功能功能描述1外借报表查询按条件检索外借信息2查看详情查询对应外借信息详情3还书快捷还书 　　●业务用例用例编号UC-001用例名称外借信息查询角色管理员前置条件执行者登录系统并进入[外借报表]页面用例描述管理员查询外借图书信息流程描述1. 登录成功2. [外借报表]3. 输入/选择检索条件4. 【查询】按钮5. 外借未还图书信息备选事件流程无后置条件外借信息查询成功业务规则报表只展示 状态为“逾期”+“未还”的所有借阅图书信息，按图书进行聚合，详情中展示借阅图书所产生的单据详情，可快捷操作还书。列表页默认值为最新数据。特殊说明无 　　●字段表单序号字段名称类型字段规则是否必填1搜索框字符可输入书名/作者/出版社/ISBN/索书号查询对应外借出去的图书2借阅用户字符借阅该图书的借阅用户信息3借阅日期时间表示首次借阅的日期4外借数量数字外借总数量5图书名称字符显示该用户所有逾期未还图书6图书分类字符图书所属的分类，筛选处可通过下拉框筛选7借阅单据字符未还图书所关联的借阅单据8图书编号字符所借阅图书的唯一标识编号9作者字符图书的作者10借阅类型字符图书的借阅类型11借阅天数数字累计借阅的天数12应还日期时间读者用户应该还书的时间13超期天数时间用户逾期未还的天数，计算应还日期到当下时间的累计天数14剩余数量数字剩余可借库存：总数量-外借数量=剩余数量 　　●原型界面

　　Tips：特别注意写用例规则的内容范围不要遗漏：状态是否穷尽，异常情况是否齐全，交互说明是否完整，字段映射关系是否考虑，增删改查规则是否都考虑到，操作校验是否一致，是否具备缺省值（默认值）等。 　　全局说明 　　此模块是指整个系统的全局说明，为了减少我们prd的写作工作量，一般会把大部分通用规范与通用原则在此处进行整理。 　　●交互规则：包含页面加载、按钮、页面滚动、toast提醒交互、数据为空、弹窗交互样式、页面布局、选中样式、焦点样式、通用的一些交互组件等。B端系统和C端系统略有不同，app、小程序、H5也存在差异。 　　●数据规则：描述产品的数据规范和限制，包括全局的数据生成规则、分页处理、数据极值、全局通用性的数据规范，默认值等 　　●业务规则：一些全局通用的业务规则，比如数据的导入导出，按钮防连击处理 　　●接口规则：描述产品的接口规范和限制，包括接口格式、接口参数、接口安全等方面。例如，要求接口遵循RESTful API的设计原则，保证接口的可扩展性和易用性。这里更多是和后端开发或者技术经理进行讨论确定。有条件提供。 　　●测试规则：描述产品的测试规范和流程，包括测试用例、测试流程、测试环境等方面。也是属于有条件提供，一般有测试人员，和测试讨论出结果，不要过多干涉其他领域专业人员的处理意见。 　　●其他说明：特定情况下的一些备注。以下是部分示例：

　　非功能性需求 　　非功能性需求是描述产品功能以外的要求，通常与产品的性能、安全性、可靠性、可维护性、可用性、可扩展性、兼容性等相关。以下是一些常见的非功能性需求： 　　●性能要求：描述产品的性能指标，例如响应时间、并发数、吞吐量、负载能力等。 　　●安全要求：描述产品的安全需求，包括用户身份认证、数据加密、安全审计、访问控制等。 　　●可靠性要求：描述产品的可靠性需求，包括系统可用性、容错能力、恢复能力等。 　　●可维护性要求：描述产品的可维护性需求，包括代码可读性、可扩展性、可维护性等。 　　●可用性要求：描述产品的可用性需求，包括用户界面友好、易用性、可访问性等。●可扩展性要求：描述产品的可扩展性需求，包括系统架构、组件化设计、扩展性设计等。 　　●兼容性要求：描述产品的兼容性需求，包括与其他系统的集成、不同浏览器、操作系统等的兼容性。 　　下方是示例： 　　➢性能需求预估因为不满在线用户50人，未达到性能测试归口，经项目组开发人员与客户协商并达成一致、规定测试流程 　　➢系统安全性要求系统安全性需满足软件安全相关要求，包括但不限于： 　　服务器安全：服务器需要安装最新补丁、企业级杀毒软件、防火墙等，确保无病毒、木马。 　　数据库安全：数据库备份和恢复，数据库级用户进行角色和权限授权。 　　系统安全：用户交互模块需要客户端与服务器端增加数据有效性与合法性验证。系统授权：需要授权控制才能访问，根据角色岗位授权不同。 　　➢系统其他非功能性要求正确性：对于用户录入的数据，以相应的显示正确数据。 　　健壮性：系统需具备应对网络传输过程中发生地意外中断的能力，系统各操作界面需具备容错性，并具有友好的错误提示页面。 　　可靠性：系统在额定环境下需保持正常稳定的运行。 　　易用性：系统操作简单、易学易懂、符合标准浏览器操作风格。 　　清晰性：需符合市面常规设计标准。可扩展性：系统需建立合理的程序结构，以利于系统升级。 　　文档收尾 　　常见的尾部内容有：补充规约、补充附件、参考文献等，这里不过多说明，利用好搜索引擎即可。 　　以上就是编写一篇完整prd的全部内容，每个人所处的企业，项目环境都不相同，具体细致要求会存在一定差异，这时候自己就要学会变通，利用好互联网的便捷，多查阅资料，多学习同行经验，对文档质量进行提升。prd最根本的目的还是为了高效沟通，传递各方需求与产品设计方案，所以不管怎样，仍是以效率为主。希望看完此文后对你未来产品工作有一定参考意义与实际的帮助。 　　喜欢的点个赞，转载请注明来源出处！！！交流：旺仔产品笔记