系统分析流程.doc

参与者的特性1.参与者位于系统的外部，它不属于系统的某一部分，所以我们不需要去构建参与者。2.只有会使用系统、与跟系统互动、分跟系统交换信息的才会是系统的参与者。3.参与者会启动、参与用例，所以找到参与者，就可以引导我们找到用例。4.我们虽然不需要构建参与者，但是却需要考虑接口。系统需要提供接口让参与者使用，或系统需要用到参与者提供的接口。寻找参与者的问题1.谁会来使用这个系统？2.谁会来安装这个系统？3.谁全来启动这个系统？4.谁会来维护这个系统？5.谁会来关闭这个系统？6.哪些系统会来使用这个系统？7.谁会从这个系统获取信息？8.谁会给这个系统提供信息？9.在预定的时间到达时，有什么事情会自动发生吗？10.哪些系统会与这个系统联网？11.是否有硬件设备与这个系统联网？12.哪些数据库会与这个系统联网？13.内部会有哪些人员来使用这个系统？14.外部会有哪些人员来使用这个系统？15.当特定的时间或事件发生时，这个系统需要自动通知什么人，或者是自动通知其它系统吗？参与者种类表种类细项参与者人外部的人内部的人系统其它系统（内部）其它系统（外部）数据库时间硬件设备系统简述系统名称：系统简述：重点整理：用例的问题表1.参与者想要从这个系统中获得什么样的功能？2.这个系统存储信息吗？哪些参与者将建立、读取、更新或删除这些信息？3.当系统内部状态有变化时，这个系统需要通知参与者吗？4.是否有什么外部事件是这个系统需要知道的？当这些外部事件发生变化时，哪些参与者会通知这个系统？5.这个系统需要定其执行什么操作吗？6.当发生某些重要的外部事件时，这个系统需要自动执行什么操作吗？7.这个用例的名称够明确吗？是否能够从这个用例的名称，直接判断出它的结果？8.这个用例会有多样的结果吗？还是这些结果，其实是在不同的时间点产生的？用例要点表用例要点说明结果重要步骤议题l 参与者的特性表-简单的列出团队成员对参与者的认知，在讨论中比较容易达成共识。l 参与者问题表-把跟参与者有关的问题列出来，方便帮助寻找参与者。l 参与者的种类表-把参与者细分成数个种类，方便帮助寻找参与者，以及用来记录整个项目会遇到的参与者。l 系统简述-用三言两语简单描述一下系统，同时也可以把想到的重点都记录下来。l 用例的问表-把跟用例有关的问题列出来，方便帮助寻找用例。l 用例要点表-简单记录用例的结果、重要流程和议题，日后撰写用例叙述时这些可以参考。l 活动图-可以绘制简单的活动图表达流程，有助于寻找用例。用例叙述最简版用例：事件流程：1.2.3.替代流程的问题表1.在这个步骤中是否还有其它替找的操作？2.在这个流程步骤中是否会发生什么错误？3.在整个用例执行过程中是否随时可能发生其它未记录在叙述中的操作？4.参与者输入数据时，是否会提供不完整的数据，需要重新补上的数据？5.是否会出现错误的数据，需要特别处理的数据？6.参与者是否会会操作其间，临时中断流程？7.参与者是否会在用例执行期间随时取消交互？8.参与者是否会想要挑选其他执行方法？9.参与者在流程执行过程中，会不会有需要协助的地方？10.系统宕机时，是否需要特殊的处理？11.系统响应的时间过长时，是否需要特殊的响应方法？替代流程的分类表替换流程：替找1：不完整的数据替找2：错误的数据替代3：取消或中断的操作替代4：其他执行方法替代5：需要协助替代6：系统宕机时或无响应l 用例叙述最简版-再怎么复杂的叙述，抽丝剥茧后，到少都会留下用例的名称、点和终点。l 替代流程的问题表-针对主要流程中的每一个步骤，都可以问问这些问题，对编写替代流程很有帮助。l 替代流程分类表-编写替代流程的时候，可以直接按照这几类的替代流程来编写。包含关系要点表-不一定所有的可以共享的流程都要独立出来，记得参考包含关系要点表扩展关系要点表-谨慎的使用扩展关系，让扩展关系要点表提醒我们不要滥用关系。包含关系要点表1.需要共享的相同的流程，才能够独立出来。2.暂存数据或者存取数据库的操作，不要轻易独立出来。3.如果只是一两句相同的流程叙述，不要大费同章的独立出来。扩展关系要点表1.谨慎的使用扩展关系，避免因为滥用扩展关系，而让用例图变得很难理解。2.扩展关系通常用于系统上线之后的改版，可以在不改动原来用例叙述的情况下利用扩展关系，加上一段新的用例叙述，以满足新的需求。3.不一定会执行的流程，可以放置在替代流程中;要是想要跟其它用例共享这段流程的话，也可以用扩展关系。切分子系统的步骤1.判断原先的系统用例比较适合分派到哪个子系统，然后帮这个子系统新增一个同名的子系统用例。2.现者，原先的系统用例叙述中，大部分的流程步骤，者留给这个同名的子系统同例。3.然后，将不适合留在新的子系统用例中的其余步骤切分出来，划分给其他子系统，形成为新的子系统用例叙述。4.接着，更校报子系统的用例图，以及重新整理子系统用例叙述。5.最后，绘制其它仓系统的用例图，以及撰写这些子系统的用例叙述。用例点计算公式-Guslav Karner先生所提出的用例点公式，用来估算工时。参与者加权值-评估参与者复杂度。用例加权值-有两种评估用例复杂度的方法，其一按照事务，其二按照对象。技术系数和加权值-评估技术复杂度。环境系统和加权值-评估环境复杂度。负面系数-使用负面系数来评估一个用例点需花费20人时或28人时。对象种类表-以Pter Coad的事务模式概念为基础，衍生出来的对像种类表。用例点计算公式1.未经调整的用例点=参与者总权重+用例总权重2.技术复杂系数=0.6+（0.01*技术总权重）3.环境系数=1.4+（-0.03*环境总权重）4.用例点=未经调整的用例点*技术复杂系数*环境系数5.工时=用例点*20人时（或28人时）参与者加权值1.简单型参与者：这种类型的参与者通常是其它系统，采用程序接口与我们所开发的系统交互。简单型参与者的加权值为1。2.一般型参与者：这类型的参与者有两种，一种是采用特殊协议交互的其它系统，另一种是采用文本模式交互的人类用户。一般型参与者的加权值是2.3.复杂型参与者：这种类型的参与者就是我们常见的人类用户，采用丰富且新和力高的图形界面。复杂