第一章：
由于软件生产实践而带来的困难，可以由人为的干涉来解决。可以将各种“意外困难”分为3类：利益相关者、过程、建模。软件本身就是复杂的，软件的复杂性随着软件的应用领域的性质不同而不同。利益相关者是在软件项目中存在利害关系的人。
软件开发的不变事实定义了软件产生问题的本质问题，从而引发了软件生产中的最大挑战。一些重要的软件特征不易受人为因素的影响，因此在软件项目中都保持不变。软件开发的意外事件大部分可以归因于信息系统及社会系统这样的事实。软件过程定义在软件生产和维护中所使用的活动和组织程序。过程的目标是在开发中管理和改进协作并维持团队，使团队能够向客户交付符合质量要求的产品，并在以后对产品提供适当的支持。利益相关者、过程、软件建模是成功的三要素，软件建模即软件开发活动，这些活动被看作是软件人工制品的建模。
集成方法分为3大类：面向信息和/或面向门户的集成，面向接口的集成，面向过程的集成。面向信息的集成依赖于源应用系统和目标应用系统之间的信息交换。面向门户的集成可以看做是一种特殊的面向信息的集成，将来自多个软件系统的信息具体化到一个共同的用户界面，具有代表性的是Web浏览器门户。面向接口的集成将应用接口（即通过接口抽象定义的服务）连接在一起。面向过程的集成是将应用系统连接在一起，方法是现有应用系统的已有过程集和数据集的顶部定义一个新的过程。
业务需要采取主动，然而，由于新技术的动态发展，包括准备到定制的预报解决方案，IT专家越来越被看做是业务解决方案的提供者，而不仅仅是系统开发者。业务分析员的任务就是将两个需求集合合并构成业务模型，通过聚合关系表示，业务模型包括业务类模型和业务类用例模型。业务类模型是一个高层类图，业务用例模型是标识系统中主要功能构造块的高层用例图。需求协商和确认是需求引导同步进行的。需求协商和确认不能从书写需求文档的过程脱离出来。需求确认需要更加完整的需求文档版本，其中所有的需求都要被清楚地标识和分类。需求管理实际是整个项目管理的一部分，它涉及标识、分类、组织需求，并为需求建立文档，需求变更，需求跟踪三各主要问题。需求文档是需求确定阶段的一个实实在在的结果，大多数的组织按照预先定义好的模板产生需求文档。软件本身就是复杂的。构建能够容纳所有业务数据、规则和特殊情况的软件一贯是困难的，而一致性、可变性、不可见性、加重了这种困难。软件是开发出来的不是成批制造出来的，但是一旦软件开发出来，就可以以最小的代价复制及成批制造。
用例模型是主要的UML示例，也是行为建模的焦点，行为建模表示系统的动态视图——它对功能性需求建模。活动模型表示行为，有独特的元素组成。行为可能是用例的规格说明，也可能是可以在很多地方复用的一个功能。结构视图表示系统的静态视图——表示数据结构、数据关系及作用在这些数据上的操作。交互建模捕获对象之间的交互，为了执行一个用例或用例的一部分，这些对象之间需要通信。状态机模型说明类中的动态变化。结构图主要代表类图。