怎样做需求分析之十二：分析之子用例和扩展用例
高效的软件需求分析方法与工具
高效的软件需求分析方法与工具在软件开发中，需求分析是开发工作中的第一步，也是一项非常重要的任务。
正确的需求分析是软件开发的关键，因为它直接决定了软件开发的方向和结果。
在开发过程中，有很多方法和工具可以帮助人们更高效地完成需求分析工作。
下面将介绍一些高效的软件需求分析方法与工具。
一、用户故事法用户故事是一种人性化的需求分析方法。
它从用户的角度出发，通过设计故事的情节和细节，来描述用户的需求。
用户故事通常是以简短的语句形式来表达的，比如：“作为一位购物者，我想要能够添加商品到我的购物车中，以便能够方便地结账。
”使用用户故事来完成需求分析的好处在于，它可以让开发人员更好地理解用户的需求，同时也可以减少过度设计。
在用户故事的描述中，开发人员不需要考虑那些不必要的细节和实现方式，这使得整个过程更加简洁、高效。
二、面向对象方法面向对象方法是一种广泛应用的软件开发方法，它的基本思想是将用户需求看做一个对象，并通过设计类之间的关系来实现对应的功能。
在面向对象方法中，开发人员把系统的功能看做一系列的对象，这些对象之间通过消息传递来协调执行任务。
使用面向对象方法来完成需求分析的好处在于，它可以大大提高系统的可重用性。
当系统中需要新增一些功能时，只需要对应配置新的类和方法即可，这种方式即可支持高效的变更管理，又能保证开发的一致性和可维护性。
三、用例分析法用例分析法是一种比较常用的需求分析方法。
它的基本思想是从用户的角度出发，建立一个完整的使用场景，通过模拟场景来深入理解用户的需求。
在用例分析中，我们需要考虑各种场景的变化，来设计出符合用户体验的功能模块。
使用用例分析法来完成需求分析的好处在于，它可以让开发人员更好地理解系统的边界和需求的复杂性。
这种方法可以通过模拟场景的方式来帮助开发人员更好地理解用户的需求，从而提高开发效率和减少开发时间。
四、原型工具原型工具是一种通过模拟显示真实用户界面的工具，它可以让开发人员更好地理解用户需求，并提高软件开发效率。
UML用例图的扩展点与扩展用例讲解
UML用例图的扩展点与扩展用例讲解UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形化符号和规范，用于描述软件系统的结构、行为和交互。
其中，用例图是一种常用的建模工具，用于描述系统的功能需求和用户与系统之间的交互。
在用例图中，用例代表了系统的功能需求，用例之间的关系可以通过关联、包含和扩展等方式进行表示。
本文将重点讲解扩展点与扩展用例的概念及其在用例图中的应用。
一、扩展点的概念扩展点是指在原有用例的执行过程中，可以插入额外的功能或行为的特定位置。
它是用来定义系统在某个阶段或条件下是否可以执行扩展用例的标记点。
扩展点通常与原有用例的某个步骤或事件相关联。
扩展点的标记方式通常是在用例图中使用带有箭头的虚线表示，并在箭头上标注扩展用例的名称。
这样，当系统执行到该扩展点时，就可以根据特定的条件选择是否执行扩展用例。
二、扩展用例的概念扩展用例是指在特定的条件下，根据系统的需要，可以选择性地执行的用例。
它通常是对原有用例的功能进行扩展或增强，以满足某些特殊的需求。
扩展用例与原有用例之间的关系可以通过扩展关系来表示。
在用例图中，使用带有箭头的实线表示扩展关系，箭头指向扩展用例，并在箭头上标注扩展点的名称。
三、扩展点与扩展用例的应用扩展点与扩展用例的应用可以帮助系统设计者更好地理解系统的需求，并对系统进行更加灵活的设计。
通过定义扩展点和扩展用例，可以将系统的功能细化，并且在需要的时候选择性地引入额外的功能。
例如，假设我们正在设计一个电子商务系统，其中包含了一个购物车功能。
在购物车中，用户可以添加商品、修改数量、删除商品等操作。
我们可以将购物车的添加商品操作定义为一个扩展点，当用户添加商品时，系统可以根据特定的条件选择是否执行扩展用例。
在这个例子中，我们可以定义一个扩展用例为“优惠券使用”，当用户添加商品到购物车时，系统可以检查用户是否拥有可用的优惠券，并根据优惠券的规则进行相应的折扣计算。
软件需求说明书编写中的用例分析与设计
软件需求说明书编写中的用例分析与设计软件需求说明书是软件开发过程中必不可少的一部分，它描述了软件的功能需求、性能需求、安全需求等。
而用例分析与设计则是软件需求说明书中的重要内容之一，它有助于更好地理解用户需求、识别系统功能以及构建有效的软件系统。
一、用例分析在软件需求说明书编写过程中，用例分析是首要的一步。
用例是对系统功能和行为的描述，它通常以场景的方式来呈现，旨在揭示系统的功能逻辑和用户与系统的交互。
以下是用例分析的具体步骤：1. 确定参与者：确定所有涉及到系统的参与者，包括主要用户、管理员、外部系统等。
2. 辨识用例：通过与用户沟通、研究用户需求文档等方式，辨识出系统中的所有用例。
3. 描述用例：对每个用例进行详细描述，包括用例名称、主要参与者、前置条件、后置条件、基本流程、备选流程等。
4. 识别用例间的关系：审视用例并找出它们之间的关系，如主要参与者、调用关系、扩展关系等。
5. 确认用例的粒度：根据具体场景需求，适当划分用例的粒度，不要过于细致或者过于宏观。
二、用例设计用例设计是用例分析的补充，它更加侧重于用例的实现细节和系统的架构设计。
以下是用例设计的具体步骤：1. 识别用例的类别：根据用例的功能和行为特点，将用例分为基本用例、扩展用例和特殊用例。
2. 设计用例的输入/输出：确定每个用例的输入参数和输出结果，保证用例的完整性和准确性。
3. 定义用例的执行条件：明确每个用例执行的前置条件和后置条件，以确保用例的可控性和可重复性。
4. 划分用例的步骤和动作：将每个用例进一步拆分为多个步骤和动作，以便更好地描述用例的执行过程和用户操作。
5. 设计用例的界面：根据需求和功能，设计用户界面，包括布局、控件、交互等，确保用户友好和易用性。
6. 确定用例的数据：确定用例所需的数据表、字段、格式等，以支持用例的数据操作和数据流动。
三、用例分析与设计的好处用例分析与设计在软件需求说明书编写中起到了至关重要的作用，具有以下好处：1. 明确系统功能：通过用例分析，可以清晰地描述系统功能和用户行为，帮助开发人员更好地理解用户需求。
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：用例说明当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。
过去，在面向过程的时代，我们绘制DFD图、流程图，以及编写流程说明来描绘这一部分分析；而现在，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作在这部分工作中，编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。
现在我们来看看用例说明应当怎样编写。
毫不疑问，做用例分析首先是要绘制出用例图（前面已经说过了）。
图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。
由于不同的人对用例的理解不同，格式也不尽相同，但一些基本的元素是一样的。
以上表格是我采用的用例说明格式，其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明的基本元素。
用例标识：就是用例的编号，一般采用“项目编号-子系统编号-模块编号-序号”来编号。
用例名称：没啥可说的，就是用例图中该用例的名称。
注意用例的命名规则：用例名称通常是一个动词短语或短句，而不是一个名词短语。
它可以是一个动词（如：自动考核），一个动宾短语（如：提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款，这个不推荐，因为主语就是参与者，显得有些多余）。
用例类型：在我看来，不同类型的用例，其用例说明的格式是不一样的。
以上给出的是“业务操作”类用例的格式，它更加着重地在描述业务操作的流程。
而“查询报表”类用例则没有什么流程，它更加着重地在描述报表格式及显示内容（后面再给出）。
还有用例类型还包括“子用例”、“扩展用例”。
用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。
同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。
通过用例描述，阅读者可以对该用例有一个整体的认识。
用例间的关联(泛化-包含-扩展)
➢A extend B 表示B是A在系统某些情况下（特定条件）触发产 生的，B不是A中必须存在的部分，B可以单独存在 ➢B是对A在一些基本功能上具体的扩展（在A的扩展点处）
9
用例间的关系
➢Include 包含关系通常发生在多个用例中，有可以提取出来 的公共部分（就象提取公因式一样） ➢例如 UseCaseA 中包括了 a 和 b 两个流程，而 UseCaseC 中 包含了 c 和 b 两个流程。为了提高复用性，可以把 b 提取出来， 形成另一个用例 UseCaseB，此时，UseCaseA include UseCaseB，UseCaseC 也 include UseCaseB。 ➢当有 include 关系时，被 include 的用例通常会被两个以上的 其他用例 include（否则就不需要提取出来了）
10
用例间的关系
➢Extend 关系：假设 UseCaseA 的功能描述为“发送一条通 知”，可是，发送通知的方式可能有许多种（例如通过邮件发 送、通过短信发送等）。在需求分析阶段，可能无法明确到底 有多少种方式， 在用例分析阶段，UseCaseA 需要留出扩展接 口，然后把已知的发送方式作为扩展用例给出，例如 UseCaseB 是“通过短信发送”，而 UseCaseC 是“通过邮件 发送”，此时，UseCaseB 和 UseCaseC extend 了 UseCaseA， 表现为两根虚线，箭头指向 UseCaseA
11
用例间的关系
12
用例间的关系
错！
13
用例间的关系
➢销户：因为销户必需先进行账户结算，所以这里用include ➢停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend
需求分析用例范文
需求分析用例范文用例是一种需求分析工具，用于描述系统如何与各种类型的用户（称为参与者）交互以实现特定的目标。
以下是一个需求分析用例的示例，对于一个在线购物网站：用例名称：用户购买商品主要参与者：用户、网站管理员目标：用户能够浏览和购买在线商城中的商品前提条件：用户必须具有有效的账户，并且已经登录到网站成功情况：用户成功选择并购买所需的商品主要流程：1.用户登录到网站，并使用功能浏览商品目录。
2.用户在结果中选择感兴趣的商品。
3.用户查看商品详细信息，包括价格、描述和评价等。
4.用户决定购买该商品，并将其添加到购物车中。
5.用户选择继续购物或者进行结账。
6.如果用户选择继续购物，则返回步骤27.如果用户选择结账，则显示订单确认页面。
8.用户确认订单，并选择支付方式。
9.如果用户选择在线支付，则跳转到支付平台进行支付。
扩展流程：-如果用户在结果页面中没有找到合适的商品，可以进行新的。
-如果用户在浏览商品详细信息时发现误导性的信息，可以向网站管理员举报。
-如果用户对购物车中的商品进行更改或删除，更新购物车并重新计算总价。
-如果用户选择货到付款或其他非在线支付方式，则不需要跳转到支付平台，而是将订单状态设置为待支付。
特殊要求：-网站应提供安全性保护措施，以保护用户的个人信息和支付信息。
-网站应提供订单跟踪功能，以便用户查看订单的状态和物流信息。
这个用例描述了用户购买商品的正常流程以及一些可能发生的异常情况。
它可以帮助开发团队和用户更好地理解交互过程，并指导系统的设计和实施。
除了这个用例，还可以创建其他用例来描述系统的其他功能，例如注册用户、查询订单等。
这有助于全面考虑系统的需求，并确保系统满足用户的期望和需求。
需求分析用例编写
需求分析⽤例编写⼀、需求分析？1.什么是需求软件产品必须完成的，以及必须具备的品质。
功能性需求：产品必须完成的那些事，要求⼀定的功能和品质。
例⼦：淘宝的⽤户名登录。
⾮功能性需求：产品必须具备的属性和品质。
诸如观感、可⽤性、安全性和法律限制等。
例⼦：平台⽤户数为5万⼈，每天登录⽤户数为10000左右，⽹络的宽带为100M宽带。
在⼯作时间根据资料名称条件进⾏搜索，可以在3秒内得到搜索结果。
⼀旦知道了产品要做的事情，就可以确定它的⾏为⽅式，它需要具备什么品质以及它的响应速度、可⽤性、可读性和安全性。
限制条件：是全局性的需求。
他们可以是对项⽬本⾝的限制，或是对产品最终设计的限制。
2.如何进⾏软件测试需求分析测试需求分析的主要⽬的：根据需求⽂档提取测试点（测试执⾏的要点）---我都是⽤测试点做⽤例标题，根据测试点来编写测试⽤例测试需求分析的步骤：1.熟悉需求背景及商业⽬标：a)了解清楚项⽬发起的原因，是为了解决⽤户的什么问题。
b)当前的解决⽅案是不是最优的，为什么会这样做？2.业务模型法：a）考虑本项⽬与外部系统的交互、划分系统边界（除了本项⽬的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。
b）确定测试范围和关注点。
系统的边界是测试的重点，特别需要关注边界交互时的数据交互。
3.业务场景法：a)考虑⽤例的调⽤者；考虑每⼀个⽤例提供的服务时供哪些外部⽤例或者时系统调⽤，找出所有的调⽤者。
调⽤的前提、约束都要考虑。
每⼀个调⽤都可以考虑成⼀个⼤的业务流程。
（⼀般和外部有交互的⽤例输出的概率⽐较⼤，需要重点关注）b)考虑系统内部各个⽤例之间的交互，形成内部业务流程图。
需求分析每个⽤例之间的约束关系、执⾏条件、组织出各种业务流程图。
4 、功能分解法a). 业务功能：与⽤户实际业务直接相关的功能或细节。
b). 辅助功能：辅助完成业务功能的⼀些功能或者是细节，⽐如，设置过滤条件。
如何进行有效的需求分析与设计
如何进行有效的需求分析与设计需求分析与设计是软件开发过程中至关重要的一步。
只有在充分了解用户需求的基础上，才能设计出满足用户期望的软件系统。
本文将介绍如何进行有效的需求分析与设计，并提供一些实用的方法和技巧。
一、需求分析1. 明确目标：在进行需求分析之前，首先要明确项目的目标。
明确目标有助于指导需求分析的方向，并避免过多的无效分析。
2. 收集需求：收集用户的需求是需求分析的关键步骤。
可以通过面对面的访谈、问卷调查、观察用户行为等方式收集用户需求。
3. 细化需求：将收集到的用户需求进行整理和归纳，确保每个需求都具备清晰的描述和明确的定义。
可以使用用例图、需求文档等工具来细化需求。
4. 优先级排序：根据用户需求的重要性和紧急程度，对需求进行优先级排序。
这有助于合理安排开发进度，并确保核心功能的优先实现。
5. 确定可行性：在需求分析的过程中，需要考虑技术可行性、资源可行性和经济可行性。
确保需求可行性有助于避免项目失败风险。
6. 验证需求：需求验证是需求分析的最后一步，通过与用户进行沟通和确认，确保需求的准确性和全面性。
可以通过原型演示、用户测试等方式进行需求验证。
二、设计阶段1. 系统设计：根据需求分析的结果，进行系统架构设计和模块划分。
确保系统的可扩展性和灵活性。
2. 数据库设计：根据需求确定的数据模型，设计数据库结构和表关系。
确保数据库的完整性和一致性。
3. 用户界面设计：根据用户需求和使用习惯，进行用户界面的设计。
界面设计要美观、简洁、易用。
4. 功能设计：根据需求分析的结果，设计软件系统的各个功能模块。
确保功能的完备性和高效性。
5. 安全设计：在设计阶段考虑系统的安全性和数据的保护措施。
确保系统能够有效地防范安全风险和威胁。
6. 完整性和一致性设计：在设计阶段考虑系统各个组件之间的完整性和一致性。
确保系统各部分能够协同工作，提供一致的用户体验。
三、需求分析与设计的技巧1. 多角度考虑：在需求分析与设计过程中，要从不同的角度考虑问题，充分理解用户需求。
需求分析与用例
一、需求分析与用例：需求:就是系统必须提供的能力和必须遵从的条件，包括:功能需求和非功能的需求(性能要求）。
需求分析：重要手段是确定和编写用例.用例:是文本形式的情节描述，用于需求的发现和记录.用例会影响后续的OOA/D 工作.参与者（Actor)：某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如收银员。
场景（Scenario):是参与者和系统（我们要开发的系统）之间的一系列特定的活动和交互。
包括主成功场景和交替场景(主成功场景表示正常功能…。
;交替场景是如果….）二、用例的目的与形式：用例编写的形式：需求分析早期使用，通常用于主场景(如“管理员向系统提交用户名和密码。
系统进行认证。
系统向管理员显示功能登录信息”）三、用例编写的格式：四、如何发现用例:1选择系统边界2确定主要参与者3确定每个主要参与者的目标4定义满足用户目标的用例，根据其目标对用例命名在真实项目中发现用例，遵循如下思维习惯:调研需求时最先弄清楚有多少部门，多少岗位（参与者）,然后找到每一个岗位的业务代表，问他们类似的问题:你平时都做什么？(参与者目标）这件事是谁交办的?做完了你需要通知或传达给认证吗?做这件事情你都需要填写些什么表格吗？五、用例关联及一些术语用例彼此之间可能具有联系，比如：处理信用卡支付用例可倾向于为处理销售、处理租金等常见用例的一部分.（1）关联在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联.它表示了一个执行者和一个用例之间的关系。
在用例图中,关联关系只用在执行者和用例之间,用例和用例之间不会存在关联关系。
关联关系采用的是单箭头的连线,表示在该关联中执行者是主动的，是执行者启动的用例。
如下图所示。
（2）包含包含是指一个用例作为另一个用例必需的部分被使用,包含关系是依赖关系的一种。
包含关系用一条连接二者带箭头的虚线表示,并在虚线的上面标注《include》，箭头方向由基本用例指向包含用例,如下图所示.包含的使用场合：如果多个用例有大量一致的功能，可以将这个功能分解到一个用例中，其他用例和这个用例建立包含关系。
软件测试中的需求和用例分析
软件测试中的需求和用例分析软件测试作为软件开发过程中不可或缺的环节，其核心目标之一就是验证软件的需求是否得到满足，并通过用例分析来确保软件的质量。
本文将对软件测试中的需求和用例分析进行详细探讨。
一、需求分析在软件测试过程中，需求分析起到了重要的作用。
需求分析是明确、理解和定义软件系统所应具备的功能和非功能性需求的过程。
只有对需求进行准确的分析，才能确保测试过程能够针对性地进行，并最终达到测试的目标。
在需求分析中，我们需要关注以下方面：1.1 功能性需求功能性需求指软件系统应具备的具体功能要求，例如用户登录、数据查询等。
在需求分析中，我们应该明确列出这些功能，并确保测试用例的编写能够覆盖到所有功能性需求。
1.2 非功能性需求非功能性需求指软件系统在使用过程中应该具备的性能、可靠性、安全性等方面的要求。
比如响应时间、系统稳定性等。
在测试过程中，我们需要针对这些非功能性需求进行相应的测试，并编写对应的用例。
1.3 隐含需求除了明确列出的功能性需求和非功能性需求之外，软件中还会存在一些隐含的需求。
这些需求在软件开发和测试中可能被忽略，但实际上对用户使用是非常重要的。
在需求分析中，我们需要通过与用户沟通、了解用户实际需求，尽可能多地挖掘隐含需求，并进行相应的测试和用例设计。
二、用例分析用例是一种描述系统行为的技术工具，用于明确系统应具备的功能和用户行为。
通过用例分析，可以帮助我们全面了解软件系统的功能需求和预期结果，并进一步进行相关的测试。
在用例分析中，我们需要注意以下几点：2.1 用例编写用例应该清晰、具体地描述用户的行为和系统的响应。
用例应包括前置条件、输入、输出和后置条件等要素，以确保测试过程中的准确性和完整性。
在编写用例时，我们应该充分考虑各种场景和边界条件，并根据实际需求进行详细的设计。
2.2 用例优先级在测试过程中，不同的用例具有不同的优先级。
有些用例对软件系统的关键功能进行验证，因而具有高优先级；而另一些用例则可能用于覆盖较为次要的功能，优先级较低。
实例讲解：如何一步步做好需求分析
实例讲解：如何一步步做好需求分析做为产品经理，口中说得最高频率的词就是“需求”，这也是产品人所必须掌握的能力。
在这个人人都说需求，谈痛点的互联网时代，作为产品经理的你，是否真的掌握了需求分析的方法和能力？我曾写过一篇文章，题为《经验总结：产品需求文档的编写四步法》，此文是我多年产品工作经历所总结出的一套快速有效的需求文档编写方法。
相比我写的其它话题文章，这篇文章发布后浏览量，收藏量都非常高，可此可见产品人对需求，对技巧，对实例分享都非常有兴趣。
为此，本文就再次围绕需求这个话题作出进一步分享。
在写需求文档之前，我们必须先进行需求分析，从用户需求到产品需求，再到产品功能，最后形成产品需求文档转入产品开发。
对于如何进行需求分析，知乎上各路大神们都写出了高深莫测指导理论，令人膜拜。
但这种高度理论化的内容，让人看完之后，仍然有一种无从下手的感觉。
因此，我准备用更直白的实例方式来分享一下我的需求分析经验。
一、尽可能地让自己成为用户不管你在做任何产品，如果想要做好它，都需要将自己代入相应的用户角色，从真实的使用者角度去思考问题。
我曾在一家车联网公司负责智能车机产品，当时我还没有拿到驾照，所以并没有驾驶经验。
虽然我对车联网非常感兴趣，但作为非车主，我对此并没有产品感，在做需求分析时，很难做出合理的判断和设计。
为了让自己成为车主，有产品感，我提前去买了辆车（半年后才拿到驾照），虽然没法上路，但至少有辆车让自己体验，甚至在小区的车库里转两圈也是没问题的。
在后来的一次产品需求评审会上，有位同样没有开过车的项目经理提出了一个问题，车机系统界面上为什么没有关机功能，一直开着多耗电？这个问题在熟悉汽车的人眼里会觉得可笑——因为车机是直接连通汽车电源的，而汽车只要点火后，发动机工作就可以为蓄电池充电，并不存耗完电的问题；而且汽车的部分控制操作是通过车机界面进行的，如果真关机了，就没办法操作了。
所以车机并不需要关机功能，最多也只是关闭屏幕。
软件需求分析中的用例模型
软件需求分析中的用例模型软件开发是现代科技的重要表现形式，而软件需求分析是软件开发的第一环节。
软件需求分析的主要任务是将用户需求转化为软件所需功能的详细规格说明，这些规格说明成为软件开发中的基准标准，同时也是软件测试的基础。
需求分析有很多方法，用例分析是常用的一种。
用例是针对某一特定场景下的系统行为、功能、性能等的具体描述，它从用户的角度出发，描述了用户与系统之间的交互过程。
本文主要介绍在软件需求分析过程中的用例模型。
一、用例的定义用例主要是用来描述软件的功能以及用户与软件的互动过程。
用例模型是一种面向对象的需求分析方法，它把用户使用系统的一组典型路径描述清楚，并通过文档的形式来呈现这些标准路径，让开发人员和客户都能够理解。
用例模型的主要作用在于记录与评审需求、澄清需求和确认需求。
二、用例模型构建过程用例模型的构建过程可以分为以下几个步骤：1、识别参与角色：用例模型最基本的概念就是参与角色，用户就是用例模型中的参与角色之一，系统管理员、客户或其他用户等也是用例模型的参与角色。
用例模型的构建需要准确地识别并区分参与角色。
2、确定用例：用例是由一系列的动作和反应组成的流程，需要通过观察用户与系统的交互，并记录下来，以便将来进行分析。
在用例构建过程中需要考虑应用场景、功能需求以及业务规则等因素。
3、撰写用例：用例的撰写需要遵循一定的规范，一般情况下用例会包括一个简要的描述、用例步骤和用例结束时需要达到的状态等信息。
撰写好的用例需要经过严格的问题验证与测试操作，以保证其描述的准确性。
三、用例模型的应用用例模型不仅可以用于需求分析，还可以用于测试与开发过程中，如下图所示：图1 用例模型在需求分析、测试与开发中的应用在需求分析中，用例模型可以协助开发人员更好地了解用户需求，并且设计满足用户需求的软件系统。
在开发过程中，通过回顾用例模型可以评估软件的质量和性能，找出潜在的问题并进行修正。
而在测试过程中，用例模型可以作为测试计划的一部分，并且可以作为测试人员在测试过程中的参考依据。
UML用例图中泛化、扩展、包括
UML⽤例图中泛化、扩展、包括在画⽤例图的时候，理清⽤例之间的关系是重点。
⽤例的关系有泛化(generalization)、扩展(extend)和包含(include)。
其中include和extend 最易混淆。
下⾯我们结合实例彻底理清三者的关系。
基本概念⽤例图（Use Case Diagram）:⽤例图显⽰谁是相关的⽤户，⽤户希望系统提供什么服务（⽤例），以及⽤例之间的关系图。
⽤例图主要的作⽤是获取需求、指导测试。
⽤例图的4个基本组件：参与者(Actor)、⽤例(Use Case)、关系(Relationship)和系统。
泛化(generalization)：泛化关系是⼀种继承关系，⼦⽤例将继承基⽤例的所有⾏为，关系和通信关系，也就是说在任何使⽤基⽤例的地⽅都可以⽤⼦⽤例来代替。
泛化关系在⽤例图中使⽤空⼼的箭头表⽰，箭头⽅向从⼦⽤例指向基⽤例。
扩展(extend)： extend关系是对基⽤例的扩展，基⽤例是⼀个完整的⽤例，即使没有⼦⽤例的参与，也可以完成⼀个完整的功能。
extend的基⽤例中将存在⼀个扩展点，只有当扩展点被激活时，⼦⽤例才会被执⾏。
extend关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<extend>>)，箭头从⼦⽤例指向基⽤例。
包含(include)： include为包含关系，当两个或多个⽤例中共⽤⼀组相同的动作，这时可以将这组相同的动作抽出来作为⼀个独⽴的⼦⽤例，供多个基⽤例所共享。
因为⼦⽤例被抽出，基⽤例并⾮⼀个完整的⽤例，所以include关系中的基⽤例必须和⼦⽤例⼀起使⽤才够完整，⼦⽤例也必然被执⾏。
include关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<include>>)，箭头从基⽤例指向⼦⽤例。
实例需求场景联通客户响应OSS。
系统有故障单、业务开通、资源核查、割接、业务重保、⽹络品质性能等功能模块。
用例扩展关系
1.1 指南：扩展关系主题∙解释 ∙执行扩展 ∙记录扩展关系 ∙ 使用示例1.1.1 解释扩展关系将扩展用例与基本用例连接了起来。
通过在基本用例中引用扩展点，可以定义在基本用例的哪些位置插入扩展用例（有关扩展点的讨论，请参见指南：用例）。
扩展用例通常是抽象的，但并不必须如此。
您可以出于以下几个目的使用扩展用例：∙表明用例的某一部分是可选（或可能可选）的系统行为。
这样，您就可以将模型中的可选行为和必选行为分开。
∙表明只在特定条件（有时是例外条件）下才执行分支流，如触发警报。
∙ 表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互。
扩展是有条件的，它是否执行取决于在执行基本用例时所发生的事件。
基本用例并不控制执行扩展的条件：这些条件在扩展关系中进行说明。
扩展用例可以访问和修改基本用例的属性。
但基本用例看不到扩展用例，也无法访问它们的属性。
扩展用例以隐含的方式修改基本用例。
也可以说，基本用例定义了可以在其中添加扩展用例的模块化框架，但基本用例看不见特定的扩展用例。
基本用例自身应是完整的，即基本用例应该是可理解且有意义的，而不必引用任何扩展用例。
但基本用例并不独立于扩展用例，因为如果无法遵循扩展用例，就不能执行基本用例。
示例：用例“召开电话会议”和“显示呼叫方身份”是基本用例“打电话”的两个扩展用例。
在电话系统中，为用户提供的主要服务通过用例“打电话”来表示。
可选服务的示例包括：∙能让第三方加入通话（召开电话会议）。
∙允许接收方看到呼叫方的身份（显示呼叫方身份）。
我们可以将这些可选服务所需的行为表示为基本用例“打电话”的扩展用例。
这是扩展关系的一种正确应用：由于“打电话”本身就具有意义，您无需阅读扩展用例的说明就可理解基本用例的主要目的，并且扩展用例具有可选字符。
如果基本用例和“基本加扩展”用例都必须是可以直接实例化的，或者如果您希望通过添加来修改基本用例中的行为，则应使用用例泛化关系（请参见指南：用例泛化关系）。
需求分析方法 调研方法、用例分析、类图分析
需求调研方法
需求调研方法横向比较： 现场观摩—最生动技术 利：百闻不如一见，能够对需求与业务流程建立直观的认识。 弊：消耗时间长，而且由于被观摩的微妙心理变化，会使得观摩失真。 适用性：对复杂流程的深入的理解时。 要点：悄悄地进行，明确要强化理解的具体流程。
构建可行性发现原型:主要目的是为了更好理解用户的需求。 原型是模型、样品的意思,原型法会应用软件开发过程的各个阶段。分析阶段是发现 原型用来明确并完善需求。设计阶段建立原型来测评各种设计和界面设计。编码阶段 建立原型测试各种编程技术的效果和效率。 发现原型是一个仅显示外观而不是提供执行能力的界面。发现原型不是为了实现所有 功能，而是用来检验需求的某种实现方法的可行性。
发现原型好处： 1.通过构建原型,分析师可以和用户讨论系统如何支持业务处理过程,可向用户示范系 统业务处理过程。 2.原型有助于用户发现一些以前从未考虑过的问题，可使用户与分析师跳出原来的思 维模式。
心理学表明人们对活动着的界面原型的理解力远远大于对文本描述的理解！
需求获取及分析
需求获取经典三个问题: 问题1:确定哪些人使用? 问题2:会有哪些物件?
需求分析方法
引言
需求分析过程如右图所示：领域专家
需求分析方法： 需求调研方法
场景 用例
业务需求 描述
用例图
用例分析
系统分析师
领域概念模型
类图
类图
说明:需求分析说明书：系统概要信息＋用例描述功能需求＋类图描述数据需求＋ 非功能需求描述（性能等）组成。
需求调研方法
需求调研是需求分析过程中与客户交往最多一段时间，这阶段存在问题如下： 绝大部分客户不知道如何全面而又准确无误表达自己的需求 关注核心客户还是大多数客户 沉默的大多数与骑墙的大多数
需求分析和用例模型
意义 有利于将来实现系统时，拟定哪些功能能够重用，在编写代码
时就能够实当代码旳重用，缩短开发周期。 注意：执行基用例时，每次都必须调用被包括用例。
用例旳辨认
➢ 用例图对整个系统旳建模过程非常主要，在绘制系统用例图前， 有许多工作需要做。
➢ 系统分析者必须分析系统旳参加者和用例，它们分别描述了 “谁来做”和“做什么”这两个问题。
➢ 辨认用例最佳旳措施就是从分析系统旳参加者开始，考虑每个 参加者是怎样使用系统旳。使用这种策略旳过程中可能会发觉 新旳参加者。
了工作效率？
用例旳辨认
➢ 还有某些与目前参加者旳日常工作无关旳问题，也能帮助发觉 用例
• ⑴ 系统需要旳输入、输出是什么信息？这些信息是从哪里来到 哪里去？
• ⑵ 系统目前旳这种实现措施要处理什么问题（可能用自动系统 替代手工操作）？
用例之间旳多种关系
用例图中，除了参加化关系，用例和用例之间有泛化关系、包括关系 和扩展关系。 1.关联关系 ➢参加者与用例之间一般用关联关系来描述。每个参加者能够参加 一种或多种用例。 ➢参加者与用例之间旳关联关系使用带箭头或者不带箭头旳实现表 达。
（2）仓库管理员负责产品旳库存管理。 涉及产品入库管理、处理盘点信息、处理报损产品信息 和某些信息旳设置。这些设置信息，涉及：供给商信息、产 品信息。 仓库管理员每天对产品进行一次盘点，当发觉库存产品 有损坏时，及时处理报损信息。当产品生产后，将产品进行 入库。当产品销售后时，产品进行出库处理。
用户需求分析的方法
用户需求分析的方法在软件开发中，用户需求分析是非常重要的环节。
只有深入理解用户需求，才能够开发出符合用户期望的产品。
本文将介绍用户需求分析的方法，包括用户调研、用户故事、用例分析和原型设计。
一、用户调研用户调研是获得用户需求信息的重要手段。
用户调研可以通过定期组织用户访谈、用户问卷、用户群体讨论来获取用户需求。
在用户调研过程中，设计师可以了解用户的使用习惯、痛点、期望，从而为产品开发提供最为直接的指引。
在用户调研中，除了切实了解用户使用习惯和需求外，还应该注意保护用户隐私，确保用户信息的安全。
同时，在用户调研过程中，也可将其录音或视频录制，便于后期整理。
二、用户故事用户故事是软件开发中常用的分析用户需求的方法。
用户故事可以描述用户目标、需求和期望，从而理解用户需求。
使用用户故事的好处是可以强化用户的参与感，提高软件产品的用户体验。
在创建用户故事时，应尽量满足以下几点：1.简明扼要：用户故事应该简洁明了，集中描述用户需求。
2.从用户视角出发：用户故事应该从用户角度出发，带有用户的情感和感受。
3.具备可实现性：用户故事也应在技术可行性和可实现性上进行评估。
三、用例分析用例分析是一种以用户需求为核心开展的需求分析方法。
用例分析一般可分为以下步骤：1.需求文档编写：根据用户调研结果编写需求文档。
2.确定用例：根据用户需求，确定与用户相关的用例，包括主要和其他用例。
3.编写用例：编写详细的用例，包括前提条件、步骤和结果描述。
4.评估用例：评估用例的实际效果、可行性和用户满意度。
5.更新需求文档：更新需求文档并实验较为困难的用例问题并解释。
通过用例分析，可以更好地了解用户期望。
在实际运用过程中，用例分析应根据具体情况进行灵活运用，可以适当加入其他分析方法。
四、原型设计原型设计是软件开发过程中的必要环节。
原型设计是通过创建草图、线框图、原型图等手段，使用户和设计师能够具体了解产品的功能和流程，从而评估和优化产品设计。
怎样做需求分析
怎样做需求分析如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。
建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。
下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求这是该阶段的一个最重要的任务。
以下为获取用户需求需要执行的活动（如图1所示）。
● 了解客户方的所有用户类型以及潜在的类型。
然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
● 对用户进行访谈和调研。
交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。
需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。
例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
● 需求分析人员对收集到的用户需求做进一步的分析和整理。
下面是几条常见的准则：⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；图1 获取用户需求的活动⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。
大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。
需求分析人员在这个任务中需要执行下述活动：⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；⑵使需求符合系统的整体目标；⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
分析用户需求在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：子用例与扩展用例（转）用例模型作为UML中4+1视图中非常重要的一员，非常集中地体现了面向对象的分析与设计思想。
用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。
由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了日后各种对象的雏形。
同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，又体现了面向对象设计中的复用性。
现在我们来谈谈用例分析中的子用例与扩展用例吧。
前面我们在用例说明中提到了基本流程。
基本流程就是所有步骤都非常理想地正确执行，并最终完成所有操作的那个“最佳流程”。
在基本流程中，可能有些步骤是多个用例都共有的，可以相互共享的流程。
将这部分流程提取出来形成的就是子用例。
子用例应当是在逻辑上相对独立的一系统流程组成的用例。
这个用例应当是抽象的，没有自己的参与者，只有在调用它的用例中，才能真正明确它的使用者。
如图是一个子用例使用的例子。
图中，用例“调整前信息查询”、“调整后信息查询”、“调整前时间段查询”、“调整后时间段查询”都用到了“按单位汇总考核结果”。
它们是一种使用关系或者包含关系，因此被绘制成一条虚线，从使用者指向被使用者，并标注为use或include。
另外，在用例中还存在许多扩展流和异常流。
当系统在运行到基本流程中某个步骤时，由于满足了某个分支条件或异常条件，这时系统就从基本流程流转到了扩展流或异常流中。
扩展流和异常流其实不那么泾渭分明。
在业务逻辑上扩展流依然是一种正常的操作，仅仅只是正常操作的另一个操作，而异常流其本身就是有什么东西不对劲了，需要进行一些异常处理，比如用户密码输错了、用户忘带身份证了，等等。
扩展流和异常流最终都可能回到基本流程中，也可能不能回来，而从另一个结束点结束。
与子用例相似，扩展流和异常流中的流程如果相对独立、可以为其它流程所共享，则可以提取出来，形成一个单独的用例，叫扩展用例。
UML用例图的用例拓展与关联分析
UML用例图的用例拓展与关联分析UML（Unified Modeling Language）是一种用于软件系统的建模语言，用例图是UML中的一种图示工具，用于描述系统的功能需求和用户与系统之间的交互。
在用例图中，用例是对系统功能的描述，用例之间的关系则表示了不同用例之间的交互和依赖关系。
本文将探讨UML用例图中用例的拓展与关联分析。
一、用例拓展用例拓展是指在某个用例执行过程中，根据特定的条件和需求，对该用例进行扩展或修改。
用例拓展可以通过扩展关系（extend）来表示，该关系表示一个用例的行为可以被另一个用例的行为所扩展。
扩展关系可以帮助我们更好地理解系统的功能需求，并且可以在系统设计过程中提供更多的灵活性。
举个例子，假设我们正在设计一个在线购物系统的用例图。
其中一个基本用例是“下订单”，但是在某些情况下，用户可能需要修改订单中的商品数量或者删除某个商品。
这时，我们可以通过用例拓展的方式来描述这些特定的需求。
我们可以创建一个名为“修改订单”的拓展用例，它扩展了“下订单”用例，并且在用户需要修改订单时触发。
二、用例关联分析用例关联分析是指在用例图中，通过关联关系（association）来描述不同用例之间的关联和依赖关系。
关联关系表示了用例之间的相互关系，可以帮助我们更好地理解系统中不同用例之间的交互和依赖。
举个例子，假设我们正在设计一个社交媒体应用的用例图。
其中一个基本用例是“发布动态”，而另一个基本用例是“评论动态”。
这两个用例之间存在着关联关系，因为用户在发布动态后，其他用户可以对该动态进行评论。
我们可以在用例图中使用关联关系来表示这种关联和依赖关系。
除了关联关系，还有其他类型的用例关系可以用于描述不同用例之间的关系，如包含关系（include）和泛化关系（generalization）。
这些关系可以帮助我们更好地组织和理解系统的功能需求，同时也可以在系统设计中提供更多的灵活性和可扩展性。
综上所述，UML用例图的用例拓展与关联分析是系统设计过程中重要的一环。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
怎样做需求分析之十二：分析之子用例和扩展用例
作者: fangang发布时间: 2012-04-11 10:12
用例模型作为UML中4+1视图中非常重要的一员，非常集中地体现了面向对象的分析与设计思想。
用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。
由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了日后各种对象的雏形。
同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，又体现了面向对象设计中的复用性。
现在我们来谈谈用例分析中的子用例与扩展用例吧。
前面我们在用例说明中提到了基本流程。
基本流程就是所有步骤都非常理想地正确执行，并最终完成所有操作的那个“最佳流程”。
在基本流程中，可能有些步骤是多个用例都共有的，可以相互共享的流程。
将这部分流程提取出来形成的就是子用例。
子用例应当是在逻辑上相对独立的系统流程组成的用例。
这个用例应当是抽象的，没有自己的参与者，只有在调用它的用例中，才能真正明确它的使用者。
如图是一个子用例使用的例子。
图中，用例“调整前信息查询”、“调整后信息查询”、“调整前时间段查询”、“调整后时间段查询”都用到了“按单位汇总考核结果”。
它们是一种使用关系或者包含关系，因此被绘制成一条虚线，从使用者指向被使用者，并标注为use或include。
另外，在用例中还存在许多扩展流和异常流。
当系统在运行到基本流程中某个步骤时，由于满足了某个分支条件或异常条件，这时系统就从基本流程流转到了扩展流或异常流中。
扩展流和异常流其实不那么泾渭分明。
在业务逻辑上扩展流依然是一种正常的操作，仅仅只是正常操作的另一个操作，而异常流其本身就是有什么东西不对劲了，需要进行一些异常处理，比如用户密码输错了、用户忘带身份证了，等等。
扩展流和异常流最终都可能回到基本流程中，也可能不能回来，而从另一个结束点结束。
与子用例相似，扩展流和异常流中的流程如果相对独立、可以为其它流程所共享，则可以提取出来，形成一个单独的用例，叫扩展用例。
如果扩展用例是直接从基本流程中某个环节扩展出来，则该环节被成为扩展点，进入扩展用例的条件叫扩展条件。
在用例图中，扩展关系被绘制成一根虚线，从扩展用例指向被扩展的用例，并标注为extend。
用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。