好像軟體開發人員都特別討厭文件（個人觀察，個人觀點）。做軟體有一大堆文件，例如專案立項報告，需求調研報告，需求規格說明書，概要設計報告，詳細設計報告...。文件一大堆，真正讓大家仔細閱讀，起到作用的好像不多。
倒也不是這些文件沒有，其實這些文件的作者都是費很大的心力去完成的，雖然有些段落是文件中模板需要才新增的，有很多套話。但是還是有很多章節是很有用，作者下了很大功夫的，
對開發很有用的。如專案立項報告中對開該項目的定位，市場分析及可能形成的門檻和競爭優勢的分析都是很有用的。需求調研報告中的競品分析，特性識別也是很有用的。需求規格說明書也是開發人員在開發過程中，會時不時找出來仔細閱讀，認真去摳的。
但是文件給我們的感覺還是雖然下了大力氣寫，但是好像效果都不好，價效比不高。
在敏捷開發中，
對文件就不是很重視了。在敏捷開發中，
提倡講述使用者故事，然後就是實現，測試等。敏捷開發提倡源**即文件。
當時在做了多年的開發後，我發覺適當的文件，對於產品經理，開發者，測試人員之間的溝通，還是很有用的。
最近進行了一次編碼和文件相結合的實現，在這裡寫出來，和大家交流一下。
最近做了乙個小功能。**做完後大約有800-1000行左右（
c程式），功能比較獨立， 而且是有乙個後台需求， 沒有
ui。我嘗試在開發這個功能的過程中寫文件。
這個文件是按照自己的理解寫的，
沒有套用任何模板。最開始也是自己使用的，作為整理思路的工具。該文件後來也用於與產品經理及測試人員溝通。自己覺得效果還可以。通過該文件，與產品經理澄清了一些自己認識不正確的地方。
該文件給測試人員提供了幫助，而且能讓測試人員盡量的了解了需求和設計。
首先是關於需求的整理。因為只有理解好需求才能開發出正確的軟體。怎麼算是理解了需求，
寫出來，並於需求相關人員達成一致，才能算理解了需求。
以前經常會遇到開發人員自己以為理解了需求，
下手開發，開發完成後才發現和需求人員理解的不一致，
甚至需求人員理解與客戶的真正需求不一致的情況。所以上來我就對需求進行整理。
到這兒，可能大家會頭大。用瀑布式開發流程下，寫過需求調研報告和需求規格說明書的人知道，這些都是大工程，工作量大，而且預期效果也不好。
在這裡，我沒有按照以前的需求規格說明書的思路整理需求。而是採用敏捷開發中的使用者故事的方式來寫。
2.1.1使用者需求
使用者需求按照如下樣式寫的：
作為一名...，我希望
...， 以便於
...。
這裡沒有以前需求規格說明書中大寫繁瑣的部分，只是簡單的一句話，當時很有用。如果你沒有寫過，非常建議你試試。
該段文字資訊量還是比較大，
而且每一段都是很重要的，根據優先順序有大到小：以便於》作為一名
>
我希望。
關於這句話，簡易看看《軟體需求
第三版》的相關章節，寫的很好。《敏捷革命》的第六章中的「不要盲目執行任務， 要領會使用者故事」對這個句子也有精彩的描述。
關於這部分，我的建議是：
不要超過5條，如果超過條，請仔細反思一下，是不是對需求真正理解了。（我的前提是乙個較小的功能）。
關於這部分，在我的實踐中，
最開始以兩條（實際使用者和維護人員），
後來又一次識別出了一條（工廠模式的測試人員）。
2.1.2功能需求
有了使用者需求後，
需要將使用者需求細化為功能需求，也就是功能點。簡易用下面的語句：
a應該...
。我本次的實踐中，功能點共6項， 包括「該功能應該提供完善的日誌，以便於在出現為你的時候，通過日誌能快速定位問題」和「在系統重啟後，日誌不應該丟失」等。其中多數是在開始時識別出來的，也有後來新增的，例如工廠模式下的特殊處理。
2.1.3限制，依賴和假設
在我們的功能開發中，其實是有很多限制，依賴和假設的。很多時候，我們會把這些依賴和限制記在心裡，這是不夠的，我們需要把它們寫出來。這些對我們開發人員，測試人員和需求相關人員都很有用。這些限制，依賴和假設要得到需求人員的認可，測試人員的理解。在編碼時候，我們甚至需要把這些作為注釋放在**中。
2.1.4總結
在使用者需求中，能真正明白「以便於」部分和「作為一名」部分，就算是真正了解了）， 測試人員應該深入了解這些內容，才能知道功能的來龍去脈，寫出正確的測試用例。
在我的實踐中，這部分的文件其實不多，
應該只有半頁多一點的文件。
根據需求編寫需求測試用例，我是站在開發者的角度寫的測試用例，目標就是覆蓋需求中的功能點及其各種情況。格式比較隨意，
主要是能把這些功能都驗證了，沒有落下測試點。
在本次實踐中，我共編寫10條測試用例。
這些測試用例希望能得到測試人員的評審。
其實測試人員未必會直接用這些測試用例，但是能給他們很大的輔助。本次實踐中，
測試人員對這些測試用例還是很關注的。
主要是記錄下設計中的想法和思路。在本次實踐中，
我畫了一張關聯圖，主要用來標識該功能中，
系統與哪些外部物件互動，互動了哪些資訊。然後用一些文字表述了實現的基本思路。
本次實踐中，設計部分大約佔半頁，
包括關聯圖。
針對設計設計的測試用例。這一塊也需要測試人員評審。
但是這塊測試主要是我自己使用的。因為我覺得乙個功能發布出去，最好自己能做以便ft測試。
本次事件中，設計的測試用例大約有*項。
這一部分主要是給**review的人看的。因為我覺得讓別人給自己
review
**，只提供乙個
reviewboard
或diff
檔案，不是很好。
在本次實踐中，我提供了乙個時序圖，並在發出review請求的時候，將該文件作為附件也傳送了出去。
如果是用物件導向程式設計，我可能會提供乙個類圖及乙個類列表，在類圖中表述類之間的關係，在類列表中，描述乙個每個類的功能及想法。
以上是自己本次實踐中的文件。個人覺得對自己的開發很有幫助，而且文件的規模也不大，維護成本也不高。
該文件將客戶和需求人員，開發人員，測試人員以及**review人員都涉及到了。
這次實踐其實是我看了《軟體需求
第三版》後的一次練習（專案是個正式的專案）。
最開始是從需求部分開發的。
雖然已經有需求人員整理了需求，但是沒有表達為文字。鑑於以前經常出現開發人員對需求的理解與實際不一致的情況，我就對需求按照《軟體需求
第三版》說的做了整理（筆者有十多年編寫需求規格說明書的經驗，但是總覺得以前在瀑布發下寫的需求規格說明書並不好，主要困惑容易在需求規格說明書中包含過多設計），並且發給相關人員看。
得到認可後，
又覺得既然功能明確了，可以嘗試讓自己站在乙個測試者的角度看，該怎麼測試，
於是有了需求測試用例相關部分。
因為到這時候，文件還是很小，所以我就把設計及設計的測試用例都放在一起了，作為自己使用的文件。
在編碼完成後，考慮到方便別人review，又把時序圖加了上來。
這就是我本次的文件實踐。
軟體開發 如何寫軟體開發文件
3.程式設計實現 4.整合 5.測試 6.維護 依據什麼需求，開發出什麼 硬體開發平台 nvidia jetson tx2 工業相機 作業系統 ubuntu 16.04 開發平台 ros 程式語言 python c 系統包含 資料採集 演算法實現 結果輸出 在某某硬體平台上安裝某某作業系統，安裝ro...
軟體開發文件如何編寫
目 錄 1.概述4 1.1編寫目的4 1.2定義4 1.3關鍵字5 1.4參考資料5 2總體設計5 2.1需求規定5 2.2執行環境5 2.3 基本設計概念和處理流程 2.4 結構 2.5 功能需求與程式的關係 2.6 人工處理 2.7 遺留問題 3介面設計5 3.1使用者介面6 3.2外部介面6 ...
軟體開發編碼規範文件 乙個完整的軟體開發流程
軟體開發流程即軟體設計思路和方法的一般過程，包括對軟體先進行需求分析，設計軟體的功能和實現的演算法和方法 軟體的總體結構設計和模組設計 編碼和除錯 程式聯調和測試以及編寫 提交程式等一系列操作以滿足客戶的需求並且解決客戶的問題，如果有更高需求，還需要對軟體進行維護 公升級處理，報廢處理。一 需求分析...