在系统开发的过程中，开发者常常是以轻视、随意的态度对待信息，为了解决众多的系统以马马虎虎的方式处理数据的问题，我们需要一种方案——数据实体需求模式。该方案把所有的实体分为几个固定的种类，共享很多重要的特征，目的是施加一些秩序和一致性。数据实体领域的需求模式包含：数据实体（活实体、交易、配置、编年史）和信息储存。其中，活实体需求模式是用来定义一种实体，它的信息需求保存，并且有预期寿命（也就是说，可以被建立，可以被多次修改，并最终被终止）。它的内容必须至少包括：实体名称、实体的解释、实体包含的信息、实体被唯一确定的方式、父实体的详细内容；额外需求有：编辑功能、查询功能、修改历史、公共数据、只是逻辑删除。交易需求模式是用来定义一个活实体生命中的一种事件，和/或输入这样一个交易的功能。它的内容有：交易名称、交易的解释、交易包含的信息、一个交易如何被唯一确定、所有者活实体详细信息、什么时候交易被认为是发生了、交易的寿命。在开发的过程中我们应该注意一点，就是交易一旦发生，它的数据就是永远不能被修改的。配置需求模式是用来定义参数值和控制系统如何运行的。有两种方式组织配置需求：1.定义一个配置值（名称和目的、代表值、数据类型、级别、配置值什么时候可以修改），然后描述它所处的级别；2.定义配置实体（实体名称、实体的目的、实体内容、实体如何唯一确定、实体什么时候可以修改），它形成了配置的一部分。编年史需求模式是用来定义系统生命中必须被记录的某种或某几种事件。一个编年史需求应该包括：记录的事情的类型、每件事情记录的信息、严重程度；额外需求有：访问控制、公共编年史特征、编年史查看功能、严重级别、清洗编年史、归档编年史、触发其他操作、开启或关闭编年史记录。而信息存储基础架构则是用于永久保存信息的。
用户的功能是丰富多彩的，所以我们很难找到共同点对它们分类，并值得为它编写需求模式。在《软件需求模式》的书中，我们就了解其中的一部分：查询模式和报表模式。查询需求模式是用来定义屏幕显示功能，显示给用户指定的信息。定义一个查询需求应该指定以下信息：查询名称、查询的业务意图、显示的信息、排序顺序、挑选标准、浏览、交互、自动刷新；额外需求有：1.综合查询，为了防止不得不对每一个琐碎的信息都定义一个查询，定义一些覆盖广的需求，处理可能忘记的事；2.公共查询特征，如果有一些规则适用所有的查询，只定义一次，这样可以应用于整个系统。在开发的时候，我们应该注意检查信息是否可用，考虑是否有潜在的性能问题和在预计的用户界面环境下自动的自我刷新是否容易实现。报表需求模式是用来定义报表，该报表用于显示指定的信息给用户，而被显示的信息不会被报表修改。当需要决定是以查询的方式显示还是报表的方式显示时，我们需要考虑的因素有：1.有多少信息要显示，显示多列信息报表可能更好；2.需要怎样交互，报表是被动的；3.多久需要一份硬拷贝，经常打印应该采用报表；4.多少人要看，运行一个报表发给别人比较可靠；5.是否需要保存结果，报表比查询更容易保存；6.信息来自哪里，如果信息不是来自于数据库报表产品可能不能读取；7.信息不稳定的程度，如果数据经常改变报表的拷贝会很快过时；8.查询还是报表实现更便宜。报表需求模式应该指定以下内容：报表的名称、报表的业务意图、显示的信息、排序顺序、挑选标准、自动运行详细信息、总计级别、换页级别。易用性需求模式是用来定义某种残障人士或者有特定需要人士使用系统的容易程度，也就是说必须如何方便他们的使用；额外需求有：常规的易用性、特定需要步骤、裁剪以适合某一个用户、文档和支持、证明一致、可用性。而为了做好易用性功能的开发，软件工程师应该具备3个领域的基本应用知识：（1）计算机用户的特定需要范围（2）内置于操作系统以及正在使用的其他产品和技术的易用性特性（3）一些最重要的辅助技术的类型以及它们如何工作的大致概念。用户界面基础架构就是一组相关的组件，它们一起使用可以与系统交互；而报表基础架构是为我们产生报表，并且通常可以设计新的报表的，在实现时需要考虑的重要方面是：报表设计工具、交付机制、编年史信息、访问控制、通知接收人的方式、报表内容和格式、报表调度、报表基础架构使用的报告、备份和维护。
