本篇文章從【什么是需求文檔】、【需求文檔編寫目的】、【需求文檔內容】三個方面闡述了我理解的“To G的需求文檔怎么寫”。

1 什么是需求文檔

本文的需求文檔可以理解為大家熟知的PRD，在To G的傳統(tǒng)IT行業(yè)內稱之為《需求規(guī)格說明書》。與之配套的還有《需求分析文檔》，該文檔主要為客戶調研結果的管理，主要目標用戶為甲方客戶，暫不在本文的討論范圍內。

2 需求文檔編寫目的

按照項目大致流程——項目啟動、需求分析、開發(fā)、測試、收尾、結束，需求文檔編寫的目的我認為主要有以下幾點：

? ? ? （1）項目啟動---留檔：To G的產品是某一個具體項目的產出成果，可以簡單理解為是一個工程，在“保修期”內會完成要求的1.0版本，若想要2.0版本，則需要再次簽訂新的合同。1.0和2.0版本間的間隔可能會比較長，也就意味著會遇到需求分析人員或項目管理人員變更的情況，這時一份好的1.0版本的需求文檔可以為后來者做好基礎；

? ? ? （2）需求分析---備忘錄：好記性不如爛筆頭，需求分析人員也需要記錄下來每一個功能或模塊的來源及內容；

? ? ? （3）開發(fā)---呈堂證供：一旦進入開發(fā)階段，則意味著這份需求已經被各方評審過，沒有問題和質疑。開發(fā)人員需要依照需求文檔進行開發(fā)，同時針對開發(fā)的成果，可以找到責任人是需求方還是開發(fā)方或是某（ling）某（dao）方（ceng），避免無辜背鍋；

? ? ? （4）測試---測試依據(jù)：To G的產品往往同政策文件或是甲方的實際工作流程緊密相關，主要業(yè)務流程中的功能是重中之重，因此需求文檔中的業(yè)務流程是測試的主要依據(jù)；

? ? ? （5）收尾---驗收文檔：傳統(tǒng)行業(yè)的項目大部分通過政府招投標方式獲得，需求文檔將作為驗收文檔之一參與項目驗收；

? ? ? （6）結束---組織過程資產：需求文檔在項目結束后將作為公司的組織過程資產，為后期相關業(yè)務方向或涉及到相似功能的其他項目提供參考。

3 需求文檔內容

從需求文檔的編寫目的中，可以抽取出需求文檔的大致結構，如下圖所示。（其中標注黃色感嘆號的將在下文進行詳細說明。）

需求文檔內容結構圖

3.1 數(shù)據(jù)分析

數(shù)據(jù)分析主要包含兩大部分：已有數(shù)據(jù)的情況及支撐系統(tǒng)正常運轉所需的數(shù)據(jù)情況。

需求文檔中該小節(jié)需對這兩大類數(shù)據(jù)情況進行詳細描述。例如空間數(shù)據(jù)需求，需對數(shù)據(jù)名稱、格式（TIFF、SHP等）、類型（點狀、面狀）、坐標系、I查詢需求等進行描述。

3.2 業(yè)務流程

業(yè)務流程不同于系統(tǒng)流程，業(yè)務流程是政府端客戶在實際工作過程中解決某一問題的現(xiàn)實流程；系統(tǒng)流程是在完成這項業(yè)務需求時，可通過信息化系統(tǒng)完成的過程，二者的用戶、流程可能存在較大區(qū)別。

例如在進行某項審批時，現(xiàn)實生活中需要申請人將相關紙質材料提交至相關政府部門的窗口辦理人員處，然后經過窗口辦理人員、主任、處長等的各級審批，逐級通過后完成辦理。

xxx審批業(yè)務流程圖

? 但在系統(tǒng)中，窗口辦理人員在對相關材料審核無誤后通過系統(tǒng)錄入電子材料，并發(fā)送至主任、處長等上級領導審批，逐級通過后完成辦理。

xxx審批系統(tǒng)流程圖

通過上面的例子可以看出，申請人在業(yè)務流程中作為執(zhí)行者參與其中，但在系統(tǒng)流程中并不存在，因為申請人提交紙質材料給窗口辦理人員的過程，系統(tǒng)無法幫助其完成。同時在系統(tǒng)流程中，也去掉了窗口辦理人員對申請人提交材料的線下審核過程，錄入系統(tǒng)的材料為窗口辦理人員在申請人提交時便審核通過的材料。

3.3 功能結構圖

功能結構圖是對系統(tǒng)各功能結構的整體展現(xiàn)，可直觀了解系統(tǒng)結構。

以v1.8.0版本的網易蝸牛讀書APP為例進行展示。

網易蝸牛讀書APP功能結構圖

4 總結

在上述需求文檔結構中，并沒有提到任何UML相關內容，該部分內容在我的學習范疇中，使用尚不熟練，怕引起歧義，因此暫不表述。

以上是當前我對To G類行業(yè)需求文檔編寫的見解，歡迎討論！