软件需求分析与建模-(1)
软件需求分析与系统建模
软件需求分析与系统建模软件需求分析是软件开发过程中非常重要的一环。
通过对用户和相关利益相关者需求的充分了解和合理分析，可以为软件开发团队提供准确的指导和参考。
系统建模作为软件需求分析的一种手段，可以帮助开发团队更好地理解和描述系统的各个方面。
本文将围绕软件需求分析与系统建模展开论述，以期给读者带来一些有益的理解和启发。
一、软件需求分析概述软件需求分析是指对软件开发过程中的需求进行识别、分析和规范的过程。
它主要包括需求收集、需求分析、需求规范等环节，旨在确保软件开发团队对用户需求有清晰准确的理解，并以此为基础进行后续的系统设计和开发工作。
在软件需求分析过程中，开发团队需要广泛倾听用户和利益相关者的意见和建议，通过有效的沟通和反馈机制，不断完善和优化需求规范。
二、软件需求分析的重要性软件需求分析的重要性不言而喻。
只有充分理解用户需求，并准确地进行需求规范，才能确保最终开发出的软件能够满足用户的期望和要求。
软件需求分析过程中的细节决定了后续开发过程中的成败，所以要特别注意。
三、软件需求分析的方法和技巧在软件需求分析过程中，采用合适的方法和技巧可以提高分析的效果和准确性。
常用的软件需求分析方法包括面谈法、问卷调查法、观察法等，这些方法可以帮助开发团队获取用户需求的相关信息。
此外，需求分析人员还要具备良好的沟通和分析能力，能够准确理解用户需求，并将其转化为可执行的开发任务。
四、系统建模在软件需求分析中的作用系统建模是一种用图形化的方式对系统进行描述和表示的方法。
它可以帮助开发团队更好地理解和分析系统的各个方面，包括系统的结构、功能、关系等。
在软件需求分析过程中，系统建模可以通过绘制用例图、活动图、状态图等方法，让开发团队对系统需求有一个直观的印象。
系统建模可以有效地帮助开发团队与用户进行沟通和反馈，避免沟通误差和需求偏差。
五、结语软件需求分析与系统建模是软件开发过程中不可或缺的环节。
只有深入了解用户需求，通过合适的方法和技巧分析和规范需求，才能确保开发出满足用户期望的优质软件。
需求分析和系统建模(1)
第2章需求分析和系统建模一旦获得并整理出软件系统的各种需求，并通过特定的形式加以描述，然后再得到客户的认可之后，就需要对软件系统的需求进行分析，并最终能够建立软件系统的分析模型。
通过建立软件系统的分析模型，可以捕获到独立于软件系统具体实现技术细节之外的各种信息和预期行为，而这些内容与使用的开发语言、开发平台、部署的应用服务器等都是无关的。
如果对软件系统的设计活动是基于系统的分析结果而得到的，那么软件系统的开发人员可以更加确信开发出的应用系统项目将是一个完全按照用户需求构建的应用系统。
如何有效地进行需求分析并建立正确的系统分析模型?通过对软件系统中的需求进行分析，开发者最终能够获得什么结果呢?如何熟练应用可视化的建模工具?这都是读者感兴趣的问题，本章将介绍如何进行软件系统的需求分析和系统建模等内容，并通过详细的图示和实现步骤来说明在Rational Rose工具中的具体实现方法。
2.1 Rational Rose对UML建模的支持2.1.1 Rational Rose 2003工具概述1．Rational Rose工具概述（1）Rational Rose工具是美国Rational公司（即现在的IBM公司）开发的面向对象建模工具。
利用这个面向对象建模工具，开发者可以建立用UML描述的软件系统的各种模型，而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码，达到先建模后编码的效果。
（2）Rational Rose工具是个菜单驱动应用程序，用工具栏帮助开发者使用常用特性。
它默认支持大多数流行的编程语言，包括C++、Ada、CORBA、Java、COM、VB、XML、Oracle、VC等；另外还能通过添加第三方Add-Ins插件组件，来支持其他的编程语言。
（3）Rational Rose工具支持统一建模语言。
统一建模语言（UML）是由Rational公司3位世界级面向对象技术专家Grady Booch、Ivar Jacobson和Jim Rumbaugh通过对早期面向对象研究和设计方法的进一步扩展而得来的，它为可视化建模软件奠定了坚实的理论基础。
软件需求分析与建模
信息隐蔽原则建议模块应该具有的特征是：每个模块对其他所有 模块都隐蔽自己的设计决策。 信息隐蔽意味着通过一系列独立的模块可以得到有效的模块化。 独立的构件或模块之间的“接口”简单而清晰。
逐步求精，或称逐步细化，是一种自顶向下的设计策略。连续精 化软件的层次结构，逐步细化来实现软件开发，逐步功能分解的 过程抽象，直至形成程序设计语句。
软件设计过程 模块化设计原理 模块独立性度量 软件组成结构 软件体系结构
ห้องสมุดไป่ตู้
软件设计阶段的基本目标是构造系统“怎么做”的模
型描述。 “设计先于编码”，这是软件工程“推迟实现”基本 原则 软件系统设计是把软件需求“变换”为用于构造软件 的蓝图。
“输入”是需求分析各种模型元素
“输出”是软件设计模型和表示
4.2 人机界面设计规约 4.3 外部接口设计 外部数据接口 外部系统或设备接口 4.4 内部接口设计规约 5 （每个模块）过程设计 5.1 处理说明 5.2 接口描述 5.3 设计语言描述 5.4 使用的模块 5.5 内部设计结构 5.6 注释/约束/限制 6 需求交叉索引 7 测试部分 7.1测试方针 7.2 集成策略 7.3 特殊考虑 8 附录（包括特殊注解）
过多关联的模块。 模块独立性两大优点：
独立的模块由于分解了功能，简化了接口，使得软件比
较容易开发； 独立的模块比较容易测试和维护。
模块独立性由两个定性标准度量： 模块自身的内聚（Cohesion）），也称为块内联系或模 块强度， 模块之间的耦合（Coupling)，也称为块间联系。 模块独立性愈高，则块内联系越强，块间联系越弱。
模块是一个独立命名的，拥有明确定义的输入、输出和特性的程 序实体。
把一个大型软件系统的全部功能，按照一定的原则合理地划分为 若干个模块，每个模块完成一个特定子功能，所有的这些模块以 某种结构形式组成一个整体，这就是软件的模块化设计（Modular Design）。 软件模块化设计可以简化软件的设计和实现，提高软件的可理解 性和可测试性，并使软件更容易得到维护。
软件工程中的需求分析与建模
● 03
第3章 需求建模技术
需求建模概述
需求建模是软件工程中的一个重要环节，通过对需求 进行建模，可以更清晰地理解和定义系统需求。需求 建模的目的是为了准确地捕获用户需求，确保软件开 发过程中不会遗漏任何重要需求。同时，需求建模还 可以帮助团队更好地沟通和协作，提高项目的成功率。
用例建模
用例是描述系统功能的一种有效方式。通过用 例建模，可以清晰地定义系统的功能和用户与 系统之间的交互。用例图可以直观地展示系统 的功能和不同用户角色之间的交互关系。用例 描述则详细描述了每个用例的具体行为和步骤。
意度。
需求变更频繁
导致开发过程混乱
需求不明确
影响产品质量
沟通不畅
导致需求误解
面临的挑战
可能的改进方向
采用敏捷开发模式
迭代开发 持续集成 快速反馈
加强需求管理
建立需求数据库 制定明确需求文档 实施变更控制
提高沟通效率
定期沟通会议 使用协同工具 建立需求反馈渠道
展望未来
未来在软件工程领域，人工智能技术的发展将为需求 分析带来更多可能性，大数据技术的应用将提升需求 建模的精度，需求管理工具的不断创新将提高团队效 率。
测试
单元测试 集成测试
软件工程发展历程
软件工程的发展经历了多个阶段，从最初的混沌时期 到逐渐建立起规范的软件开发流程和方法。随着科技 的不断进步，软件工程也在不断演变和完善。
● 02
第二章 需求分析基础
需求分析概述
需求分析是软件工程中至关重要的一部分，它 涉及定义、识别和规范软件开发项目中的需求。 通过需求分析，可以确保开发团队在项目开始 阶段清晰了解客户的需求，明确目标和方向。 需要对需求进行系统性的分析，以确保最终的
软件设计师中的软件需求分析与建模方法
软件设计师中的软件需求分析与建模方法在软件开发过程中，软件需求分析与建模是至关重要的环节，它们帮助软件设计师深入了解客户需求，并将其转化为可行的软件方案。
本文将介绍软件设计师中常用的软件需求分析与建模方法，包括面向对象分析与设计（OOAD）、UML建模语言以及用户故事。
一、面向对象分析与设计（OOAD）面向对象分析与设计（Object-Oriented Analysis and Design，OOAD）是一种常见的软件需求分析与建模方法。
它以对象为中心，将系统建模为一系列相互关联的对象，并通过定义对象的属性和行为来描述系统。
OOAD方法有助于设计师理清系统的功能、对象之间的关系以及交互方式。
在OOAD中，常用的建模方法包括用例图、类图、时序图和活动图等。
用例图用于描述系统的功能需求，通过显示系统与外部实体（用户、其他系统等）之间的交互来展示系统的行为。
类图展示了系统中各个类的属性、方法和关系，帮助设计师理解系统的结构和组成。
时序图用于描述对象之间的交互顺序和消息传递过程，便于分析系统中的时序逻辑。
活动图则展示了系统中的业务流程和操作行为，有助于设计师理解系统的业务逻辑。
二、UML建模语言统一建模语言（Unified Modeling Language，UML）是一种常用的软件需求分析与建模工具，它提供了丰富的图表和符号，方便设计师进行系统建模和描述。
UML中常用的图表包括用例图、活动图、类图、时序图、状态图等。
用例图用于描述系统的功能需求和行为，展示了各个参与者（角色）与系统之间的交互。
活动图描述了系统的业务流程和操作行为，有助于设计师理解系统的工作流程。
类图描述了系统的结构和组成，展示了类之间的关系和属性。
时序图用于描述对象之间的交互顺序和消息传递过程，方便设计师分析系统的时序逻辑。
状态图描述了对象在系统中的状态转换和行为变化，帮助设计师分析系统的状态变化。
UML作为一种标准化的建模语言，广泛应用于软件开发过程中，通过图表和符号的方式，使得需求分析和建模更加直观、易于理解。
第3章软件需求分析与建模
软件工程教研室
2
3.1 需求分析
系统工程
需求分析是软件设计的基础，需
求分析建造了软件处理的数据模型、
功能模型和行为模型。
软件需 求分析
软件设计
需求分析是开发者对待开发软件项目的“理解、分解 与表达”的过程，指明系统必须实现什么的规格说明，而 并非产品的设计、构造特征和方法，也就是说需求定义描 述的是“系统要做什么”，而不是“系统如何做”。它是 从逻辑上确定系统功能，并用图表和文字建立新系统的逻 辑模型。
的数据、用户程序与其它程序间的处理、系统隔离与系统
备份要求；
(10)软件成本消耗与开发进度：开发的时间规定、软硬件投资
有无限制；
(11)质量保证：系统的可靠性要求、系统是否要监测和隔离错
误、规定系统平均出错时间、出错后重启系统允许的时间、
维护是否包括对系统的改进、系统的可移植性。
(12)各种计划、单据和报表的处理：计划单据和报表都是信息
2020/4/5第3章软件需求分析与建模
软件工程教研室
性； (6)文档：文档类型和种类、使用对象； (7)数据：输入/输出数据的格式、数据的准确性和精度、数
据量、数据需保持的时间；
2020/4/5第3章软件需求分析与建模
软件工程教研室
6
(8)资源：软件运行时所需的数据、软件、内存空间等，软件
开发、维护所需的人力、支撑软件、开发设备等。
(9)安全保密：对访问系统或系统信息的控制、隔离用户之间
2020/4/5第3章软件需求分析与建模
软件工程教研室
11
（4）设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于 为用户接受的。 （5）查阅档案记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、 报表等。 3、处理 通过调查了解了用户需求后，还需要进一步分析和表达 用户的需求，并建立快速原型，以便于进行技术评审。
软件需求分析和建模
易变问题：分清需求稳定部分和易变部分
收集活动： 识别真正的客户/用户 正确理解客户的需求
耐心听取客户意见和思考
尽量使用符合客户语言习惯的表达
25/150
2.3 分析和精化
开发一个精确的技术模型，用以说明软件的功能、 特征和约束。
精化是一个分析建模动作，由一系列建模和求精 任务构成
2.1.2 扩展流程：......
31/150
系统需求
系统需求是比用户需求更详细的需求描述，是系 统实现的基本依据
系统需求描述可能包括许多不同的模型，如对象 模型和数据流模型
32/150
软件需求各组成部分之间的关系
33/150
软件需求规格说明的原则
从现实中分离功能，即描述要“做什么”而不是 “怎样实现”
用户交流不够 需求规约质量差 低效的需求分析
有拓展性的系统设计，才会给 系统更大的扩展空间，从而在 需求发生变化的时候可以更从 容的修改。
13/150需求分析的Fra bibliotek要性需求的重要性： 需求是产品的根源，需求工作的优劣对产品影响最大。 是系统开发的基础，质量和成败的关键 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一 直忙碌不停地开发。
软件工程方法与实践
软件需求分析与建模
..
1
主要问题
什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 什么是面向数据的建模？ 什么是面向数据流的建模？ 什么是非形式化建模、半形式化建模和形式化建模？ 什么是统一建模语言（UML）？ 什么是用例建模？ 什么是领域模型？
2/150
软件需求分析过程
软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“产品”， 它是客户、管理者、分析工程师、测试工程师、 维护工程师交流的标准和依据。
软件需求分析与系统建模
软件需求分析与系统建模软件需求分析是软件开发过程中的关键步骤之一，它是在系统开发的初期，对用户需求进行深入分析和理解的过程。
通过软件需求分析，可以准确地确定系统的功能需求、性能需求、安全需求等，为后续的系统设计和开发工作提供指导和参考。
在需求分析的过程中，系统建模是一种有效的方法，它能够以图形化的方式表达系统的各种模块、组件、操作和数据之间的关系，帮助开发团队更好地理解和描述系统的结构和行为。
本文将介绍软件需求分析与系统建模的相关知识和方法。
一、软件需求分析软件需求分析是系统工程中的一项基础性工作，它主要包括以下几个方面：1.1 需求收集需求收集是软件需求分析的第一步，它通过与用户、管理人员、开发团队等进行沟通和交流，获取到系统的需求信息。
需求收集的过程中，可以采用面对面访谈、问卷调查、文档分析等方法，确保获取到全面、准确的需求信息。
1.2 需求分析需求分析是对需求进行分类、整理和分析的过程。
在需求分析的过程中，可以使用需求建模技术，将需求分解为不同的功能模块或子系统，以便更好地进行后续的设计和开发工作。
1.3 需求验证需求验证是验证需求的合理性和正确性的过程，它通常包括需求评审、原型验证、用户验收等环节。
通过需求验证，可以确保系统需求符合用户的期望和要求。
二、系统建模系统建模是通过图形化的方式描述系统的各种组成部分和它们之间的关系。
常用的系统建模方法有数据流图、用例图、类图等。
下面将分别介绍这些系统建模方法的基本原理和使用场景。
2.1 数据流图数据流图是一种图形化工具，用于描述系统中数据的流动和处理过程。
数据流图由数据流、处理、数据存储和外部实体等要素组成，通过连接和箭头来表示它们之间的关系和交互。
数据流图适用于描述系统的数据流程和功能。
2.2 用例图用例图是一种描述用户与系统之间交互的图形化工具。
用例图由参与者、用例和关系等要素组成，通过参与者和用例之间的连线来表示它们之间的交互关系。
用例图适用于描述系统的功能需求和用户需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
进系统。 系统在屏幕上给出该图书的“书名”、“作者”、“出版社”、
“单价”、“出版日期”、“架存册数”等信息； 2．售书员输入图书册数。 如果图书册数大于当前图书架存数，系统在屏幕上给出提示，并
告诉修改册数。 ** 重复前两步，直到把该读者所要购买的所有图书输入系统。 3．系统打印出该读者的三联购书书单。 **读者持书单到收款台交款。 4．收款员扫描书单号，收款员界面显示该读者购书信息。 5．收款员把读者给的书款数额输入系统，并按收款确认键。 ** 收款员给书单上盖章，并自己留存一联，其它两联给读者。读
概念类主要来源于业务领域中的客观实体、 系统与外界的交互处理和对系统要素的控 制三个方面。
概念类面向用户需求，一般不考虑性能要 求，具有突出业务领域、突出概念性及大 粒度的特征。
概念类的类型
UML把概念类分为实体类、边界类和控制 类三种类型，并表示成为下图所示的两种 形式。
形式1：
形式2：
实体类
实体
概念类字典由概念类目录和概念类条目两 部分构成。
1．概念类目录
书店信息销售管理系统概念类目录见表6-1。 目录中列出了书店信息销售管理系统逻辑模型中 的概念类。概念类条目编号的规则是： 第1位表示该概念类的顶层逻辑包，用字母表示。 其中，A表示计划订购，B表示书库管理，C表示 图书销售，D表示事务处理，Q表示公用概念类。 第2位是概念类的类型。其中，1表示实体类，2 表示边界类，3表示控制类。 后两位是顺序号。例如，C-2-01表示“售书界面” 属于“图书销售”逻辑包中界面类的第一个概念 类。
把盘架信息提交到打印机进行打印
C-3-14
C-3-15 C-3-16 C-2-09 C-1-08 C-1-09 C-3-17 C-3-18 C-3-19
C-3-20
清空盘架单 盘架查询界面 盘架单信息 接收盘架查询 浏览盘架单 显示盘架单 定位盘架单
删除盘架单 报损界面 报损图书信息
把盘架单屏幕清空，以便售书员重 新输入数据 售书员与系统的交互界面
把架存信息提交到打印机进行打印
删除架存图书
把架存信息从数据库中删除
盘架界面
售书员与系统的交互界面
盘架图书信息
待盘架的图书的基本信息
盘架图书
每次盘架图书的基本信息
接收待盘架图书 信息 保存盘架单
接收待盘架图书的书号、数量 保存盘架单到数据库中
提交盘架单 打印盘架单
提交盘架单到数据库中，信息一但 提交就不能进行修改
在软件需求分析中，通过对需求模型中 的每一个用例的分析，得到了对应于需 求模型中用例的用例分析结果。用例分 析与用例之间存在一一对应的跟踪关系， 可以从用例分析追踪到用例（见下图）。
需求模型 用例
《跟踪》
逻辑模型
用例分析
用例分析类图 用例分析协作图
用例分析类图（UseCase Analysis Class Diagram）用来描述一个用例中 的概念类之间的关系所呈现出的静态 结构。
接收待上架图书的书号和册数 提交上架信息到数据库中，同时增 加数据库中的架存数目 按查询条件把满足条件的上架图书 信息显示给售书员
C-2-06 C-2-07 C-2-08 C-1-04 C-1-05 C-1-06 C-1-07 C-3-11 C-3-12
C-3-13
查询架存图书 打印架存报表
按查询条件把满足条件的架存图书 信息显示给售书员
定概念类之间的关系，以及绘制用例分析类 图和用例分析交互图三项工作。 （2）概念类分析
概念类分析（Conception Class Analysis） 是对所提取的各概念类的职责、属性、关系 和特殊需求所进行的分析。
概念类（Conception Class）是在概念 层次上，对系统的抽象要素的一种称谓。
例如，“售书界面”用来抽象地描述售 书员与书店系统的交互处理，见图。
售书员
售书界面
控制类（Control Class）是表示系统对 其它对象实施协调处理、逻辑运算的抽象 要素。
例如，在书店系统中，“出售图书”就属 于控制类，见下图。
售书
售书界面
出售图书
架存图书 售出图书
第一步： 用例分析
1．概述 用例分析是指从概念层次上对一个 用例的分析及分析的结果。 用例分析的结果有两种图： 1）用例分析类图表示用例概念类结 构； 2）用例分析协作图表示各概念类之 间动态交互信息。
2 属性的命名
（1） 使用名词或带定语的名词。像“姓 名”，“学生姓名”，“型号”，“产品 型号”，“商品条形码”等。
（2） 尽量使用问题域中规范、通用的词 语，避免使用没有明确含义或自定义的词 语。
2） 属性的类型 属性的类型是指属性值的类型，一般有 数字型、字符型、逻辑型、日期型等。在 软件需求阶段一般不需要确定属性的类型。
通过整个消息的传递来实 现用例的过程。下图是对应于上 图的用例分析协作图。
“售书处理”的用例分析协作图
“售书处理”的用例分析协作图
:书目 3:取书目信息
1:书号及册数 2:书号及册数
5:待售图书
6:待售图书
7:书单
:售书员
图书信息
:售书界面
:产生待售图书
:待售图书
:开书单
4:图书信息
8:待售图书
10:售出图书
图书的基本信息
出库图书
出库图书的基本信息
出库图书信息
待出库图书的基本信息
条目编号 C-2-01 C-3-01 C-3-02 C-3-03
C-3-04 C-3-05 Q-1-01 C-1-01 C-1-02
查询出库界面 出库单信息 接收出库查询 删除出库单 浏览出库单 定位出库单
显示出库单 图书销售界面 图书上架界面 查询上架界面
软件需求分析
软件需求的含义及特点
软件需求（Software Requirements）是在 业务需求分析和用户需求分析的基础上，从抽 象的概念层次上确定系统的要素、构成和结构， 得出系统的逻辑模型，并为系统设计提供依据。
特点：
（1） 内在性:站在系统内部的角度，分析软 件系统的要素、构成和结构。
:打印进程
9:减架存数量
:架存图书
:出售图书
:售出图书
用例分析一般需要经过三个步骤：
●第一步，提取用例的概念类。包括实 体类，边界类，控制类。
●第二步，确定用例中概念类之间的关 系，并绘制用例分析类图。概念类之间有 关联关系、泛化关系和依赖关系，其中主 要是关联关系。
●第三步，分析参与者与用例所交互的 信息，以及用例中各概念类之间所交互的 信息，并得出用例分析交互图。
7:书单
:售书员
图书信息
:售书界面
:产生待售图书 :待售图书
:开书单
4:图书信息
8:待售图书
10:售出图书
:打印进程
9:减架存数量
:架存图书
:出售图书
:售出图书
图 “售书处理”的用例分析交互图
第二步：概念类分析
1．属性的概念 一般讲，属性表示实体的特性或特征。 在OO方法中，属性用来表示对象的静 态特性。 例如，对象“人”的属性有：姓名、 性别、出生年月、家庭住址、电话、体 重、身高、血型、爱好、职业、毕业院 校、专业等。
者持书单又回到售书员处，把已交款后的书单交给售书员。 售书员扫描书单号，并按“售出图书”键。 ** 售书员给图书上盖章，并把图书交给读者，售书结束。
1、 提取概念类 边界类：售书界面 实体类：书目，架存图书，待售图书，售出图书 控制类：产生待售图书，开书单，出售书单
售书界面 产生待售图书 开书单 出售图书 书目 架存图书 待售图书 售出图书
如果一个类中因属性项目过多，使得类过于庞大，可 以根据这些属性的相关性，把一个类分成多个类，以 简化类的规模。
几个概念的属性：
“书目”：书号、书名、作者、 出版社、单价、出版日期、图书类 别。
“售书界面”：图书书号，图书 信息。
“产生待售图书”：没有属性。
第四步、概念类字典化
概 念 类 字 典 （ Conception Class Dictionary）用来记录软件需求中提取的概 念类，并对概念类进行说明。
边界类 边界
控制类 控制
书目
书单
书款
实体类（Entity Class）是系统表示客观实体 的抽象要素。
例如，书店中的“书目”、 “书单”、“书 款”等。
实体类一般对应着在业务领域中的客观事物， 或者是具有较稳定信息内容的系统元素。
实体类来源于业务分析中所确定的实体，实 体字典是确定实体类的依据。
边界类（Boundary Class）是描述系统 与参与者之间交互的抽象要素。边界类只 是对系统与参与者之间交互的抽象建模， 并不表示交互的具体内容及交互界面的具 体形式。
“图书销售：售书处理”用例分析
售书员
销售图书
售书处理
《包含》
收书款
浏览图书销售信息
打印图书销售报表
收款员
销售图书的过程用例图
图书销售管理::销售图书::售书处理
编号：03-05-01 参与者：售书员，收款员 所在包：图书销售管理::销售图书 说明：售书员在“图书销售管理”中的“销售图书”中选择“售书
（2） 概念性： 第一，面向业务领域，反映业务概念； 第二，在较宏观和抽象的层次进行分析工
作，一般不过多涉及具体细节； 第三，不涉及系统的实现环境。
（3） 一致性:软件需求所确定逻辑模型应该 具有逻辑一致性，它要纠正需求模型中存在 的冗余及错误。
软件需求的主要工作
（1）用例分析 用例分析包括提取用例涉及的概念类，确