軟體工程中明確定義了，最為乙個軟體需求說明書的任務，它是乙個溝通客戶和程式設計師的紐帶，是乙個對於系統將要幹什麼的詳細描述。因此，在這個檔案中，必須包含很多內容，最近幾天，我一直在閱讀乙份很奇怪的需求說明書和設計說明書，這兩份資料裡，不但沒有系統流程說明，而且沒有概念定義，需求說明書先寫系統與其他系統關係，然後是系統選單，後寫選單內容，最後寫設計的表結構，我連軟體對應的實體有幾個都沒弄清。設計說明書中，先寫系統目的和產生原因，後寫定義的資料和功能介面設計，我連設計的那些表哪些是其他系統定義的，哪些是自己生成的，資料如何關係都不知道。就這樣兩個檔案，要設計程式**，讀得我這個頭疼啊！
下面是我根據我歷史曾經做過幾個管理軟體系統的需求分析與設計的經驗，寫的心得，希望能給大家以幫助。
乙個需求說明書，必須包含以下內容：
1、必須包含系統建立的背景資料，目的和參考資料索引以及附帶相應的參考資料檔案。這部分資訊看上去似乎對於軟體開發沒有直接關係，但是，它就象我們吃一道菜必須有盤子一樣，必不可少。它首先告訴讀者，這個說明書依據什麼而寫的。
3、必須包括系統的範圍、主要完成什麼內容、和已經有的或已知的正在建的系統關係是什麼？這個關係描述，有兩種，一種以業務操作為線索描述操作員在哪個系統做什麼，又到另乙個系統做什麼。還有乙個線索，是程式開發角度，乙個系統給另乙個系統提供了什麼，內容是什麼，或者系統間用什麼方式溝通的等。根據閱讀者已經有的共識和知識體系去書寫。
4、必須包括計畫安排或開發人員安排。這個內容很關鍵。也很微妙。因為開發人員有的能力強，有些功能能做，有的能力弱，有些需求他可能不會做。我曾經做過些系統，也寫過需求說明書，很多時候，因為開發人員的變動，往往會影響系統計畫與質量。因此，一定事先獲得開發人員的配置。一般需求說明書在書寫開始，是沒有這個資訊的，只有當需求基本確定後，就可以根據功能範圍，由開發團隊計畫出乙個人力預安排，根據這個人力安排，時間安排等來決定系統開發到什麼程度與範圍。這部分內容，如果放在概要設計時，就有些偏晚。因為需求不應該只是使用者想要幹什麼，很多時候，需求目標是要綜合多方面因素來確定的。如果放在概要設計上，就會使乙個系統說好完成什麼，但實際上卻被分出幾個階段來實現，或者需求都談好了要這樣實現，結果開發人員不會做，不得不改變目標甚至流程。因此，在需求說明書書寫中，一定要在需求框架基本明晰的基礎上，進行開發人員的確認與預安排。預安排的結果要寫在檔案裡，作為乙個參考資料。
5、必須包含業務/操作流程描述。可以用e-r圖，寫清楚都牽扯了什麼部門，每個角色/實體都怎麼怎麼樣操作的。或者用業務流程圖去說明，或者用**/文字說明。但是必須說明清楚。並且，是需求分析中佔主要的部分，尤其是乙個新建立的系統，這部分內容可能經常被改動！這是我做過10來個管理資訊系統（包括幾個大型管理軟體）分析設計的經驗。這部分內容的改動是恐怖的，尤其是新建立乙個系統，各部門先決定這麼幹，討論討論就出問題了，又換乙個想法。建立管理資訊系統的時候，會引起企業流程重組，業務關係變化，個別操作簡化，職能重組，這些都直接引起要建立乙個新的流程。所以，如果想讓系統做好，就要把這部分內容寫的不能再細，說的不能再清楚，同時，還要忍受在與使用者討論、小組分析中可能要不斷推翻重寫與改動。要經得起各方面推敲。
6、必須包含概念定義。不要小看概念定義，它就象說文解字一樣，是解決溝通障礙的關鍵問題。如果懶得做名詞解釋，就一定會為它付出代價。代價就是可能會多出去很多問題，多開好幾次討論會，延長整個軟體專案實現的時間。甚至，可能程式都做出來，某個功能根本不是使用者要的。概念定義一定要定義準確，嚴謹，反覆推敲，避免二義性，要同時能被使用者和開發人員讀懂。最好定位閱讀者具有小學文化。
7、必須包含系統資料流的說明。這部分內容看上去好象是概要設計的內容。其實，在需求報告中，不應該只簡單說明有什麼什麼單子，上面有什麼。一定要說明清楚，誰根據什麼產生了這個資訊，資訊裡有什麼，經過什麼途徑，又給了哪個位置等。同時，如果流程重組了，可以不描述舊的流程，直接按照新的流程開始說明。這部分不僅可以使閱讀者明白詳細的系統要求，同時還可以給需求報告書寫人員乙個整理思路的方式。它可以使需求分析更準確嚴謹，避免出錯，遺漏或避免一些關鍵點沒問清楚。
8、必須包含介面或其他要求的描述。比如資料精度，介面顏色與布局風格等。很多人嘗試在概要設計中，去做這部分內容，其實，有的時候，在需求報告中，也要反應使用者的要求。現在很多使用者已經具備了比較強的計算機理解與使用能力，他們有時會主動告訴你他要的是上面有什麼，下面有什麼，左面什麼樣，右邊什麼樣，哪個地方都怎麼樣。這是很寶貴的資訊，採集並獲得使用者確認，就可以使系統推廣的時候，減少不少阻力。
9、必須包括系統未來的思考。這部分內容主要是作為乙個需求調研人員，需求分析後，認為系統現在這樣做，還有哪些侷限或不足，將來還可以發展成什麼樣。這部分書寫，可以給系統概要設計人員定義系統生存週期、設計資料結構等提供寶貴的參考資料。因此，如果有能力，就要讓自己發揮作用，一定別忘了寫上。
在需求說明書的書寫中要注意的幾個問題與誤區：
1、不要怕寫的多。一定要建立合理的目錄結構，使人們可以按照自己關心的部分去閱讀。不要怕長，但是語句一定要準確精練。有的時候，閱讀者不一定需要第一次就把檔案全看完，他首先是有乙個概念，然後去某部分仔細確認與查詢。要把需求說明書寫得象我們的手機使用說明書那樣，越明白越細緻越準確越好。
2、千萬不能出現二義性。在需求說明書中，有二義性的語句可能會產生災難性後果的！所以，作為書寫人員，一定要盡量迴避二義性，同時做需求報告評審審核時，也要把二義性做為重點消除目標。
3、寫報告前定義閱讀者。這個工作可以寫在需求說明書裡，讓每個閱讀者都知道，也可以開發小組內部確認就行了。因為實際情況不同，需求說明書可能不是給使用者讀，也可能是使用者與開發人員，還可能是使用者、開發人員和某些特殊部門。閱讀者的不同，會影響我們說明書的內容與書寫角度。看看手機說明書，如果是給使用者，一種寫法，如果是給維修人員，一種寫法，如果是給測試人員，一定是另一種寫法，所以，需求說明書書寫前，要確認閱讀者範圍。
4、一定要在寫需求說明書的同時，保留乙份書寫記錄。這個工作看上去沒什麼，其實，這個工作可以幫助你去清理思路，甚至指導需求分析人員，去問什麼，找什麼人，系統計畫是否合理等。我的記錄內容是乙個**，從什麼時間開始，到什麼時間，做了什麼，參與人是誰，內容簡介。比如，我接觸乙個系統，先根據個人經驗，寫了乙個系統框架，以它為第一稿。然後獲得了一些電子檔案資料，我就會在書寫記錄裡加一行，什麼時間，從誰那裡獲得電子資料，是什麼，放哪個目錄裡了。然後，根據這個電子資料，寫了乙個改動檔案，定義為第二稿，我也會寫什麼時間，寫了第二稿，與第一稿的區別主要是增加/修改了哪些內容。 我個人覺得，這個資料對於乙個大型管理系統的分析非常有用，前後責任人及專案進度很清晰。
5、討論會議與流程確認前，一定要寫計畫及執行結果。內容為有哪些疑問，都是怎麼回答的。這個資料可以使需求說明書更嚴謹，不容易出錯，也可以避免一些理解偏差與重複討論。還可以參考結果進行計畫安排。
6、個人定位要低調。做需求調研和報告書寫，必須本著唯物主義，客觀的，冷靜的觀點去書寫。同時，還要肯付出，對於反覆修改的工作不厭其煩，始終保持耐心細緻，紮實認真的態度。這個態度決定說明書的可用性有多高。
Linux系統公升級的經驗之談
當我們使用linux一段時間以後，自然不會滿足總是在沒有任何變化的系統中工作，而是渴望能象在windows系統中一樣，不斷對自己的linux進行公升級。另一方面，linux本身就是乙個開放的系統，每天都會有新的軟體出現，linux發行套件和核心也在不斷更新。在這樣的情況下，學會對linux 包括系統...
機房收費系統（三）軟體需求說明書
軟體需求說明書 1引言 1.1編寫目的 軟體需求說明書是需求分析階段的乙個文件，是對軟體目標及範圍的求精和細化，深入描述軟體的功能和效能以及軟體的約束範圍，使使用者和軟體開發者對該軟體的初始規定有個大概了解，有利於對專案的回溯和指導後續的開發和維護。文件讀者 開發人員與使用者代表 1.2背景 a.待...
機房收費系統 軟體需求說明書
軟體需求說明書 說明編寫這份軟體需求說明書的目的，指出預期的讀者。主要是方便設計人員，分析人員以及使用者之間的聯絡與交流，明確使用者的需求，及時改善專案的功能和效能，同時對該項目的功能和效能以及開發的環境等做出描述等，為下一步的進行做準備。預期讀者 使用者，專案開發人員 a.軟體系統名稱 機房收費系...