快速学习COSMIC之六：如何识别触发事件

    要度量功能点，就要先识别功能处理，要识别功能处理，就要先识别触发事件。

    触发事件通俗地讲就是发生在被度量软件以外的，由其他事物所产生的，要求被度量软件响应的事件。

    触发事件由功能用户所感知，然后功能用户产生一个输入，来激发功能处理响应这个事件，这个输入被称为触发输入，它要么仅仅起到通知功能处理、激发功能处理的作用，要么除此之外还移动了其他的数据给功能处理。除非在一个功能处理中只有一个输入数据移动，否则触发输入总会移动了其他数据给功能处理。

    触发事件、功能用户、触发输入、功能处理之间的关系如下图：

    触发事件是由谁来产生的呢？

    它有两种可能的来源：

    1 功能用户自己产生触发事件。

    比如，用户感觉到饥饿了，就去饿了么去订餐。感觉到饥饿就是一个触发事件，它是用户自己产生的触发事件，是功能用户自己的想法。

    再如，设置了空调的自动启动时间，到了规定的时间后，空调开始工作。此时，定时器就是功能用户，12点到了就是一个触发事件。这个事件是定时器自己产生的。

    2 功能用户及非被度量的软件模块以外的其他事物产生触发事件。

    比如，每到中午11点，用户就去饿了么下订单。此时中午11点就是一个触发事件，这个事件被用户所感知，用户去应用中下订单。此时的触发事件就是由时钟产生，而被用户感知的。

    再如，发生地震，地震传感器检测到地震的位置信息传递到地震监测系统中，地震传感器是被度量软件的功能用户，发生地震是触发事件，它不是地震传感器产生的。

    触发事件发生后，可以被多个功能用户感知，也可能会产生多个数据组，产生多个触发输入，从而触发多个功能处理。

比如，每到晚上12点，应用系统需要自动备份，需要自动记账。此时就触发了2个功能处理。

   一个功能处理也可以有多个触发事件，比如每到中午11点就去饿了么下订单，也可能不到11点你感觉到饥饿了，就去下订单，这就是两个不同的触发事件。

    所以：触发事件和功能处理之间是多对多的关系。

 

    注意不要把触发事件和输入混为一谈。输入是功能用户与被度量软件之间的交互，触发事件可以理解为功能用户与被度量软件之外的其他事物（也可能是自己）的交互。

    在上图中4类功能用户中，容易出错的是第1类，即人作为功能用户时，他即可以感受到其他事物产生的触发事件，也可以是自己发出触发事件，前者比较容易识别，不易出错。后者在实践中往往出错，可能会把自己产生的触发事件漏识别，也可能把非触发事件误识别。一个基本的经验法则就是由功能用户主动产生的事件，是触发事件，由于被度量软件的请求而要去产生输入的活动，则不是触发事件！

 

    在度量手册中对触发事件有一个定义，这个定义比较抽象。在COSMIC方法中的定义都比较抽象，之所以如此是为了严谨，为了让该方法适合于任何类型的软件。我们可以分解此定义的每句话，这样来理解：

    1 触发事件是在被度量的软件功能性需求中识别出的事件；

    2 触发事件是发生被度量软件之外的一个事件；

    3 触发事件被功能用户感知，导致软件的一个或多个功能用户生成一个或多个数据组。

    4 功能用户生成的第一个数据组会被触发输入所移动。

    5 触发事件是单一事件，不能是一组事件。

    6 触发要么发生，要么不发生，是瞬时产生的。

    7 时钟和定时事件可以是触发事件。