《如何对电子商务系统进行需求分析.docx》由会员分享，可在线阅读，更多相关《如何对电子商务系统进行需求分析.docx（14页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、如何对电子商务系统进行需求分析一、需求分析 在具体的研究需求分析之前，我们先了解一下软件工程这个 概念。软件工程分为三个层次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的概念说明）。关键过程区域构成了软件工程的管理控制的基础， 并且确立了上下文各区域的关系，其中规定了技术方法的采 用、工程产品的，模型、文档、数据、报告、表格等，等的 产生、里程碑的建立、质量的保证及变化的适当管理。方法 层主要是过程在技术上的实现。它解决的问题是如何做。软 件工程方法涵盖了一系列的任务：需求分析、设计、编程、 测试、维护。
2、同时他还包括了一组基本原那么，控制了每一个 的关键过程区域。工具层就很好理解了，他对过程层和方法 层提供了自动和半自动的支持。这些辅助工具就称为CASE。可以看到需求分析的位置，但是事实上需求分析是跨越了软 件工程的三个层次的。这一点是和其他的过程是一样的。当 然我们这里比拟重点强调的是在软件工程的方法层，同时也 涉及到一些过程层的思想，至于工具层那么不再我们的讨论之 列，但是会提到一些很适合在需求分析时应用的工具，诸如 Word、Excel Visio等。方法需求分析都包括了哪些方法 呢？这里列举出在需求分析一书中推荐的一些方法。1）绘制系统关联图，这是一个简单的模型，用于定义系统 与系统外
3、部实体之间的边界和接口。同时也定义了通过接口 的信息流和物流。一个用例可能包括完成某项任务的许多逻辑相关任务和交互 顺序。因此，一个用例是相关的用法说明的集合，并且一个 说明(scenario)是用例的实例。这种关系就像是类和对象 的关系。在用例中，一个说明被视为事件的普通过程 (normalcourse),也叫作主过程，基本过程，普通流，或 “满意之路(happypath)。在描述普通过程时列出执行者和 系统之间相互交互或对话的顺序。当这种交互结束时，执行 者也到达了预期的目的。在用例中的其它说明可以描述为可选过程 (alternativecoruse) o可选过程也可促进成功地完成任务，
4、但它们代表了任务的细节或用于完成任务的途径的变化部 分。在交互序列中，普通过程可以在一些决策点上分解成可 选过程，然后再重新汇成一个普通过程。角色类和角色实 例。软件产品最终是给一些用户来使用的，而用户之间的差 异是非常大的。造成差异的原因包括了对计算机的认知程度 的不同，使用习惯的不同，在软件目标组织中所处的地位不 同，地理位置不同，业务熟练程度不同。不同的用户都有自己一系列的功能需求和非功能需求。对电脑熟练程度不同 的人可能就会有不同的要求，熟练程度低的用户可能希望有 一个友好的界面，熟练程度高的用户可能更希望有快捷键或 宏的操作以提高工作效率。考虑到用户的差异性，将用户分 类并研求。抓住
5、用户代表的需求就大致把握住了用户类的需 求。当然，需求分析还是需要在用户中做大规模的调查的， 只是要把重点放在用户代表上。一定要和用户直接沟通！你玩过传递信息的游戏吗？也许 你有。一群人排着队，一句句从上到下传到后面。最后，这 句话被判得面目全非。因此，需要确保工程团队能够直接接 触用户。对于和用户直接沟通这一点，针对具体企业的通用 应用系统当然不是问题，但是如果是开发行业软件，和用户直接沟通几乎是不可能的。在这种情况下，一般有几种解决 方案: 做大规模的市场调查，针对你的目标市场做市场调查，并根 据统计学的理论建立你的数学模型。这局部的工作效果最 好，其性质有些象一些游戏公司会发布一些Dem
6、o版的游戏。 是对于一般的企业来说，这项工作费时费力，高昂的本钱往 往使大家知难而退。我的意见是，方法是非常好的，但是可 以软件技术并不熟悉；第二种是开发过同类软件的软件专 家，这种人在开发同类软件过程中已经积累了大量的工程经 验，并且具有软件开发的知识。这种方式是获取需求的最好 的方式。分析比照同类软件，微软在开发Office、 VisualStudio的时候，也是参照了 Lotus和Borland的成熟产品。这种方式的特点在于本钱很低，比拟适合和其他的方 式配合使用。但是，要注意自己有没有触犯专利法。有的时 候，虽然已经将用户分类并选出了用户代表。但是需求的来 源众多，往往会发生需求之间自
7、相矛盾的事情。需求从四面 八方收集来后，人们难以解决冲突，澄清模糊之处以及协调 不一致之处。某些人还要对不可防止要发生的范围问题单独 作出决定。在工程的早期阶段，你必须决定谁是需求问题的 决策者。如果不清楚谁有权并且有责任来作出决策，或者授 权的个人不愿意或不能作出决策，那么决策者的角色将自然 而然地落在开发者身上。这是一个非常糟糕的选择，因为开 发者通常没有足够多的信息和观点来作出业务上的决策。在软件工程中，谁将对需求作出决策的问题并没有统一的正 确答案。分析员有时听从呼声高的或来自最高层人物的最大 的需求。即便使用用户代表这一手段，必须解决来自不同用 户类的相冲突的需求。通常，应尽可能由处
8、于公司底层的人 作出决策，因为他们与题密切相关，并能得到关于这些问题 的广泛信息。如果不同的用户阶层有不一致的需求，更重要的是决定满 足哪一类用户的需求。了解可能使用该产品的客户类型以及 他们的使用与该产品的业务目标之间的关系，将有助于您决 定哪个用户类别拥有最大的份额。当开发者想象中的产品与客户需求冲突时，通常应该由客户 作出决策。然而，不要陷到“客户总是对的”的陷阱中去， 对他们百依百顺。现实中，客户并不总是对的。客户总是持 有自己的观点，开发者必须理解并尊重这一观点。人员有一 系列的交互，在系统内部也往往存在着复杂的交互。因此， 在系统建模时，除了描述系统与外界的交互，同时还要描述 系统
9、内部的交互。传统的MIS系统中，系统与外界的交互较 多。典型的，如ATM取款机：存在着大量的用户与ATM, ATM 与其它系统的交互。而电信领域的系统，与外界的交互较 少。例如，系统的输入可能仅仅是从交换机上采集信息，然 后由系统进行处理。系统的复杂逻辑包含在系统内部处理的 流程上，而非与外部系统的交互。建模主要任务是表达系统 内部的交互。用例图适于表达交互，之所以上面使用了电信系统，是因为 用例最早来自于Ericsson的交换机系统。当时，还是Ericsson雇员的Jacobson初步建立了用例图的概念，并于 1994年提出了 OOSE方法，其最大特点是面向用例(Use-Case),并在用例
10、的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，比拟适合支持商业工程和 需求分析。随着用例的开展，用例被大量的用于对功能进行 描述。每个用例代表了系统与外部ACTOR的交互。可以采取 顺序图来表达用例的具体操作程序。ACTOR用于确定系统的边 界。ACTOR、用例可以从不同的层次来描述信息。采用该原那么的原 因有：L需求在工程开始时并不明确，但往往会随着工程的进展 而逐渐细化。2.人的认知往往具有层次的特性。从粗到细、从一般到特 殊。采用不同的层次来描述，适于认知的过程。使用用例开 发系统的一般过程。在开发过程的初始阶段，可以根据具体 的工程特点，制订开发各个视图之间的关联原
11、那么，指导规 范。在开发的过程中，视图的组织原那么应不断进行维护、更 新。识别ACTOR来识别系统与外界交互的实体。ACTOR具有特定领 域的特征，例如：交换机（采集系统）、97信息系统等。在 系统层次的ACTOR确定了系统的边界。识别用例。同ACTOR一样，用例具有不同层次。对较为概括 的USECASE,需要细化。注：系统开发需要一定的规那么来确 定，如何来分解用例；可能基于原有系统的经验，或是参考 现有资料。当用例细化到可以被理解的层次。需要基于用例进行下一步 的开发。如前面提到的，用例主要用来描述交互。因此，存 在交互的实体和交互的细节。交互的实体采用类图来描述； 而交互的细节，采用顺序
12、图来描述。当系统复杂到一定层次时，类图和顺序图可能不能足以描述 其复杂程度。在该情况下，需要使用状态图来辅助阐述。状 态图和顺序图之间使用事件联结在一起。它们之间的一致性 问题，目前UML和ROSE没有提供解决方案。相对折衷的方法 是使用事件的命名规范强制一致性。可以说，之前说的所有的东西都是为了能够导出用例在需求 中的作用。用例是从用户的角度看待系统，而不是基于程序 员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体 现。用户和程序员间通过用例沟通，防止了牛头马嘴的尴尬 局面。从前，系统开发者总是用于开发的流程。当系统的开 发过程都是基于用
13、例的，用用例获取需求，用用例设计，用 用例编码，用用例测试的时候。这个开发过程就是用例驱动 的。用例和用例文档软件需求一书中提到了几种方法来 确定用例： 首先明确执行者和他们的角色，然后确定业务过程，在这一 过程中每一个参与者都在为确定用例而努力。确定系统所能 反映的外部事件，然后把这些事件与参与的执行者和特定的 用例联系起来。能需求，这些功能需求可以使用户完成其任 务，也可以把它们描述成非功能需求，这些非功能需求描述 了系统的限制和用户对质量的期望。虽然最初的屏幕构思有 助于描述你对需求的理解，但是你必须细化用户界面设计。 建立用例文档。在每一次的需求获取之后，都会生成很多未 整理的需求，你
14、必须将它们组织成用例文档。使用诸如模板 的技术能够提高你的速度和需求的复用性。一个用例文档可 以使用表格来组织，主要的要素包括了用例标识号、用例名 称、父用例标志号、创立者、创立时间、审核者、修订记 录、角色、说、先决条件、请求结果、优先级、普通过程、 可选过程、例外、非功能需求、假设、注释和问题。虽然列 举出了这么多的属性，但是实际中使用的属性这要看你的团 体而定，看工程的大小而定。把大量的时间花在用例的描述 上是没有意义的。用户需要的是一个软件系统，并不是一大 堆的用例说明。2）创立用户接口原型，当开发人员或用户不能确定需求时,开发一个用户接口原型一一个可能的局部实现一这样使得许 多概念和
15、可能发生的事更为直观明了。用户通过评价原型将 使工程参与者能更好地相互理解所要解决的问题。注意要找 出需求文档与原型之间所有的冲突之处。3）分析需求的可行性，分析在允许的本钱和性能要求下实 现每项需求的可行性，识别与实现每项需求相关的风险，包 括与其他需求的冲突、对外部因素的依赖和技术障碍。4）确定需求的优先级别，应用分析方法确定使用实例、产品特性或个别需求的优先级别。根据优先级确定产品版本中 将包含哪些特性或需求类型。当需求被允许变更时，在特定 的版本中添加每个变更，并在该版本计划中进行所需的变 更。5）建立需求模型。需求的图形化分析模型是对软件需求规 格说明的极好补充。他们可以提供不同的信
16、息和关系来帮助 发现不正确的、不一致的、缺失的和多余的需求。这些模型 包括数据流图、实体关系图、状态转换图、对话图、对象类 和交互图。6）创立数据字典，数据字典是对系统用到的所有数据项和结 构的定义，以确保开发人员使用统一的数据定义。在需求阶 段，数据字典至少应定义客户数据项以确保客户与开发小组 是使用一致的定义和术语。分析和设计工具通常包括数据字 典组件。7）使用质量功能调配，（QFD）是一种高级系统技术，它将 产品特性、属性与对客户的重要性联系起来。该技术提供了 一种分析方法以明确那些是客户最为关注的特性。QFD将需求 分为三类：期望需求，即客户或许并未提及，但如假设缺少会 让他们感到不满
17、意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但假设未实现也不会受到责备 （Zultnerl993；Pardeel996）。记住一点，不要试图在你的工程中把这些方法都用上去, 个现代化并不是一夜就可以实现的。同样，尝试着使用你认 为对你很有帮助的方法，确实收到效果之后，在考虑继续学 习方法。因为上面提到的都是需求分析的大方法，事实号、 记录业务规范、创立需求跟踪能力矩阵、审查需求文档、以 需求为依据编写测试用例、编写用户手册、确定合格的标 准。二、业务建模 很多人都没有意识到业务需求阶段应该做些什么事情，实际 上业务建模是最重要的一件事情。不要觉得业务建模这个词 很深奥，让人模不着头脑。其
18、实所有做过需求分析的人都做 过业务建模，比方你了解企业的运作模式就?是一种你脑海中 的业务建模。但是大多数人都没有科学的、系统的、文档化 的做过业务建模。业务建模的目的在于：了解目标组织的结构和机制（系统将在其中部署的组织）。了解目标组织中当前存在的问题，并确定改进的可能性。确保客户、最终用户和开发人员对目标组织达成共识。导出支持目标组织所需的业务需求。上面的话是不是很抽象呢，其实没有什么复杂的：人和电脑 是完全不同的思想（思维方式）。所以，原先适合人的业务 流程对于计算机来说可不一定合适的，为了最大限度的利用 计算机，必须要了解原先的业务流程并对此加易改造（流程 自动化），当然这些动作需要得
19、到用户的许可。有些人认为 说只有ERP这种大系统才需要对业务流程进行重组，但是实 际，不管是部门级的MIS系统，还是社会级的电子商务系 统，都需要对业务流程进行改造，所不同的只是改造的程 度。业务建模很重要的一点是在分析企业流程的同时分析出基础(这个词我翻译的不(这个词我翻译的不企业对象(CommonBusinessObject) 好，如果大家有更好的翻译，请告诉我)。任何企业都有最 基础的一些元素，例如银行的CBO就有帐户，制造业的CB对 多，订单和产品之间又是一对多，这样一个多对多的关系就 拆分成两个一对多的关系，而新的订单类也就顺理成章的产 生了。在订单类产生时，你可能还会加入一个关联类
20、：业务 员类。而业务员类又是从员工类继承下来的。所以呢，企业 的四种CBO通过不同的组合，不同的关系，能够形成企业运作的许许多多的CBO。CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业务流程， 改进业务流程的定义，设计业务流程实现，改进角色和职 责，研究流程自动化，开发领域模型等一系列在RUP中定义 的工作流程实现业务建模的目标。三、需求获取需求获取(requirementelicitation)是需求工程的主体。对 于所建议的软件产品，获取需求是一个确定和理解不同用户 类的需要和限制的过程。获取用户需求位于软件需求三个层 次的中间一层。业务需求决定用户需求，它描
21、述了用户利用 系统需要完成的任务。从这些任务中，分析者能获得用于描 述系统活动的特定的软件功能需求，这些系统活动有助于用 户执行他们的任务。需求获取是在问题及其最终解决方案之 间架设桥梁的第一步。获取需求的一个必不可少的结果是对 工程中描述的客户需求的普遍理解。一旦理解了需求，分析 者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设 计系统，否那么，对需求定义的任何改进，设计上都必须大量 的返工。把需求获取集中在用户任务上一而不是集中在用户 接口上一有助于防止开发组由于草率处理设计问题而造成的 失误。需求获取、分析、编写需求规格说明和验证并不
22、遵循 线性的顺序，这些活动是相互隔开、增量和反复的。当你和 客户合作时，你就将会问一些问题，并且取得他们所提供的 信息(需求获取)。同时，你将处理这些信息以理解它们， 并把它们分成不同的类别，要交流的方面。需求获取只有通 过有效的客户一开发者的合作才能成功。分析者必须建立一 个对问题进行彻底探讨的环境，而这些问题与产品有关。为 了方便清晰地进行交流，就要列出重要的小组，而不是假想 所有的参与者都持有相同的看法。对需求问题的全面考察需 要一种技术，利用这种技术不但考虑了问题的功能需求方,还可讨论工程的非功能需求。确定用户已经理解：对于 某些功能的讨论并不意味着即将在产品中实现它。对于想到 的需求
23、必须集中处理并设定优先级？，以防止一个不能带来任 何益处的无限大的工程。需求获取是一个需要高度合作的活 动，而并不是客户所说的需求的简单善本。作为一个分析 者，你必须透过客户所提出的外表需求理解他们的真正需 求。询问一个可扩充(open-ended)的问题有助于你更好地 理解用户目前的业务过程并且知道新系统如何帮助或改进他 们的工作。调查用户任务可能遇到的变更，或者用户需要使 用系统其它可能的方式。想像你自己在学习用户的工作，你 需要完成什么任务？你有什么问题？从这一角度来指导需求 的开发和利用。还有，探讨例外的情况：什么会阻碍用户顺利完成任务？对 系统错误情况的反映，用户是如何想的？询问问题
24、时，以“还有什么能“，当？时，将会发生什么”“你有没有曾经 想过“，“有没有人曾经“为开头。记下每一个需求的来源, 这样向下跟踪直到发现特定的客户。有些时候，尝试着问一些“愚蠢”的问题也有助于客户翻开 话匣子。如果你直接要求客户写出业务是如何实现的，客户 十有八九无法完成。但是如果你尝试着问一些实际的问题， 例如：“以我的理解，你们收到订单后，会。客户立刻 就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就 在一边仔细的聆听吧。这一招就叫做“抛砖引玉”O 需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟 练的人把所有的讨论记录下来，记录的同时还要做一定的整 理。如果不这样做，那么你结束会
25、议的时候就会发现，所有 的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥 远的事情。在座谈讨论之后，记下所讨论的条目(item),并 请参与讨论的用户评论并更正。及早并经常进行座谈讨论是 需求获取成功的一个关键途径，因为只有提供需求的人才能 确定是否真正获取需求。进行深入收集和分析以消除任何冲 突或不一致性。尽量把客户所持的假设解释清楚，特别是那些发生冲突的部 分。从字里行间去理解以明确客户没有表达清楚但又想加入 的特性或特征。Gause和Weinberg (1989)提出使用“上下 文无关问题“一这是一个高层次的问题，它可以获取业务问 题和可能的解决方案的全部信息。客户对这些问题的回答诸
26、 如“产品要求怎样的精确度”或“你能帮我解释一下你为什 么不同意某人的回答吗？ ”这些回答可以更直接地认识问 题，而这是封闭(close-end)问题所不能做到的。需求获 取利用了所有可用的信息来源，这些信息描述了问题域或在 软件解决方案中合理的特性。一个研究说明：比起不成功的 工程，一个成功的工程在开发者和客户之间采用了更多的交 流方式(KielandCarmell995)。与单个客户或潜在的用户组 一起座谈，对于业务软件包或信息管理系统(MIS)的应用来 说是一种传统的需求来源。直接聘请用户进行获取需求的过 程是为工程获得支持和买入(buy-in)的一种方式。试着去理解用户用来表达需求的思
27、维过程。充分研究用户 执行任务时做出决策的过程，提取潜在的逻辑关系。流程图 和决策树是描述这些逻辑决策路径的好方法。在需求获取的过程中，你可能会发现对工程范围的定义存在 误差，不是太大就是太小。如果范围太大，你将要收集比真 正需要更多的需求，以传递足够的业务和客户的值，此时获 取过程将会拖延。如果工程范围太小，那么客户将会提出很 重要的但又在当前产品范围之外的需求。当前的范围太小, 以致不能提供一个令人满意的产品。需求的获取将导致修改 工程的范围和任务，但作出这样具有深远影响的改变，一定 要小心谨慎。正如经常所说的，需求主要是关于系统做什 么，而解决方案如何实现是属于设计的范围。这样说虽然很
28、简洁，但似乎过于简单化。需求的获取应该把重点放在“做 什么”上，但在分析和设计之间还是存在一定的距离。你可 以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概 念表达得更加清楚，然后提供一个寻找错误和遗漏的方法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高 效交流的概念性建议，而不应该看成是对设计者选择的一种 限制。需求获取讨论会中如果参与者过多，就会减慢进度。 人数大致控制在5到7人是最好的。这些人包括客户、系统 设计者、开发者和可视化设计者等主要工程角色。相反地， 从极少的代表那里收集信息或者只听到呼声最高、最有舆论 影响的用户
29、的声音，也会造成问题。这将导致忽视特定用户 类的重要的需求，或者其需求不能代表绝大多数用户的需 要。最?好的权衡在于选择一些授权为他们的用户类发言的产 品代表者，他们也被同组用户类的其它代表所支持。没有一 个简单、清楚的信号暗示你什么时候已完成需求获取。当客 户和开发者与他们的同事聊天、阅读工业和商业上的文献及 在早上沐浴时思考时，他们都将对潜在产品产生新的构思。 你不可能全面收集需求，但是以下的提示将会暗示你在需求 获取的过程中的返回点。L如果用户想不出更多的用例，也许你已经完成了收集需 求的工作。用户总是按照重要性的顺序来决定用例。2 .如果用户提出了新的用例，但是你可以从其他用例的相 关
30、功能需求中得到这些新用例，那么也许你已经完成了收集 需求的工作。这些新的用例可能是您已经获得的其他用例的 可选过程。3 .如果用户开始重复之前讨论的问题，此时，也许你已经 完成了收集需求的工作。4 .如果提出的新需求的优先级比你已经确定的低，也许你 已经完成了收集需求的工作。5 .如果用户提出对将来产品的要求，而不是现在我们讨论的 特定产品，也许你就完成了收集需求的工作。以上知识大致上讨论需求分析应该如何做，实际上对于需求 分析的方法有很多很多，已经形成了一定的用例在需求分析 中的使用。多年来，分析者总是利用情节或经历来描述用户和软件系统 的交互方式，从而获取需求(McGrawandHarbi
31、sonl997)。 IvarJacobson (1992)把这种看法系统地阐述成用例(用 例)的方法进行需求获取和建模。虽然用例来源于面向对象 的开发环境，但是它也能应用在具有许多开发方法的工程 中，因为用户并不关心你是怎样开发你的件。而最重要的， 用例的观点和思维过程带给需求开发的改变比起是否画正式 的用例图显得更为重要。注意用户要利用系统做什么远远强 于询问用户希望系统为他们做什么这一传统方法。用例的重 要功能是用画用例图的功能来鉴别和划分系统功能。它把系 统分成角色(actor)和用例(用例)。角色(actor)表示系 统用户能扮演的角色(role) o这些用户可能是人，可能是 其他的计
32、算机一些硬件或者甚至是其它软件系统，唯一的标 准是它们必须要在被划分进用例的系统局部以外。它们必须 能刺激系统局部并接收返回。用例描述了当角色给系统特定 的刺激时系统的活动。这些活动被文本描述。它描述了触发 用例的刺激的本质，输入和输出到其他活动者，和转换输入 到输出的活动。用例文本通常也描述每一个活动在特殊的活 动线时可能的错误和系统应采取的补救措施。这样说可能会 非常复杂，其实一个用例描述了系统和一个角色(actor)的 交互顺序。用例被定义成系统执行的一系列动作，动作执行 的结果能被指定角色发觉到。用例可以:用例捕获某些用户可 见的需求，实现一个具体的用户目标。用例由角色激活，并 提供确
33、切的值给角色。用例可大可小，但它必须是对一个具 体的用户目标实现的完整描述。在UML中，用例表示为一个 椭圆。角色是指用户在系统中所扮演的角色。其图形化的表 示是一个小人。在某些组织中很可能有许多角色实例(例如 有很多个销售员)，但就该系统而言，他们均起着同一种作 用，扮演着相同的角色，所以用一个角色表示。一个用户也 可以扮演多种角色。例如，交换。单个角色可与多个用例联 系；反过来，一个用例可与多个角色联系。对同一个用例而 言，不同角色有着不同的作用：他们可以从用例中取值，也 可以参与到用例中。需要注意的是角色在用例图中是用类似 人的图形来表示，尽管执行的，但角色未必是人。例如，角 色也可以是一个外界系统，该外界系统可能需要从当前系统 中获取信息，与当前系统有进行交互。