经过阅读上一本《需求工程-软件建模与分析》，已经基本上了解了这一部分的内容，所以读的也比较粗糙。也对需求分析了解更加深入，了解到在做需求分析时通过作图或其他方式能更好更快的解决问题，获取需求同时能更加清晰的分析需求做出相应的需求报告，对软件的开发有着很大的帮助。
第四章是需求规格的说明，在这章中作者提出需要用图形和其他形式化模型来说明需求。需求规格说明用客户的叙述性需求作为输入，用构造规格说明模型作为输出，这些模型分为3组，即状态模型，行为模型和状态变化模型。对象的状态由它的属性和关联的取值来决定，状态规格说明提供系统的静态视图，通常情况下得首先识别类，方法包括名词短语法，公共类模式方法，用例驱动方法，CRC方法和混合方法；接着是为关联建模，依次是发现关联，说明关联；其次是为聚合和组合关系建模，之后是为泛化关系建模，对象建模，它们的建模方法与关联一样。行为规格说明从操作的角度描述了功能，是对需求分析与系统设计的用例，包括用例建模，活动建模，交互和公共接口建模。然而为状态变化建模即为对象状态建模，是从动态的角度描述功能，状态图用来为状态变化建模。第五章讲了从分析到设计，首先我认识了高级类建模包括：构造型，约束，导出信息，可见性，量化关联，关联类和参数化类等。构造性扩展了现有的UML的建模元素，它改变了一个现有元素的定义，解决设计模型问题的一个构造型的专门集合称为一个简档；任何建模元素都可以具有一个关联的约束，或者可以被构造型；注释符号可以包含正文来表示约束，它可以包含任何信息，为了保证注释是一个约束，它应该用关键字<constraint>来另外够造型；导出信息是一种作用到一个属性或一个关联上的约束，导出信息从其他模型元素中获得，可以导出属性，导出关联；关联类也叫做类的关联，关联类通常是当两个类之间存在一个多对多的关联，并且每个关联实例都有它自己的属性值的时候使用，它带有一个隐含的约束，它不能拥有它到所关联的对象所关联的副本，然而具体的类是独立于所关联的类的，没有这个限制，具体类的主码不用来指定相关类的属性。层次结构将复杂性从指数式降低到多项式，它引入对象的层次并且存在层与层之间的相互通信；复杂性控制的解决方案取决于如何将类组合为类的层次，从而简化网络的结构，这样，类就可以形成层次，以强调层与层之间的层次分解，同时允许在层内进行网络式交互来实现的；包用于划分一个应用程序的逻辑模型，用折起的图标表示；边界—控制—实体是基于类的三因素对象建模方法；类中有三类重要的关系：关联，聚合和泛化；聚合分为4种：ExclusiveOwns聚合，Owns聚合，Has聚合和Member聚合；聚合和代理是泛化和继承的一种重要的建模替代品。第六章中讲到体系结构与程序设计，在迭代与增量软件开发中，使用技术细节不断的对分析模型进行细化。一旦技术细节考虑软件/硬件，分析模型就变成了设计模型。系统设计包括两个方面的主要问题——系统的体系结构设计和系统中程序的详细设计。体系设计说是从系统模块方面对系统进行描述，包括确定系统的客户机构件和服务器构件的解决方案策略。体系结构定义类与包的分层组织、将进程分配给计算设施、复用和构建管理、体系结构设计解决多层物理体系结构及多层逻辑体系结构的有关问题。对每个模块内部工作的描述称为详细设计，详细设计为每个模块开发完整的算法和数据结构。这些算法和数据结构是针对底层实现平台的所有约束专门设计的。详细设计描述协作模型，协作模型是实现从用例中捕获的程序功能所需要的。
需求确定阶段捕获需求，并且以自然语言描述来定义需求采用UML进行形式化的需求建模实在以后的需求规格说明阶段进行的。然后，所收集需求的高层可视化表示通常在需求确定阶段完成。作为最低需求，高层可视化模型需要确定系统范围标示主要用例。系统开发中需要考虑到的主要问题也是由于需求变更引起的范围蠕变。在需求中的某些变更不可避免的时候，我们必须确保请求的变更不会超出项目可接受的范围。因此，系统范围可以通过识别外部实体以及在外部实体和我们系统之间的输入和输出数据流来确定。我们系统获得输入信息，进行必要的处理，产生输出信息。任何不能被系统内部处理所支持的需求都不在项目范围内。