系統分析流程.docVIP

参与者的特性 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.这个用例会有多样的结果吗？还是这些结果，其实是在不同的时间点产生的？ 用例要点表 用例 要点 说明 名称 结果 重要步骤 议题 参与者的特性表----简单的列出团队成员对参与者的认知，在讨论中比较容易达成共识。 参与者问题表----把跟参与者有关的问题列出来，方便帮助寻找参与者。 参与者的种类表----把参与者细分成数个种类，方便帮助寻找参与者，以及用来记录整个项目会遇到的参与者。 系统简述----用三言两语简单描述一下系统，同时也可以把想到的重点都记录下来。 用例的问表----把跟用例有关的问题列出来，方便帮助寻找用例。 用例要点表----简单记录用例的结果、重要流程和议题，日后撰写用例叙述时这些可以参考。 活动图----可以绘制简单的活动图表达流程，有助于寻找用例。  用例叙述最简版 用例：名称 事件流程： 1.起点 2.…… 3.终点 替代流程的问题表 1.在这个步骤中是否还有其它替找的操作？ 2.在这个流程步骤中是否会发生什么错误？ 3.在整个用例执行过程中是否随时可能发生其它未记录在叙述中的操作？ 4.参与者输入数据时，是否会提供不完整的数据，需要重新补上的数据？ 5.是否会出现错误的数据，需要特别处理的数据？ 6.参与者是否会会操作其间，临时中断流程？ 7.参与者是否会在用例执行期间随时取消交互？ 8.参与者是否会想要挑选其他执行方法？ 9.参与者在流程执行过程中，会不会有需要协助的地方？ 10.系统宕机时，是否需要特殊的处理？ 11.系统响应的时间过长时，是否需要特殊的响应方法？ 替代流程的分类表 替换流程： 替找1：不完整的数据 替找2：错误的数据 替代3：取消或中断的操作 替代4：其他执行方法 替代5：需要协助 替代6：系统宕机时或无响应 用例叙述最简版----再怎么复杂的叙述，抽丝剥茧后，到少都会留下用例的名称、点和终点。 替代流程的问题表----针对主要流程中的每一个步骤，都可以问问这些问题，对编写替代流程很有帮助。 替代流程分类表----编写替代流程的时候，可以直接按照这几类的替代流程来编写。 包含关系要点表----不一定所有的可以共享的流程都要独立出来，记得参考包含关系要点表 扩展关系要点表----谨慎的使用扩展关系，让扩展关系要点表提醒我们不要滥用关系。 包含关系要点表 1.需要共享的相同的流程，才能够独立出来。 2.暂存数据或者存取数据库的操作，不要轻易独立出来。 3.如果只是一两句相同的流程叙述，不要大费同章的独立出来。 扩展关系要点表 1.谨慎的使用扩展关系，避免因为滥用扩展关系，而让用例图变得很难理解。 2.扩展关系通常用于系统上线之后的改版