《软件需求分析和软件需求规格.pdf》由会员分享，可在线阅读，更多相关《软件需求分析和软件需求规格.pdf（10页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、 第3章 软件需求分析和软件需求规格 IEEE 把软件需求定义为：（1）用户为了解决某一问题或者达到某一目标而需要的功能和条件；（2）这些条件和功能要求必须要被系统所满足，同时要满足相关的合同契约、标准、规范，或者其他一些正式强制性文件。需要指出的是，所需处理的软件需求是动态的，也就是系统的性能是不断发展的。正如我们所看到的，所有的开发模型都要求有明确的需求。若使用敏捷技术就需要高层需求说明书，详细需求通过与客户反复交换意见得到，并且直接反映在软件中。另一方面是需求描述要精准，需求活动的目的就是要得到软件需求规格说明书 SRS（software requirement specificatio
2、n），它描述了软件需要做什么，而不描述怎么做。这一章中要讨论：?SRS 在工程中的作用，以及一个好的 SRS 会带来的价值。?在产生所需要的 SRS 的过程中的一些不同的活动。?SRS 文档要求的特性，结构以及它的关键部分。?用例分析方法和功能需求的指定以及怎样开发用例。?其他一些需求分析的方法，如数据流图（data flow diagram）分析法。?怎样验证需求。3.1 好软件需求规格的意义 多数软件系统起源于某些客户的需要，软件系统本身由某些开发者生产，最终完成的系统由用户使用。然而，在一个新的系统中有我们感兴趣的三个主要部分，它们是：客户、开发者和用户，那些客户所要求的以及用户 软件工
3、程导论 28关心的需求必须要与开发者交换意见。问题是客户往往不懂软件和软件的开发过程，同时开发者也往往不理解客户的问题和应用领域。这就造成在项目的开发过程中，各方交流的空隙。SRS 最基本的目的就是要填补这个交流空隙，开发出一个拥有共同视图的软件。所以一个优秀的 SRS 的主要优点是：SRS 使得客户与开发者之间在软件究竟要做些什么上达成一致。客户与开发者会频繁的把这些一致做成具有法律效力的契约，所以通过 SRS，客户清楚地描述它期望从开发者那得到什么，开发者也清楚地理解构造的该软件将具备什么功能。一个相关但重要的优点是：SRS 对最终产品的验证提供一个参考。也就是说，SRS 帮助客户确定一个
4、软件是否满足需求，没有合适的 SRS，客户就没有办法去决定软件是否按照所要求的那样去做，同时开发者也没有办法向客户表明那些需求已经全都满足。就以上所言已有足够的理由使客户与开发者需严肃处理这个需求说明，但是对一个优秀的 SRS 还有更加实际的原因。研究表明需求阶段存在着许多错误，并且 SRS 中的错误在最后的软件实现中肯定将是个错误。显然，若我们想要得到一个高质量的最终产品，而且几乎没有错误，那就必须从做高质量的 SRS 开始。换句话说，可以归纳为：高质量的 SRS 是高质量软件的前提。高质量的 SRS 可以减少工程费用，我们知道 SRS 可能存在错误，同样也知道随着工程的进展，弥补一个错误所
5、需的花费是呈指数增长的。所以，通过提高 SRS 的质量可以为将来节省一大笔检测开销。或者说：高质量的 SRS 可以减少开发费用。3.2 需求过程 需求分析过程就是做需求分析时的一系列活动的顺序，最终以形成高质量的 SRS 文档为终点。典型的需求分析过程包括三个基本任务：问题或需求分析、需求说明以及需求验证。问题分析通常由一个高层的“问题陈述”开始，在问题分析期，为问题域和环境建模，这对理解系统的行为、约束、以及输入输出等是很有效的，这项活动的基本目标就是彻底地弄懂所开发的软件究竟要提供些什么。在分析过程中，分析者往往会与客户和终端用户召开一系列的会议。在早期的会议中，客户和终端用户会向分析者解
6、释他们的工作和工作环境，还有他们的一些期望。在这个过程中都会提供任何有关描述工作和组织的文档，在这些早期会议中，分析者主要是作为听众，掌握他们所提供的信息。一旦第 3 章 软件需求分析和软件需求规格 29分析者对所要开发的系统了解到一定程度时，他会在接下来的几次会议上澄清那些他所不懂或不清楚的部分，也可能会把这些信息文档化或建成模型，他也有可能进行头脑风暴或者想象一下这个系统将要做什么。在最后的几次会议上，分析者会向客户解释对系统要做什么的理解，同时也会利用这几次会核实他对系统的理解是否和客户的目标一致。由问题分析中得来的信息会形成一个最基本的需求说明书，在这份说明书中，主要是清楚地记载需求。
7、在这个活动中事实的陈述，说明语言和工具等都会确定下来。同时把烦琐的信息和知识进行合理的整理并除去冗余信息，这也是这个阶段的重要目标。需求验证把重点放在保证那些在 SRS 中所说明的一定是软件所需要的，同时保证产生高质量的 SRS。需求分析过程在对 SRS 验证后就结束了，本章后面会有更详细的介绍。必须指出的是，在需求分析过程中，这三个活动不会是线性的顺序，考虑他们之间会有重叠和互相反馈，在图 3.1 中展示了整个需求分析过程。正像图中所展示的那样，从产品描述阶段可能要返回到问题分析阶段。当问题的一部分已经被分析和说明而另外一部分却未得到分析和说明时，这种情况会经常发生。而且，在描述一个问题时会
8、经常出现一些缺陷，因此有必要做进一步的分析。一旦一个问题描述已经完成，就会到达需求验证阶段。这个阶段可能会显现出说明书本身的一些问题，或者显现出对问题理解上的一些偏差，这样就需要重新回到说明描述阶段，甚至返回到问题分析阶段。3.3 需求规格 最终输出的是 SRS 文档。因为分析阶段是在规格说明书之前，引起的第一个问题是：如果在分析阶段产生了正式的模型，为什么这个模型的输出不是 SRS 呢？主要原因是模型主要关注的是问题的结构，而不是它的外部行为。然而，外部行为像用户界面一样很少被模型化，而却经常成为 SRS 主要组成部分。同样，为了减轻建模的难度，一些次要的事件，如出现错误的情形（如输出错误）
9、很少被合适的建模，而在 SRS 中，面对此情形下的行为要有明确说明。另外，模型中一般不包括性能约束、设计约束以及遵从标准、恢复等，但是这些在 SRS 必须被明确定义，因为设计者必须知道这些才能精确的设计系统，所以模型的输出文档很显然不能成为我们想要得到的 SRS。不能从分析结果直接生成规范说明书，即使在分析中有一部分是正式的模型。一个优秀的 SRS 需要说明许多事，其中有一些很难在分析阶段处理，其实本质上那些能从分析阶段直接传到说明阶段的东西就是系统所需要的东西。建模是一个很好的工具，它能 图 3.1 需求过程 软件工程导论 30帮助我们完整地获得系统所需要的东西。SRS 就是基于从分析中获得
10、的知识写成的，因为不能把知识直截了当地转换成有结构的文档，所以规范说明书本身就是项重要的独立任务。3.3.1 软件需求规格应该具备的特点 为了很好的满足这些基本要求，一个 SRS 必须有一些特定的属性和一些不同类型的需求。其中一些 SRS 特性如下所述：1.正确性；2.完整性；3.明确性；4.可核实性；5.一致性；6.重要性或稳定性的等级。如果 SRS 中包括的内容都是最后系统所需要的，那么这个 SRS 是正确的。如果软件所期待要做的所有事和该软件对任何的输入的响应都被写进了 SRS，那么该 SRS 已经完成。如果所有的需求都仅有一种解释，那么它是明确的，没有歧义的。如果需求是用自然语言书写的
11、，那么 SRS 的作者必须非常小心以保证不存在二义性。如果每一个确定的需求是可核实的，那么这个 SRS 是可核实的。需求的可核实性取决于是否存在一个有效的过程，这个过程能检查最后的软件是否满足需求。专业术语会造成前后的不一致；比如，对于同一对象，不同的需求文档可能用不同的术语来阐述。在这些不一致中，也有可能是些逻辑上或暂时的冲突造成的。如果 SRS 中包括两份或更多的需求文档，这些合起来的文档的逻辑性或是特性暂时不能被软件系统所满足，那么上面提到的状况就会发生。比如，假设需求表明 e 事件发生在另一事件 f 之前，但是另一些需求文档表明（直接的或间接）事件 f 必须发生在事件 e 之前，SRS
12、 中的不一致可能涉及一些主要问题。一般来讲，对于软件的所有需求不是同等重要的。一些是关键的，而另一些很重要但不一定是关键的；还有一些是期望得到的但它并不很重要；类似的，有些需求是核心要求并不依赖于时间，它不随时间的推移而发生改变，而有一些更依赖于时间；有些需求对用户而言比其他需求更有价值。如果需求的重要性或稳定性是知道的，那么可以按重要性或稳定性来分级。需求的稳定性反映它将来的变化性，可以用期待变化量来反映。理解每个需求文档的价值对下一步的开发至关重要，因为重复性的选择需求正是基于需求价值的。在所有的特性中，完整性可能是最重要的，同时它也是最难建立的。在需求规格说第 3 章 软件需求分析和软件
13、需求规格 31明书中最常见的缺陷就是缺乏完整性。需求缺陷迫使在后面的开发过程中对需求进行增加和修改，这些增加和修改很难和之前的需求合并。客户与开发者之间的不一致主要是由这些不完整性产生的。然而，一些人认为不是所有的细节中完整性都是渴望得到的。对完整性的追求可以使细节更明确，可以更好的理解一些设想（如，明确什么是增加记录操作的细节）。明确这些细节导致生成大量的需求文档，这些文档自身也会产生问题，比如使得后面的验证更困难。但另一方面，如果给出的细节太少，开发者对此的理解就会很困难，这又导致以后软件中的缺陷。因为完整性，在即将开展的工程中得到“足够多的细节”是个合理的目标。例如，如果工程是按瀑布模型
14、来开发，那么最好得到详细的需求说明，以至于后面尽可能少的修改。另外，如果是迭代模型，由于在反馈过程中总是有机会修改需求，那么需求说明书可以粗糙些。如果采用敏捷方法，那么只需在顶层的需求上寻找完整性，而不必写细节，因在具体需求实现时会引出相关细节。性能需求、接口需求、以及设计约束需求统称为非功能需求。3.3.2 软件需求规格的组成 需求说明中的完整性是很难得到的，而且更难得到核实。但是 SRS 中究竟要做哪些事有些指导原则，那么这些原则对完成需求说明将有很大的帮助。下面是 SRS 的基本 论点：?功能；?性能；?影响实现的设计约束；?外部接口。功能需求必须指明系统的什么行为是所期待的，这些行为就
15、是在给定输入时，产生什么输出，它描述了系统中输入与输出之间的关系。对每一个功能需求，需详细描述所有输入以及它们的源、度量单位、有效输入范围等都必须明确。所有为了得到输出而在输入数据上做的相关操作都必须明确，包括输入、输出数据和那些受到操作影响的参数的合法性检查、等式或用于把输入转换成相应输出的逻辑操作。例如，如果有一个计算输出的公式，这个公式必须要明确描述。需求规格说明书中的一个重要部分就是描述系统在异常情况下的行为，如非法输入（有多种情况出现）或者计算中的错误，功能需求必须清楚地说明当系统发生这种情形时应该怎样做。特别是当系统出现非法输入和输出时。此外，当出现输入正确，但正常的操作却不能执行
16、的情形时，功能需求要详细说明应对行为。预定系统就是这种情况的一软件工程导论 32个例子，如果没有实用性，即使一个有效的请求预定功能也做不了。总之，对于那些可以预见的输入和系统状态，系统相应的行为都必须明确。SRS 中的性能需求是对软件系统中相关性能的约束，所有与系统性能相关的需求都要明确。有两种性能需求：静态和动态。静态需求是那些不会对系统执行特性有要求的性能需求。如支持终端用户数和用户并发数；系统处理文件数以及这个文件的大小等需求，这些也称为系统的容量；动态需求指明了系统执行行为上的约束，典型有系统的响应时间和吞吐量约束。响应时间就是在特定的环境下一操作完成的期待时间，吞吐量就是在单位时间内
17、期待可执行的操作数量。例如，SRS 可能会规定在每一单位时间上执行事务的数量或者是特定命令的响应时间。同时也要确定对不同性能参数的可接受范围，以及在平时或工作负载峰值时的性能可接受值。所有的这些需求都必须是可量化的，类似响应时间很短于、或者系统处理任何事务都很快这样的描述是不可接受的，因为这种描述不精确且不可验证。相反，如命令 X 的响应时间必须在 90%的次数中小于一秒，或者在 98%情况下，一个事务可以在一秒以内处理完，这样的描述通常被需求说明所采用。在客户的环境下，有许多因素可能会约束设计者的选择，这就导致了设计约束。比如必须遵循的某些资源限制、操作环境、可靠性和安全性需求，以及与系统设
18、计相冲突的政策等。SRS 必须标识和明确这些约束。下面是一些例子：?标准的服从：系统需求要服从的标准必须明确，可能包括的标准有报告格式和结账流程，也可能有些审计需求，它要求操作记录。?硬件限制：软件必须运行在现在已有的或预先确定的硬件上，而这些硬件会对软件产生设计约束。硬件限制包括使用机器的类型、系统上的操作系统和支持语言，以及主存和辅存的限制。?可靠性和容错性：容错需求在如何设计系统上增加了约束，因为它使得系统更加复杂和昂贵。系统的恢复性需求通常以整体性确保特定的属性，它详细描述了当一些错误发生时系统应该怎么做。?安全性：安全性需求变得越来越重要，这类需求在使用某些命令上加以限制，约束特定数
19、据的存取，提供了对不同人的不同访问需求，要求使用密码和加密技术，以及记载系统活动的日志。它也要求适合对安全的评估，合理的编程技术和使用相应工具探测像缓冲区溢出等的错误。在外部接口说明部分，所有软件与人、硬件和其他软件的交互都得明确描述。对用户接口，软件产品的每一个特性都要明确。用户接口变得越来越重要，必须投入更多的注意力。一些初始的用户操作有用户命令、屏幕显示格式、系统如何呈现给用户的解释、反馈和错误消息等，都必须要说明。像其他的说明一样，这些需求说明也要具备精准性第 3 章 软件需求分析和软件需求规格 33和可核实性。所以像“系统对用户必须友好”类的句子必须避免，像“命令长度不超过六个字符”
20、或者“命令的名称必须反映它所执行的功能”这样的句子则可以使用。关于硬件接口需求，SRS必须明确软件产品和硬件组件之间的每个接口的逻辑属性。如果软件是运行在已有的或预先确定的硬件上，那么包括内存约束在内的所有硬件特性都必须明确。另外，必须给出当前使用和加载的硬件特性。接口需求也必须明确那些将要在系统中使用的其他软件的接口，包括操作系统和其他应用软件，每个接口的消息内容和格式都必须明确规定。3.3.3 需求文档的结构 需求是用某种描述语言来描述的，在说明文档时，尽管在描述系统属性时存在专业术语，但是自然语言还是用得最多。当采用格式语言时，这类语言一般是用来描述系统的特定属性。对于一个系统的所有需求
21、，不管是用格式语言还是自然语言描述，文档都应该清楚和简明。为此，合理地组织需求文档是必须的，这里基于 IEEE 对软件需求说明的指导原则讨论需求说明的结构。IEEE 标准认定这样一个事实，不同工程它们的需求文档可以有不同的结构组织，也就是对所有工程来说，没有一个固定的方法。IEEE 提供一些不同的SRS结构，SRS的前两部分对所有工程来说是一样的。图 3.2 给出了一个大概的 SRS 结构。简介部分包括需求目的、范围、概述等，这里的重点是阐明这个工程的动机和商业目标及工程的范围；第二部分给出系统的综合视图，什么样的大系统合适，以及对系统所有的需求的概述，此部分不会涉及详细的需求说明，产品视图本
22、质上就是它与其他产品的关系。定义该产品是独立的，还是其他产品的一部分，以及什么是产品的主要接口。同时必须给出产品功能的一个大概描述，用图表大概地展示各功能以及它们之间的关系是很有用的。类似地，也必须给出一些典型的终端用户特征和约束说明。如果采用敏捷方法，有这个初始层面的需求就足够了，因为当需求文档实现时，会做更多的细节。详细需求说明部分描述需求的细节，这些细节是开发者在设计与开发系统时必须知道的。这也是文档中最重要和占份额最多的部分，对于这一部分不同组织已提出了相应标准。这类需求可用操作模型、用户类、对象、特征、激活方式或分层功能模型等组成。1 简介 1.1 目的 1.2 范围 1.3 定义、
23、首字符缩写和缩略 1.4 参考文献 1.5 概述 2 总体描述 2.1 产品视图 2.2 产品功能 2.3 用户特征 2.4 一般约束 2.5 假设与依赖 3 详细需求 图 3.2 SRS 的一般结构 软件工程导论 34组织具体文档时，首先确定外部接口，这个接口是由之前的功能需求、性能需求、设计约束和系统属性所决定的，图 3.3 展示了这个结构。外部接口需求部分明确了软件接口，包括与用户、其他软件、硬件和其他系统的接口。用户接口是一个很重要的组件，它明确了系统所要面对每个用户的接口，包括屏幕、帮助信息、菜单内容和命令结构。在硬件接口中，提供软件运行的硬件、硬软件之间的逻辑关系必须明确。本质上，
24、任何软件对硬件的假设都应在此列出，在软件接口中，此软件所需的其他软件连同接口必须明确。如果软件需要与机器上的其他实体通信时，那么必须明确通信接口。功能需求部分描述系统的功能，在这一部分，给出软件的所有操作功能的描述。对于功能需求，需要的输入、输出和处理过程都要明确定义。对输入、输入源、度量单位、有效范围、精度等必须明确。在处理过程说明时，所有需要在输入数据上的操作以及产生何种临时数据必须明确。包括在输入上的有效性检查、操作顺序、异常情况的响应以及将输入转换成相应输出的方法说明。性能部分需要说明静态的和动态的性能需求。在性能限制说明部分必须确定所有影响系统的因素。属性部分描述了一些系统本应有的综
25、合属性，所有没有在此被囊括的需求必须在其他需求文档中说明，设计约束要说明那些由于设计引起的约束。当有用例时，用例说明就会代替功能需求说明。SRS 中的产品视图部分可以提供对用例的一个概括和总结。3.4 用例驱动功能规格 功能需求说明通常是需求文档的核心，传统的功能说明要明确系统必须提供的功能。通过用例来说明系统功能是要明确系统行为，这些行为是在用户与系统交互中捕获得到的。用例也可以用于描述商务流程或软件组织，或者只是描述软件系统的行为，我们把描述重点放在即将开发的软件行为上。尽管用例通常是指定软件行为的，但是它也可以用于效率分析。后面当讨论怎样开发用例时，我们将讨论怎样采用用例引出需求。Jac
26、obson56建议把用例作为面向对象模型已引起大家的关注，正是由于与面向对象方法关联，所以用例通常被看做面向对象软件开发模型的一部分。然而，它一般是描述3 详细需求 3.1 扩展的接口需求 3.1.1 用户接口 3.1.2 硬件接口 3.1.3 软件接口 3.1.4 通信接口 3.2 功能需求 3.2.1 模块 1 3.2.1.1 功能需求 1.1?3.2.1.n 功能需求 1.n?3.2.m 模块 m 3.2.m.1 功能需求 m.1?3.2.m.n 功能需求 m.n 3.3 性能需求 3.4 设计约束 3.5 属性 3.6 其他需求 图 3.3 详细需求 第 3 章 软件需求分析和软件需求
27、规格 35系统交互的一种方法（即使不是 IT 系统），这里关于用例的讨论是基于24中的概念。3.4.1 基础知识 一个软件系统可能被许多用户或其他系统使用，我们用于揭示需求。在用例术语中角色是一个人或系统，它用系统而达到一个目标。注意角色与系统交互而达到一些目标，那么角色是逻辑实体，它代表着一群有相同行为的用户（人或系统）。不同的角色因为不同的目标代表着不同的群体，所以对系统发送某些消息而由另外用户接受消息的普通“使用者”，采用“接受者”和“发送者”来称谓比较好。主角色是使用用例（UC）来达到某个目标的主要角色，而满足这一目的是该用例的主要目标。主角色是逻辑概念，尽管我们假设主角色执行用例，但
28、是一些代理可能会真正执行主角色用例中的行为。例如，用区域用例获得销售增长报告的 VP 可以是主角色，尽管真正执行的是秘书。我们把主角色认为是那个真正使用用例结果的人，以及目标中的主要消费者。时间驱动触发器是关于主角色怎样执行用例（在这种情形下，有时报告是自动生成的）的另一个例子。注意，虽然主角色的目标是用例的驱动力，但是用例也需要满足其他相关者的目标。那就是说，尽管用例可由主角色的目标来驱动，但是用例的目的是描述系统满足所有用户的目标行为。例如，一个从 ATM 机上取款的用例，它的客户是主角色，将正常地描述客户与 ATM 之间的全部交互。然而，银行也是 ATM 系统相关者，它的目标包括记录所有
29、的步骤、当账户里有足够资金时钱才被取出、一次取款不能超过多少限额等。ATM取款用例中要满足所有这些目标。为了描述交互行为，用例采用情景。情景描述了在某些特定条件下为达到某一目标而执行的活动集。活动集通常描述为明确的顺序，尽管有些操作的执行以并行或其他次序，情景中的每一步都是由系统或角色执行的一个逻辑上完整的活动，通常是角色的某个行为，每一逻辑步骤是系统为达到某目标的向前发展，或者是为了满足某些目标而改变一些中间状态。用例总是有一个成功情景，该情景描述了在交互时若没有任何失败，那么所有的步骤将全部成功完成。可能会有几个成功情景，尽管用例标准是为了达到这些目的，但是当系统和角色在进行一些不能使系统
30、完全地达到目的的交互时，就会发生许多不同情 况。有时被称为例外情景，用例就是一个包括所有与目标有关的成功情景和它的例外情景。表 3.1 中是有关用例术语的总结。为了达到期望的目标，系统可被分成几个子目标。其中某些子目标可由系统自身完成，也可以由另外系统所支持角色的用例所执行。例如，假设核实一个 ATM 取款用例中的用户是否使用了认证服务，与这个服务的交互可作为一个单独的用例。因此情景中 软件工程导论 36表 3.1 用例术语 术 语 定 义 角色 使用系统完成某一目标的人或系统 主角色 主角色初始化用例且使用用例的主要目的是满足他的目标 情景 在一定条件下为实现某一目标而被执行的一组操作 主情
31、景 描述交互，如果每一步骤都成功执行 例外情景 描述系统行为，如果某些步骤在主情景中没有完全成功 的用例为了完成一些任务而借用其他的用例。换句话说，用例允许按层次组织。用例预想的最基本系统模型是，系统对角色使用时所需求的最基本的响应，这是显然的。在描述了角色与系统的交互之后，系统的行为就可以确定了，通过行为它的功能也就确定了。这种方法的一个关键优势在于用例只关注外部行为，因此可以避免需求期间的内部设计，尽管期望某些事情，但是用多种模型的方法不容易做到。用例通常用文本描述，它代表着系统行为性的需求，这些行为说明可以覆盖系统中的大部分功能需求。虽然用例不能形成完整的 SRS，但是可以成为其中的一部
32、分。如我们所见，完整的 SRS 需要捕获其他一些需求，如性能和设计约束等。尽管用文本可详细描述用例，但是图表可以作为文本描述的辅助工具。例如，UML的用例图可以展现系统中的用例和角色，以及它们的依赖性，UML 用例图通常用椭圆表示系统中的用例，用线连接用例与主要角色，然后展示出用例的依赖性。也可以表示用例中的一些其他关系，然而用例本质上是自然语言的文本描述，在开发过程或用例说明中图表描述有限，在此不进一步讨论用例图表表示。3.4.2 几个例子 让我们用少许用例说明这些概念，这些用例也将用来解释一些与用例相关的概念。考虑一个大学社团建立的在线小型拍卖系统 UAS，通过这个系统，大学中的不同人可以买卖物品。我们假设有一个单独的金融子系统，每个买家和卖家在子系统中都有一个账号，可以通过该子系统买、卖东西。在这个系统中，尽管这里有相同的买和卖的人，但是仍把“买者”和“卖者”按不同的目标分成不同的逻辑角色。除了这些之外，拍卖系统本身也是个相关者和角色，金融系统也是。首先考虑该系统的主要用例，“拍卖物品”、“喊价”和“完成一次拍卖”。图 3.4 中给出了这些用例。用例是自我解释的，这是用例的最大价值所在，它们很自然，像故事一样，这样使得不管是分析人员还是外行都很容易理解。因此，用例很大程度上帮助缩小了开发者与