领域需求建模规范0316
医疗器械风险管理0316培训课件pptx
创新驱动
鼓励创新思维和方法，探索更有效的风险控 制手段。
跨部门合作
加强跨部门之间的沟通和协作，共同推进风 险控制的持续改进。
动态调整
根据外部环境和内部条件的变化，动态调整 风险控制策略和措施。
05
医疗器械风险管理培训与意 识提升
培训需求分析
组织内外部环境分析
识别组织在医疗器械风险管理方面的 优势和不足，以及面临的机遇和挑战 。
进入21世纪，医疗器械风险管理在 全球范围内得到广泛推广和应用， 成为医疗器械监管的核心内容。
02
医疗器械风险识别
风险来源与分类
设备设计缺陷
由于产品设计不合理、 考虑不周全等因素，可
能带来使用风险。
生产制造缺陷
生产过程中出现的质量 问题，如零件损坏、装
配错误等。
使用环境风险
设备使用环境不符合要 求，如温度、湿度、压
风险评估结果分析
风险排序
根据风险评估结果，对医疗器械的风险进行排序，确定高风险、中等风险和低风 险级别。
风险分析报告
编写风险分析报告，对评估结果进行详细分析和解释，并提出相应的风险控制措 施和建议。
风险评估报告编写
报告内容
风险评估报告应包括风险识别、风险分析、风险评价和风险 控制等方面的内容，以及相应的数据、图表和结论。
总结词：快速响应
详细描述：某医疗器械公司针对不良事件采取了快速响应策略，及时发现、报告 并处理问题。通过建立有效的信息反馈机制，确保不良事件得到及时处理，并采 取措施防止类似事件再次发生。
案例三：某医疗器械召回事件的风险控制措施
总结词：预防为主
详细描述：某医疗器械公司在召回事件中采取了预防为主的风险控制措施，对产品进行严格的质量检 测和风险评估，提前发现潜在问题并及时采取措施解决。同时，加强与监管部门的沟通与协作，确保 召回工作顺利进行。
一文读懂软件开发的国家标准和行业准则
一文读懂软件开发的国家标准和行业准则软件开发作为信息技术领域的核心活动，其标准化和规范化对于保障软件质量、提高开发效率以及确保信息安全具有重要意义。
本文将为您详细解读软件开发的国家标准和行业准则，帮助您了解和遵循这些规范，以确保软件开发过程的合规性和产品的高质量。
一、国家标准国家标准是指由国家相关管理部门制定和发布，在全国范围内统一的技术规范。
在软件开发领域，国家标准主要包括以下几个方面：1.1 软件工程基础标准软件工程基础标准涉及软件开发过程中的基本概念、术语、符号、图形等。
这些标准确保了软件开发各环节的沟通一致性，如GB/T 11457（软件工程术语）和GB/T 8566（软件需求规格说明书规范）。
1.2 软件开发过程标准软件开发过程标准规定了软件开发各阶段的任务、方法和工具使用，如GB/T 15532（软件生命周期过程）和GB/T 26260（软件工程项目管理）。
1.3 软件质量标准软件质量标准定义了评价软件产品质量的指标体系和测试方法，如GB/T 16260（软件工程软件质量）系列标准。
1.4 信息安全标准信息安全标准涉及软件在设计、开发、部署和使用过程中的安全要求和措施，如GB/T 22239（信息系统安全保护等级划分）和GB/T 25069（信息安全技术信息系统安全等级保护基本要求）。
二、行业准则行业准则是在国家标准的基础上，由行业协会或组织针对特定行业或领域制定的规范性文件。
软件开发领域的行业准则主要包括：2.1 行业最佳实践行业最佳实践通常总结了一系列在软件开发过程中被广泛认可的高效方法和最佳实践，如敏捷开发、DevOps等。
这些实践在提升开发效率和软件质量方面发挥了重要作用。
2.2 行业安全准则针对软件开发中的安全问题，行业会发布相关的安全准则，指导开发人员和企业如何防范和应对安全威胁，如OWASP（开放式Web应用安全项目）发布的安全指南。
2.3 行业代码规范为了提高代码的可读性和可维护性，降低软件项目之间的差异性，行业会制定统一的代码规范，如《软件工程代码规范》（GB/T 36291.1-2018）系列标准。
国家软件开发标准与行业规范概述
国家软件开发标准与行业规范概述软件开发作为当今世界的重要产业之一，其质量与安全性对于国家经济、国防、信息安全等方面具有举足轻重的意义。
为了保证软件产品的质量，提高软件开发效率，确保软件开发过程的安全可控，我国制定了一系列软件开发标准与行业规范。
本文将对这些标准与规范进行概述。
一、国家软件开发标准国家软件开发标准是为了规范软件开发过程、保证软件产品质量、提高软件开发效率而制定的。
这些标准涉及软件需求分析、软件设计、软件实现、软件测试、软件维护等各个方面。
1. 需求分析标准：主要包括GB/T .1-2006《软件工程软件生命周期过程第1部分：过程描述》等标准。
需求分析标准：主要包括GB/T 16260.1-2006《软件工程软件生命周期过程第1部分：过程描述》等标准。
2. 设计标准：主要包括GB/T .2-2006《软件工程软件生命周期过程第2部分：支持过程》等标准。
设计标准：主要包括GB/T 16260.2-2006《软件工程软件生命周期过程第2部分：支持过程》等标准。
3. 实现标准：主要包括GB/T .3-2006《软件工程软件生命周期过程第3部分：管理过程》等标准。
实现标准：主要包括GB/T 16260.3-2006《软件工程软件生命周期过程第3部分：管理过程》等标准。
4. 测试标准：主要包括GB/T -2008《软件工程测试过程》等标准。
测试标准：主要包括GB/T 15532-2008《软件工程测试过程》等标准。
5. 维护标准：主要包括GB/T .5-2006《软件工程软件生命周期过程第5部分：支持过程》等标准。
维护标准：主要包括GB/T 16260.5-2006《软件工程软件生命周期过程第5部分：支持过程》等标准。
二、行业规范行业规范是为了适应不同行业特点，保证软件产品在特定领域的应用质量而制定的。
以下是一些主要行业规范：1. 金融行业规范：主要包括《金融行业软件开发规范》等，涉及金融软件的开发、测试、部署、维护等方面。
uml用例需求模型的基本概念、主要内容、设计
uml用例需求模型的基本概念、主要内容、设计
UML用例需求模型是软件开发过程中的一种重要工具，它主要用于描述系统的功能需求和用户与系统之间的交互关系。
该模型包含了多个不同的元素，包括用例、参与者、关系、扩展点等，这些元素共同构成了一个完整的需求模型。
在UML用例需求模型中，用例是最基本的元素，用于描述系统的功能需求。
每个用例都由一个或多个参与者触发，并且完成一定的工作。
参与者是系统的外部用户或其他系统，用于触发系统中的用例。
关系描述了参与者和用例之间的交互关系，包括关联、泛化、包含和扩展等。
扩展点用于描述用例的可扩展性，允许系统在未来的发展中增加新的功能需求。
在进行UML用例需求模型的设计时，需要遵循一些基本原则，包括用例应该具有可测性、粒度应该适当、应该避免用例之间的重复等。
此外，还需要注意用例的关注点应该集中在用户需求上，而不是系统实现细节上。
总的来说，UML用例需求模型是软件开发过程中非常重要的一部分，它可以帮助开发人员更好地理解用户需求，从而更加准确地设计和实现系统功能。
- 1 -。
数仓业务领域标准模型
数仓业务领域标准模型
在数据仓库业务领域，存在多种标准模型，包括维度模型、范式模型、星型模型、雪花模型、星座模型、Data Vault模型和Anchor模型等。
这些模型在数据存储、数据处理和分析方面具有不同的特点和适用场景。
1. 维度模型：维度模型是数据仓库中最常用的一种数据模型，由事实表和维度表组成。
事实表存储度量值，维度表存储相关属性，适用于Ad-Hoc查询和报告，方便分析多个维度之间的关系。
2. 范式模型：范式模型是关系型数据库中常用的一种数据模型，遵循数据库设计的范式理论，将数据存储在不同的表中，并通过键将它们连接起来，以避免数据冗余。
3. 星型模型：星型模型是一种基于维度模型的数据模型，由一个事实表和多个维度表组成，维度表和事实表通过外键连接。
4. 雪花模型：雪花模型是一种基于范式模型的数据模型，遵循高内聚、低耦合的原则，将不同的表分隔开来进行存储。
雪花模型适用于数据规模较小的情况，能够减少数据冗余，提高数据的完整性和一致性。
5. 星座模型：星座模型是对星型模型的扩展延伸，多张事实表共享维度表。
6. Data Vault模型：DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成，是Dan Linstedt发起创建的一
种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
7. Anchor模型：高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。
这些标准模型在数据仓库业务领域中具有广泛的应用价值，可以根据具体业务需求选择合适的模型进行数据处理和分析。
需求管理规范
需求管理规范一、引言需求管理是软件开发过程中至关重要的一环，它涉及到对需求的收集、分析、确认、跟踪和变更控制等方面。
在项目开发过程中，合理的需求管理可以确保项目按时交付、满足客户需求，并减少后期的修改和维护工作。
本文旨在制定一套需求管理规范，以提高项目的成功率和质量。
二、需求收集1. 需求来源：需求可以来自客户、用户、市场调研、竞争对手分析等多个渠道。
在收集需求时，应确保需求来源的准确性和可靠性。
2. 需求分类：将需求按照功能、性能、界面、安全性等方面进行分类，以便于后续的需求分析和管理。
3. 需求描述：需求应该清晰、具体、可测量和可验证。
在需求描述中，应包括需求的背景、目标、功能、性能要求等信息。
三、需求分析1. 需求分析方法：可以采用面谈、问卷调查、用户故事、用例分析等方法进行需求分析。
根据项目的特点和需求的复杂程度，选择合适的分析方法。
2. 需求优先级：根据需求的重要性和紧急程度，为每个需求确定优先级。
优先级的确定可以参考客户需求、业务价值、技术可行性等因素。
3. 需求可行性评估：对需求进行可行性评估，包括技术可行性、资源可行性、时间可行性等方面的考虑。
四、需求确认1. 需求确认会议：组织需求确认会议，邀请相关的利益相关者参加。
在会议上，对需求进行详细讨论和澄清，并达成共识。
2. 需求文档：将确认的需求记录在需求文档中，包括需求的描述、优先级、验收标准等信息。
需求文档应该具备可读性、易理解性和易更新性。
五、需求跟踪1. 需求追踪矩阵：建立需求追踪矩阵，将需求与设计、开发、测试等工作进行关联。
通过需求追踪矩阵，可以清晰地了解每个需求的状态和进展情况。
2. 需求变更控制：对需求的变更进行控制，确保变更的合理性和影响的评估。
需求变更应该经过相关人员的评审和批准，并及时更新需求文档。
六、需求评审1. 需求评审会议：定期组织需求评审会议，邀请项目相关人员参加。
在会议上，对需求进行评审，发现和解决潜在问题，并确保需求的一致性和可行性。
需求建模方法
需求建模方法
需求建模是一个非常重要的过程，它可以帮助开发者捕捉到用户需求，为开发提供指导。
在软件开发过程中，需求建模涉及到对需求的描述、分析、规范和管理等方面，为软件开发提供了一个有序、标准化的方法。
需求建模方法主要包括以下几个方面：
1. 需求获取：通过与用户、项目组成员等进行互动，获取相关需求信息。
2. 需求分析：对需求进行归纳、整理和分类，确定需求的优先级和重要程度，并与系统设计进行协调。
3. 需求规范：将需求转化为规范化的文档或模型，以便于开发人员理解和实现。
4. 需求管理：对需求进行跟踪、变更和评审，保证需求的完整性和正确性。
在需求建模过程中，需求建模者需要对不同的需求进行分析和梳理，确定需求的优先级和重要性，根据需求的不同特点选择不同的建模方法，如用例建模、数据流图、状态转换图等等。
总之，需求建模是软件开发过程中一个非常重要的环节，它可以帮助开发者更好地理解用户需求，为软件开发提供准确、完整的需求描述，从而提高软件开发的效率和质量。
- 1 -。
模型产品通用技术规范要求
模型产品通用技术规范要求模型产品通用技术规范要求引言：模型产品是指通过建立数学模型、计算模拟等方法对真实系统进行分析、预测和优化的工具和软件。
作为一种重要的工具和手段，模型产品在各个行业和领域都有广泛的应用。
为确保模型产品的质量和可靠性，制定一套通用的技术规范要求是必要的。
本文将以模型产品通用技术规范要求为主题，分部分深入探讨该主题的多个方面。
第一部分：模型产品的可靠性要求在模型产品的开发和使用过程中，可靠性是一个关键的要求。
模型产品的可靠性包括两个方面，一是模型的准确性，即模型能否准确地模拟真实系统的行为和特征；二是模型的稳定性，即模型能否在各种情况下保持一致的预测结果。
1. 模型的准确性要求为确保模型的准确性，应当从以下几个方面进行考虑：（1）模型的基础数据需准确可靠，包括系统的输入数据和参数。
（2）模型的建立需符合科学原理和统计方法，并经过可靠的验证和校准。
（3）模型应当能够充分考虑系统的非线性、不确定性和复杂性。
（4）模型的结果应当与真实系统的观测数据相符合。
2. 模型的稳定性要求为确保模型的稳定性，应当从以下几个方面进行考虑：（1）模型应当具有良好的数值稳定性，能够适应不同的计算条件和求解算法。
（2）模型的结果应当具有一致性，不受初始条件和边界条件的微小变化所影响。
（3）模型的参数和结构变动应当能够合理地反映系统的变化。
第二部分：模型产品的可扩展性要求模型产品的可扩展性是指模型能否适应不同规模和复杂度的问题。
在实际应用中，往往需要针对具体的问题进行模型的调整和优化，以满足特定的需求。
因此，模型产品应当具备一定的可扩展性。
1. 可扩展性的建模要求模型产品应当具有以下特点以提高其可扩展性：（1）模型的结构需清晰明确，能够方便地进行扩展和修改。
（2）模型的参数和变量应当能够灵活地调整，以适应不同的问题和需求。
（3）模型的求解算法应当具有通用性和高效性，能够处理大规模复杂问题。
2. 可扩展性的应用要求为提高模型产品的可扩展性，应当从以下几个方面进行考虑：（1）模型应当能够适应不同规模和复杂度的问题，例如可以简化模型以应对较简单的情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
领域需求建模规范1.概述1.1编写目的用于指导领域建模人员进行领域需求建模。
1.2适用部门适用于面向领域的嵌入式开发环境项目组。
1.3规范执行日期自本规范审核通过之日起执行。
1.4规范执行制度进行领域需求建模时，要求建模人员一律严格按照本规范的流程进行建立。
2.领域需求建模流程领域需求建模的流程如下所示：1)由领域专家提供关于领域中系统需求规约和实现的知识，组织出规范的、一致的领域术语，记录在领域词典中。
2)根据领域词典，用自然语言对领域需求进行描述。
3)领域分析人员可以把一个领域中各应用系统所描述的服务、以及采用的各种技术抽象成为特征，建立特征模型。
4)通过对领域知识和现有的应用系统的分析，挖掘领域中所存在的各种用例，建立用例模型。
2）和3）是同时进行的，同时在此过程中完善领域词典。
5) 构造出用例与特征的对应表。
领域需求模型建立流程图如图2.1所示：建立领域词典建立特征模型建立用例模型构造用例特征对应表开始结束描述领域需求完善完善图2.1 领域需求建模流程图2.1 建立领域词典建立领域词典的目的是统一术语。
统一术语可以使领域工程的参与者有共同的语言，便于领域工程的实施。
术语也就是对事物的分类。
统一术语的过程，也就识别了领域中有哪些共同事物，以及这些共同的事物可以有何种共同的分类方式，即识别了领域中的共同性。
随着领域需求模型的生成，领域词典也将随之更新演化。
领域词典中包括了名词（词组）、动词以及特征名称。
在领域需求模型建立过程中，所用到的事件、对象、角色等都要与领域词典中的条目保持一致。
2.1.1名词（词组）任何能够指代领域中实体或抽象事物的名词或者名词词组。
例如：住宅安全系统。
2.1.2动词形容和表示各类动作的词汇。
例如：控制。
动词需进行分级，分为1级、2级、3级等等，数字越小，级别越高。
例如：精通（1级），掌握（2级），了解（3级）。
2.1.3特征名称每个特征都必须有自己唯一的名称，并且在领域词典中有相应的定义：●对于功能性特征采用名词（或名词词组）+动词的命名规则，名词和动词在领域词典中应该包含对它的定义。
例如：磁卡访问。
●对于非功能性特征采用名词（或名词词组）的命名规则，例如：安全性。
●对于硬件特征直接用硬件名作为特征名称。
例如摄像头。
2.2描述领域需求采用自然语言对需求进行描述。
所描述的需求应具有以下特点：●完整性每一项需求都必须将所要实现的功能描述清楚，使开发人员获得设计和实现这些功能所需的全部必要信息。
●正确性每一项需求都必须准确地描述其开发的功能。
●可行性每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
●必要性每一项需求都应该是客户真正所需要的和最终系统所遵从的标准记录。
●无二义性对所有的需求说明都只有一个明确的统一的解释。
●可验证性检查一下每项需求是否能通过设计测试用例或其它的验证方法。
领域需求一般用以下句型描述：描述完一条需求要换行，每条需求的前面用符号（R+序号+：）表示。
在以下句型中，n指代名词或名词性词组，v指代动词或动词性词组，（）内为可替换的，【】内为可选的。
●当+ n + v【+ n】+时（前）（后），n + v【+ n】。
例子：当用户按下启动按钮时，系统运行。
●n + 能够+ v + n。
例子：系统能够提供用户注册功能。
●n + 可以是+ n 【+、（或者）+ n】。
“、”表示多选多。
“或者”表示多选一。
例子：用户名中的字符可以是英文字母、数字。
●n + 要求（允许）+ n + 达到（至少）（为）+ n例子：系统要求处理器频率至少2.0GHz。
2.3建立特征模型特征是系统中用户可见的、显著的或具有特色的方面、品质、特点等。
特征的识别主要是通过对已有的领域知识进行抽象来完成的，领域知识则来源于领域专家，书籍，用户手册，设计文档和源代码等各种信息源。
特征可以是应用系统提供的服务，应用系统的性能，应用系统需要的硬件平台、费用及其他相关信息等。
特征模型是对一个特定领域的软件所具有的特征的有组织的描述，主要记录了特征自身具有的重要属性和特征之间存在的各种关系。
特征模型主要包括：●通过组成关系形成的特征层次分解图，即特征树；●每个特征的变化性类型和绑定时间属性；●每个特征的具体描述；●特征之间存在的约束关系。
2.3.1特征树特征模型主要由特征树组成，特征在特征模型中的表示方法如表2.1所示：表2.1 特征图例表分类图例功能特征名称NF非功能特征名称H硬件特征名称特征树通过以下关系组成：●包含关系（include）包含关系是特征之间的主要关系。
一个父特征可以包含一系列的子特征。
通过包含关系，特征以一种树状的层次结构被组织在一起。
在特征模型中，用实线连接父特征和子特征。
特征A包含了特征B、C、D的图例如下所示：AB C D●特殊化关系（specialization）一个泛化的特征在具体的环境中根据不同的情况被扩展为一组具有不同细节的特征。
在特征模型中，特征A特殊化为特征B、C、D的图例如下所示：AB C D2.3.2特征模型的可变性为捕获领域中应用系统的共性和变化性，我们定义以下几种特征。
●必选特征：指在领域中每个应用系统中都应该包含的特征。
●可选特征：指对于领域中的各个应用系统可有可无的特征。
●多选一特征：是对某一个一般性特征的具体化。
只能选择一个。
●多选多特征：也是对某一个一般性特征的具体化。
可以选择多个。
在特征模型中，必须对所有可选的、多选一特征、多选多特征进行标识。
例如在图3.2中，访问控制为必选特征，用符号表示。
室内监视为可选特征，用符号表示。
室外运动检测和室外视频检测室多选一特征，用符号表示。
磁卡访问和密码访问为多选多特征，用表示。
对可选特征的选择或者多选一特征、多选多特征的选择，可以由软件体系结构设计人员来决定它们的绑定时间。
绑定时间就是指特征在整个生命周期中必须被做出绑定或删除决策的时间段。
有三种类型的绑定时间：编译时、装载时、运行时。
2.3.3特征之间约束关系特征之间主要包含以下几种约束关系：●使用关系（use）使用关系描述功能性特征之间的调用关系。
表示使用特征调用被使用特征完成之后的结果。
对于两个特征A和B，特征A使用特征B的图例如下所示：箭头指向被使用特征。
useA B●通知关系（inform）对于两个特征A和B，A informs B表示A向B发送特定的信息以通知B特征的事件已经发生。
特征A通知特征B的图例如下所示：箭头指向被使用特征。
A Binform●需要关系（require）需要关系是指由于语义或逻辑上的关系，一个特征的存在要求若干个特定特征的存在。
对于两个特征A和B，特征A需要特征B的图例如下所示：箭头指向被依赖特征。
A Brequire●互斥关系（exclude）互斥关系是指两个特征之间由于语义或逻辑上的矛盾关系而不能同时存在于某个环境中。
特征A与特征B互斥的图例如下所示。
A Bexclude2.3.4特征描述特征描述采用文本的方式对特征分解视图进行描述，特征描述中的关键字主要是用于表述特征之间的关系，如表格2.2所示。
所有的特征通过英文符号的逗号“,”隔开；特征列表用英文符号的括号“()”括起来；特征与其后面的特征列表用英文字符的冒号“:”隔开；每一个功能的描述占据一行。
具体语法如下： future : relation-keyword(sub-future, sub-future, ……)表2.2 特征描述关键字关键字 含义all 表示该特征由后面的所有特征组成 more-of 表示该特征由一个或多个后面的特征组成 one-of 表示该特征由其中一个后面的特征组成 specializations表示该特征特殊化为后面的特征？ 表示该特征可有可无use 表示该特征依赖后面的特征，依赖关系为use 。
inform 表示该特征依赖后面的特征，依赖关系为inform 。
requires 表示该特征依赖于后面的特征，依赖关系为inform 。
excludes表示该实体与后面的实体不能共存，存在排斥关系2.3.5 特征模型举例图2.2是住宅安全系统的部分特征图。
住宅安全控制室内监视访问控制入侵检测室内视频监视室内运动检测磁卡访问密码访问破窗检测室外运动检测室外视频检测图例必有的可选的多选一特征非功能特征安全性反应时间多选多使用互斥use通知Inform 需要require摄像头HNFNF NFrequirerequire图2.2 住宅安全系统部分特征图其中每个特征的详细描述如表2.3所示：表2.3 住宅安全控制相关特征的描述特征名称特征描述是对整个住宅安全进行控制，进一步包含室内检测、访问控制、住宅安全控制入侵检测等子特征。
利用摄像头对室内的环境进行监视。
包含一对多选一的特征：视室内监视频监视、室内运动监视。
对进入住宅的访问者进行识别。
包含一对多选多的特征：磁卡访访问控制问、密码访问。
对采用其他方式进入住宅的访问者进行监视。
包含破窗检测和一入侵监视对多选一的特征：室外视频监视、室外运动监视。
室内视频监视对室内进行监视，有异常发出警报。
室内运动检测对室内运动物体进行检测。
磁卡访问访问者使用磁卡进行访问。
密码访问访问者使用密码进行访问。
破窗检测对窗户完好度进行检测。
室外运动检测对室外的运动物体进行检测。
室外视频检测对室外进行视频监视。
摄像头在进行室内视频监视和室外视频监视时需要用到的摄像头硬件。
安全性是住宅安全系统的安全性。
反应时间是住宅安全系统对异常出现作出相应动作的反应时间。
特征文本描述如下所示：住宅安全控制: all(访问控制, 入侵检测, 室内监视?)访问控制: more-of(磁卡访问, 密码访问)入侵检测: all(破窗访问, one-of(室内运动检测,室外视频检测))室内监视: one-of(室内视频监视, 室内运动检测)室内视频监视: requires(摄像头)室外视频监视: requires(摄像头)2.4建立用例模型用例模型主要是通过对领域知识和现有的应用系统的分析，挖掘领域中所存在的各种用例。
用例模型包括用例图、用例场景（时序图）和用例描述。
这里采用UML相关规范构建用例模型。
2.4.1用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作。
它以图形的方式定义系统的各功能点和参与者以及其之间的相互关系。
用例图中的图例如表2.4所示：表2.4 用例图图例名称图例备注参与者用例用户参与用例用例扩展第一个用例给第二个用例增加步骤，就称为扩展第二个用例，例如查看单据明细是查看单据表头的扩展。
用例泛化父用例可以特化形成一个或多个子用例。
用例包含第一个用例包括第二格用例的全部步骤，就称第一个用例包含第二个用例，主要用于用例分解。