需求文档怎么写最有效 产品需求文档范例word


Android APP开发需求文档范本软件需求文档格式的标准写法
1.引言
1.1编写目的
· 阐明开发本软件的目的;
1.2项目背景
· 标识待开发软件产品的名称、代码;
· 列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户;
· 说明该软件产品与其他有关软件产品的相互关系 。
1.3术语说明
列出本文档中所用到的专门术语的定义和英文缩写词的原文 。
1.4参考资料(可有可无)
列举编写软件需求规格说明时所参考的资料 , 包括项目经核准的计划任务书、合
同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档 , 以及相关产品
的软件需求规格说明 。
在这里应该给出详细的信息 , 包括标题、作者、版本号、发表日期、出版单位或资
料来源 。
2.项目概述
2.1待开发软件的一般描述
描述待开发软件的背景 , 所应达到的目标 , 以及市场前景等 。
2.2待开发软件的功能
简述待开发软件所具有的主要功能 。为了帮助每个读者易于理解 , 可以使用列表或
图形的方法进行描述 。使用图形表示 , 可以采用:
· 顶层数据流图;
· 用例UseCase图;
· 系统流程图;
· 层次方框图 。
2.3用户特征和水平(是哪类人使用)
描述最终用户应具有的受教育水平、工作经验及技术专长 。
2.4运行环境
描述软件的运行环境 , 包括硬件平台、硬件要求、操作系统和版本 , 以及其他的软
件或与其共存的应用程序等 。
2.5条件与限制
给出影响开发人员在设计软件时的约束条款 , 例如:
· 必须使用或避免使用的特定技术、工具、编程语言和数据库;
· 硬件限制;
· 所要求的开发规范或标准 。
3.功能需求
3.1功能划分
列举出所开发的软件能实现的全部功能 , 可采用文字、图表或数学公式等多种方法
进行描述 。
3.2功能描述
对各个功能进行详细的描述 。
4.外部接口需求
4.1用户界面
对用户希望该软件所具有的界面特征进行描述 。以下是可能要包括的一些特征:
· 将要采用的图形用户界面标准或产品系列的风格;
· 屏幕布局;
· 菜单布局;
· 输入输出格式;
· 错误信息显示格式;
建议采用RAD开发工具 , 比如Visio , 构造用户界面 。
4.2硬件接口
描述系统中软件产品和硬件设备每一接口的特征 , 以及硬件接口支持的设备、软件与硬件接口之间 , 以及硬件接口与支持设备之间的约定 , 包括交流的数据和控制信息的性质以及所使用的通信协议 。
4.3软件接口
描述该软件产品与其有关软件的接口关系 , 并指出这些外部软件或组件的名字和版本号 。比如运行在什么操作系统上 , 访问何种类型的数据库 , 使用什么数据库连接组件 , 和什么商业软件共享数据等 。
4.4通信接口
描述和本软件产品相关的各种通信需求 , 包括电子邮件、Web浏览器、网络通信协议等 。
4.5故障处理
对可能的软件、硬件故障以及对各项性能而言所产生的后果进行处理 。
5.性能需求
5.1数据精确度
输出结果的精度 。
5.2时间特性
时间特性可包括如下几方面
·响应时间;
·更新处理时间;
·数据转换与传输时间;
·运行时间等 。
5.3适应性
在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时 , 软件的适应能力 。
6.其他需求
列出在本文的其他部分未出现的需求 。如果不需要增加其他需求 , 可省略这一部分 。
7.数据描述
7.1静态数据
7.2动态数据
包括输入数据和输出数据 。
7.3数据库描述
给出使用数据库的名称和类型 。
7.4数据字典
对于数据流图、层次方框图中出现的所有图形元素在数据字典中都要作为一个词条加以定义 , 使得每一个图形元素都有唯一的一个清晰明确的解释 。
数据字典中所有的定义必须是严密的、精确的 , 不可有二意性 。
7.5数据采集
·列出提供输入数据的机构、设备和人员
·列出数据输入的手段、介质和设备;
·列出数据生成的方法、介质和设备 。
8.附录
包括分析模型 , 待定问题图表等 。
怎么写新产品的产品需求方案一款新产品在推向市场做推广之前要考虑以下几个问题:找到市场上的同类产品的差异化 , 提高市场推广的销售份额;增加产品结构 , 提高品牌竞争力;拓展空白市场 , 增加产品的知名度 。那么怎么写新产品的产品需求方案呢?下面一起和我看看吧 。
篇一
一、写产品需求的准备工作
你要做的是一个让人无可争议的产品 , 为了做好他 , 你必须做好前期的准备工作 。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术 。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法 。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述 。
建立良好的交流也非常重要 , 它会影响着产品团队 。如果你的准备工作做的够好 , 你也会变得越来越有信心和说服力 。
二、清楚了解产品需求
任何一个好的产品都开始于一个需求 。你必须清楚的了解这个需求 , 你的产品如何达到这个需求 。
产品经理需要提出一个清晰、简明的价值主张 , 让它很容易被接受 , 要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图 。虽然这听起来很简单 , 但是也只有少数产品才有这样的价值主张 。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试 。假设你在做电梯的时候遇到公司CEO , 他问你产品的意图是什么 , 你能在电梯到达之前回答这个问题吗?如果不能 , 你就还有工作需要做 。也许是你的说明没有针对性 , 他可能表现出来和其他产品做的没有什么明显区别;也许你提出的观点不能和你的用户产生共鸣;也许你解决的是一个非常规的问题 , 可能你想应用一种技术 。这个价值主张可能需要满足公司的产品战略 。注意你不需要阐述太多的细节 , 从某些方面来说 , 一个有价值的观点应当是越简越好 。
产品需求需要确切的指出这个产品发布的目标 , 同样的这个目标也有优先之分 。例如 , 你的目标可能是:1)易用 , 2)零售价不足$100 , 3)和前期产品很好的结合 。然后你需要说明如何去测算 。对于“易用”这类项目 , 你需要明确指出产品可用性达到某个水平 。这是通常用目标用户来定义 。可用性工程师能测算出你的产品对目标用户的可用性 , 也测算出可用性问题的严重程度 , 同样你可以说明没有重大的可用性问题 。
这里的关键就是让每个人都知道产品成功的时候是什么样 , 还有给产品团队在设计和实施中遇到问题如何进行取舍的指导 。
三、确定用户原型、用户目标和用户任务
现在你已经明白你想要解决什么问题 , 下接下来就要深入了解目标用户和顾客 , 在这步中 , 和你的PD(产品设计)紧密联系非常重要 。
1、用户原型
在这个阶段 , PM需要和很多用户交流 , 需要花费大量的时间去直接观察和讨论 。现在我们需要对用户和顾客进行分类 , 然后决定那一类是我们的首要用户 。
比如你正在做一个像eBay一样的互联网拍卖服务 , 你同时拥有买家和卖家 , 在这之中还有使用频率少的用户和经常使用的用户 , 不难想象还有个别特殊的用户 , 比如团体公司采购者 。
PM(产品经理)和PD(产品设计)需要首先确定类型是最重要的 , 然后尽量对这个用户群的特征进行详细的描述 , 以便使用这个模型去指导产品的设计 。这个模型通常称其为“人物角色” 。虽然是想像的 , 但是应该是典型的、可行的和真实的 , 让你能够使用 。这个想法来自与一个能代表这类用户的本质的原型 。
注意缩小范围 , 让他仅仅描绘必不可少的 。满足所有人是徒劳的 , 通常最后没人会满意 , 所以尽量提出几个最重要的和最流行的角色描述是非常重要的 。同样 , 如果你不去精确的定位你的目标用户 , 你就只会存在模糊的概念 , 你会发现理解你用户的反应非常困难 。你要倾向于设想 , 让你能更像你的用户 。
2、用户目标(用户意愿)
一旦我们确定并描绘了我们主要的用户类型 , 我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单 , 但是解开根本问题是非常具有挑战性的 , 特别当你周围的人告诉你你已经解决了他们想要的 。从CEO、销售代表、工程师到客户 , 每个人都太兴奋而不能帮助你找到解决根本问题的办法 , 他们会告诉你在某个地方添加一个快捷按钮 , 或则添加一个功能仅仅是因为竞争对手有 , 或则是改变成他们喜欢的颜色 。
最好的解决办法取决于清晰的了解到底什么问题需要解决 , 每个用户模型可能有不同的目的 , 需要在用户原型涉及的方面中进行寻找 。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一 。
3、用户任务(tasks , 用户为达到目标使用产品而需要做的任务)
掌握了用户原型与他们的目标愿望 , 我们就开始着手设计任务来满足他们的目标意愿 , 这是产品制作进程中最核心的部分 , 也是创造力和创新力被激发的地方 。
许多优秀的产品仅是用更好更新的办法解决一个已有的问题 , 有时候这种办法仅仅是应用一个种新技术 , 但是大部分是来自深刻的见解而使一种新方法的产生 。
注意我们虽然谈到了目标和任务但是还没有谈到具体的功能 , 这些功能都需要达到用户目标而必须的 。你以后会发现许多功能都是低优先级或则是完全多余的 。
以“必须功能”这个理由可以排除很多功能 。讽刺的是 , 你用越少的功能 , 你的产品被发现得越来越强大 。这是因为产品的功能越少 , 你的用户就会发现并使用更多的功能 , 成功的使用越来越多的功能他们就认为你的产品非常强大 。这些理由都是违反我们直觉的 , 我们大多数人都不能和我们的用户一样 , 我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性 。
四、写产品需求的原则
现在你需要开始把你的需求和用户体验定义成详细的要求 。同时你仍然会面临着许多的决定和权衡 , 为你的产品标准作出最佳的决定是非常重要的 。
在大多数的产品团队中 , 每个成员都有做好产品的原则 , 但很少有两个人有同样的想法 , 这些差异都会导致不可思议的结果 。尝试和制订一系列指导整个团队的产品原则是非常有价值的 , 这些原则需要具体到域名和项目 。
五、检验测试产品
这是一个拿出你想法的阶段 , 创造力和创新力拿出成就的地方.很多人都容易犯一个常见的错误 , 他们对产品设计规范太有信心 , 结果一旦得到beta的测试他们就必须调整产品 。
但是肯定beta测试版并不是进行重大改变的时候 , 所以才会有许多首次发布的产品离目标太远 。对于许多产品来说 , 这个时候你可以用大量的原型做很多的实验 。首先 , 下面的三个非常重要的测试你可能需要做可行性测试
产品是否可以开发 你的工程师和设计师应当介入技术的可行性调查和探索可用办法 。有些办法是行不通的 , 但是有其他的办法可行是非常有希望的 。工程师会发现在产品的某个阶段不可能逾越 , 现在知道比以后知道要好 。
可用性测试
产品设计师将要和你紧密工作共同提出产品功能 , 让它能适应不同的用户 。可用性测试常常会找出遗漏的产品要求 , 同时确认产品最初的要求是否是必须的 。在你拿出一个成功的用户体验之前需要多做一些测试工作 。可用性的目的是在真正的用户身上测试 , 从产品目标用户得到质量反馈的测试是非常艺术和科学的 。当然产品经理和产品设计将模仿使用 , 但是实际是没有人能取代真实的目标用户 。
概念测试(Product Concept Testing)
光是可用和可行是不足的 。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值 。这测试可能与可用性测试联系在一起 。对于一部份小产品 , 您的想法写在纸就足够了 , 但是对于多数产品 , 为了预计产品是否达到目标 , 复杂用户互作用或新技术的使用、某种形式原型都是非常重要的 。
原型也许是一个物理设备 , 或者它也许是软件产品的一个预览版本 。关键是它需要足够现实 , 您能用原型在实际目标顾客身上测试 , 并且他们可以给您质量反馈 。
以前做原型主要有两个障碍 。第一是缺乏良好的原型工具 , 需要花费很多的时间制作原型;另一个是管理方不知道原型和真实产品的区别 , 在不可预计的情况下 , 按照最终产品来要求原型 。
今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型 , 可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试 。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样 。
在实际去做产品之前去检验你的产品是非常重要的 。一旦实际的工程开始 , 作出重要的变动会变得非常困难 , 花费也会变得很高 。
六、对新产品进行验证和质疑
当你认为你弄懂了你需要解决的问题 , 现在是时候开始验证和质疑假设 。假设甚至当作不知道是很容易的 , 但是切勿把不可知的结论当作指引 , 那会妨碍你获得成功 。
七、在写产品需求时要考虑优先级
除了明确的要求 , 对每一个您的要求给予优先和排列秩序是很重要的 。多数产品经理 , 如果他们给予优先级 , 一般都是表明要求是否是“必须有 ,  “重要”或“希望拥有” (或其他一些分类系统) 。分类是很重要的 , 不可掉以轻心 。
产品经理对任何一个标记“必须拥有”都需要有高度的标准 。如果还没有找到必须拥有的功能意味着产品还不应该产生 。所以小心标注“必须拥有” , 这些标注“必须拥有”的功能直接反应出产品的核心价值 。
“重要”的分类也很重要 , 在产品销售前只要有机会就要满足这些功能 。
“希望拥有”产品团队也应该注意到 , 即使大多数也都没有实现 , 在未来版本也适当的慢慢实现 。
这些有时候是不够的 , 从1到n每一个分类优先排序都是很重要的 。有几个原因:
首先 , 上市时间总是被关注 , 并且日程表经常下降 , 您说不定被迫使削减有些特点为了尽快进入市场 。你也不想产品团队先开发简单的功能而放松重要的功能 , 导致最后客户使用的关键功能还没完成 。
其次 , 在产品设计和开发阶段 , 团队将会发现更多的问题产生并解决这些问题 , 所以很有可能有更多关键功能出现 。优先顺序会可以帮助你如何平衡以容纳更多的功能 。
这点就是说产品经理如何不给出优先级和重要等级 , 其他相关较少的因素也会跟着无法确定 。
整个PRD是一个不断完善和思维提高的过程 , 明朗锐利就是可以成功的产品的 , 模糊就是失败的产品 。在争论最激烈的时候也能容易做决定 , 并且帮助工程师做出计划 。
八、测试产品需求完整性
现在你有一个PRD草稿 , 你需要测试它的完整性 。工程师是否可以充分了解并达到目标?OA Team(质量管理团队)是否有足够的信息来做出测试计划 , 是否可以开始做案例?
当投资人或相关人审核了PRD , 确定了各个需要说明的方面 , 所有的问题得到解决 , 现在你就可以按PRD进行产品开发 。
九、管理产品
在产品实施期间 , 就算是最好PRD , 也有不计其数的问题被解决 。解决所有PRD中存在问题 , 如果不在PRD中就写进去 。你的任务就是迅速解决问题并记录在PRD 。
如果你做了你的工作并准备记录在PRD , 项目审查就会变得非常简单 , 因为任何一个部份都历历在目 。
记住PRD是一个“活”的文件 , 在要跟踪记录在产品开发期间的所有功能过程 。最后你会发现很多额外的东西 , 如果你认为是必要的就在PRD中写进 。
篇二
当今时代 , 唯一不变的事情就是变化 , 创新是企业生命之所在 , 创新已经成为时代发展的主旋律 。对白酒企业而言 , 开发新产品具有十分重要的战略意义 , 因为随着白酒行业竞争的日益白热化 , 企业要想在市场上保持竞争优势 , 只有不断创新 , 开发新产品 , 才能巩固市场 , 不断提高企业的市场竞争力 , 保持市场可持续发展 。因此 , 新产品是企业生存与发展的重要支柱 , 是确保企业基业长青的有力武器;对于营销人员来说 , 推广新产品是提升业绩 , 增加收入 , 体现个人业务能力的有效途径;对经销商和二批商来说 , 新产品是提高销量 , 增加利润 , 保证厂商双赢 , 保持市场可持续发展的有效办法 。
然而现实中往往很多企业投入了大量的人力、物力、财力研发的适合市场的新产品却在推广的过程中早早的夭折了 。为什么即使适合市场的新产品会在推广的过程中会夭折呢?事实证明原因如下:一、凡是新产品推广较好的企业都有推进计划 , 并按计划一步步进行落实 。而那些推广不好的企业则是企业将新产品分给客户就万事大吉 , 不再采取其他积极推进措施 。二、真正的销售是靠人来落实的 , 往往企业的销售人员和经销商会对新产品存在严重的抵触情绪 , 抵触的原因是 , 销售人员和经销商不愿意去费心费力推广新产品 , 他们都会把注意力集中在成熟产品做促销 , 迅速起量上 , 这样做既轻松销量提升也明显 。那么 , 企业要确保新产品成功推广应采取哪些步骤呢?
确保新产品成功推广的“步骤”
一、确保销售队伍和经销商、二批商的关注度和士气、齐心协力推广新品
新产品上市前举办新产品上市培训会 , 充分调动渠道中各个成员的积极性 。提高销售人员、经销商、二批商的积极性 , 共同参与到新产品推广中 , 形成“三级联动”推动新产品推广的氛围 。如: 向销售人员、经销商和二批商进行“新产品推广的重要性”宣导 , 向他们介绍清楚新产品的诞生思路、它的优势和利益点在那里 , 具体的包装口味、价格描述是怎样的等等 , 使渠道中各成员对新品的上市做到心中有数 , 增强信心 。另外针对销售人员、经销商和二批商进行新产品上市各项过程指标的专项考核 , 加快新产品铺市速度 , 形成新品销售氛围 , 让他们明白“过程做的好 。结果自然就好” , 只要能把新产品推广过程中的各个指标(铺市率、陈列、促销、价格体系等等)落实到位 , 新产品自然就会推广成功 , 销量自然就好 。如:新产品在上市销售的过程中会有广告投放、铺货、经销商进货奖励、二批及零店促销、超市进店、消费者促销、销售人员开店奖励、等一系列动作 , 新品上市计划要对每一项工作做出具体规划和安排 , 确保新产品推广的各项活动有条不紊的进行 。具体要做到:
1、新品上市前召开所有销售人员、经销山和二批商新产品推广培训会 。
2、对所有销售人员、经销商专门订出新品销量任务;
3、日常销售报表和会议体现对新品销售业绩的格外关注 , 建立完善的业绩分析系统全程掌控新产品推广动态 ;
4、上市执行期销售例会中新品业绩成为主要议题 。对不能如期完成新品推广任务的市场要求做出“差异说明” , 并进行奖罚激励 ;
5、举办销售竞赛(如:新品销售冠军)对优胜者予以公开表彰和奖励;
6、人员奖金考核制度 , 把新品销量达成从总销量达成中提出来单独考核;
7、企业高层领导对新品推广不力市场亲自检核 , 指出工作漏洞并进行协助;
二、确保经销商进货并在正确的渠道分销
要确保经销商按照推进计划在规定的时间内按照企业的进货标准进新产品 , 并且把新产品在正确的渠道分销 。因为在实际推广的过程中 , 企业的销售人员和经销商往往凭自己的主观判断新产品不好卖 , 所以就一拖再拖不进货或者适当进点但是没有放到正确的渠道去销售 , 就判断企业研发的新产品不好卖 , 肯定会影响新产品的成功推广 。例如:有一家白酒企业在新产品上市初期 , 对所有渠道人员召开了新产品推广培训会 , 也制定了详细的推广计划 。可是在具体推广的时候 , A经销商主观认为新产品不好卖 , 就迟迟不肯进货 , 经销商连新产品进都没进是不可能推广的;B经销商到是按照企业的规定时间和数量进货了 , 可是把中高价位的新产品放到C、D类酒店和 C、D类商超渠道销售 , 结果导致合适的产品没有放到合适的终端店销售 , 使得新产品动销缓慢 , 就反映企业的新产品不好卖 。
三、确保对于新产品推广的指导、协助必须参与进去
要确保渠道中个成员对产品推广的指导、协助必须参与进去 。就是经销商进货后要做到让销售人员下市场车上必须装新产品 , 拜访终端店时必须把新产品上市的信息告知终端店并把促销政策准确无误的介绍给终端店(卖新产品的利润比老产品利润大) 。如:C经销商是按照企业的要求进了新产品 , 可是新产品进了以后 , 每天业务员的送货车上不装新产品 , 业务员下市场也没有把新产品上市的信息告诉终端店 , 也没有把新产品的促销政策介绍给终端店 , 终端店也就不知道新产品上市的信息 , 也不知到销售新产品比销售老产品的利润空间大 , 结果导致新产品在该市场推广失败 。因此渠道成员如果没有对新产品的指导、协助参与进去 , 就说新产品不好卖 , 新产品的推广肯定是不会成功的 。
四、确保新产品的价格体系
确保新产品按照企业规定的价格体系销售 , 因为新产品上市前 , 企业是经过大量的市场调查 , 根据市场的实际研发出来适合市场的新产品 。因此在新产品推广的过程中必须检查经销商的出货价是否正确 , 有没有按照企业规定的价格执行;终端的零售价格是否正确 , 有没有按照企业规定的统一零售价销售 。在实际推广过程中往往渠道成员擅自更改企业新产品的价格体系销售 , 结果影响新产品的推广 , 反倒说企业研发的新产品不适合自己的市场不好卖 。如:A企业的新产品在上市的时制定的价格体系:经销商开票价:20元/瓶(经销商的利润来自于企业的返利) , 终端店开票价:20元/瓶 , 终端店零售价25元/瓶 。但是在实际推广的过程中 , 经销商私自把终端开票价改成25元/瓶 , 终端店零售价改成35元/瓶 , 结果导致新产品的价格体系脱离的了企业推广新产品打压竞品、抢占25元价位市场占有率的目的 , 结果使得终端店感觉新产品的包材支撑不了35元/瓶的价位 , 使得新产品市场铺市率低动销迟缓 , 使得新产品在该市场推广夭折 。
五、确保新产品陈列和推销
要确保新产品按照企业的陈列标准陈列和确保终端店主主动推销 。因为在新产品研发阶段企业是经过大量的市场调查的 , 从而确立新产品在该市场的竞争优势 , 在推广的时候制定相应的促销政策和陈列标准 。因此在新产品推广的过程中必须确保按照企业的规定的陈列标准做好柜台陈列 , 并且在维护的过程中不厌其烦的告知终端店新产品的优势以及销售新产品的利润空间 , 以及销售新产品的奖励政策 。如果陈列不合格 , 店主不知道销售新产品的利润和政策 , 那么新产品推广就不可能成功 。如:A企业在新产品推广的过程中渠道成员都反映新产品不好卖 。结果企业派市场部人员去市场走访过程中发现 , 终端店是签了陈列协议 , 但是新产品有的在终端店的库房根本就没有摆上柜台;有的即使摆放在柜台但也不在明显位置 。当问到终端店新产品是多少钱进的 , 卖多少钱 , 终端店也不知道 , 意味着终端店销售新产品都不知道比销售同等价位的竞品利润空间大 。结果导致新产品在该市场推广迟缓 。
六、确保新产品的铺货率
铺货率检验是新品上市成功的基础 , 铺货率达不到一定水平 , 评估新品接受度根本没有意义 , 因此必须确保新产品在市场上达到规定的铺市率(低于60%的铺市率是很难判定新产品是否适合该市场的) 。如:某企业在新产品推广的时候 , 经销商是打款发货了 , 结果经销商在新产品推广的时候 , 只把新产品放到跟他关系特好的几家终端店销售 , 因为这些终端店在吃独食 , 所以他们零售价卖的很高 。结果导致新产品在该市场没有形成一定的市场占有率 , 市场占有率低使得市场影响力低 。
七、确保力所能及的掌控的终端售点数量的铺市率
所谓为力所能及的终端网点的铺市率 , 就是指该终端店和经销商的客情关系很好 , 一直在销售经销商的其他的产品 , 但却没有销售新产品 。如果此类终端都不知道新产品上市信息和销售新产品政策等或没有进货 , 证明经销商根本就没有推广新产品 。如;
某经销商一直抵触说新产品不适合自己的市场 , 终端店不接受新产品等等 , 结果企业高层亲自到该市场走访并和终端店沟通 , 结果在沟通时了解到不是新产品不好卖 , 而是经销商就没有把新产品的优势和促销政策准确无误的介绍给他们 。
八、确保新产品推广员工的奖金制度执行到位
企业在新产品推广初期都会制定推广新产品的特殊政策 , 如对于销售人员销售新产品提成比销售老产品高 , 新产品进店有开店奖励等 , 要确保让经销商的员工知道销售新产品的提成比销售老产品高 , 新产品进店还有开店奖励 。如果经销商的员工不知道到这些激励政策更定不会去推新产品 。如:某企业在新产品推广初期针对经销商的员工制定了相应的激励政策 。但是经销商在实际推广的过程中把企业的激励政策自己克扣了 , 使得员工在新产品的推广过程中没有积极性 , 导致新产品推广迟缓 。
“幸福的家庭都是相似的 , 不幸福的家庭各有各的不幸” 。事实证明:要确保新产品成功推广 , 就必须制定严格的推进计划 , 并且不折不扣的按照推进步骤去执行 。
篇三
1、产品用途
你的工作就是指出目标 , 团队需要知道他们的目的是什么 , 目标说明要尽可能的明确 , 请确保你的内容包括:
*那些问题你要解决 , 不是解决方案
*谁是目标用户
*细节很多 , 但是大图片必须清晰
*情景描述
2、产品功能特性
产品需求文档最主要的当然是需求 。具体的需求完全地将取决于您的领域 , 但是不管你是什么行业 , 您的产品团队将受益于陈述需求的清楚 , 毫不含糊的要求 , 而不是模糊的解决方案 。描述每个功能的互动设计和使用案例 。您必须非常清楚每个功能和用户体验 , 还需要给工程团队留下足够多的灵活
3、发布标准
发布标准经常是不断变化的 , 但是好的PRD应该考虑到为每种标准定一个最低要求 。典型的如:性能 , 可测量性 , 
可靠性 , 可用性 , 可控性 。
4、时间进度
其中很困难的一个问题就是描述产品需要的时间进度表 。随便列出一个时间是没用的 , 你需要描述环境、动机、预计目标 。你需要整个团队都和你一样达到预计目标 , 最终完成一个成功的产品 。
新产品的产品需求方案文档框架
A、总体说明
1.修订版本
2.产品目标
3.产品受众
4.名词解释
5.其它说明(流程图之类的可以放这里)
B、用例需求部分
1.用例需求1
2.用例需求2
C、用例需求优先级
D、进度表
写好新产品的产品需求方案需要注意的五个方面
1、修订版本 , 用户需求文档不可能开始就很完美 , 后期可能会进行多次修订 , 所以需要记录下 , 为什么改动 , 什么时候改动 , 谁改的 。
2、产品目标 , 让参与这个产品的每一个人知道自己需要朝哪个方向工作 。
3、确定产品的受众 , 让团队知道我们在为什么样的用户做产品 。这样团队里每一个人都可以根据自己的理解去发挥自己的想象力 。
4、用例需求描述 , 产品需求文档的核心模块 。
5、时间进度与优先级 , 产品核心功能的实现基础 , 无论什么企业 , 资源有限 , 核心保证核心功能的开发就需要对产品需求文档设置优先级 。
扩展阅读
什么是PRD?
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档 , 其作用就是“对MRD中的内容进行指标化和技术化” , 这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能 。
产品需求文档应该包含哪些内容我们先假如产品需求文档(PRD)是一个产品 , 那么该如何做出一个拥有良好用户体验的PRD?
首先先来考察下PRD的用户群体(User Persona):主要是开发人员 , 在繁忙的开发任务中最希望看到“简洁易懂”的产品需求文档 。
梳理下PRD的功能:
传达出产品需求;
管理记录产品迭代过程;
各部门共享产品信息 , 以促进沟通;
因此一个好的PRD的原则是:
结构清晰
语言简洁易懂
实时共享
具体我们该如何制作?
答案很简单——一个PRD文档即可
现在 , 越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式 , 因为之前的word+原型的方式管理起来繁琐 , 而且还容易产生信息疏漏 。
将原型和文本说明统一 , 直接分享一个链接 , 开发人员就能看到所有信息 , 是理想状态 。
多级导航结构展示PRD信息
通常来讲 , 一个产品需求文档里包含“产品概述”、“流程图”、“功能详情和原型” , “全局说明” , “非功能性需求” 。
如何把这些内容清晰有条理地呈现在一个文档里呢?使用一个网页般的多级导航结构即可 。
1、产品概述
产品概述部分用于展示文档修订历史、版本说明、开发周期、和产品介绍 。
「文档修订历史」用来记录产品经理对该PRD文档的修改状况 , 也方便成员能及时了解到PRD是否有改动;
「版本说明」展示上线产品各版本的核心功能;
「开发周期」用于梳理开发、测试、上线的预计开始和结束日期 。
「产品介绍」用来记录产品名称、简介、用户画像、使用场景、产品定位等等 。
(墨刀“PRD模版A”中的“版本信息”模块 , by 小龙)
2、流程图
流程图是产品经理梳理产品逻辑和功能的一个思维Map , 一般会有“功能结构图’、“信息结构图”、“任务流程图” 。
「功能结构图」 展示产品的功能模块 , 一般展开用户可见的最小单元 。
「信息结构图」则是以信息为维度 , 用来描述有哪些数据字段 , 展现用户信息/行为信息等 。
「流程图」记录着用户使用产品的路径 , 也是一种产品线路图 , 展示着产品的所有页面及对应关系 , 有助于产品理解 。
(墨刀“PRD模版A”中的“结构图”模块 , by 小龙)
3、功能详情和原型
这个模块是开发人员查看频率最高的模块了 。目前一种快捷高效的呈现方式便是“原型”+“注释” 。
图文互补 , 把图片传递不了的信息用文字补充清楚 , 比如产品的一些使用逻辑 , 方便同事理解 。
使用墨刀的话 , 可以创建一个大的画布 , 然后把墨刀制作的原型页面粘贴到画布里 , 并添加文字注释 , 在关键位置有一些边界条件的说明 。
或者 , 直接在产品原型项目里通过“批注”添加注释 。
(“PRD模版A”中的“交互原型”模块 , 直接嵌入了墨刀原型 , by 小龙)
4、全局说明
这个页面用来展示整个产品的设计规范 , 一些通用的规则可以附在这里 。
对于这点 , 使用墨刀制作的方便之处在于:
可以直接把有关设计规范的原型项目通过网页链接的方式嫁接过来 , 还能点击“标注”查看各元素的细节信息 。
( 墨刀“PRD模版A”中的“全局说明”模块 , by 小龙)
5、非功能性需求
对于不同类型的产品 , 非功能性需求会有各种差异 , 一般会涉及到的有:
性能需求
系统需求
运营需求
安全需求
统计需求
财务需求
……
这部分就要自己按需要调整 。
总结

PRD作为一种重要的公司内部沟通的文档 , 能把必要的信息汇集在一个逻辑清晰的结构里是提高工作效率的一个优势 。语言上的简洁易懂 , 再结合可视化的结构图和原型 , 都是为了增强易读性 , 让沟通更高效 。
把PRD当作一个小产品去打磨一下 , 不是浪费时间 , 一个好的PRD文档可以继用很久 。
墨刀新出了两种产品需求文档的模版 , 这两种PRD里的各级页面内容、导航和交互都为大家设计好了 。
现在大家可以点击“创建项目” , 从墨刀模版中选取“产品需求文档A”或者“产品需求文档B” , 点击“使用模版” , 再按照自家产品需要做一些更改就okay!
通过墨刀的分享链接还能直接让公司内部人员在线实时同步PRD的更新 , 不用再担心信息滞后或者文档不兼容问题 。
让我们着手开始创建或者优化您的产品需求文档吧~
希望采纳!谢谢!
配图来自“运维派”以及墨刀官网截图
需求文档怎么写最有效摘要:对于产品经理来说 , 撰写一份完整的产品需求文档往往需要花费很长时间 , 那么
如何提升产品需求文档的撰写效率呢?
对于产品经理来说 , 产品需求文档(PRD文档)是工作的核心产出 。一份严谨、优秀的产品需求文档能够给项目的其他人员 , 包括设计师 , 开发工程师 , 测试工程师 , 运营人员等带来很大的帮助 。但对于产品经理来说 , 撰写一份完整的产品需求文档往往需要花费相当多的时间和精力 。
今天我们一起来看看 , 如何提升产品需求文档的撰写效率 。
为什么要写产品需求文档?
对于稍微大一点的产品开发团队来说 , 产品经理未必能向所有团队成员准确传达产品开发需求 , 这时就需要一份完整的产品需求文档供项目参与人员阅读 。
首先 , 产品经理可以根据项目的阶段运营目标提出合理需求 , 通过PRD文档阐述产品整体设计需求背景 , 设计思路 , 功能范围 , 交互逻辑 , 页面细节及其他信息 。
其次 , 团队的相关人员可以快速获取自己需要的信息 , 节省反复沟通的时间成本 , 更好地开展工作 。
最后 , 产品需求文档也是一个产品项目投入开发前的重要附件之一 。团队领导可以根据产品需求文档清晰了解为什么需要开发这样一款产品 。项目的其他相关方也可以随时参阅需求文档 , 了解项目的基本信息 。
总的来说 , 产品需求文档有三个核心作用:


  • 传达产品开发需求;

  • 保证团队成员沟通顺畅;

  • 制定产品质量控制标准 。

  • 产品需求文档的在项目中的重要性已经不言而喻 。那么对于产品经理来说 , 有哪些技巧可以更好地完成产品需求文档的撰写呢?
    产品需求文档包含哪些内容?
    通过下图 , 我们可以简单了解产品需求文档需要呈现的基本内容 。
    请点击输入图片描述
    1.产品概述
    产品需求文档的第一部分 , 首先需要对整个项目的研发背景及整体规划进行说明 , 让阅读者可以快速理解需求背景和产品定位 。其次是对产品需求文档本身进行阐述 , 在每一次修订后都需要进行记录 , 方便阅读者了解产品需求文档的修订更新 。这一部分主要包括以下内容:
  • 项目概述

  • 词汇表

  • 文档修订历史

  • 版本说明等

  • 2.功能范围
    这一部分需结合用户、业务规则及市场环境 , 对产品的用户和市场需求进行分析梳理 , 找出差异性和优势 , 制定业务流程和需求清单 。可通过业务逻辑图、流程图、产品结构图等图表 , 让产品逻辑和功能以最简单的方式陈列出来 , 团队成员可根据这一部分了解用户信息、行为信息等 , 也有助于对产品进行进一步的理解 。
    3.功能详情和原型
    首先是列举功能总表 , 将产品功能进行逐条梳理 , 每一条功能都能对应前面的产品目标 。
    其次是功能详情展示 , 通过Mockplus等原型工具快速绘制原型 , 配合关键部分的批注说明 , 详细描述业务模块的展示、交互和数据逻辑 , 以供开发人员查看和理解 。
    4.全局说明
    这一部分包括设计规范、数据统计、通用规则说明等信息 , 方便设计师和开发人员查看产品细节信息 。
    5. 测试需求
    产品一般在正式上线前都有BETA版本或者内测版本 , 产品经理需要定制测试产品的功能或者性能 。
    6.非功能性需求
    非功能需求为用户常规操作产品时的极端情况 , 涉及很多内容 , 包括产品性能、安全性、可靠性、拓展性等方面 。
    7. 产品运营和市场分析
    完成产品开发并不是终点 , 产品的最终目的是要赢得市场 。产品上线后如何运营?建议的推广策略是什么?产品经理和运营人员该如何协作?等等问题 。
    产品需求文档撰写技巧
    如何高效完成产品需求文档的撰写?我们可以从以下四个方面展开说明:
  • 理清文档结构

  • 详尽叙述每一个细节

  • 语义明确 , 没有歧义

  • 搭配原型图或设计稿进行说明

  • 1.理清文档结构
    一份产品需求文档的内容往往多而复杂 , 因此 , 产品经理在撰写产品需求文档时 , 必须理清文档的结构 , 才能提升产品需求文档的可读性 , 让阅读者可以快速了解文档的思路和查阅重要信息 。
    将一份产品需求文档看做一个产品 , 首先需要梳理出它的结构 , 如上文中所呈现的文档内容 , 然后再按顺序进行撰写 , 这样才能写出结构清晰 , 层次分明的产品需求文档 。
    2.详尽叙述每一个细节
    当我们站在产品经理的角度思考问题时 , 往往会出现这样的误区:产品的这一功能模块逻辑非常简单 , 业内常见 , 开发人员也一定能懂 , 不用再进行单独说明 。
    产品经理对于产品的功能及逻辑往往非常了解 , 但如果从开发或测试人员的角度来看 , 往往对于许多产品的细节和逻辑关系都不太了解 。因此产品经理在撰写产品需求文档时 , 一定要做到事无巨细 。不仅需要详尽叙述页面逻辑、交互逻辑、数据逻辑等所有细节 , 还需要从开发、测试等角度检查是否有遗漏或错误 , 才能保证后续开发工作有条不紊 。
    3.语义明确 , 没有歧义
    在撰写产品需求文档时 , 要做到语义明确 , 不能出现让阅读者产生歧义的词汇或语句 , 如:大概、可能、似乎等词语 。另一方面 , 对于产品定义的表述方式 , 必须做到全文统一 。比如在撰写一份APP的产品需求文档时 , 前文写了“首页轮播图” , 后文就不能再使用“首页Banner”、“横幅”等名称 。
    4.搭配原型图或设计稿进行说明
    产品需求文档往往包含大量文字描述 , 团队其他成员在阅读某些功能细节时 , 往往无法完全理解文字内容 。此时如果使用原型图或设计稿进行说明 , 就可以补充文字内容很难描述的信息 , 帮助阅读者快速理解产品功能和内在逻辑 。因此产品经理在撰写产品需求文档时 , 需要配合原型图或设计稿进行说明 。
    一款产品的原型图或设计稿通常会进行反复修改 , 产品需求文档必须同步更新 , 才能让阅读者及时了解到项目的最新动态 。但如果每修改一次原型图或设计稿 , 产品经理都必须手动去替换文档中的配图内容 , 那效率就太低了!其实 , 使用高效的产品需求文档撰写神器即可解决这一难题 。
    产品需求文档撰写神器
    随着产品开发流程的不断发展 , Office等传统办公软件已无法满足产品文档的撰写需求 。今天为大家推荐的 , 是一款专门面向产品经理的文档工具——摹客:网页链接 。除了上述图文同步的难题外 , 摹客还能解决审阅沟通、版本管理等产品需求文档的写作困境 , 让产品经理可以更高效地创建专业的产品文档 。一起来看看~
    1.富文本撰写 , 充分表达产品需求
    摹客全新的富文本在线写作模式 , 符合产品经理日常编辑习惯 , 可以快速完成文档撰写 。撰写内容自动保存 , 可随时查看历史版本 , 方便对比修改 。此外 , 产品经理也可以直接上传本地产品文档 , 会自动解析目录 , 并生成文档树 , 方便查阅 。
    请点击输入图片描述
    2.与原型图、设计稿深度结合 , 相互说明论证
    产品经理在撰写产品需求文档时可插入设计稿 , 当对设计稿进行了更新修改 , 可在文档中设置内容同步 , 无需重复插入 。另外 , 团队成员在设计稿上打点评论时 , 也可以引用文档进行说明 , 让团队成员可以一目了然地查看相关信息 。
    请点击输入图片描述
    3.实时审阅 , 高效沟通
    文档编辑完成后可以通过链接一键分享给团队成员 , 团队成员可选中文字增加评论 , 对文档进行在线审阅 , 清晰表达项目意见 , 实现产品开发团队的高效沟通 。
    请点击输入图片描述
    4.追踪修改记录 , 备份历史版本
    通常 , 产品需求文档的写作不会一步到位 , 往往会根据团队成员的评审意见进行反复修改 , 因此会产生大量的迭代版本 , 对于产品经理来说 , 如何管理产品需求文档的历史版本 , 是一个很大的难题 。在摹客
    撰写产品文档 , 每一次修改都可以自动生成历史版本 , 可以随时跳转查看和恢复 , 管理便捷 。
    请点击输入图片描述
    5.在线预览、分享更便捷
    在摹客中在线撰写或上传的产品需求文档 , 可通过链接快速分享给团队成员 , 团队成员获得链接后可自由查看 , 当产品需求文档有修改时 , 团队成员仍可通过链接查看最新版本 。
    请点击输入图片描述
    使用摹客等高效便捷的产品文档撰写工具 , 可以简化产品文档撰写流程 , 提升产品经理的文档撰写能力 , 让产品经理事半功倍 。
    总结
    产品需求文档作为产品开发团队的重要沟通文档 , 文档的质量好坏会直接影响到各部门是否能够明确产品的功能和逻辑 。一份简洁易懂、逻辑清晰的产品需求文档 , 可以让团队沟通更加高效 , 从而有效提高产品开发团队的工作效率 。

一篇文章让你快速理解PD常用3大文档:BRD、MRD、PRD以下文章是结合网络资料以及自己的实践经验 , 从产品经理的角度出发 , 如何去理解和熟悉使用三大文档:BRD、MRD、PRD , 3大文档的目标群体和核心内容都不尽一样 , 但是相互之间又存在着相辅相成的关系 。如下是正文内容:
一、 BRD商业需求文档Business Requirement Document
BRD是针对谁看的呢?一般都是针对老版或CEO或者项目总负责人 , 那么他们需要了解的是什么呢?
1、要做什么样的产品;
这就包含了项目定义 , 描述项目并且让老版感觉到产品的竞争优势 。
2、需要什么样的资源
要什么资源就必须知道产品的市场位置 , 通过多少人、多长时间、多少Money、多少关系等等能够实现这样的市场位置 , 并且还需要有利且有力的商业说明 , 需要有一定的高度!
3、最终做成什么样;
要怎么做或者说怎么安排 , 老板们很少关心 , 更多的是关心产品的结果展示及盈利 , 这个产品能带来什么样的收入情况 。
最终BRD就浓缩为商业模式、盈利模式、资源投入、市场优势等;还有重要的一点就是“战略壁垒” , 为什么呢?这一点主要是针对产品自身的化以及快速占领市场层面来做 , 这一点或许决定着整个产品的成败 , 但是如果说有些公司有特殊的资源那就另一码事!
二、 MRD市场需求文档Market Requirement Document
MRD是针对谁看的呢?一般都是商务、运营、市场人员 , 那么他们需要了解的是什么呢?整个文档对于他们的重要性?
1、我们要找什么样的客户 , 进行资源合作
一般公司资源合作的都是商务和市场人员 , 或者加上运营人员 , 那么他们是资源拓展者 , 对于产品保驾护航 , 正如船要出海 , 就必须有在海里或者有水的地方 , 海的大小决定了船的大小 , 所以他们就是船的载体 。商务、市场及运营人员在产品需求成型前必须对于产品进行资源拓展 , 且快速评估产品的实现情况 , MRD就是给他们一个清楚的方向 , 我该找什么样的客户 , 在这里或许有的朋友就问题了?n你没有产品这些人员不可能空说吧 , 看到客户该怎们沟通 , 这一块就是项目与运营之间一种Demo沟通了 , 在这里暂时不说了!
2、找到客户后 , 我们该怎么和他们说
上面说了MRD指引着商务、市场和运营往前走 , 那么找到客户该怎么和他们说呢?除了文档描述一个清晰的蓝图 , 或者说从红海中挖出新的路子 , 这里边就是MRD中的业务模式了 , 通过业务模式 , 可以看到清晰的产品 , 且客户可以看到他们在中间的位置 , 甚至说他们怎么赢利;一般给客户看到的都是PPT+Demo的方式 , 这样对于客户更直观更易于理解 , 所以MRD的文档就是给团队和客户一个说明;
3、产品针对什么样的用户群体
商务是资源拓展的关键、市场是产品保障的关键、则运营就是产品的推手 , 那么市场和运营就需要了解产品是针对什么用户群体的 , 毕竟最终的是使用人群是用户 , MRD基本需要明确产品的用户人群 , 这样市场才能更好的进行分析 , 通过分析这个人群 , 给运营提供很好的参考资料 , 这样运营在推广这部分人群的时候也能够制定出很好的方案 , 资源优化及减少资源消耗 , 这就是MRD对于商务、市场、运营的关键作用;
最终MRD就浓缩为产品模式、业务模式、运营模式、市场模式等 , 明确客户及市场方向!
三、 PRD产品需求文档Product Requirement Document
PRD是针对谁看的呢?一般都是项目组、开发组、测试组、策划组、体验组人员;
1、产品具体是什么样的呢?
对于与产品相关的人员 , 就必须有一个清楚的产品概念 , 这个产品到底是干嘛的?插句话说 , 公司对于人员有一个硬管理文化 , 这就是公司的管理制度 , 而产品则是公司的软文化 , 让每一个参与产品的人都有一个“产品梦” , 变成一群有产品信仰的人 , 无形中就会增加团队的战斗力 。但要了解到底是什么产品 , 那就需要详细而简单的进行说明 , 但是这个只能是描述 , 还需要有与策划、开发、测试等另一种沟通语言 , 那就是UI、UE、原型图、流程图等 , 这样方便策划及开发人员的工作进展!
2、我们该怎么实现呢?
该怎么实现 , 那就是规划了 , 包括时间、人力、资源等 , 什么时间完成什么事了!在前进的路上设立一些里程碑!这就对于产品经理来说就是一个挑战 。为什么呢?因为产品经理与商务、市场、运营沟通的方式和开发人员方式不一样 。商务、市场、运营更多的是发散型思维 , 而开发则更多是紧密型思维 。对于开发人员的沟通则不能用“基本”“差不多”“还好”等这样的词来进行沟通 , 否则开发人员会开始发散 , 如果发散的和你一致的话 , 你就烧高香吧 。如果不一致 , 对于程序来说推导再来 , 就不是那么容易的了!甚至出现了大量的BUG , 有时候过多的BUG会让一个产品死掉!
所以就需要有详细的功能说明 , 细化到什么程度了 , 用YN原则来说明 , VISIO是甚好的工具 , 不能出现模凌两可的语句 , 甚至需要通过语句进行if else描述 。还有default , 这个很关键 , 当程序运行正确了那固然好 , 如果程序出现BUG , 则你不能让程序没有出口吧 , 那就是default了 , 给程序的BUG找一个合理的理由!
3、什么样的产品才能投入到市场?
产品开发人员更多的是站在产品角度思考问题 , 以实现产品而完成产品 , 那么产品最终开发完后 , 是不是能够满足运营需求呢?这时候产品经理就需要进行产品验收!怎么验收呢?简单的依据于之前的详细功能说明来进行需求审核 , 但是需求审核只是测试走完了第一步 , 第二步就是黑盒、白盒、甚至灰盒测试 , 走完第二部还有第三步 , 那就是需求优化 , 怎么优化呢 , 依据于市场人员及运营人员提供的用户数据来进行 , 再让产品设计人员进行UI优化 , 立足站在用户的角度;第三步完成了 , 就是最终的步骤了 , 体验师就起了关键性的作用 , AB原则就出来了 , 将产品上线 , 体验师们就开始采集用户信息进行分析了 , 这个阶段对于产品的整个战略规划很关键 , 因为用户对于产品的第一感觉非常重要 , 如果是互联网产品则你可以换个网站 , 反正用户没法删除你的网站 , 但是对于移动互联网的产品APP来说 , 就是一个挑战了 , 看着不顺眼就直接给删除了 , 你说你的产品还有第二次机会进入用户的手机吗?除非你搞特殊!
PRD最终浓缩下就是产品界面、产品流程、功能需求、测试需求、体验需求等 , 保证产品有效率有节奏的进行!关系到整个产品的发展方向!
如何写互联网产品需求文档你好 , 网上有很多产品需求文档的例子 , 你可以参考一下 , 大致有以下这些内容:
首先自己要能理解需求 , 知道具体是要做一个什么样的产品 , 产品的主要用户是谁 , 产品有哪些主要的功能
然后你能把这个需求描述给团队其他成员 , 让他们也能明白这个需求
最后在和团队其他成员沟通的过程中你能解决他们提出的一些问题
产品背景、需求描述、关键词/字、功能结构、功能流程图、页面流转图等
【需求文档怎么写最有效 产品需求文档范例word】关于产品需求文档范例和产品需求文档范例word的内容就分享到这儿!更多实用知识经验 , 尽在 www.hubeilong.com