系統分析怎么寫
在軟件開發工程中我們所做的第一步：系統分析。希望我們中國的代碼人能吸取更多更好的理論和實際的經驗，有符合我們實際情況的系統分析、開發方法、步驟以 及文檔。系統分析，我個人認為它應該是能體現系統的靈魂性的文檔。該文檔應有什么內容，表達什么意思是我想在這里與大家探討的問題。我覺得在系統分析書中 應該有以下內容（視項目而定）：
1、系統需求說明 說明系統是一個什么樣的系統，用市場上現有的系統來類比，用客戶（或是我們自己）需要一個什么樣的系統進行說明，力求完整。并對系 統的發展可擴充性進行描述（現在沒有哪個系統是一次OK的）。說明與現有的系統有什么相同什么不同，說明未來系統的發展方面以及可移值性等能預見的事情。
2、系統資源說明 對系統所需要的軟件、硬件資源進行說明。描述系統所需要的所有的TCO成本。包括人員、時間、設備、系統、一次性投入資金、持續性投入資金這樣的所有資源。
3、系統可行性分析 對系統的實施中的資源進行分析，說明投入的合理性和必然性，對其中的所有不可預見性的投入進行合理的量化說明，來說明系統的實施的可行性。
以上為我所想到的系統分析說明書中應出現的前三種文檔，不知大家有什么想法，請賜教。
作為開發前期的工作，還應該包括：總體設計和詳細設計。
總體設計這個階段必須回答的關鍵問題：概括地說，應該如何解決這個問題？
首先，應該考慮幾種可能的解決方案。例如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那么是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是數據庫……
通常至少應該考慮下述幾類可能的方案：
低成本的解決方案
系統只能完成最必要的工作，不能多做一點額外的工作。
中等成本的解決方案
這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些 功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力 在實踐中將證明是很有價值的。
高成本的"十全十美"的系統
這樣的系統具有用戶可能希望有的所有功能和特點。系統分析員應該使用系統流程圖或其他工具描述每種 可能的系統，估計每種方案的成本和效益，還 應該在充分權衡各種方案的利弊的基礎上，推薦一個較好的系統 （最佳方案），并且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可 以著手完成本 階段的另一項主要工作。
上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是怎樣設計這些程序呢？
結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟件的結構，
也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟件的結構。
詳細設計總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題："應該怎樣具體 地實現這個系統呢？"這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似于其他工程領域中工程師經常使用的工程藍 圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。通常用 HIPO 圖（層次圖加輸入/處理/輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。
我想這樣的文檔系統的思路是一個慢慢積累的過程，如JJX所說，我們現在有太多的形式上的東東，它并不是一個程序員真正需要的系統分析/設計書， 對于系統的設計到實施到最后的代碼以及驗收有太多的改動和變化，我們正在一個極不規范的系統中生存，所以我們不可能有太多的選擇，只能抄抄應付了事。所以 與大家一起探討一個真正適合我們的文檔模式，這個模式或是說模板能為我們的代碼工作減少負擔，帶來更多的動能:)
就目前的開發思路，應用環境和編程方法來說，傳統的需求分析-系統分析-概要設計-詳細
設計-……已越來越不行了，因為：
1、現在的應用和以前大不一樣。現在的應用是一種龐大的集成，包括跨平臺，網絡，數據庫等等，而且新技術的出現越來越快，任何人都無法精通甚至是掌握 全部技術。簡單例子：現在有Windows,Unix,Linux等平臺，有SQL Server,Oracle,Syba等數據庫，有C++,VB,Delphi等工具，誰能全部精通呢？如果不能，那么如何確定是 Windows+SQL Server+Delphi好還是Unix+Oracle+C++合適？
2、客戶沒有需求。我做過銀行、電信等大客戶及各種小客戶，他們無一另外的說"我要做一個OA系統"，"我要做一個企業網"，"我要做一個……"。可 他們無法確定要實現什么，因為很少有用戶是真正由于業務的需求而做項目的；而且他們也不清楚能夠實現什么(因為他們不懂notes,不懂企業網)。
3、需求與環境的變化。由于在項目開發前客戶沒有實質性的需求，加上軟件開發人員不熟悉客戶的業務，就導致在開發過程中需求的不斷變化，嚴重時將導致分析與設計作廢。
4、對象化的工具和過程化的程序現在的開發工具已經很對象化了，而我們開發的程序卻很
過程化。也就是說你雖然努力的模塊化，層次化，可只要運行環境有所變化，你還要不斷地修改再修改。
上述的實際情況說明我們確實需要把實際中的做法修改一下。一個項目如果做到了80%的時候才真正明確這個系統是什么樣子的話，我認為是設計者的失敗。 所以在設計階段不但應該做好傳統做法的各種文檔和論證，而且，應該做一些具體的設計工作。比如，系統的整體運行設計及系統各功能模塊的具體設計。而且這些 設計應當都有詳細的設計說明書。當這些說明書完成后，應當能做到：隨便找個程序員他都能只通過看某功能模塊的設計說明書就能夠開始代碼的開發而不用再重新 思考該怎樣去做了，程序員在這里就真的只是一個設計者的實現工具。當然，也象某些兄弟說的那樣，現在的系統都越來越繁雜、越來越龐大、越來越向集成性質靠 攏，似乎是沒有多少人能掌握具體用什么做效果如何，但關鍵就在這里。莫非真的沒有人能做到這點嗎？非也！只不過是目前的顯示情況是，設計人員的水平偏低， 有些公司的設計人員根本就沒有多少的開發經驗，他又怎能了解太多的系統呢。
系統設計在目前看來似乎是個拿錢多干活少的工作，這是不正常的現象。培養一個程序員
根本不用花多大的力氣，一個人只要不太笨不太蠢，給他一個機會，相 信就能掌握某門技術或方法。但要掌握若干種方法，就不是能夠通過速成解決的了。問題也在于此。目前似乎所有的系統設計人員都能夠設計所有的東西。其實不 然。很多人都有知識的局限性，這就決定他只能對某些方向的東西做出決策和設計。客戶固然不知道他要做什么，但我們應該知道。如果在前期能夠多接觸用戶、多 深入實際，把設計人員當成客戶工作中的一員，他就能夠真正了解到客戶的需求，當然也就能夠為他做出合適的設計。
至于說到各種系統之間的好壞對比，我想，任何東西都沒有絕對，有的只是某些方面的權衡。比如性能或空間的權衡、價格和性能的權衡和功能側重上的權衡等 等如此而已。計算機里的東西沒有哪一樣的存在不是包含了這種權衡在內的。雖然從商務上似乎總想說服用戶什么東西好什么東西不好，其實從技術上講無所謂好和 不好，有的只是區別及該區別所針對的問題而已。這就象有人總在爭論Linux和Window到底誰好一樣。或許從"技術"上講，Linux比Window 好，但這其實并不公正，因為漂亮的GUI界面和友好的人際交互同樣應該是"技術"中應該考慮到的一部分。把所有的東西結合起來一看就知道沒有絕對的好。所 以，不見得非要在用戶決定之前由系統設計的人員事先來為各種方案做個排隊，只需要了解用戶的需求，然后從大方向上決定一個方向再做具體設計就可以了。
在這里我只從過去的實踐角度舉例來說，至于理論方面實在沒時間深入。首先，認同兩個說法：
1. 項目(或說工程)有三個主要方面：功能，時間，成本。
2. 系統分析的任務：將用戶的業務邏輯轉化為程序邏輯，計算時間和成本。
讓我們來做一個概要設計：
1) 功能：簡單的信息發布系統。
2) 系統分析員根據項目的時間和成本，在充分權衡各種方案的利弊的基礎上提出SQLSERVER+CORBA+DELPHI的方案……用戶很滿意，OK，開始詳細設計：
1) 為方便用戶的安裝使用三層結構。
2) 客戶端包含信息分布和查詢兩個模塊。
3) 使用各種圖或語言描述各種函數，過程，模塊，層次……一切順利，開始編碼……編碼
完成，用戶試用，這時用戶提出：在客戶端要能實時跟蹤信息的變化，而你卻 發現DELPHI的CORBA不支持回調！轉用其它方按時間上不可能，補救措施也不靈(比如使用timer，但客戶的網絡環境不允許多個用戶的頻繁刷 新)，怎么辦？
分析一下問題出在哪里：
1) 有人會說系統分析員不真正了解客戶的需求，可這不可能(項目時間的限制)也不現實(不可能讓分析員到每個崗位都去操作一下)。
2) 有人會說系統分析員的知識和經驗不足，可現實卻是分析員認為應該的客戶覺得沒必要，而客戶覺得必須的分析員又不可理解。這是不同的工作造成的，俗話說隔行如隔山。
3) 有人會說系統分析員的水平不夠，可問題絕大部分是出在細節而不是大方向上，掌握全部細節可能嗎？這就是一個長期困擾我的問題：細節(而不是方向)往往成為成功與失敗的關鍵(注意，這里的成功是包含了時間和成本的)，而細節是不可能全部發現與分析清楚的。
如何在這種不完整的需求上構造完整的系統呢？或是根本不可能呢？這種問題我遇到過多
次──當然都是別人做的設計。但我認為這個過程中不足的地方就是： 把東西做死了，沒有切實地為用戶著想。很多人在做設計時，可能考慮的最多的是實現上的方便，而不是系統的擴展及更新。需知道，用戶的需求是在不斷變化的， 如果總是在設計前就"善意"地替用戶假設，是難以預料后事的結局的。所以我想，在設計階段就因該把可能出現的問題都擺到桌面上討論，包括其特點、效果和后 果，而不是自以為是地、好心地替用戶"假設"。其實一個系統設計的優劣，其系統的擴展性能是一個很重要的指標，一個單純就事論事地針對某件事情而做出的" 專用"系統是沒有任何遠見的
