软件系统中的构想文档

　　构想文档为开发中的软件系统提供了完整的构想，并支持投资方和开发组织间的合同。不管是一个巨大的军事标准开发项目（其构想可能是300页的系统规格说明），还是小型的、内部投资的商业产品（其构想可能只有两页白纸），每个项目都需要一个捕获项目相关人员期望的来源。项目构想应该随着理解需求、构架、计划和技术的进化变更。优秀的构想文档应该缓慢变更。
　　构想文档时从用户的角度编写的，它侧重于系统的基本特性和质量的可接受等级。构想文档至少应包含两个附属品。第一个附属品是使用用例（一个可视化模型和一个单独的制品）来描述可操作概念。第二个附属品应该描述构想陈述固有的变更风险，以便指导自卫性的设计工作。
　　构想陈述应该描述应包括什么特征以及不应包括但应考虑的特征，它还应该详细说明可操作的能力（容量、响应时间和精确性、用户剖面图以及与可应用的整个外部系统边界的互操作性接口。构想不应该只为初始的操作等级定义，还应该处理它的可能的进化路径，这样才能有一个评估设计适应性的语境。可操作的概念包括指定正式和非正式使用的用例和场景。用例陈述为理解和细化范围、评价设计模型的完整性、开发验收测试规程提供了动态的语境。构想文档为项目相关人员可见的需求提供了合同性的基础。