???? 呵呵，正好在寫一份需求分析。看到“假定和約束”的問題，有些自己的思考，拿來分享一下，同時也讓更多牛人來幫我指正一下我自己在概念上的錯誤。
???? 看了很多需求說明書了，包括自己以前也寫了很多，大部分時候我會刪除這個章節（呵呵，只是我個人的行為而已）。刪除的目的不是為了省事，是很多情況下連我自己都不清楚這些假定和約束，所以就沒有去寫。
??? 從個人理解（含教材中學到的知識）：“假定和約束”描述系統設計中最主要的約束，這些是由客戶強制要求并在需求說明書寫明的。說明系統是如何來適應這些約束的。另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那么系統可能還受到其它的約束。實現的語言和平臺也會對系統有約束，同樣在此予以說明。“假定和約束”，應該是現實需求所有的假定和約束包括了約束包括了性能、規模、進度及商業等方面等因素。“假定和約束”，就是開發項目所使用到的一些資源條件。包括：人力，財力，時間，設備等。一般情況下可以寫這么幾方面的內容：建議開發軟件運行的最短壽命、經費來源和使用限制、法律和政策方面的限制、硬件、軟件、運行環境和開發環境的條件和限制、可利用的信息和資源、建議開發軟件投入使用的最遲時間等等。
??? 和很多人考慮的一樣，我自己也希望在一個項目中沒有所謂的“假定和約束”這個概念。畢竟作為軟件而言，計算機是死的，必須要有開發人員告訴計算機怎么去做，怎么去計算（難道計算機最會干的不就是循環、判斷嗎？），所以我就希望所有的一切都有一個定論。以前一個朋友畢業做論文要寫需求分析，問我們幾個圈子里面的朋友，我們當時給的回答就是“需求說明一定要像《呂氏春秋》一樣，一字千金。就不能有什么假定之類的概念。”呵呵，后來當幾個兄弟都開始自己要寫需求的時候才發現，《呂氏春秋》般的需求說明書才是真正的軟件開發過程中的烏托邦，幾乎不可能出現的。很多項目不停的進行修改、不停的有推翻重來的可能，終極原因也就是因為項目經理沒有很好的注意對于假定和約束的思考。（唉，去年組里面的兄弟為此可是吃了不少虧，這幾乎是去年我自己工作中的致命bug了，很是羞愧ing）
???? 完整的“假定和約束”描述對于項目經理進行后期的數據庫設計、系統詳細設計等工作的時候都能起到良好的幫助作用。需求多思考一分鐘，對于后期工作的工作效率提高的遠遠不是這么一點點時間了。同時完整的“假定和約束”描述對于程序開發人員而言作用也是相當大的，也就是把所有的問題在前期提出來，其實每個程序員都有自己的思想，沒有人愿意別人要他作甚么他就作甚么，項目經理能在需求分析階段將所有的“假定和約束”提出，對于程序員自己的思考也是很有幫助的。至少，不停的修改，不停的升級這種情況能盡量少一些：）
?
?? 所以，從現在開始，呵呵，好好思考“假定和約束”問題
????
???