建模系统需求是通过事件列表、数据字典、数据流图、实体关系图、流程图、用例来实现系统的具体业务diagrams图形充分描述后，用户可以通过模型感知或识别系统，并进一步提出问题和改进需求，避免实际开发的系统偏离用户最初预期的问题。所有的系统开发方法都是从对发生在特定时间和地点的事件进行建模开始的，这些事件可以被描述，系统应该记录它们。我们先来看一个事件的例子。家里使用的空调可以自动调节温度。调节温度的重要部件是温度控制器，它可以感知周围的环境温度。当温度高于设定温度时，温控器触发继电器吸合，空调运行；当温度低于设定温度时，温控器触发继电器断开，空调停止运行。图2-1空调温控器事件从图2-1可以看出，温控器本身会触发两个事件，一个是温度高于设定温度时发生的事件，事件后执行的动作是启动空调；另一个事件发生在温度低于设定温度时，事件发生后的动作是关闭空调。系统中的所有进程都由事件驱动或触发。在定义系统需求时，首先调查可能影响系统的事件是很有用的。概括地说，什么事件需要系统响应？通过调查对系统有影响的事件，我们可以关注系统的外部环境，把整个系统看成一个黑盒子，从更高的层次全面地审视系统，而不是关注系统的内部工作系统。在调查系统需求之前，需要识别系统利益相关者，然后调查识别出的系统利益相关者并列出系统需求。调查系统利益相关者系统功能需求的主要来源是新系统的各种系统利益相关者。系统涉众是对系统感兴趣的人。对于基于互联网提供服务的系统，系统的利益相关者主要有四类：一类是通过互联网使用系统的人，这类人也称为用户；另一种是购买并拥有系统的人，这类人也称为Customer，比如软件公司为互联网公司开发系统；三是为系统提供服务的人，又称系统操作员；四是保证系统运行的维护人员，也称为系统管理员。图2-2系统相关器图2-2描述了电子书在线阅读系统相关器。用户是通过电脑浏览器或APP客户端使用系统，通过浏览器或APP客户端购买和阅读图书的人。系统运营商是为系统提供服务的人。他们通过浏览器登录系统后台，完成图书上传、图书上下架、处理用户投诉和建议等任务。系统管理员为系统的正常运行提供技术支持，负责系统的部署、维护和数据备份。客户是为系统提供资金的人员和组织。客户可能是项目投标人、购买系统的个人和组织，以及制定项目的公司管理层。客户被包含在系统涉众列表中是因为系统开发人员必须在整个项目开发过程中向客户提供项目进度的概览。召开需求论坛是了解系统功能和业务规则最有效的方式，但也非常耗时耗资源。在这种方法中，我们需要准备一些关于系统需求的问题，然后与系统用户、系统运营商或客户进行讨论，直到我们了解他们对系统的需求和期望。多做几次。需求座谈会的最终结果是系统功能需求列表，电子书在线阅读系统的功能需求如表2-1所示。表2-1功能需求列表识别系统事件从表2-1的需求列表中识别外部实体。外部实体是与系统打交道的人。表2-2列出了系统的外部实体。表2-2外部实体表标识了外部实体针对表2-2中列出的外部实体触发系统的事件。图2-3是用户触发的系统事件。图2-3用户触发的系统事件图2-4系统操作员触发的事件识别事件后，应记录有关每个事件的附加信息以供将来分析。关于事件的附加信息是触发器、来源、操作、响应和目的地。触发器是通知系统事件将要发生，系统需要对事件做出响应。事件源是触发事件的外部实体或参与者。事件的动作是事件发生时系统执行的一系列操作。事件的响应是系统处理完事件后产生的输出结果。事件的目的地是接收系统输出的外部实体或参与者。触发器——用于通知系统事件已经发生。该事件可以是需要处理的数据到达，也可以是某个时间点。源——向系统提供数据的外部实体或参与者动作——当事件发生时系统执行的动作响应——系统产生的输出，将为某个目的地选择目标——外部实体或参与者接收系统输出数据的关于事件的附加信息通常被组织为一个事件列表，一个事件列表包括行和列，行代表事件，列是关于事件的附加信息。事件表中的每一行记录了一个事件的信息，表中的每一列代表了该事件的一个关键信息。表2-3用户事件列表表2-4系统操作员事件列表
