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

上篇文章介绍了需求文档中的系统/产品的目标和功能模块概要介绍“ 产品经理的需求文档怎么写？应该包括什么内容？（三） ”，接下来看看功能需求详细规格说明。
4.功能需求详细规格说明

看到标题，机智的程序员瞬间就懂得从愉快玩耍的前奏里，停顿几秒后直入主题。然后开始了一场痛并快乐着的旅程。阅读、思考、玩耍、编码、加班、熬夜、纠结，继续玩耍和编码，周而复始。那这一章节到底要写点神马，才能让程序员读的开心、想的明白，熬夜的甘心、纠结的痛快，从而实现持久的玩耍和编码呢？这一章节是核心，我需要花更多的时间去梳理和胡说额。好吧，赶紧切入主题。

4.1.描述系统产品的容颜

按照User访问系统功能模块的界面的依次顺序，从上而下，界定和描述页面上的全部元素（Text Field、Droplist、Button、Box、可视化图表等等）及元素的属性。

如下拉单包含那些枚举值，填写框输入的数据类型、哪些元素需要弱化，哪些元素需要突出，有/无数据时怎么样。

描述过系统的容颜之后，需要明确界定，功能模块中全部页面的输入和输出项。比如一个可视化的报表页面，输入：需要选择的组合查询条件，输出：要呈现的数据可视化图表。

4.2.USER在界面的交互

通常，User对系统的体验都是老司机，你只要告诉这个系统会提供什么功能、能给他带来什么，即刻他便明白他将在系统里能怎么操作，能得到什么。因为User永远会在最大程度地想让自己在使用某个系统或者某款产品的时候得到最大的灵活和便捷，以及满足感。所以，功能和用户体验才会成为所有系统和产品研发的最根本的出发点和立足点。

USER在这个界面是单纯的浏览，还是编辑，是操作的主流程，还是分支流程都需要有清晰的定义和描述。例如，一个互动功能，不论是点赞、关注还是评论，我们要从用户体验的角度和先后次序去阐述它：鼠标/手指触控/点击后控件的样式变化， 取消的时候又是什么变化等等。

很多时候，User是不愿意告诉PM实际的目的和想法，只是纯粹在争取他们想要什么，强调一个系统/一款产品必须要能够解决掉User在业务流程里的难点和痛点。这没有错，但PM需要能够站在User的立场上，去思考对方的真实想法，需要去分辨那些才是真正实际的、有利于业务发展的需求，然后前瞻性地考虑功能页面的交互。在这过程中，需要不停地将很多需求点，进行转换和变通。把需求的理解，从User的角度、演化为系统/产品的理解：交互和功能层面。而后，抛开体验层面，回归到需求层面，不断地验证和完善系统/产品设计背后的逻辑。

所以，你看到了吗，PM的地位在User面前就像低到了尘埃里，并且还开不出花来。

下篇文章继续给大家说说系统产品业务逻辑和规则以及非功能性需求，感兴趣的话可以去看看。

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