免规则采集器列表算法( 原型式产品需求文档的一级导航(PRD)怎么做？)

　　免规则采集器列表算法(

原型式产品需求文档的一级导航(PRD)怎么做？)

　　目前互联网产品迭代的速度越来越快，大家都在追求一种小而美的MPV产品开发方式，以应对市场的快速发展变化。

　　传统产品经理使用Axure绘制原型图，使用word输出产品开发需求规范（PRD），耗时耗力。最后，开发和测试的小伙伴可能不喜欢看，因为他们需要看原型图并打开它。PRD 文档和其他各种产品文档看起来很麻烦。

　　结合这个痛点，我推荐在原型图的基础上编写产品需求文档，这样不仅可以节省产品经理的时间，而且开发和测试也不需要阅读那么多文档，提高了整体的工作效率。团队。

　　首先打开原型产品需求文档。整个文档界面的顶部分为黑色的主导航区和红色的辅助导航区。

　　如下图，黑色的一级导航可以选择不同的目录轮廓。每个一级导航与多个二级导航菜单相关联。每个二级导航菜单下方是我们产品需求文档的具体内容。

　　原型需求文档的一级导航分为四个模块：产品介绍、思维导图、原型图、非功能需求。每个模块都有多个子菜单模块。下面开始详细讲解二级导航的菜单。

　　一、产品介绍1. 产品说明

　　主要作用是帮助大家更清楚地了解需求的背景和目的。为什么这样做？怎么做？通过阅读本文档，您可以清楚地了解产品的全线需求，如下图所示。

　　2. 功能列表

　　主要功能是告诉你当前版本涉及到哪些需求点和功能点，每个需求点的一般需求描述是如何实现的，设计逻辑是什么。

　　3. 修订历史

　　主要功能是在外部审核需求后，记录每次修改需求中的哪些页面、哪些字段、哪些逻辑等，并记录修改前的逻辑和页面中的修改。

　　修订历史列表支持跳转到修订详情页面，方便大家快速了解和查看。后面我会单独写一个原型需求文档编写规范再详细介绍。

　　4. 版本介绍

　　主要定义当前版本号、版本上线时更新和发布的内容、上线更新方式、应用商店截图是否更新，并进行说明。

　　二、思维导图

　　本模块主要帮助您了解产品的整体系统设计架构、功能、信息结构，并以图表的形式梳理产品逻辑和流程。

　　本模块不限于这4个内容，所有对大家理解产品有帮助的图都可以在本模块中呈现，如：序列图、泳道图、用例图、关系图、状态图、行为数据图、操作流程图、财务资助进度表等。

　　1. 功能*敏*感*词*

　　是介绍功能模块类别下各模块功能的图。一个功能模块可以是完成某项任务的一组程序，一个功能点可以是程序中的某个处理过程。

　　方便大家对功能结构形成直观的认识，防止产品需求转化为功能需求的过程中出现功能模块和功能点缺失的现象。

　　2. 信息*敏*感*词*

　　它是从产品的实际页面中分离出来，对产品的数据进行抽象，并结合分类的图表。提示大家查看产品复杂的信息内容时是否会出现遗漏、混淆、重复等情况，可以作为开发工程师建立数据库的参考。

　　3. 业务流程图

　　是业务需求不同阶段各功能模块之间信息流动和交互的过程，以图表的形式呈现。它的作用是帮助你全面了解业务处理的过程，分析业务的合理性，帮助开发可以实现计算机的处理部分。

　　4. 功能流程图

　　它是针对功能的特定功能点系统的处理流程。这个过程可以和当前的功能点需求文档一起呈现，更有利于大家阅读理解的连贯性。

　　5. 时序图

　　它反映了对象之间交互的顺序，是前端和服务器端消息传递和数据交互建模的基础。它可以帮助开发人员了解产品功能是如何实现的，以及如何设计开发文档。

　　三、原型图1.业务规则

　　是通过一定的约束来限制、控制和影响业务的行为。通过这个内容，你可以清楚的看到整个产品中存在多少业务规则和限制。

　　2. 全局描述

　　用于描述在整个产品线中遇到的全局性问题，以及描述在不同位置频繁出现的一些相同类型的信息。功能是方便大家集中阅读产品需求中的常见需求点，也方便需求的维护和管理。

　　3. 原型页面列表

　　它是当前版本中要设计和开发的所有页面的列表。通过这个内容可以直观的看到具体的开发任务，也可以通过这个内容查看各个功能和页面的具体产品设计需求文档。

　　4. 产品规格

　　分为交互规范、视觉设计规范和其他说明。事实上，它与全局描述有些相似。为了方便大家更好的理解和区分全局问题和规范的区别，我们分成两部分进行说明。

　　四、非功能性需求

　　非功能性需求是产品为了满足用户的使用和操作需要而必须具备的功能性需求以外的需求。

　　不仅限于以上四个内容，还可能包括安全需求、易用性、可扩展性、可维护性需求、网络需求、数据需求、接口需求、统计需求、服务器-客户端交互需求等需求，本模块仅需要以上4个内容作为基本要求。

　　1. 数据埋葬

　　它是一种数据采集的方式，是未来数据分析的基础。

　　2. 兼容性要求

　　当前版本的内容和历史版本的内容在系统中协同工作，不能产生bug，必须兼容新旧功能和历史数据的正常运行。

　　3. 性能要求

　　它是从系统的数据性能、系统的并发性、响应特性和系统的结构特性对系统性能的需求。

　　4. 测试要求

　　就是组织测试焦点（逻辑、数据、流程），明确测试焦点的优先级，为测试伙伴提供测试用例所需的功能信息。

　　最后我想说，一份好的《原型产品需求文档》还需要整个产品、开发、测试团队的不断磨合和应用。分享一下我的产品体验，希望对大家有帮助，谢谢！

　　本文由@Brilliant 千阳原创 发表 每个人都是产品经理。未经作者许可，禁止转载。

　　标题图片来自 Unsplash，基于 CC0 协议。