是否需要在业务需求、功能需求、软件规范等文档中包含类图?
简单的答案是“这要看情况了！“
与其他任何UML图一样，类图只是一个供分析员使用的工具。如果没有一个固定的过程，分析师可以自行决定何时使用类图。因此，在哪个分析文档中应该包含类图取决于它的使用。
首先，让我们通过查看类图的一些特性来确定它能为您做些什么：
类图为“类”建模，也称为类型Class。它显示了在被分析的领域中可以存在哪些类型的事物。
记住：事物=名词！
比如为了表达交易可以找到“订单”这个事物名词，这称为名词法，分析领域基本分两大派：名词法和动词法。动词法就是首先找出动词、动作、事件，比如事件建模。又比如事件和状态就是动词和名词，从事件入手分析导致函数计算方向，从状态入手分析导致类图数据表等结构方向，这两者不能偏颇，见：一篇有关函数式编程的形象生动教程
类图可以显示类的“属性”，它显示了可以使用什么类型的数据来描述给定的事物。
类图说明了“类”是如何相互关联的。它描述了在一个特定领域中存在的各种事物之间可能存在的关系。
类图显示“多重性”，也称为“基数”。这个概念是用来进一步澄清事物之间的关系，通过指定一种类型的事物有多少与另一种类型的事物有多少相关。
因此，如果分析人员使用类图来描述业务用户（也称为业务域）的术语中发现的关键名词以及它们之间的关系，那么这个类图将表示一个领域模型，并且可能属于项目的早期构件之一，如业务需求文档。
另一方面，如果类图用于解释将使用哪些C类来实现功能需求和描述这些类的数据属性类型，那么该图将被视为设计工件，可能属于系统规范/技术规范文档。