转自：http://www.blogjava.net/sinoly/archive/2007/03/12/103189.html
看到“假定和约束”的问题，有些自己的思考，拿来分享一下，同时也让更多牛人来帮我指正一下我自己在概念上的错误。
看了很多需求说明书了，包括自己以前也写了很多，大部分时候我会删除这个章节（呵呵，只是我个人的行为而已）。删除的目的不是为了省事，是很多情况下连我自己都不清楚这些假定和约束，所以就没有去写。
从个人理解（含教材中学到的知识）：“假定和约束”描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。实现的语言和平台也会对系统有约束，同样在此予以说明。“假定和约束”，应该是现实需求所有的假定和约束包括了约束包括了性能、规模、进度及商业等方面等因素。“假定和约束”，就是开发项目所使用到的一些资源条件。包括：人力，财力，时间，设备等。一般情况下可以写这么几方面的内容：建议开发软件运行的最短寿命、经费来源和使用限制、法律和政策方面的限制、硬件、软件、运行环境和开发环境的条件和限制、可利用的信息和资源、建议开发软件投入使用的最迟时间等等。
和很多人考虑的一样，我自己也希望在一个项目中没有所谓的“假定和约束”这个概念。毕竟作为软件而言，计算机是死的，必须要有开发人员告诉计算机怎么去做，怎么去计算（难道计算机最会干的不就是循环、判断吗？），所以我就希望所有的一切都有一个定论。以前一个朋友毕业做论文要写需求分析，问我们几个圈子里面的朋友，我们当时给的回答就是“需求说明一定要像《吕氏春秋》一样，一字千金。就不能有什么假定之类的概念。”呵呵，后来当几个兄弟都开始自己要写需求的时候才发现，《吕氏春秋》般的需求说明书才是真正的软件开发过程中的乌托邦，几乎不可能出现的。很多项目不停的进行修改、不停的有推翻重来的可能，终极原因也就是因为项目经理没有很好的注意对于假定和约束的思考。（唉，去年组里面的兄弟为此可是吃了不少亏，这几乎是去年我自己工作中的致命bug了，很是羞愧ing）
完整的“假定和约束”描述对于项目经理进行后期的数据库设计、系统详细设计等工作的时候都能起到良好的帮助作用。需求多思考一分钟，对于后期工作的工作效率提高的远远不是这么一点点时间了。同时完整的“假定和约束”描述对于程序开发人员而言作用也是相当大的，也就是把所有的问题在前期提出来，其实每个程序员都有自己的思想，没有人愿意别人要他作甚么他就作甚么，项目经理能在需求分析阶段将所有的“假定和约束”提出，对于程序员自己的思考也是很有帮助的。至少，不停的修改，不停的升级这种情况能尽量少一些：）
所以，从现在开始，呵呵，好好思考“假定和约束”问题
----------------------------------------------------------分割线---------------------------------------------------------
在做一个操作系统移植的项目，对方的需求分析里要求要有设计约束。好好看了任务书，确实提了不少约束。
1）对编程语言的约束
它是一个自主研发的设备，所有有自己的汇编语言，这个必须遵守。
2）工具约束
编译器，模拟器都是它自己的，所以得用
3）性能约束
中断响应时间，任务切换时间等
4）特殊场景约束
5）代码体积
是一个嵌入式设备，所以对OS的代码体积有要求
6)在某几个实现上，有具体的要求
---------------------------------------------再理解一下---------------------------------------------
设计约束，主要根据工具，和客户需求对设计和实现进行一定的指导。就像6).一个功能的实现有很多方法，但是人家要求了，你这个就得按他的意思来。