- 1、本文档共6页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
任务Task用例UseCase用户故事UserStory场景Scenario
任务Task、用例UseCase、用户故事UserStory、场景Scenario与任务类似的概念有:用例、用户故事、场景等。在本小节,我们会对其作详细的澄清。任务Task任务,来自“目标导向的活动模型”,即:目标-任务-工具,它所描述的是人们为了到达某种目标而采取的行动。用户所采取的行动有大有小、有粗有细,其粒度是与“目标”的层次相对应的。设计软件时,我们需要考虑海平面及更高的任务目标。任务是对用户为了达到某种目标所采取的行动的统称,它既可以是海平面级的任务,也可以是风筝层、云彩层的任务。海平面级的任务是最小粒度的任务,游鱼层、蛤贝层的用户“行动”一般对应执行任务时所采取的“步骤”,它们都没有业务价值。因此,我们可以讲任务定义为“有业务价值的”用户行动。由于海平面级的任务有着最小的业务价值,所以,我们以后提到“任务”一词时通常都特指“海平面级的任务”,对应“用户级别的目标”。用例UseCase“用例是代表系统中各涉众之间就系统的行为所达成的契约。用例描述了在不同条件下,系统对某一涉众的请求所做出的响应。提出请求的涉众被称为主执行者(primary actor)。主执行者通过发起与系统的一次交互来实现某个目标。系统对任一执行者所做出的响应,要保证所有涉众的利益不受侵犯。根据执行者做出的请求和请求涉及的条件,系统将执行不同的行为序列,每一行为序列称之为一个场景(Scenario)。一个用例是多个不同场景的集合。”以上是Alistair Cockburn在《编写有效用例》中对“用例”的一段描述。在我看来,用例更像是一种文学体裁,一种与小说、诗歌、散文等并列的文学体裁。用例这种体裁很适合用来描述业务过程、软件需求以及人机交互过程。也就是说,我们写用例的目的,就是要对业务过程、软件需求、人机交互过程等进行详细准确的描述,以便让涉众就软件系统的行为达成一致。而用例,正是能清晰地记录涉众所达成的一致意见的最佳表达形式,所以,用例不仅仅是一种“契约”,它也正是记录涉众就系统行为所达成的一致意见的“最佳体裁”。正如任务会有不同的层级(云彩层、风筝层、海平面层),用例也可以描述不同层次的内容。因为用例只是一种“体裁”,所以它的内容可以非常广泛:业务过程、软件需求、人机交互过程。我们在“任务建模”阶段,主要用用例来描述人机交互过程,并且,多数情况下是用来描述“用户目标级”的任务的。用例也会包含这两种情况:1)只描述用户执行任务的步骤;2)既描述用户执行任务的步骤又描述系统的反馈,此时的用例反映整体的人机交互过程。在此给出用例的模板,供大家参考。用户故事UserStory在介绍“敏捷软件开发生命周期:产品–版本计划–迭代–用户故事”时,我们已经对“用户故事”有过介绍:用户故事是最基本的设计单元。用户故事就是以用户的语言对产品功能(feature)所作的描述。关于用户故事,应注意以下几点:每个用户故事,只描述一个功能(feature)用户故事,用的是用户的语言,体现了“以用户为中心”的思想用户故事是产品设计的上下文背景用户故事,是用来做出开发计划的,每个用户故事的开发周期不要太长,建议不超过1周或10天(属经验性估计,仅供参考,您别跟我较真,别问我为什么不是1周零一天或11天等等…….。一个用户故事是最小的开发单元,所以开发一个用户故事的时长最好是您能掌控的最小开发周期,所以给出了1周或10天的建议。)接上一点。“能掌控”,就意味着每个用户故事都可以在“事前”被准确地估量出来,“事后”被准确地衡量。用户故事由3部分组成:用户(user)、任务(task)以及用户执行该任务所要达到的目标(goal)。通常的格式如下:作为[某种类型的用户]我想[执行某某任务]这样,我就能[达成某某目标]例如:作为“直奔主题”的购物者我想在店内找到CD的位置这样,我就能快速买下它,然后马上离开;我好继续回到自己的生活轨迹中,爱干嘛干嘛了。“用户故事”这一概念是在敏捷开发过程中为了控制项目的迭代进度而采用的。用户故事是最小的设计单元,它只包含一个功能点,可以被任意地分配给任何一个开发人员来实现。用户故事中所包含的功能点,可能只对应用例/任务中某一步骤中所涉及的某一个具体操作,User Story通常会比Use Case小。但是,为了在开发人员在实现该功能时,能够贯彻UCD思想,体现用户目标,所以我们会在描述该功能的时候提及用户的“目标”和“任务”,当然,也会说明该功能所要面对的用户是什么样子的。这样,就有了用户故事“作为[××用户],我需要[××功能]支持我完成[××任务],这样,我就能达成[××目标]”。Alistair Cockburn曾对User Story、Use Case、Scenario作过区分:A user story is the title of one
文档评论(0)