事件驱动用例用例导出需求—

需求开发也是有套路的，而且还不只一种。通过《掌握需求过程》一书，我发现了下面这样的套路：由事件驱动用例，由用例导出需求。

它由以下几个步骤组成：

软件是为了帮助用户更好地完成工作的，所以要开发用户需求，就要先了解清楚用户的工作。而要了解用户的工作，首先就要建立工作范围。

工作的范围必须包括预期的参与者和他要做的工作，也包括工作的相邻系统。

建立工作范围，通常的成果就是上下文范围图。在图中以用户的工作核心，画出工作的相邻系统，并给出相邻系统与工作之间的数据流及其流向。通过这种方式，对工作的范围作出了界定。

在建立了工作范围的基础之上，就可以分析影响工作的业务事件。对于业务事件的描述可以使用列表的形式，如：

业务事件名称	业务事件描述
建立项目	点击“新建项目”菜单命令，在弹出的界面中填写项目名称，项目负责人，项目类型等信息，并提交

业务事件的响应有以下两种方式：数据流触发，或者时间流逝触发。前者，如“显示导入的数据”事件，就是由“导入数据”事件触发的；后者，比如设置了一些定期发生的事件，“定期备份数据”事件。

研究对业务事件的响应，不仅要给出每个事件的响应方式，还要考虑产品的目标，上下文范围，相邻系统，边界，外部影响等因素，综合考虑之后，再来确定对工作来说最佳的响应方式。

用例是工作的一部分，由产品完成的那部分响应就是用例。用例正是从业务事件中推出的，是产品的一组动作序列，这些动作序列都是发生在某个场景之中。换句话说，用例可以是一个或一组场景，描述场景下的一系列行为。用例的大小，就要看用例包含了多少动作序列。

确定了大小合适的用例后，还要将其与参与者联系起来。因为这些动作都是由参与者来触发的，所以需要理清楚参与者和用例之间的关系。一般我们使用用例图来表述参与者、用例以及它们之间的关系。用例图可以使用UML工具来生成。这样的用例图就是描述软件的功能需求的视图。换言之，软件的需求已经被导出。

通过上述步骤，我们从了解工作的范围，识别业务事件，确定产品的响应，确定产品的用例，最终导出软件的需求。这样的开发用户需求的套路，是基于对用户工作场景的了解，能够发现用户真正想要的功能需求，所以，使用这个套路开发需求，可以在一定程度上提高用户满意度。

微信号：IdeaofSE

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。