首先让我们定义一下经常在项目中用到的术语。系统是指你打算开发的任何事物,他可能是软件、硬件或者过程;项目是指为了建立一个系统而做的所有事情,包括指定计划、安排进度以及归档等。
在项目描述以及风险分析后我们需要做的是确定系统边界,那么如何才能确定系统边界?
系统边界通俗点来说就是将项目分割成系统内的和系统外的,系统内的在以后的项目进展中我们必须为创建他们而投入大量的精力,系统外的我们不需要创建,但是需要我们考虑与他们的接口。若要将系统外的事物进行划分,那么系统外部大致可以分为我们产品将要面对的使用者(人),以及为外部别的系统提供的服务(其他的软件),数据存储,硬件设备,以及网络等等,这些都是不需要我们去创建的,但是我们必须考虑到他们甚至以他们为中心来分析我们的系统内部该做些什么。
通常我们将系统外部与系统内部交互的的事物统称为执行者,执行者是同系统交互的所有事物,执行者总是在我的系统之外,从来就不是我的系统的一部分,每一个执行者都对应一种特定的角色,每一个系统之外的实体对应多种执行者,就好比一个人在系统中他会有多种角色一样,又或者几个人可以用一个执行者来表示,因为他们对于系统来讲属于同一个的角色。
如何寻找系统的执行者?只要能回答一下几个问题,我想系统的执行者大体上也就找到差不多了。
谁使用这个系统?
谁安装系统?
谁启动系统?
谁维护系统?
谁关闭系统?
哪些其他的系统使用这个系统?
谁从这个系统获取信息?
谁为这个系统提供信息?
是否有事情自动在预计的时间发生?
举一个较为通用的例子,对于一个网站来说,他的执行者主要有一下几个
如果这个网站会对外提供RSS订阅的动能,那他的执行者还包括RSS订阅的软件。
在确定了系统外部的执行者后我们要做的当然就是确定系统的内部了,看来如何确定系统内部又是一个麻烦的问题,还好我们已经确定了系统的执行者,顺着执行者这个藤想要摸到瓜应该是不难了。
每个执行者在使用系统的过程中总是希望系统能够为他做点什么,不然这个系统也就不在有用,执行者使用系统想要做的事情我们就称之为用例,用例描述了执行者想要完成的一些事情,同时也会为执行者产生一个结果。站在执行者的角度来看用例,用例应该是执行者想要完成的一个完整的独立的任务
上图似乎是已经列出了所有的用例,其实有很多一部分没有列出来,
执行者希望系统提供什么样的功能?
系统存储信息吗?
执行者将要创建,读取,更新或删除什么信息?
系统是否需要把自身内部状态的变化通知执行者?
系统必须知道哪些外部的事件?执行者将怎样通知系 统这些事件?
其他需要考虑的用例包括:启动,关闭,诊断,安装,培训,改变商业过程以及维护系统。
面对上面的这些问题,我们发现还有很多用例没有关注到,同时也发现很多用例房在一起看起来是比较乱的,我们也可以将用例单独的列出来,同时对用例进行梳理去除冗余的用例,在重新思考后注册会员对应的用例图如下:
在有了用例后,我们还要做的一件事就是详细的描述每一个执行者,以及每个用例是用来做什么事情的。
有时我们会遇到系统自动执行一个活动的事情,比如每天深夜系统对数据库进行维护优化,那么他的执行者是谁?
第一种方法是把时间当成执行者,每天深夜到达规定的事件就会执行该用例;
第二种方法就是将它当成系统的一部分,但是每次执行后他都会发出一个通知将结果发送给系统维护人员;
另外将这两种方法结合起来也是可以的
在确定执行者和用例时发现新的需求怎么办?
当发现新的需求时应该考虑的一些问题:
这些需求对系统是否是必须的?
这些需求是系统在逻辑上会完成的吗?
新的需求将如何影响我们目前的风险分析?
这些需求是否可以被系统目前的执行者处理?换句话说是否有别人对这些需求负责?
这些需求是系统希望客户去做的吗?
这些需求会使产品在市场上变得与众不同吗?
在确定好系统的执行者,用例后我们也就完成了系统边界的确定,接下来我们需要做的就是确定项目的范围,清晰的定义项目的范围,将不需要做的事情放到一边,同时为需要做的划分优先级对于那些系统的基础部分可以给他最高的优先级。应该在系统较晚的阶段考虑那些很好但是不是必须的需求,或者移到系统的后期版本考虑。
最后让我们在来回答一下这些问题:
是否所有的系统需求都被用例代表了?如果不是验证这些需求是在你的系统之内,并且无法被执行者看到,这
种需求不在用例图中出现。
是否所有的用例和执行者都有描述名称?对那些需要以后解释的事物是否有简短的描述?
系统边界和项目范围是否被清晰的定义了?如果不是,他会成为系统的主要风险,要尽早解决这一问题,如果无法回答,那就做一个决定并把它作为一个假设记录下来。
是否所有的未确定部分都在假设列表之内了?
回顾并更新项目描述、风险、假设等等,看看在定义系统吧边界的过程中我们又得到了什么。
分享到:
相关推荐
用例分析技术
总结来说,编写有效的用例是一个系统化的过程,它要求编写者深入理解业务背景,清晰定义系统边界,详细描述用户目标和交互场景,并且注重沟通和文档的维护。通过运用上述知识点,用例的编写将成为软件工程项目成功的...
- 包括典型取值的输入,多模块组合,多功能处理,以及操作确认等不同场景的用例。 通过遵循这些规范,测试人员能够构建出一套完整且有效的测试用例集合,确保软件在各种情况下都能表现出预期的行为,从而降低缺陷...
4. 测试用例设计方法:包括等价类划分、边界值分析、状态迁移等方法。 测试用例编写步骤详解 测试用例编写步骤是测试用例编写的核心步骤。以下是测试用例编写步骤的详细解释: 步骤一:需求分析 * 输入:业务...
《用例分析技术2E》是一本深入探讨UML(统一建模语言)中的用例分析技术的专业书籍。UML是一种广泛使用的系统建模语言,它为软件开发提供了图形化的表示方式,帮助开发者清晰地表达系统的需求、设计和实现。在软件...
用例分析是一种重要的面向对象系统建模方法,其核心在于通过描述系统与外部实体(执行者)之间的交互来明确系统边界、功能需求及行为特征。用例不仅能够帮助开发者理解系统的核心功能,还能够为后续的设计、实现、...
编写有效用例(中文版)-Writing Effective Use Cases part2
UML建模用例-家谱管理系统-11软件1班
2. **识别用例**:通过观察参与者与系统的交互,确定系统的主要功能。 3. **细化用例**:编写用例描述,包括主成功场景和可能的扩展场景。 4. **绘制用例图**:用图形方式表示参与者和用例之间的关系,帮助理解...
在软件测试过程中,测试用例的设计与管理是关键步骤之一,它确保了产品功能的全面性和质量的可靠性。本文将详细介绍如何在TestDirector (TD) 中进行自定义用例描述和导入,以及如何添加优先级列。 首先,我们来探讨...
海航集团BI接口系统系统测试用例文档_v1.0----下载不扣分,回帖加1分,童叟无欺,欢迎下载。
《用例分析技术》PPT课件是针对软件工程领域中用例分析的重要教程,它旨在帮助学习者理解和掌握如何有效地进行用例分析,以便在实际项目中编写出清晰、全面的软件需求文档。这份资料涵盖了用例分析技术的概述、实际...
这些种类包括常规的测试用例、初始化的测试用例、边界的测试用例、空值的测试用例、格式错误的测试用例、溢出的测试用例、关联的测试用例、唯一值的测试用例、权限不足的测试用例、角色权限的测试用例等。...
用例分析技术是软件开发中一种重要的需求捕获和建模方法,主要用于理解和描述系统与用户之间的交互行为。在银行自动取款机(ATM)的例子中,用例分析技术帮助我们清晰地定义了系统的主要功能,如取款、查询余额和...
现在RUP如日中天,需求分析是第一步,可以看作是高级系统分析员的必备知识,那么,如果用面向对象的分析技术来描述需求呢?你还在为怎么建模而烦吗?你还不知道如果开始您的系统用例分析吗?那么强烈建议您看看这本...
编写有效用例(中文版)-Writing Effective Use Cases part10
编写有效用例(中文版)-Writing Effective Use Cases part4
编写有效用例(中文版)-Writing Effective Use Cases part11
编写有效用例(中文版)-Writing Effective Use Cases part12
编写有效用例(中文版)-Writing Effective Use Cases part9