快速学习COSMIC之五：如何识别功能用户

    一个（类）功能用户是软件的功能性用户需求中数据的发送者或预期的接收者。功能用户是与被度量软件交互的人、设备或软件系统。度量目的决定了功能用户，功能用户不同，度量范围不同，度量出的功能规模就不同。

 

   在识别功能用户时，要注意如下几点：

 

    1 功能用户是从功能性用户需求中识别出来的。

    比如有这样一个需求：业务员录入订单信息：

    显然，业务员是录入订单信息这个功能的功能用户，而在需求中没有描述的操作系统、数据库系统、键盘等是不能识别为功能用户的。我们不能脱离功能性用户需求识别功能用户，不能杜撰出一个功能用户出来。

 

    2 功能用户是数据的发送者或预期的接收者。

    功能用户一定要和被度量的软件有数据的交互，要向被度量的软件输入数据或从被度量的软件中获得数据。

    比如有这样一个需求描述：部门经理通知采购员下采购订单，采购员在系统中录入采购订单。

    虽然在需求中出现了部门经理这个角色，但是部门经理并没有和被度量的软件有数据的交互，而是采购员和被度量的软件有数据的交互，所以此时应该把采购员识别为功能用户，而不能把部门经理识别为功能用户。

  

    3 度量目的决定了功能用户。

    比如我们要度量一个手机中的软件规模，我们想了解提交给最终手机用户使用的功能的规模是多少，或者我们想与竞争对手的产品进行对比分析，看谁提供给用户的功能多。

    此时在识别功能用户时应该把最终的手机用户识别为功能用户，虽然在手机中也为电信运行商开发了一些功能供其使用，但是根据此次的度量目的，我们就不把电信运营商识别为功能用户。

 

    4 消息传递链中的多个候选功能用户不能共存。

    比如如果在一个商业应用软件中，有这样的一个需求描述：业务员通过键盘录入订单信息：

    我们要去度量订单管理模块的规模，此时把键盘识别为功能用户就没有道理。因为订单管理模块是为人服务的，不是为键盘服务的。键盘仅仅是一种输入数据的手段，它只是用来传递数据，不负责对数据的内容与含义进行解释或处理，或者我们可以认为它根本不理解传输的数据的含义，我们可以通过键盘输入数据，也可以通过语音输入数据，所以键盘也好，麦克风也好，都是输入设备，是可以替换的。

图一 商业应用软件的消息链

   对于商业应用软件，一般不会把输入输出设备识别为功能用户，这取决于度量目的。

 

   再比如在一个空调控制软件的需求描述中，有这样一个需求：

   当人按下温度的设置按钮后，空调软件会修改目标温度。

   此时是把人作为功能用户呢，还是把温度设置按钮作为功能用户呢？

   如果把人当作功能用户，则需要把设置按钮当作I/O设备，触发事件是对温度不满意。如果把设置按钮当作功能用户，则需要把人按下温度的设置按钮当作触发事件。

   对实时软件，一般会把与被度量的软件直接交互的设备识别为功能用户，这也是取决于度量目的。

   所以此时会把温度设置按钮识别为功能用户。

   当然，基于度量目的，有时我们也可以把人识别为功能用户。但是需要注意的是不能同时把人和温度设置按钮识别为功能用户。

   一个最基本的原则就是：在数据传递链中，不能同时把一条链上的两个候选功能用户作为同一个被度量软件的功能用户。

 

   5 注意区分功能用户的类型与实例

   比如当我们要度量WINDOWS操作系统的规模时，应用软件、数据库系统都会和WINDOWS交互，此时WINDOWS给它们提供的服务（接口）都是一样的，与它们交互的数据也是一样的，并不区分是哪个程序调用它，此时就应该把应用软件与数据库系统都视为同一个（类）功能用户。

 

   6 通过环境图，穷举出所有的功能用户

   环境图是COSMIC方法中定义描述度量范围的一个很简单有效的工具，它仅仅定义了4个图符：