产品经理的需求文档怎么写？应该包括什么内容？（三）

上篇文章给大家介绍了用户及应用场景“ 产品经理的需求文档怎么写？应该包括什么内容？（二） ”，下面看看接下来的内容。
2.系统/产品的目标

通俗一点讲，就是要解决什么问题、带来什么价值。这本质上是要明确产品需要满足用户的什么需求。但凡需求，均有价值和优先级。判断需求的价值，可用 PST方法分析，但通常这个理论都比较繁琐。其实优先级很容易得出，通常User急切想要的东西，或者急切想要借助一个系统或一款产品来帮助他解决业务当中棘手的问题时，这些都是优先级比较高的需求。

这一章节的内容，它决定了，我们要设计什么样的产品，用这个产品能够用来做些什么。比如一个绩效系统，主要就是要实现企业不同部门，不同层级、角色的绩效指标的自动化计算、汇总、可视化呈现。做的好一点，时间维度、能够自由而灵活界定， 准确而便捷地评鉴个体的绩效趋势和走向方便绩效的精细化管理和追踪。另一方面能够从全面的职责维度出发，对比和观测不同职责的绩效表现与趋势。能够更加容易、全面、公正地绩效考评并有效联动奖金激励机制。

3.功能模块概要介绍

这一章节是概要地介绍，你要设计和规划的产品都需要具备哪些功能模块、功能点、大致会有哪些主要的功能页面来支撑这个功能模块。

模块的定位、模块间的划分与交互都需要有基本的介绍。目的主要有2个：

一方面，是为了方便PM清晰地将产品规划的功能落地下来，因为这些琐碎的创意和设计，只有在你具体去描述它的时候、并画出它的Mockup的时候，它的局限性、用户交互、用户体验等种种缺陷才会展现出来，你才能进行持续的思考和摒弃。通过这样的过程，PM把这些星星点点的创意和设计，经过一个产品化（系统化）的体系思考、演绎之后变得生动和流畅起来。

另一方面，功能概述的意义旨在为程序员服务，程序员前期不参与需求、系统规划和设计，拿到需求规格说明书后，如果立马进入到具体某个页面、功能点的详尽规格描述里，通常都会一脸懵逼，然后开骂和抱怨。

所以功能模块概要需要用尽量简练的语言将各个功能模块里的主要功能点提炼概述而过，不拖泥带水、不瞻前顾后。最好图文并茂地将功能模块的profile像一张蓝图呈现在程序员面前。这是他们读需求规格说明书的一个前奏，要不然都不能愉快地编码和玩耍。

而所有有才的程序员，大多数都是机智过人的汉子，你若遇见冰雪聪明的妹子，可以一块共事，那该是多么大的小确幸，且行且珍惜。

有点才华的PM遍地都是，但才华横溢的程序员真的是千里难寻。因为在编码和玩耍的世界里，不存在“三个臭皮匠顶一个诸葛亮”程式，一个有才而好学的程序员远远胜过10个平庸的呆笨男。

接下来就是功能需求详细规格说明，下篇文章继续给大家分享，赶紧去看看吧！

以上就是“产品经理的需求文档怎么写？应该包括什么内容？（三）”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站。