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