建立用例模型应当注意的问题

本文探讨了在建立用例模型时常见的问题和原则。首先,通过与客户沟通和理解功能来发现用例,逐步细化并调整系统边界。其次,介绍了有效用例的评判标准,如老板测试、EBP测试和规模测试。用例模型的重点在于文字描述而非图形,以黑盒方式和参与者视角编写,避免描述用户界面,并采用迭代方式构建。用例分析是一个与客户反复沟通和确认需求的过程。
摘要由CSDN通过智能技术生成

        给大家几个建立用例模型中常出现的问题和应对遵循的原则:

  一.如何发现用例

  经过以上的讲解,相信大家对建立用例模型有了一个整体的概念,然后开始着手练习绘制用例模型。这时候,一个非常严峻的问题出现了:如何发现用例。大师曾经给出了答案,大致意思就是:首先选择系统边界,然后确定主要参与者,定义满足用户目标的用例,为其命名。然而,我在实践中证明,这套方法过于理论,并不实用。也许,我们换一种思路会更加符合实际。
  当我们开始一个项目的需求分析时,肯定是去听客户谈他们的需求,或者看客户提交的业务需求文档。这其中,客户一定会提出一个又一个的功能或要求,他们中的每一个就成为了我们最初的用例。分析这些用例,关注它们每一个的参与者,以及它们相互之间的关系,这就形成了最初的用例模型。这里特别应当提醒大家的是,我们采用用例分析的方式与客户沟通需求的时候,我们应当着重关注的是参与者及其目标,即每个功能的参与者是谁,完成这个功能的目标是什么,以及如何完成这个目标。这时的用例说明采用概述的方式,即只进行主成功场景(基本流程)的描述。
  此后,我们继续与客户沟通,一方面,继续细化以后的用例,各个用例的替代场景(分支流程)逐渐被整理出来,用例在一步步细化。同时,我们对一些需求的认识一开始可能存在着偏差,因此我们还不断在更正我们的用例描述。另一方面,一些新的功能被用户提出来,形成一些新的用例。
  如此反复数轮之后,项目需求的整体框架逐渐清晰,这时候我们开始讨论系统边界。这是

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值