技術需求文檔，應當這麼寫！

需求文檔是咱們在開發中經常使用的一類溝通方式和媒介，它承載着需求方的指望，同時也標記着一系列事項的生命週期。

不一樣部門、不一樣受衆的需求文檔各異，例如運營人員向產品人員提出的活動需求、產品人員向開發人員提出的功能需求、開發人員向運維人員提出的服務支撐需求、各小組內部同事之間互相提出的需求等等。

爲什麼須要需求文檔？

大部分場景下需求提出方和需求承接方都存在不小的信息差，需求提出方經常使用的語句是「我須要作成這樣」、「越快越好」、「怎麼用你不用管，給我就行」、「這不是我想要的」、「我想要的實際上是那樣」。

一我的常常否認本身的選擇和言語的現象是存在的，不管有意或無心，但這無疑會耗費雙方的時間和精力。需求文檔不只能夠做爲雙方溝經過程中的清單，還能夠做爲雙方選擇和執行的日誌，有了需求文檔，就可以避免因先後矛盾致使空耗的問題。同時，需求文檔能夠清晰地體現參與人員的勞動成果與勞動價值，是自我總結的良好依據。

需求文檔通用模板參考

一百種需求有一千種提法，但需求中的事項相差卻無幾。這裏給出了一份需求文檔模板，你們能夠將其用在工做當中，做爲不一樣人員之間的信息傳遞媒介。

要注意的是，需求和執行是雙生相伴的，所以這裏的下面這份參照文檔與其說是需求文檔，不如說是任務執行記錄，由於它記錄着這個任務從產生到執行完畢的完整生命週期。

爲了方便你們理解，文檔選用不一樣顏色來幫助咱們區分階段，其中：

🔲 淺粉色區塊呈現的是文檔的基本信息；
🔲 淺藍色區塊呈現的是需求主體與需求生命週期主體；
🔲 淺綠色區塊呈現的是需求生命週期接近末尾，即將達成目的；

爲何要這麼設計？

相信各位見過很多的需求文檔，所以對上面這份參考也有不一樣的見解，可能不由會問：

• 爲何設計成這樣的結構？
• 怎麼不用在線需求文檔管理工具呢？
• 必填項和非必填項如何體現？
• 這份參考好像不能知足全部開發場景？

爲何設計成這樣的結構？

需求文檔應當涵蓋從需求產生到需求完成交付的完整過程，例如需求是在什麼樣的場景下產生的、到底要作成什麼樣、須要何時完成、以什麼形式交付、需求是否可以實現、需求實現過程當中作了哪些、交付的結果是否達到預期等。

咱們能夠將完整過程分爲如下幾個階段，以便更好地展開工做：

🔲 需求描述
🔲 需求調研
🔲 需求評審
🔲 開發/實施
🔲 階段驗收
🔲 測試/數據驗證
🔲 上線

按照這個結構，咱們可以想象工做流大抵以下：

首先需求提出方給出需求的背景、具體事項描述等信息，幫助需求承接方更好地理解，同時提出對交付時間、交付方式的指望。需求承接方收到需求信息後須要作初步的調研，瞭解需求實現過程當中的關鍵項並記錄不明確的事項。

接着，雙方初步接觸後約定時間對需求進行評審，雙方的討論將基於調研期間得到的信息展開，在評審討論會結束後一般會肯定需求是否能實現、需求改動項、交付方式、交付時間、最終參與人員等。

而後評審經過，需求承接方開始進行開發/實施。需求承接方要記錄這個過程當中誰在什麼時間作了什麼事並獲得怎樣的結果、期間是否出現了哪些變化。

需求提出方可能會階段性地跟進事件進展，並幫助需求承接方確認工做和工做結果沒有出現誤差，同時雙方互換一些信息。

開發/實施接近尾聲或完成後，需求方組織人員檢驗成果，檢驗經過則通知需求承接方交付/發佈上線，檢驗未經過則作相應調整。

版權水印 - 微信公衆號 Python 編程參考

除了需求背景、開發/實施相關的信息外，需求文檔自己也須要提供一些基礎屬性，用以對需求進行整理、分類、追溯、總結等，因此在需求文檔的開頭設定了一些重要信息欄，例如：

🔲 需求重要等級；
🔲 需求發起日期；
🔲 需求完結日期；
🔲 需求發起人及對應部門；
🔲 需求承接人及對應部門；
🔲 需求所屬的業務類型；
🔲 需求關鍵詞；
🔲 也求所屬業務的名稱；
🔲 需求關注者；
🔲 需求編號；
🔲 需求名稱；

團隊內部能夠定義統一的需求等級，例如緊急且重要的設爲 A、緊急但不重要的設爲 B1、重要但不緊急的設爲 B2、不重要也不緊急的設爲 C 等，這樣你們在參與需求的時候可以合理地分配時間和資源，優先解決那些等級高的需求。

怎麼不用在線需求文檔管理工具呢？

市面上的需求文檔管理工具繁多，Python 編程參考但願在不依賴特定工具的狀況下向你們介紹需求文檔，各位在理解需求文檔後再結合工做中用到的管理工具，效率定會更高。

實際上工做中老是會用到各式各樣的管理工具，工具能夠很好地幫助咱們關聯文檔、彙總信息。例如一個編號爲 TK2020120101 的需求完成後，後續又衍生出針對它的維護類需求 TK2021010103 時，能夠將維護類需求 TK2021010103 與 TK2020120101 關聯起來，這樣在管理需求文檔的時候就可以直觀地看到需求之間的關係和變化，具體以下圖所示。

實際工做中大機率會用到管理工具，工具能夠提升咱們的效率，便於咱們管理事件，藉助工具是很是好的選擇

必填項和非必填項如何體現？

實際上這份文檔包含的區塊都是必要信息，但區塊中的子項能夠根據實際狀況省略。

首先，淺粉色區塊的需求文檔基礎信息部分是必填的，這裏的內容是整個需求的縮影，因此一個格子也不能少。

其次，淺藍色區塊的主體部分是能夠省略的，例若有時候需求調研和需求評審能夠放在同一時間展開，劃分到需求評審便可；例如子項詳細描述中的注意事項、交付要求等選項也是能夠根據實際狀況省略的；若是需求並不複雜，或者說時間週期也不長，那麼子項階段驗收能夠省略，在數據驗證階段校驗便可；若是沒有預上線，或者需求並不須要上線，那麼能夠省略淺綠色區塊部分的項。

最後，若是以爲上面的階段還不足以記錄完整的需求生命週期，能夠根據實際狀況增長階段或子項；

這份參考好像不能知足全部開發場景？

固然，開發場景千千萬萬，Python 編程參考提供的這份需求文檔做爲基礎，各位在具體使用的時候能夠根據團隊狀況和業務狀況自行調整文檔項。

需求文檔實例參考

雖然上面提供了一份基礎模板，可是有一些讀者可能還不太明白在實際使用的時候應該如何編寫。下面以實際的工做需求給出一份實例參考。

閱讀並吸取上面的知識後，想必聰明的你對整個需求文檔的構成、設計考量和具體實踐有了必定的認知，如今已經可以很好地梳理、組織需求文檔了。這裏做者再幫助諸位整理一下需求文檔的一些細節。

需求調研研究的是什麼？

需求調研是基於需求展開的實際狀況探索，主要訴求是得出是否、可否等確切的結論；例如參考實例中提到的：

🔲 當前線上 Nginx 配置文件是否須要改動；
🔲 調用方是否要在更換新 Nginx 後切換調用地址；
🔲 線上服務地址權限是否能順利得到；

需求評審討論什麼？

需求評審基於調研結果和需求背景展開，主要訴求是得出實現方式、結果、呈現方式等確切的結論，並針對那些不穩定的事項給出結果，同時也包含是否、可否等確切結論，例如：

🔲 評審項：監控項與可視化面板是否匹配
🔲 評審結果：監控項與可視化面板匹配，但要設定告警則須要單獨設置面板，不影響展現；

開發實施記錄哪些內容？

開發/實施項中沒必要記錄細節，只須要記錄階段性內容便可。一般是誰在什麼時間完成了什麼事，也就是 時間[事件] 這樣的格式，例如參考實例中記錄的：

🔲 2020-12-01[張三] - 提供 Nginx 配置文件；
🔲 2020-12-05[王五] - 在 Grafana 中導入 Prometheus 數據源並配置可視化面板；
🔲 2020-12-07[王五] - 更改域名解析；

階段驗收寫什麼？

階段驗收關注的是事件結果，也就是 時間[結果] 這樣的格式，與開發/實施記錄相似，例如參考實例中記錄的：

🔲 2020-12-08[張三] - 服務切換後一切正常；
🔲 2020-12-06[張三] - Grafna 可視化面板數據；
🔲 2020-12-03[張三] - Nginx 日誌已同步到 ElasticSearch 中；

上線項關注什麼？

上線項關注的是上線結果和業務自己的狀態，是 時間[狀態] 這樣的格式，例如參考實例中記錄的：

🔲 2020-12-09[王五] - 服務正常正常；
🔲 2020-12-09[張三] - 數據正常；
🔲 2020-12-09[李四] - 數據正常；

這裏的狀態也能夠理解爲結果，但細細想來，仍是用狀態更爲貼切一些。

這裏是微信公衆號 Python 編程參考，若是你以爲這篇文章對你有幫助，請來關注我哦。點擊前往做者韋世東的技術專欄 www.weishidong.com，看更多有用知識。熱門文章一覽：

《幾個有效應對 35 歲危機的辦法》

《工程師繪圖與設計實踐指南》

《持續交付實踐 - GitHub Actions 部署 Node 應用到雲服務器》

《SSH 免密碼/免用戶名/免IP登陸雲服務器實踐》

《ElasticSearch 定時刪除指定天數的數據實踐》