需求说明书一般都包含什么内容？

客户关系管理需求说明书1 引言

1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。

1.2 项目背景：应包括

● 项目的委托单位、开心单位和主管部门；

● 该软件系统与其他系统的关系。

1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。

1.4 参考资料：可包括

● 项目经核准的计划任务书、合同或上级机关的批文

● 文档所引用的资料、规范等

1.5其他说明：

前期开发为客户关系管理中的客户管理和市场管理、决策支持中的客户信息部分

2 任务概述

2.1 目标

2.2 运行环境

2.3 条件与限制

3 数据描述

3.1 表态数据

3.2 动态数据：包括输入数据和输出数据。

3.3 数据库描述：给出使用数据库的名称和类型。

3.4 数据词典

3.5 数据采集

4 功能需求

4.1功能划分

如何撰写四大核心产品文档？

在产品未进入生产性开发之前，所做的所有工作成果都是以文档的形式进行体现的，是新产品开发最重要，也是价值最大的工作内容，包括商业文档、市场文档、设计文档及功能详述，如图5-11所示。从广义上来讲，产品文档内容包含有产品的战略和战术，战略是指：目标市场、客群定位、竞争对手、产品概念、价值主张、产品定位、商业模式等；战术是指竞争策略、产品创意、创新设计、产品结构、核心业务流程、具体用例描述、功能及内容描述等。

图5-11 产品设计相关四大文档

1. 商业文档

BRD商业需求文档是指基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。作为报告的撰写者，你必须让高层明白，你的报告中将展现出怎样的商业价值，如何用有力的论据来说服企业对你这个项目的认可，并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏，直接决定了项目的质量水平，那么BRD的作用，就是决定了你的项目的商业价值。优秀的BRD文档，可以让决策层充分被你的报告观点所吸引，或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动；或许技术主管会因为项目的牵涉面广泛而头疼不已；又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景……

BRD需要产品经理（产品设计师）像对待PRD一样，充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告, 内容和格式要求够直观、精炼，要点突出,一般比较短小精炼，没有产品细节。产品经理通常需要向上汇报商业文档，供决策层们讨论，汇报会议主要内容如下。

会议开始，产品经理首先要给与会的领导介绍一下产品要做什么吧？（解决什么问题或满足什么用户需要）

为什么要做？谈谈背后的原因（背景、市场空间、竞争对手、环境）

打算怎么做？（产品规划、模块规划、研发计划、运营计划）

需要多少资源？（人力成本、软硬件成本、运营成本）

最终能获得什么收益？（带来收入、带来用户、扩大市场、占有市场先机、满足未来三年战略规划等）

做这个有没有风险？（开发失败？失去市场机会？失去先机？竞争不过对手？没有带来收入？没有带来用户？与公司战略背道而驰？）

2. 市场文档

MRD市场需求文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对某个产品进行市场层面的说明”。该文档中，侧重的是对产品所在市场、客户、购买者、用户以及市场需求进行定义，并通过原型的形式加以形象化。这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。文档包含主要内容如下。

l市场说明：目标市场、市场规模、市场特征、未来3~5年的发展趋势，现在市场存在的问题和机会。一般来说，这里会得到一个比较有市场商业价值的结论。

l用户说明：目标客群的共性分析，常用用户特征（要求准确：年龄段、收入、地区、学历），通过用户画像建立虚拟用户角色：形象化，用户名称，用户技能、与产品相关的用户特征，演示性的场景，用户在时间、地点，完成的某个事的故事。从技术层面剖析市场，洞察用户心理案例分析[张乐飞1] （动机和目标是不一致的）影响用户使用的主要因素。

l产品定位：我们用什么样的产品满足用户或用户市场；针对什么用户，做什么事。

l产品价值：解决目标市场、用户的核心需求（核心价值优先级最高）。

l产品架构：整体结构，不是功能结构。是产品的核心目标，市场定位，产品定位的直接体现。

l产品路线图：以时间为节点，任务为导向。

l产品功能性需求：用户注册、留言等等。

l非功能性需求：有效性、性能、扩展性、安全性、健壮性、兼容性、可用性、用户体验等。

3. 设计文档

PRD产品设计文档是把我们想做的东西变成一张清晰明了的“图纸”，让研发人员看到这张“图纸”就知道我们要做啥，需要做到什么程度，大概需要什么技术，并能对成本进行一个预估。不同平台和不同行业的产品的设计文档有所区别，但思想都差不多。这里以网站为例，设计文档一般包括网站结构图，线框图和网页描述表。产品设计文档伴随着产品整个生命周期，帮助产品团队与研发团队和高层领导达成共识，进而明确研发计划和指导研发过程。不同的公司、不同的产品会有自己不同的要求和模板，但在这里我想提醒一些大家需要注意的地方。

l保持简短：对于产品设计文档，保持简短很重要，因为越是简短，包含的错误越少，同时更容易阅读，同时也越可能带来简洁的设计。但是一定要在穷尽的基础上简短，不要为了最求简短而忽略一些细节，在产品设计中，每一个小细节对产品的质量来说都很重要。所以一定要仔细思考，认真推敲。

l消灭错误：错误的文档会花费研发团队大量的时间，甚至会导致大规模的改动，这时对研发来说没有谁会很爽，一个个都恨不得把你给撕了。有点夸张了。但心里面绝对是一万个“操尼玛”！同时也会让产品团队在研发团队面前抬不起头。当然，也不用太想不开，毕竟没有错误的文档和没有错误的代码一样，都是不存在的，我们需要做的是尽可能的消灭错误，让错误能在可承受范围内。错误有很多种，有产品逻辑错误（最致命的），有多个需求相互矛盾的错误，还有错别字等层面的低级错误。在撰写产品设计文档的时候，产品团队因对应产品逻辑进行充分的讨论和测试，最终要组织评审会议，采用审核通过的方式把关。

l别对他人（主要是研发人员）的工作指手画脚：也就是说在设计文档中不要提一些技术性的东西。比如：将其存入数据库的一个新表中，连续存放，以优化查询效率。别提之类的需求，你很可能犯一些细节上的错误。己所不欲，勿施于人，别人在你的领域内指手画脚你也会感到很烦。如果你是个技术专家，可以私下沟通，别把应该写在技术文档中的内容写在设计文档里。

l用适当的方式表述需求：选取适当的方式展现特定的信息，是产品经理的一项重要技能，面对研发团队的时候要用到，面对最终用户的时候也会用到，怎样去表现我们的需求让研发或客户能快速有效的理解是相当重要的，不仅可以提高工作效率，还可以避免很多因理解不当造成的错误。因理解不一致这种错误是很常见的，和不同领域类的人提需求理解不当更是家常便饭了，选用适当的表述方式是相当重要的。比如，用叙述性文字说不清楚我们就用表格或其他的，有时候还需要选择一些图形工具。

l使用肯定的语言：在产品设计文档中，使用肯定的、确切的语言，切勿出现“也许，可能”这类词语。我们最终提交的文档内容都是确切的，可被执行的，含糊不清的东西一定要全部消灭掉。如果有吃不准的东西，就放在内部充分讨论后在做决定。

l切勿忽视沟通：很多产品新人在写产品设计文档的时候，独自埋着头写，写好了之后再出去沟通，这样文档有99%的概率会被大幅度修改，这等于是在做无用功，所以在写设计文档的时候千万不要忽略和团队沟通。

4. 功能详述

FSD功能详细说明定义产品功能需求的全部细节，这是一份可以直接让工程师创建产品的文档。FSD建立在BRD、MRD和PRD的基础上，从这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。功能需求是所有的产品功能的描述和规划，以互联网产品为例包括以下内容。

l简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。

l场景描述：产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。

l业务规则：每个[张乐飞2] 产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。

l界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。

l使用者说明：对产品使用者做出说明，可融入简要说明中。

l前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像的文件。

l后置条件：操作后引发的后续处理。

l主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。

看过很多的PRD（包含FSD），文档中对既没有前提条件，也没有后置条件，只对主流程做了说明，但是在描述主流程时却没有描写主流程中每个功能流程的各种走向，只有一个主走向，让人感觉PRD成了操作手册。事实上，对分支的介绍是非常重要的，开发和测试中提出的各类问题均与对分支的定义不明有关。一个合格的PRD不仅要描述主流程，同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。PRD的特征一定是明确的、全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案（虽然PRD不可能百分之百地覆盖所有的可能，但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则）。另外，在描写功能需求时给出的办法中不能出现“可能”、“或者”等词，一定是明确的，准确的描述。如果有别的方案，建议写入“可选方案”，在产品构建的早期可选方案可以为功能实现提供更多的选择，当方案确定后可在文档中注明本次使用了哪种方案。

如何写一份易用的产品需求文档？

在我看来产品经理产出一份需求文档，首先是要过需求审核的。而PM在审核之前的工作应该是，拿出你的数据和你思考的结论。

1、我们前一个版本的数据表现如何（一份数据表格），这是对前一段各位工作的反馈，也是树立新的工作目标。

1+、在数据的基础之上，我们哪些数据的表现不尽如人意，我们要做什么样的功能才能改善现状？

2、你为什么认为用户有这个需求（用户访谈文稿/用户反馈摘抄，竞品分析，市场调研、BOSS拍脑袋等），说服项目组成员，认为这个功能是解决用户需求的最佳方案。

3、详细解释功能实现的逻辑：包括使用流程（流程图），数据流通（脑图），需要配合的部门，可以调用到的资源等。

4、基本的场景假设，包括正常使用场景，异常使用以及无法使用等。

当以上四点都敲定以后（无论PM一人兼职UX/UE还是分值），再由具体人员，一起讨论实现细节问题，并给出时间排期。在此之后，才有高保真原型图，虽然程序研发的时候可能会按照高保真原型图进行，但是这个前提是程序的脑袋里面已经被你输出的价值观占据了，而PM价值产出应该是在需求评审时候的逻辑输出。

在软件开发中,需求分析阶段产生的主要文档是

在软件开发中,需求分析阶段产生的主要文档是PRD，产品需求文档（即PRD）是为了开发一款产品或一个产品版本的而写的说明文档。一般由产品经理（PM）撰写提供给设计师（UI）、开发（RD/FE）和测试（QA）人员使用的，内容主要包括需求背景、目标、功能规则和数据统计等方面。

PRD的查看对象：一般来说，PRD是写给以下几种人看的：1.产品同事2.运营3.设计师4.开发工程师5.其他需求方（相关业务部门等）

一份PRD至少就应该包含以下内容：功能结构图、业务流程图、功能细节描述、界面原型等。

产品设计文档需要包含这些.......

作为产品经理，日常接触最多的工作之一就是设计文档了。每个产品经理有自己的设计文档的写法，各个公司也有各自的设计文档的要求，所以大家平时看到的设计文档几乎没有一模一样的。

一份设计文档的结构大概包括一下几部分的内容：项目背景、项目排期、版本历史、信息架构分析（包括站点地图、体验地图、流程图等）、产品框架设计、线框图和视觉稿等。

具体在设计文档中要展示哪些内容，取决于实际项目的情况，公司的具体规定、产品经理的个人工作习惯等，可能删减一些内容，也可能增加一些内容。

每个部分拆分开来，我们一起来看看具体是如何的。

》》

这一部分的内容在充分沟通需求之后完成。产品经理充分了解要设计的产品是什么，是什么平台上发布的，产品的用户群体是哪些类型，使用场景有什么，他们想通过这个产品解决什么问题，业务/产品现状，关键痛点是什么。把需要和需求方了解清楚之后，能够明确产品设计目标，要解决的需求是什么，根据这些需求，需要设计什么样的功能或者如何优化现有的功能，最终达到怎样的业务目标。

》》

和需求方确认各阶段交付物的时间节点，知道什么阶段要完成什么工作，达成什么目标。根据时间节点制定完成设计的具体计划，根据这个计划有节奏、有方向地展开工作，以较高的质量按时交付。

》》

每发生一次比较大的迭代更新，都要记录在版本历史记录里。这样做的好处是，可以清晰地展现设计稿的迭代历程，做了哪些需求的改动，设计思路发生什么样的变化，哪个部分是什么时候什么人负责的。对于产品设计的回溯，提供了极大的便利。相比一个个去翻以前的设计稿，查看版本历史记录更清晰，项目结束后浏览这一部分，也可以看到自己的设计在哪些方面哪个阶段存在不足，是如何被发现、改进和提升的，下一次设计的时候是否可以更早地思考到和回避掉。

》》

根据具体项目性质的不同，这一块的分析工具也有较大的差异，具体的选择和使用要按照实际场景来，而非机械进行套用。

如果是设计一整套网站系统，站点地图必不可少。站点地图可以对整个网站的架构可以构建起一个初步的印象，像架构层级过深、页面内容重复等问题都可以通过站点地图发现，以全局的角度去观察整个产品，而不是单一的某个功能、某个页面。

体验地图可以把产品在不同使用场景、流程下的体验问题直观地呈现出来，我们通过调研，会得到一些用户的体验反馈，但是通常比较杂乱、没有逻辑性。通过体验地图可以整理出用户使用产品大概有哪些场景和环节，各场景和环节下都遇到过什么样的问题，哪些问题出现的频率较高等，让产品经理能够更贴近用户，沉浸到使用产品的实际体验过程中去，进而思考各场景、环节下都可以进行怎样的设计目标拆解与设计优化、最终帮助完成产品的整体目标。

流程图也是一个常用工具，明确展示出用户使用产品的流程和步骤是怎样的。通过它可以查找步骤是否可以合并优化，能否抽象出通用的流程来构建框架设计等。

》》

产品框架设计构建起产品的轮廓，抽象出通用的布局原则，页面上大概有哪些模块，这些模块之间的主次、优先级关系是怎样的。整体规划把握界面的结构、模块之间的关系呈现等，而不是纠结于一些细枝末节和不重要的内容上。

》》

线框图在产品框架设计的基础上具化出了产品的完整骨架。在绘制线框图的时候需要仔细考虑到每一个可能的使用场景，包括负面、误用等特殊情况都要包括在内。

Axure是绘制产品经理绘制线框图的常用的工具。在Axure中，通过命名页面和调整层级关系，建立站点地图。在每个页面中根据场景画出线框图，包括具体的功能及场景，可以加以文字说明，辅助以用例交互。

线框图不是视觉设计稿，但在视觉效果呈现上却马虎不得。如果在绘制线框图的时候不考虑如产品尺寸、页面规范等，最终完成得会比较粗糙，也容易对内容的编排产生影响，导致整个页面结构都要被迫调整之类的情况，只能增加产品设计成本，而在最开始就注意这方面的问题，就可以尽可能地避免类似的情况发生。

》》

视觉稿作为产品设计的最终产出，在线框图的基础上完成配色、图标绘制等视觉细节，为产品“涂脂抹粉”。视觉稿选择关键场景的界面进行绘制表现，注意一些Hover/Active之类的状态表现，然后就可以标注交付前端了。

这是产品设计文档中比较常见也比较重要的的几部分内容，根据你自己的需要和公司的规定、项目的具体情况，选择需要重点体现的内容，也可以有所增删，并不是一成不变的。

产品经理需要的文档

1、BRD:Business Requirements Document,商业需求文档。这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、赢利预测等，通常是给老板们演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要是获得认可，争取资源。

2、MRD:Market Requirements Document,市场需求文档。获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分那几块，功能的优先级等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。

3、PRD：Product Requirements Document,产品需求文档。PRD是对产品功能的进一步细化，是PD新人写的最多的文档，也就是“需求开发”的过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述。

4、FSD：Functional Specifications Document,功能详细说明。比较像常写的用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左右中对齐？保留几位小数等，有点像“概要设计”。

产品需求文档，PRD

1、总体说明

1.1修订历史1.2项目概述1.3功能范围1.4用户范围1.5词汇表1.6非功能需求1.7其他说明

2、UC部分

2.1整体说明2.2UC正文