Use Case(用例)和User Story(用户故事)他们之间究竟有什么联系和区别,还是他们本身就是一个物种的两种不同叫法而已,究竟哪个好或是哪个不好,这些问题的讨论见诸于各大网络文章之中,其实本人当初也有所迷惑,经过大量翻阅各种资料对比分析,算是有所斩获,下面就我所了解认识到的东西做一个分析,不对之处欢迎拍砖。
要了解二者异同,首先来看各自的概念:
Use Case(用例) :在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。
User Story(用户故事):描述对软件(或系统)用户或客户有价值的功能,只是需求描述,而
不是详细的需求规范。.
从定义上其实可以看出来,
Use Case是UML中一个重要的概念,他采用actor和系统交互的方式来描述用户需求,使用了一套逻辑上相对完整的事件流来定义,他包括了名称、描述、主要事件流、扩展流、异常流、前置条件和后置条件等等元素,可见他描述需求是相当详细的,在RUP过程中使用得比较多。User Story描述用户需求则是离客户更近一步,他所使用的描述语言类似于“作为XXXX,我希望xxxxxx”这种方式,例如,作为用户,我希望能够查看订单列表,简单的描述用户需要的东西。而没有定义如何交互等事件流方式,这种需求描述形式是比较抽象的,使用User Story在敏捷项目中使用比较多,当然Use Case 也适合敏捷项目。
因此可以看出,这里并不存在两种方法孰好孰坏的差别,而是说在不同的场景中使用合适的需求描述方式,Use Story更适合比较早期的探索需求阶段,因为他
表述起来非常的简单,一个
User Story
只需要几句话就可以完成,
另外一个因素就是
用户需求的细节是非常易变的,而其高层描述却是相对稳定的
,
所以我们可以通过使用
User Story
的方法来从高层确定其需求(包括功能性的和非功能性的),这些单独的Use Story相当于系统中可能要实现的一点,而由我们通过与用户交流所得到的所有
User Story
则构成了一个面,它就是整个系统所需要实现的功能,举个例子,
“作为用户,我希望能够查看订单列表”,非常简洁,但是阐述清楚了谁需要什么的需求;而Use Case更适合于需求分析阶段,因为该阶段需要比较详细的、更系统的需求分析,而Use
Case能够满足这一切,不过,由于这里需求进行了具体化处理,因此用户可能在变换交互方式的时候,那么对于User Story来讲不会变的东西,而对于Use Case来讲可能就会有所有变更。
最后说一句,合适当前场景的选择才是最好的选择,不要拘泥于这其中的死条款不放才能取得最好的效果。
分享到:
相关推荐
常用的需求分析方法包括Use Case、User Story等。 购物网站设计和实现计算机网络需要考虑到计算机网络的设计、实现和配置、ASP脚本语言、数据库设计、网站设计和需求分析等多个方面。只有通过系统的设计和实现,...
1. 需求工程:这部分可能考察如何有效地收集和分析用户需求,理解BRD(业务需求文档)、SRS(软件需求规格书)的重要性,以及如何用Use Case或User Story来描述需求。 2. 设计阶段:设计模式和架构选择可能是重点,...
标签为空,部分内容只显示了"Uc-1:Uc-2:-+",这看起来像是某种用户故事(User Story)或用例(Use Case)的编号系统,但没有足够的上下文来详细解释相关的IT概念或技术知识。 通常,"UC"在软件开发中代表"Use Case...
UseCase一直是一种针对业务和系统需求都有效...在google上搜索“usecase”的结果是搜索“UserStory”的结果的六倍,但软件开发不是靠名望来驱动的。反之,我们应该使用最有效的工作方式,一种允许我们持续改进的方法。
其中,用例驱动(Use case)、用户故事(User Story)和特征驱动(Feature)是最具影响力的方式。 用例驱动是Rational统一过程(RUP)的核心,它通过用例来描绘系统外在可见的行为,作为各利益相关者间关于系统行为...
常见的功能描述方法包括Use Case、User Story、Wireframe等。 8. 界面描述规则 界面描述规则是指在软件需求规格说明书中对软件系统的界面描述规则。常见的界面描述规则包括界面布局、颜色、字体、图片等。 9. ...
同时,由于敏捷测试的迭代特性,测试用例库往往被在线管理,测试人员需要根据Use Case或User Story来设计测试,而不是像传统测试那样依赖于详细的测试用例。 敏捷测试的挑战在于需要测试人员具有快速响应变化的能力...
用例(UseCase)是系统与涉众之间关于行为的契约,描述了在不同条件下,系统对涉众请求的响应。主执行者是发起交互的涉众,用例由一系列场景(Scenario)组成,每个场景代表系统的一种行为序列。用例不仅是一种契约,也...
Chapter 21: Inheritance case study: “undo” in an interactive system 695 21.1 PERSEVERARE DIABOLICUM 695 21.2 FINDING THE ABSTRACTIONS 699 21.3 MULTI-LEVEL UNDO-REDO 704 21.4 IMPLEMENTATION ASPECTS ...