《火球——UML大战需求分析》这本书的语言很有趣，系统地介绍了UML中的各种图的定义、使用情况及适用范围等，又介绍了在实际工作情况中是如何使用UML图的。在书的末尾，作者以一个案例——考勤系统的需求分析来实例化这些图，让读者更加理解UML。
我很欣赏，确切的说是很羡慕作者的一点是，他的“UML导师”，也就是他的直接领导在上任后把UML应用到实际项目中，直接使用UML与客户沟通，使得作者能在实际工作中使用UML，对它有非常直观、深刻的认识。这对于一个学习新知识的人来说无疑是一个非常良好的开端。正是在几年中积攒的UML实战经验，使得作者拥有一套属于自己的、实践性强的UML知识体系。就网上的言论来看，大家对UML的评论褒贬不一，有人推崇使用UML：刚入行的开发人员体会不到建模的重要性，是正常的；有人却不屑于使用：只要开始编码，所有UML图都被扔到一边，再也无人去维护它。那么真正在公司中职员们，会使用rose和UML去做需求分析吗？可能取决于你的上司是哪一派的吧。
UML模型是开发团队内部高效沟通的手段，但不是用来和涉众沟通的（涉众是与要建设的业务系统相关的一切人和事。涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分）。“UML只是在‘软件开发人员’圈子里面的统一表示法，强迫开发人员思考，改善开发人员的交流，表达软件开发的模型。”
UML不仅适用于软件设计，也可以用于软件需求分析。对于需求分析来说，鉴于每个人的思维方式不同、不同阶级的领导者的想法也不尽相同，他们担当着项目中的不同角色，拥有不同的角色特点。比如客户中的高层领导更理解项目的目标，能够较清晰地提出“需求”；软件公司中的程序员通常是不清楚项目的目标和需求，对自己负责部分的需求更是了解不深。这样一来就需要在需求分析时持续化地跟进客户需求，并且透过现象看本质——给客户带来切实的价值是开发人员的真正的任务，而不是盲目听从客户的要求而不加分析。但是从某种角度来说,需求变更其实是好事,说明客户对需求的理解更进一步,而我们觉得不适应,往往是因为我们对需求理解的进步程度不如客户。
项目组不应该只将自己定位在软件的制造者，而应该是软件价值的创造者。
认真学好一项技术不会有坏处，现在的我们还是应该去好好学习这门统一建模语言，以备不时之需。