程式設計快20年，寫了一些的文件。

之前也一直在思考如何寫文件，這個過程中，有幾次提升。

一次是在華為，學習如何寫設計文件。

另外就是寫需求文件，這次的專案，以前需求寫得也比較多，但都是有足夠的思間來慢慢寫，這次時間比較緊張，所以，思考如何寫作需求。

==============================

開始之前，

我們還是先回下頭，想想到底什麼是軟體。什麼是硬體。

這是因為，許多公司，特別是中國現階段，實際上大多數公司是硬體公司，然後去開發軟體，然後用硬體的思維去寫軟體文件，各方都很彆扭。

有的人，以為，用程式碼寫出來的，就是軟體，這有些片面。比如CPU也是程式碼寫出來的，但它似乎是很硬的。

所以，有人說華為是家軟體公司，理由是大家都在寫程式碼，這有點讓人哭笑不得。

===========================

這裡，我來斗膽定義一下吧：與人打交道的，特別是人機介面相關的，就是軟體。

另外，是狀態相關的。

比如，windows的win32API，算不算軟體？以前我以為是，現在我覺得不是，當然，也不能算是純硬體，屬於一種中間態吧，因為它不滿足狀態相關這件事。顯然，我們人類是有記憶的，對吧。

列一下，軟體兩個必要條件：

1. 與人打交道，人機介面相關。

2. 狀態相關的。

還有一個最好滿足的條件：

3. 用來贏利的，不是給自己公司人使用的。或是管理自己的硬體裝置產品的。

比如，華為的網管軟體，其實不能算是軟體。

================================

我們開始吧。

先從需求開始。

如上所述，需求的要點是從人開始。

也就是從使用者的角度來看。而不是從實現的角度來看。

設計文件，則是在需求明確的前提下，從設計的角度，來描述，如何實現的。

需求文件的輸入是使用者的述說，輸出給專案經理，專案經理，進行全面的評估，比如，檢視範圍是否劃的明確（這是最最重要的一點），能否實現，如果能實現，公司的資源，能否支撐，質量、進度、成本目標是否能夠達成？

然後下達給技術經理，進行設計。

當然，不得不吐槽，中國的軟體業亂七八糟，怎麼幹得都有，往往是專案經理，自己組織立項，自己組織寫需求。

最後專案經理，需求經理，技術經理，還有產品經理各人一嘴毛，誰都想跨過自己的邊界。唉，不扯這些了。

最後所有的人，都可以指責專案經理，唉，不做事不犯錯，實際是因為邊界。所以，下輩子，不當專案經理，要當給自己的公司當。

需求實際上，的確不應當由專案經理定，雖然他要參與需求的制訂，但他不是寫需求的人，他只是負責執行。

技術經理，負責實現的圖紙。

產品經理，負責驗收結果，也就是代表業主方。或者需求方。算是一個只在關鍵點有話語權的財主，可實際上，地主來干涉長工幹活的事情，在中國很普遍，我說過無數次了：對於中國人來說，邊界是個大難題，無數人，到死也沒搞清楚邊界，誰不想把別人的老婆變成自己的呢？當然，真變成了，也肯定是悲劇了。

吐槽也有好的一面，如果你真看明白上面的文字，你可能瞭解你的公司的問題在哪裡。

有人總是在純想技術，專案失敗，實際上多數時候，70%以上吧，來自於組織的問題。

=======================================

如何寫需求

1. 準備一下：寫寫前因後果，給系統起個名字，然後試圖劃清邊界和規模。這個很難，但必須要做。

2. 分清角色。

3. 站在每個角色的視角，提出，有哪些需求。這一點，回顧一下上面的描述，就出來了，要站在人的角度，如果與人無關，就沒有需求，交給實現方就可以了。比如，使用者的需求，是把資料從A地傳到B地，我們可以選裝硬盤裡用車拉過去，還是用TCP/IP協議傳過去，使用者是不在意的，這種情況，比如，“首先僱輛車，然後硬碟裝車，諸如此類的”，就不要寫了，這雖然也是與人打交道，但這人不是你的使用者；如果把TCP/IP協議棧當作人，自然更離題了。

4. 然後是細化。每個動作的詳細的描述，包括：輸入（前置狀態或允許條件等），輸出，狀態的改變

=========================

設計文件，

相對就更好寫一些。

主要是層層分解。

每一層都要先描述出：

1. 自己在上一層的位置

2. 自己與同層的模組或系統或子系統之半的關聯關係，這時，這些介面，已在上一層的介面描述中定義，只需要提一下即可。同層的模組間的流程，也不要寫，因為在上層已寫過。

3. 自己的內部構成，也就是模組分解。每模組功能簡要描述。

4. 內部模組間關聯關係和介面描述。

5. 子系統的主要流程，主要說明每個流程，各內部子模組之間的協作，主要是指資訊流動，和各子系統的狀態變化。也就是輸入，動作，輸出。