一份良好的需求文档，可以很好地传递产品经理的思路，更好地实现与开发的沟通。
一份可读性强、文脉和思路清晰、流程和功能阐述明白、页面元素、输入和输出都定义明确的需求规格说明书、通常都是需要经过几次持续的迭代和梳理，才能逐渐完善起来。
到底需要迭代几次，就取决于你对业务的理解能力和需求分析能力了。然而不论你迭代多少次、最终也是为了让程序员读到它的时候，能够心领神会，不用BA和PM解释过多。愉快地实现玩耍和编码，最终实现系统/产品（后统称产品）的功能。
所以需求规格说明书的目的，不是为了给领导和User看（领导和User并不关心这个，领导和User在乎的是这个产品啥时候能用，能为他们带来什么样的价值！！！）。工作留档？也完全没有必要，除非你今天做了一半要辞职回家去种田，需要工作交接。因为交付一个良好的产品比这个都重要100倍。如果为了纪念，你曾把大把的时间和精力投入到这个产品的规划、设计、功能交互、后台逻辑梳理等等上面。你倒是很要必要给自己留个档案。多年后，无意中再打开，你会看到自己成长的轨迹和脉络。
基本内容时间、版本、修订者、 编写目的、编写背景诸如此类的内容，就不必再多说了。我不是说这些不重要，而是这些与要实现的产品具体的需求功能均无关系。不要在这些点上浪费时间，但这些小细节会体现出你做需求的规范、流程及专业性。
1.用户及应用场景不同层次、不同角色的User有不同的诉求和应用场景。对于BI类的产品不同类型的User使用数据的场景均不一样，明确用户群体、用户角色、用户权限等，根据业务场景，梳理、构建并完善用户应用场景有助于让需求分析更准确，让产品功能更全面，更贴近用户需求。
比如一个数据分析系统，针对不同的User，对需要做业务的一线业务人员，在设计的时候，基本上就是要通过界面展现关键指标，不涉及详细分析功能。并且在某些指标异动时能及时通过手机通知。而运营分析的数据分析师，则必须提供多维度分析、灵活分析、对比分析、趋势预测分析、假设分析等功能。
另一方面，不同层级User关心的功能、数据粒度都不一样。需要站在User的立场上去规划和引导应用场景。而每一个应用场景的设计是否刚好符合用户的需求，又解决了User的痛点问题。这是一个大的前提和关键。因为只有在实现基础功能之上再考虑用户粘度和用户体验度才是有意义的，否则锦上添花的东西有时候会变的华而不实。
用户群组、角色权限、应用场景等内容需要反复Check和逐一假定演绎系统的应用场景，而在这样的过程中，很有必要和User保证紧密的联系和沟通。这也是产品规划和设计的关键，只有在一开始，就尽最大程度的努力让User参与进来，关注产品的功能、应用场景和体验，你的设计才不会距离User太远。
2.系统/产品的目标通俗一点讲，就是要解决什么问题、带来什么价值。这本质上是要明确产品需要满足用户的什么需求。但凡需求，均有价值和优先级。判断需求的价值，可用 PST方法分析，但通常这个理论都比较繁琐。其实优先级很容易得出，通常User急切想要的东西，或者急切想要借助一个系统或一款产品来帮助他解决业务当中棘手的问题时，这些都是优先级比较高的需求。
这一章节的内容，它决定了，我们要设计什么样的产品，用这个产品能够用来做些什么。比如一个绩效系统，主要就是要实现企业不同部门，不同层级、角色的绩效指标的自动化计算、汇总、可视化呈现。做的好一点，时间维度、能够自由而灵活界定， 准确而便捷地评鉴个体的绩效趋势和走向方便绩效的精细化管理和追踪。另一方面能够从全面的职责维度出发，对比和观测不同职责的绩效表现与趋势。能够更加容易、全面、公正地绩效考评并有效联动奖金激励机制。
3.功能模块概要介绍这一章节是概要地介绍，你要设计和规划的产品都需要具备哪些功能模块、功能点、大致会有哪些主要的功能页面来支撑这个功能模块。
模块的定位、模块间的划分与交互都需要有基本的介绍。目的主要有2个：
一方面，是为了方便PM清晰地将产品规划的功能落地下来，因为这些琐碎的创意和设计，只有在你具体去描述它的时候、并画出它的Mockup的时候，它的局限性、用户交互、用户体验等种种缺陷才会展现出来，你才能进行持续的思考和摒弃。通过这样的过程，PM把这些星星点点的创意和设计，经过一个产品化（系统化）的体系思考、演绎之后变得生动和流畅起来。
另一方面，功能概述的意义旨在为程序员服务，程序员前期不参与需求、系统规划和设计，拿到需求规格说明书后，如果立马进入到具体某个页面、功能点的详尽规格描述里，通常都会一脸懵逼，然后开骂和抱怨。
所以功能模块概要需要用尽量简练的语言将各个功能模块里的主要功能点提炼概述而过，不拖泥带水、不瞻前顾后。最好图文并茂地将功能模块的profile像一张蓝图呈现在程序员面前。这是他们读需求规格说明书的一个前奏，要不然都不能愉快地编码和玩耍。
而所有有才的程序员，大多数都是机智过人的汉子，你若遇见冰雪聪明的妹子，可以一块共事，那该是多么大的小确幸，且行且珍惜。
有点才华的PM遍地都是，但才华横溢的程序员真的是千里难寻。因为在编码和玩耍的世界里，不存在“三个臭皮匠顶一个诸葛亮”程式，一个有才而好学的程序员远远胜过10个平庸的呆笨男。
4.功能需求详细规格说明看到标题，机智的程序员瞬间就懂得从愉快玩耍的前奏里，停顿几秒后直入主题。然后开始了一场痛并快乐着的旅程。阅读、思考、玩耍、编码、加班、熬夜、纠结，继续玩耍和编码，周而复始。那这一章节到底要写点神马，才能让程序员读的开心、想的明白，熬夜的甘心、纠结的痛快，从而实现持久的玩耍和编码呢？这一章节是核心，我需要花更多的时间去梳理和胡说额。好吧，赶紧切入主题。
4.1.描述系统产品的容颜
按照User访问系统功能模块的界面的依次顺序，从上而下，界定和描述页面上的全部元素（Text Field、Droplist、Button、Box、可视化图表等等）及元素的属性。
如下拉单包含那些枚举值，填写框输入的数据类型、哪些元素需要弱化，哪些元素需要突出，有/无数据时怎么样。
描述过系统的容颜之后，需要明确界定，功能模块中全部页面的输入和输出项。比如一个可视化的报表页面，输入：需要选择的组合查询条件，输出：要呈现的数据可视化图表。
4.2.USER在界面的交互
