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