轉自：http://www.blogjava.net/sinoly/archive/2007/03/12/103189.html
看到“假定和約束”的問題，有些自己的思考，拿來分享一下，同時也讓更多牛人來幫我指正一下我自己在概念上的錯誤。
看了很多需求說明書了，包括自己以前也寫了很多，大部分時候我會刪除這個章節（呵呵，只是我個人的行爲而已）。刪除的目的不是爲了省事，是很多情況下連我自己都不清楚這些假定和約束，所以就沒有去寫。
從個人理解（含教材中學到的知識）：“假定和約束”描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。實現的語言和平臺也會對系統有約束，同樣在此予以說明。“假定和約束”，應該是現實需求所有的假定和約束包括了約束包括了性能、規模、進度及商業等方面等因素。“假定和約束”，就是開發項目所使用到的一些資源條件。包括：人力，財力，時間，設備等。一般情況下可以寫這麼幾方面的內容：建議開發軟件運行的最短壽命、經費來源和使用限制、法律和政策方面的限制、硬件、軟件、運行環境和開發環境的條件和限制、可利用的信息和資源、建議開發軟件投入使用的最遲時間等等。
和很多人考慮的一樣，我自己也希望在一個項目中沒有所謂的“假定和約束”這個概念。畢竟作爲軟件而言，計算機是死的，必須要有開發人員告訴計算機怎麼去做，怎麼去計算（難道計算機最會幹的不就是循環、判斷嗎？），所以我就希望所有的一切都有一個定論。以前一個朋友畢業做論文要寫需求分析，問我們幾個圈子裏面的朋友，我們當時給的回答就是“需求說明一定要像《呂氏春秋》一樣，一字千金。就不能有什麼假定之類的概念。”呵呵，後來當幾個兄弟都開始自己要寫需求的時候才發現，《呂氏春秋》般的需求說明書纔是真正的軟件開發過程中的烏托邦，幾乎不可能出現的。很多項目不停的進行修改、不停的有推翻重來的可能，終極原因也就是因爲項目經理沒有很好的注意對於假定和約束的思考。（唉，去年組裏面的兄弟爲此可是吃了不少虧，這幾乎是去年我自己工作中的致命bug了，很是羞愧ing）
完整的“假定和約束”描述對於項目經理進行後期的數據庫設計、系統詳細設計等工作的時候都能起到良好的幫助作用。需求多思考一分鐘，對於後期工作的工作效率提高的遠遠不是這麼一點點時間了。同時完整的“假定和約束”描述對於程序開發人員而言作用也是相當大的，也就是把所有的問題在前期提出來，其實每個程序員都有自己的思想，沒有人願意別人要他作甚麼他就作甚麼，項目經理能在需求分析階段將所有的“假定和約束”提出，對於程序員自己的思考也是很有幫助的。至少，不停的修改，不停的升級這種情況能儘量少一些：）
所以，從現在開始，呵呵，好好思考“假定和約束”問題
----------------------------------------------------------分割線---------------------------------------------------------
在做一個操作系統移植的項目，對方的需求分析裏要求要有設計約束。好好看了任務書，確實提了不少約束。
1）對編程語言的約束
它是一個自主研發的設備，所有有自己的彙編語言，這個必須遵守。
2）工具約束
編譯器，模擬器都是它自己的，所以得用
3）性能約束
中斷響應時間，任務切換時間等
4）特殊場景約束
5）代碼體積
是一個嵌入式設備，所以對OS的代碼體積有要求
6)在某幾個實現上，有具體的要求
---------------------------------------------再理解一下---------------------------------------------
設計約束，主要根據工具，和客戶需求對設計和實現進行一定的指導。就像6).一個功能的實現有很多方法，但是人家要求了，你這個就得按他的意思來。