本篇文章从【什么是需求文档】、【需求文档编写目的】、【需求文档内容】三个方面阐述了我理解的“To G的需求文档怎么写”。
1 什么是需求文档
本文的需求文档可以理解为大家熟知的PRD，在To G的传统IT行业内称之为《需求规格说明书》。与之配套的还有《需求分析文档》，该文档主要为客户调研结果的管理，主要目标用户为甲方客户，暂不在本文的讨论范围内。
2 需求文档编写目的
按照项目大致流程——项目启动、需求分析、开发、测试、收尾、结束，需求文档编写的目的我认为主要有以下几点：
（1）项目启动---留档：To G的产品是某一个具体项目的产出成果，可以简单理解为是一个工程，在“保修期”内会完成要求的1.0版本，若想要2.0版本，则需要再次签订新的合同。1.0和2.0版本间的间隔可能会比较长，也就意味着会遇到需求分析人员或项目管理人员变更的情况，这时一份好的1.0版本的需求文档可以为后来者做好基础；
（2）需求分析---备忘录：好记性不如烂笔头，需求分析人员也需要记录下来每一个功能或模块的来源及内容；
（3）开发---呈堂证供：一旦进入开发阶段，则意味着这份需求已经被各方评审过，没有问题和质疑。开发人员需要依照需求文档进行开发，同时针对开发的成果，可以找到责任人是需求方还是开发方或是某（ling）某（dao）方（ceng），避免无辜背锅；
（4）测试---测试依据：To G的产品往往同政策文件或是甲方的实际工作流程紧密相关，主要业务流程中的功能是重中之重，因此需求文档中的业务流程是测试的主要依据；
（5）收尾---验收文档：传统行业的项目大部分通过政府招投标方式获得，需求文档将作为验收文档之一参与项目验收；
（6）结束---组织过程资产：需求文档在项目结束后将作为公司的组织过程资产，为后期相关业务方向或涉及到相似功能的其他项目提供参考。
3 需求文档内容
从需求文档的编写目的中，可以抽取出需求文档的大致结构，如下图所示。（其中标注黄色感叹号的将在下文进行详细说明。）
3.1 数据分析
数据分析主要包含两大部分：已有数据的情况及支撑系统正常运转所需的数据情况。
需求文档中该小节需对这两大类数据情况进行详细描述。例如空间数据需求，需对数据名称、格式（TIFF、SHP等）、类型（点状、面状）、坐标系、I查询需求等进行描述。
3.2 业务流程
业务流程不同于系统流程，业务流程是政府端客户在实际工作过程中解决某一问题的现实流程；系统流程是在完成这项业务需求时，可通过信息化系统完成的过程，二者的用户、流程可能存在较大区别。
例如在进行某项审批时，现实生活中需要申请人将相关纸质材料提交至相关政府部门的窗口办理人员处，然后经过窗口办理人员、主任、处长等的各级审批，逐级通过后完成办理。
但在系统中，窗口办理人员在对相关材料审核无误后通过系统录入电子材料，并发送至主任、处长等上级领导审批，逐级通过后完成办理。
通过上面的例子可以看出，申请人在业务流程中作为执行者参与其中，但在系统流程中并不存在，因为申请人提交纸质材料给窗口办理人员的过程，系统无法帮助其完成。同时在系统流程中，也去掉了窗口办理人员对申请人提交材料的线下审核过程，录入系统的材料为窗口办理人员在申请人提交时便审核通过的材料。
3.3 功能结构图
功能结构图是对系统各功能结构的整体展现，可直观了解系统结构。
以v1.8.0版本的网易蜗牛读书APP为例进行展示。
4 总结
在上述需求文档结构中，并没有提到任何UML相关内容，该部分内容在我的学习范畴中，使用尚不熟练，怕引起歧义，因此暂不表述。
以上是当前我对To G类行业需求文档编写的见解，欢迎讨论！
