一份优秀的文档可以很好地实现与开发人员的沟通。我认为，一份可读性强，流程明了，工程阐述清晰的全面性文档都是要经过几次的梳理才可以成型的。具体需要更新几次取决于更新人员的业务能力和理解能力。但是无论你更改多少次，目的都是为了让程序员读到它时能够清晰的获得他想要的东西。
基本内容
时间、版本、修订人员、编写目的等内容就不多说了，这并不是说这些东西不重要，而是对于产品功能的阐述上并不相关，但是这些细节也时刻体现着你的专业性。
用户及应用场景
层次角色不同，诉求和应用场景也不同。明确用户群体，角色，权限等，根据业务场景，梳理构建用户场景有助于让需求分析更加准确。再者，不同层级的用户关心的功能，数据都不相同，这就意味着需要站在用户立场上去规划场景。当每一个设计的场景符合用户需求的时候，就解决了痛点问题。用户的群组、角色的权限都需要反复的check，在这个过程中与用户保证紧密的联系和沟通是非常必要的， 这也是产品设计的关键，让用户从一开始参与进来，最后做出来的东西才不会与需求相差太远。
系统/产品目标
需求什么东西，可以带来的价值有哪些。这一部分就是要明确满足客户需求的产品，它决定了设计的产品到底是什么样子，以绩效考核系统举例，就是必须实现企业内不同部门，不同层级，角色绩效指标的计算和汇总。
功能模块介绍
这个部分是概要介绍，你设计的产品需要哪些功能、模块等等。对于模块的定位，模块间的划分和联系都需要有最基本的介绍。首先是为了方便实现产品功能，因为这些琐碎的事情必须在具体的描述过程中它的问题才会暴露出来。再者主要是为了程序员来服务，很少有程序员参与前期的规划设计的，所以为了产品开发的方便，模块的叙述尽量简练明了。
功能需求详细说明
产品的具体样子
界定和描述页面上的元素和功能。比如菜单里包含哪些东西，哪些元素需要突出，哪些又需要弱化。将“容颜”描述清楚后，再明确界定，功能模块中页面的输入输出项等。
界面交互
这个部分主要针对用户，现在用户经验都很老道，你只要告诉他功能，他就可以知道他能得到什么。用户在这个页面的操作流程都要写清楚，无论是主流程还是分流程。
系统产品业务逻辑及规则
这一部分是呈现在系统里的合理的架构业务框架，并不是一个具体的交互。深入了解业务规则和逻辑，明白业务流程等。
非功能性需求
非功能性需求，本身和用户无关。比如用户体验这一方面，不用说，PM都要自己来考虑，点击使用要响应很久才能实现，那么基本这个系统已经处于失败的边缘了。至于其他安全方面等等隐性需求我就不多说了。
