编写有效有例子 之 项目相关人员和执行者

 以下来自《编写有效用例》这本小书的第四章

在做需求分析过程中，通常要找到系统直接或间接的使用者，从这些使用者身上找到系统所要实现的机能，如果系统可以完全满足这些使用者的利益需求，这个系统就可以算做是一个成功的系统

狭义来讲，项目相关人员和执行者最好能够区别看待
项目相关人员之契约的参与者。执行者是指任何具有行为的事物，某种情况下的项目相关人员也是执行者。
1. 系统的项目相关人员（stakeholder)
2. 用例的主执行者（primary actor)
3. 被设计得系统 (SuD)
4. 用例的辅助执行者（supporting actor)
5. 内部执行者 (internal actor)

项目相关人员：对用例的行为具有特定利益的人或物
除了与系统直接关联的主执行者外，要考虑一些项目相关人员的行为对系统的影响，这些人及关心系统的行为，但是却从来不与系统进行直接的交互。假如：系统的拥有者，公司的董事会等“沉默执行者”

主执行者：请求系统提供一项服务的项目相关人员，经常（但不一直）是触发用例的执行者。
不是直接触发用例的情况：１，代表其他利益相关者触发用例
                  　　　　　　　２，由时间触发
在刻画主执行者的时候，设计者期望通过对主执行的描述获得一些诸如背景，技能等方面的信息，这对于有UI界面的系统来讲尤其有帮助（简单如提示信息的专业词汇的使用）

辅助执行者：为被设计系统提供服务的外部执行者。识别其的目的是为了识别系统将要使用的外部接口及这些借口间所采用的协议。从而得到系统的其他需求，比如数据格式和外部接口等

内部执行者：多数情况下要回避。把白盒用力作为被设计系统的行为需求来编写，往往是种错误的做法.
（这也是我目前的困惑，一些往往将功能需求和系统需求合二为一，很难做到文档责任分离）