用例分析技术小记（2）--确定系统边界
首先让我们定义一下经常在项目中用到的术语。系统是指你打算开发的任何事物，他可能是软件、硬件或者过程；项目是指为了建立一个系统而做的所有事情，包括指定计划、安排进度以及归档等。
在项目描述以及风险分析后我们需要做的是确定系统边界，那么如何才能确定系统边界？
系统边界通俗点来说就是将项目分割成系统内的和系统外的，系统内的在以后的项目进展中我们必须为创建他们而投入大量的精力，系统外的我们不需要创建，但是需要我们考虑与他们的接口。若要将系统外的事物进行划分，那么系统外部大致可以分为我们产品将要面对的使用者（人），以及为外部别的系统提供的服务（其他的软件），数据存储，硬件设备，以及网络等等，这些都是不需要我们去创建的，但是我们必须考虑到他们甚至以他们为中心来分析我们的系统内部该做些什么。
通常我们将系统外部与系统内部交互的的事物统称为执行者，执行者是同系统交互的所有事物，执行者总是在我的系统之外，从来就不是我的系统的一部分，每一个执行者都对应一种特定的角色，每一个系统之外的实体对应多种执行者，就好比一个人在系统中他会有多种角色一样，又或者几个人可以用一个执行者来表示，因为他们对于系统来讲属于同一个的角色。
如何寻找系统的执行者？只要能回答一下几个问题，我想系统的执行者大体上也就找到差不多了。
谁使用这个系统？
谁安装系统？
谁启动系统？
谁维护系统？
谁关闭系统？
哪些其他的系统使用这个系统？
谁从这个系统获取信息？
谁为这个系统提供信息？
是否有事情自动在预计的时间发生？
举一个较为通用的例子，对于一个网站来说，他的执行者主要有一下几个
如果这个网站会对外提供RSS订阅的动能，那他的执行者还包括RSS订阅的软件。
在确定了系统外部的执行者后我们要做的当然就是确定系统的内部了，看来如何确定系统内部又是一个麻烦的问题，还好我们已经确定了系统的执行者，顺着执行者这个藤想要摸到瓜应该是不难了。
每个执行者在使用系统的过程中总是希望系统能够为他做点什么，不然这个系统也就不在有用，执行者使用系统想要做的事情我们就称之为用例，用例描述了执行者想要完成的一些事情，同时也会为执行者产生一个结果。站在执行者的角度来看用例，用例应该是执行者想要完成的一个完整的独立的任务
上图似乎是已经列出了所有的用例，其实有很多一部分没有列出来，
执行者希望系统提供什么样的功能？
系统存储信息吗？
执行者将要创建，读取，更新或删除什么信息？
系统是否需要把自身内部状态的变化通知执行者？
系统必须知道哪些外部的事件？执行者将怎样通知系 统这些事件？
其他需要考虑的用例包括：启动，关闭，诊断，安装，培训，改变商业过程以及维护系统。
面对上面的这些问题，我们发现还有很多用例没有关注到，同时也发现很多用例房在一起看起来是比较乱的，我们也可以将用例单独的列出来，同时对用例进行梳理去除冗余的用例，在重新思考后注册会员对应的用例图如下：
在有了用例后，我们还要做的一件事就是详细的描述每一个执行者，以及每个用例是用来做什么事情的。
有时我们会遇到系统自动执行一个活动的事情，比如每天深夜系统对数据库进行维护优化，那么他的执行者是谁？
第一种方法是把时间当成执行者，每天深夜到达规定的事件就会执行该用例；
第二种方法就是将它当成系统的一部分，但是每次执行后他都会发出一个通知将结果发送给系统维护人员；
另外将这两种方法结合起来也是可以的
在确定执行者和用例时发现新的需求怎么办？
当发现新的需求时应该考虑的一些问题：
这些需求对系统是否是必须的？
这些需求是系统在逻辑上会完成的吗？
新的需求将如何影响我们目前的风险分析？
这些需求是否可以被系统目前的执行者处理？换句话说是否有别人对这些需求负责？
这些需求是系统希望客户去做的吗？
这些需求会使产品在市场上变得与众不同吗？
在确定好系统的执行者，用例后我们也就完成了系统边界的确定，接下来我们需要做的就是确定项目的范围，清晰的定义项目的范围，将不需要做的事情放到一边，同时为需要做的划分优先级对于那些系统的基础部分可以给他最高的优先级。应该在系统较晚的阶段考虑那些很好但是不是必须的需求，或者移到系统的后期版本考虑。
最后让我们在来回答一下这些问题：
是否所有的系统需求都被用例代表了？如果不是验证这些需求是在你的系统之内，并且无法被执行者看到，这
种需求不在用例图中出现。
是否所有的用例和执行者都有描述名称？对那些需要以后解释的事物是否有简短的描述？
系统边界和项目范围是否被清晰的定义了？如果不是，他会成为系统的主要风险，要尽早解决这一问题，如果无法回答，那就做一个决定并把它作为一个假设记录下来。
是否所有的未确定部分都在假设列表之内了？
回顾并更新项目描述、风险、假设等等，看看在定义系统吧边界的过程中我们又得到了什么。