需求文档要如何写？我自己写需求文档经历过三个阶段，三个阶段分别对应不同的项目场景，因此对需求文档的写作要求也各不相同，本文将就这三种不同的场景，讨论每个场景下的需求文档要如何写。
最早开始写需求文档的时候，文档还叫《需求规格说明书》简称SRS（Software requirements specification）。写SRS的目的，一来是告诉业务需求方（一般是客户或者用户），你看你要解决的问题我已经理解了;再来是告诉软件设计开发人员，业务需求是这样的，当然需要用技术人员能够听懂的语言。简单来说，需求人员是做为业务人员和技术人员之间桥梁而存在的，需求文档是把业务语言翻译成技术语言，也是测试人员进行系统测试的依据。
一般是软件公司新接了一个外包的项目。项目周期会从几个月到几年不等，需求相对明确，因此一般是采用瀑布式开发模型，即遵循需求分析、设计、开发、集成、测试这几个阶段来开展工作。需求规格说明书是需求阶段的产出物，一般以文档的形式为主，文档中包含组织结构图、业务流程图等辅助说明图表，少数会产出界面原型。
需求规格说明书的撰写流程由甲方公司提供一份简单的业务需求文档，业务需求文档视甲方参与人员的水平和态度，质量参差不齐。有时候也会由乙方人员带笔（这种情况一般是在投标前甲方公司就已经内定了乙方）。甲方将业务需求文档提供给乙方，另外视项目具体建设系统而定，甲方提供给乙方的相关资料包括但不限于：业务办理中使用的文书表单、组织结构关系图、日常使用的报表样表、考核指标、岗位职责说明、上一代或是相关联系统的截图或用户......
需求规格说明书一般都会包括以下方面的内容：
系统范围描述：一般为文字描述，用来界定系统的范围，简单来说就是系统包括什么不包括什么。用来界定系统的边界
组织结构以及岗位职责说明：一般为组织结构图加上文字说明。用来描述系统相关的部门的结构图，以及角色的部门归属以及角色的岗位职责。通常组织结构以及岗位职责一定程度上决定了业务流程的设计。对于涉及到业务流程优化的项目，往往也会需要调整组织结构，并且一旦涉及到组织结构的调整，可以预见项目推动将会有比较大的阻力。
主要业务流程图：一般为分角色的流程图加上文字说明。用来描述主要的业务办理的流程，以及流程中各个角色的分工。流程中每个结点涉及到的文书表单、主要业务对象的状态流转在这个部分也可以梳理出来。
功能说明：一般为功能描述、主要业务规则、操作流程、涉及到的文书表单以及主要业务字段，如果有画原型还会加上原型的截图。会视工作量大小来决定功能说明的颗粒度，但是一般会到功能页面级别，但是对个别比较复杂页面或是复杂功能点，都会单独进行说明。
非功能说明：一般为文字描述，主要从性能、安全、扩展性等方面出发对系统的做出要求。
数据字典：系统涉及到的所有的业务字段的名称、含义、类型、长度、取值范围等。整理数据字典是为数据库设计做准备。
走过了苦哈哈做乙方的项目阶段，接下来是甲方公司的IT部门阶段。
这个时候写的需求文档也有个学名叫做PRD（Product Requirement Document），写PRD的目的一来是为了给技术人员传递需求，二来也是做为功能设计的产出物，三来做为测试人员进行系统测试的依据。
一般一个上千人规模的不大的公司，技术部门规模都不会太大，但是也要看公司类型，这里不讨论纯技术的公司。技术部门负责建设的系统大概分为两类，一类是对外的提供给客户使用的软件产品。一类是对内的提供给内部各部门使用的提高工作效率的信息化系统，当然这类系统也可以采用采购成型的商业产品或是公开招标的方式来进行。
这里讨论内部系统自建的情况。一般在这种情况下都需要快速建立一个能够投入使用的系统，并且需求通常都不太明确，或者说是变化会比较快。这也是为什么会选择自建系统的一个原因。这种情况下通常的做法是先快速上线一个最小化可用的系统或产品，最小化可用产品也有一个学名叫做MVP（Minimum Viable Product），上线后根据使用情况再进行快速迭代增加新的功能修改调整已有的功能。这种情况下，需求文档不太可能有时间也不太有必要写成大部头，所以一般是以画原型和流程图为主。在原型页面加上必要的业务规则说明。原型一般也就是低保真的原型，如果没有现成的资源（UI或UX人员）通常不会出效果图。
对于迭代过程中的需求，会视改动大小来决定需求文档的标准。对于有些微小的改动，有些需求人员或是产品经理会选择不直接口述，而不形成相关文档。也有些会在原型中体现。这种方式的缺点在于，原型和产品差别会越来越大，当系统运行一段时间之后，可能就没人能真正看清楚系统的全貌了，同样也就很难判断接下来的修改会影响到系统的哪些方面，出问题的概率会越来越大。（这里引出来的需求管理方面的问题，不在本文的讨论范围，有机会再来写需求管理踩过的那些坑）
走过了同样苦逼的甲方公司乙方部门阶段，接下来进入了产品阶段。
这个时候的做的东西不再是只在公司内部使用，而是做为公司售卖的商品或提供的公司主要的客户使用的产品。由于是对外提供的，并且为了减少操作培训和售后的压力，在交互方面的要求会比上一个阶段高很多。
通常也会是先出一个最小化可用的产品，然后在用户使用过程中不断快速迭代。这种情况也是会选择画原型的方式，由需求人员或是产品经理先出一个低保真的原型，通过低保真原型设计出产品功能，这个阶段需要保证界面元素基本完整。低保真原型出来后，再交由UI做效果图做界面设计，UX设计交互效果，前端开发人员和后台开发人员根据效果图进行开发。
同样，产品上线后的都会进行迭代，需求来源可能是客户、运营部门、产品部门、KPI需求等等多个来源，实际上需求文档在这种情况下变的非常重要，看到一篇Gaurav Oberoi（SurveyMonkey 的（前）联合创始人）对产品文档的看法，认为作者的方法很适合这种情况下的文档比那些，有兴趣的朋友可以参考一下，原文地址如下：
