对约束的理解：
a)《UML和模式应用（第2版）》一书对约束的理解：约束不是行为，是设计或项目的某些条件，这些条件也属于需求，但通常被称为“约束”来强调其性，例如：
i.必须使用Oracle（我们硬件签署过使用许可证了）；
ii.必须在Linux上运行（成本低）
b)《一线架构师实践指南》一书对约束的总结：
约束需求=业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素
第一，业务环境因素（来自客户或出资方的约束性需求）
1、架构师必须充分考虑客户对上线时间的要求、预算、以及集成需要等非功能需求。
2、客户所处的业务领域为哪些？有什么业务规则和业务？
3、是否需要关注相应的法律法规、专利？
……
第二，使用环境因素（来自用户的约束性需求）
1、软件将人提供给何阶层用户？
2、用户的年龄及使用偏好是哪些？
3、用户是否遍及多个国家？
4、使用期间的环境有电磁干扰、车船移动等国因素吗？
……
第三，构建环境因素（来自开发者和升级维护人员的约束性需求）。
1、开发团队的技术水平如果有限（有些软件企业甚至希望通过招聘便宜的程序员来降低成本）、磨合程度不高、分布在不同城市，会有何影响？
2、开发管理方面、源代码保密方面，是否需要顾及？
……
第四，技术环境因素（也不能遗忘，业界当前技术环境本身也是约束性需求）。
1、技术平台、中间件、编程语言等的流行度、认同度、优缺点等。
2、技术发展的趋势如何？
……下载本文
