一份良好的需求文档-应该包含哪些部分

1、一份良好的需求文档，应该包含哪些部分份良好的需求文档，可以很好地传递产品经理的思路，更好地实现与开发的沟通。一份可读性强、文脉和思路清晰、流程和功能阐述明白、页面元素、输入和输出都定义明确的需求规格说明书、通常都是需要经过几次持续的迭代和梳理，才能逐渐完善起来。到底需要迭代几次，就取决于你对业务的理解能力和需求分析能力了。然而不论你迭代多少次、最终也是为了让程序员读到它的时候，能够心领神会，不用BA和PM解释过多。愉快地实现玩耍和编码，最终实现系统/产品（后统称产品）的功能。所以需求规格说明书的目的，不是为了给领导和User看（领导和User并不关心这个，领导和User在乎的是这个产品啥时候能

2、用，能为他们带来什么样的价值！）。工作留档？也完全没有必要，除非你今天做了一半要辞职回家去种田，需要工作交接。因为交付一个良好的产品比这个都重要100倍。如果为了纪念，你曾把大把的时间和精力投入到这个产品的规划、设计、功能交互、后台逻辑梳理等等上面。你倒是很要必要给自己留个档案。多年后，无意中再打开，你会看到自己成长的轨迹和脉络。基本内容时间、版本、修订者、 编写目的、编写背景诸如此类的内容，就不必再多说了。我不是说这些不重要，而是这些与要实现的产品具体的需求功能均无关系。不要在这些点上浪费时间，但这些小细节会体现出你做需求的规范、流程及专业性。1.用户及应用场景不同层次、不同角色的User有

3、不同的诉求和应用场景。对于BI类的产品不同类型的User使用数据的场景均不一样，明确用户群体、用户角色、用户权限等，根据业务场景，梳理、构建并完善用户应用场景有助于让需求分析更准确，让产品功能更全面，更贴近用户需求。比如一个数据分析系统，针对不同的User，对需要做业务的一线业务人员，在设计的时候，基本上就是要通过界面展现关键指标，不涉及详细分析功能。并且在某些指标异动时能及时通过手机通知。而运营分析的数据分析师，则必须提供多维度分析、灵活分析、对比分析、趋势预测分析、假设分析等功能。另一方面，不同层级User关心的功能、数据粒度都不一样。需要站在User的立场上去规划和引导应用场景。而每一个

4、应用场景的设计是否刚好符合用户的需求，又解决了User的痛点问题。这是一个大的前提和关键。因为只有在实现基础功能之上再考虑用户粘度和用户体验度才是有意义的，否则锦上添花的东西有时候会变的华而不实。用户群组、角色权限、应用场景等内容需要反复Check和逐一假定演绎系统的应用场景，而在这样的过程中，很有必要和User保证紧密的联系和沟通。这也是产品规划和设计的关键，只有在一开始，就尽最大程度的努力让User参与进来，关注产品的功能、应用场景和体验，你的设计才不会距离User太远。2.系统/产品的目标通俗一点讲，就是要解决什么问题、带来什么价值。这本质上是要明确产品需要满足用户的什么需求。但凡需求，

5、均有价值和优先级。判断需求的价值，可用 PST方法分析，但通常这个理论都比较繁琐。其实优先级很容易得出，通常User急切想要的东西，或者急切想要借助一个系统或一款产品来帮助他解决业务当中棘手的问题时，这些都是优先级比较高的需求。这一章节的内容，它决定了，我们要设计什么样的产品，用这个产品能够用来做些什么。比如一个绩效系统，主要就是要实现企业不同部门，不同层级、角色的绩效指标的自动化计算、汇总、可视化呈现。做的好一点，时间维度、能够自由而灵活界定， 准确而便捷地评鉴个体的绩效趋势和走向方便绩效的精细化管理和追踪。另一方面能够从全面的职责维度出发，对比和观测不同职责的绩效表现与趋势。能够更加容易、

6、全面、公正地绩效考评并有效联动奖金激励机制。3.功能模块概要介绍这一章节是概要地介绍，你要设计和规划的产品都需要具备哪些功能模块、功能点、大致会有哪些主要的功能页面来支撑这个功能模块。模块的定位、模块间的划分与交互都需要有基本的介绍。目的主要有2个：一方面，是为了方便PM清晰地将产品规划的功能落地下来，因为这些琐碎的创意和设计，只有在你具体去描述它的时候、并画出它的Mockup的时候，它的局限性、用户交互、用户体验等种种缺陷才会展现出来，你才能进行持续的思考和摒弃。通过这样的过程，PM把这些星星点点的创意和设计，经过一个产品化（系统化）的体系思考、演绎之后变得生动和流畅起来。另一方面，功能概述

7、的意义旨在为程序员服务，程序员前期不参与需求、系统规划和设计，拿到需求规格说明书后，如果立马进入到具体某个页面、功能点的详尽规格描述里，通常都会一脸懵逼，然后开骂和抱怨。所以功能模块概要需要用尽量简练的语言将各个功能模块里的主要功能点提炼概述而过，不拖泥带水、不瞻前顾后。最好图文并茂地将功能模块的profile像一张蓝图呈现在程序员面前。这是他们读需求规格说明书的一个前奏，要不然都不能愉快地编码和玩耍。而所有有才的程序员，大多数都是机智过人的汉子，你若遇见冰雪聪明的妹子，可以一块共事，那该是多么大的小确幸，且行且珍惜。有点才华的PM遍地都是，但才华横溢的程序员真的是千里难寻。因为在编码和玩耍的

8、世界里，不存在“三个臭皮匠顶一个诸葛亮”程式，一个有才而好学的程序员远远胜过10个平庸的呆笨男。4.功能需求详细规格说明看到标题，机智的程序员瞬间就懂得从愉快玩耍的前奏里，停顿几秒后直入主题。然后开始了一场痛并快乐着的旅程。阅读、思考、玩耍、编码、加班、熬夜、纠结，继续玩耍和编码，周而复始。那这一章节到底要写点神马，才能让程序员读的开心、想的明白，熬夜的甘心、纠结的痛快，从而实现持久的玩耍和编码呢？这一章节是核心，我需要花更多的时间去梳理和胡说额。好吧，赶紧切入主题。4.1.描述系统产品的容颜按照User访问系统功能模块的界面的依次顺序，从上而下，界定和描述页面上的全部元素（Text Fiel

9、d、Droplist、Button、Box、可视化图表等等）及元素的属性。如下拉单包含那些枚举值，填写框输入的数据类型、哪些元素需要弱化，哪些元素需要突出，有/无数据时怎么样。描述过系统的容颜之后，需要明确界定，功能模块中全部页面的输入和输出项。比如一个可视化的报表页面，输入：需要选择的组合查询条件，输出：要呈现的数据可视化图表。4.2.USER在界面的交互通常，User对系统的体验都是老司机，你只要告诉这个系统会提供什么功能、能给他带来什么，即刻他便明白他将在系统里能怎么操作，能得到什么。因为User永远会在最大程度地想让自己在使用某个系统或者某款产品的时候得到最大的灵活和便捷，以及满足感。

10、所以，功能和用户体验才会成为所有系统和产品研发的最根本的出发点和立足点。USER在这个界面是单纯的浏览，还是编辑，是操作的主流程，还是分支流程都需要有清晰的定义和描述。例如，一个互动功能，不论是点赞、关注还是评论，我们要从用户体验的角度和先后次序去阐述它：鼠标/手指触控/点击后控件的样式变化， 取消的时候又是什么变化等等。很多时候，User是不愿意告诉PM实际的目的和想法，只是纯粹在争取他们想要什么，强调一个系统/一款产品必须要能够解决掉User在业务流程里的难点和痛点。这没有错，但PM需要能够站在User的立场上，去思考对方的真实想法，需要去分辨那些才是真正实际的、有利于业务发展的需求，然后

11、前瞻性地考虑功能页面的交互。在这过程中，需要不停地将很多需求点，进行转换和变通。把需求的理解，从User的角度、演化为系统/产品的理解：交互和功能层面。而后，抛开体验层面，回归到需求层面，不断地验证和完善系统/产品设计背后的逻辑。所以，你看到了吗，PM的地位在User面前就像低到了尘埃里，并且还开不出花来。4.3.系统产品业务逻辑和规则基本上有80%的PM都停留在这一阶段，认为自己完成了基本功就是长久之能，懂得画图懂得做原型懂得项目跟进，就是懂做产品了。我也是一样的，目前在一家新公司。也是处在这样的一个边思考边行走的阶段。但我明白，对业务的理解非常重要，只有你对业务逻辑相当熟悉了、明白和领悟了

12、基于这一系列业务逻辑之上的各种业务规则，你才有可能把产品做好，不然你沦为的只是老板或领导的画图工具，这个时候你规划设计的产品的价值是很难体现出来的。业务逻辑，呈现在系统里就是一个合理的架构业务的框架，并不是具体的一个交互。深入的了解业务逻辑和规则，以及对他们的思考，明白业务为何是这样的逻辑流程、为何这些业务流程逻辑上要设定这么多的规则？你不要试图去改善业务流程和逻辑，因为大公司很多时候轮不到你思考业务或者提出更好的业务。而且业务框架也定了，但你可以把业务梳理好，可以把需求方服务好，要一起前进。这也是提升的地方。明白了业务流程逻辑是什么样子，这些流程规则上为何设定这么多的业务规则。就已经成功一半。把这些内容分主题、分类别、梳理出来，归属到规划好的功能模块当中，当然还是从User的角度、习惯、意愿去梳