文章目录
引言
本文档的目的在于：将用户提供的需求描述系统化、精确化、全面化。从而实现：
1、作为高校人事管理系统开发软件协议的参考依据，为双方提供参考。
2、支持目标软件系统的确认。
3、控制系统进化过程，根据高校人事管理系统的特点，对被开发软件系统的功能、用户需求分析进行完整描述，为软件开发者进行详细设计和编程提供基础。
一、 项目需求提案计划书
1.1 所提案的项目系统
提案的项目系统用于对高校的人事管理，主要包括领导（管理员）对工勤人员和教师的管理。
1.2 系统可能的问题分析
具体问题：工勤人员和教师人数比较多，在管理教职工基本信息、教职工业绩以及教职工工资等信息时，管理难度较大信息量大且容易出错，因此设计一个操作方便，扩展性强，应用广泛的人事资源管理系统，从而提高学院人力资源管理水平，实现学院内部信息化和规范化管理。
项目的BMM类别：
对项目的预计结果分类有：项目质量、成本收益比、是否遵循法律法规。项目的影响可分为两类：外部、内部。外部影响有：竞争对手、客户、行业环境、合作伙伴、法律法规、技术发展；内部影响有：企业价值、基础设施、问题、资源。项目的评估分类有：项目的优势、弱势、项目行业的机遇与风险。一个项目的成功与设计可以分为许多分类，预计结果、影响、评估等等，这说明一个项目不是一蹴而就的，是要多次分析团队与行业等的差异，扩大自己的优势，避开弱势，从而使自己的项目预计结果更加理想。
问题背景信息：人事管理是各个单位不可缺少的工作，然而一直以来人们习惯使用传统的人工方式来进行人事管理，这种方法效率低，保密性差，还会产生大量的文件和数据，不便于查找。随着计算机网络技术的飞速发展，我们已经进入了信息化的时代。仅仅依靠传统的人工方式已经不适应时代发展的要求，因此需要利用计算机进行人事管理。利用计算机进行人事管理不仅搜索迅速，查找方便，保密安全；而且可以提高人事管理的效率，为高校教职工正规化管理提供保障。
高等教育的普及和扩大，推动了我国高校的发展，教职工数量也日益增加，因此需要现代化的管理手段，快速全面的掌握教职工的信息，更好的管理高校人力资源信息。
目前大部分高校中人事资源采用的是人力与计算机相结合的方法，但也只是利用Excel表格管理和存储教职工的信息，这种方法数据量大，容易出错，需要耗费大量的人力物力。因此需要人事管理系统对高校教职工进行有效管理，将实现数据共享，减少数据冗余，方便查询信息，提高工作效率。
本高校人事管理系统问题域：
1、完善且方便的教职工管理系统（计算机端）
2、可在系统管理员端查看所有教职工的信息、工资，对教职工进行考评
3、教职工可在系统用户端进行考勤、请假
1.3 系统的使用目标分析
要求系统可以实现教职工在线查询相关个人信息，领导等管理人员能够在线管理相关信息。在界面设计方面，要求界面设计清晰，操作简单；功能方面，要求系统有数据校验的能力。在保密设计方面，要保证信息安全可靠，不被他人非法修改或者盗取。
所有涉众：教职工（用户）、领导（客户）、系统管理维护人员、开发团队、领域专家、市场力量、*力量
1.4 系统业务过程分析
本系统首先进入登录界面，已有账号就可以直接登录，没有账号可以先注册账号，登录成功后会看到系统首页，如果不是管理员，用户就只能进行查看基本信息、查看工资、发起请假申请、发起信息反馈。如果是管理员身份，就可以对工勤人员和教师进行管理，包括各模块的增删改查操作和审核批准操作，这样就提高了系统的安全性。
用户对业务过程要求：操作简单，管理方便，页面简洁，即使是新上任或是文化水平不高的教职工也能迅速上手使用的系统，平时就可以在系统上面进行请假或是考勤签到，在管理员端可以综合教职工的表现对教职工进行考评、查看教职工信息与工资情况。
1.5 系统使用环境
系统使用环境：
CPU：1.4G以上
运行内存：512M以上
硬盘：512M以上
操作系统：Windows 2003操作系统以上
数据库系统：MySQL
二、 项目需求萃取分析书
2.1 确定项目关键涉众
2.1.1 涉众评估
2.1.2 涉众描述
2.1.3 涉众参与策略制定
采用敏捷方法广泛探索用户深度参与，从而使系统更加简便。从涉众代表中选出积极度更高、时间更容易调整的教职工群体、领导群体来参与系统的开发。其中教职工群体全程参与开始、规划、实现、评估、结束五个阶段；领导群体参与规划、实现阶段。
涉众领域模型：目的是为一个领域中的重要概念创建一个模型，该模型可用作一种通信设备，以确保所有利益相关者对概念有一个共同且一致的理解。
领域模型通常是在一个计划中创建的第一批模型之一，它构成了开发存储库其他部分的基础。 它可以像字典一样被用作交流工具。领导与管理人员：这是整个系统开发团队的客户，是系统的管理者与直接拥有者。他们可以管理所有使用者（教职工）的权限和个人信息，并且选择需要展示给用户查看的信息。教职工：这是系统的直接使用者，也是使用系统频率最多的角色。他们可以使用系统进行一些管理员（领导与管理人员）要求他们做的事（如每日打卡与请假），也可以在系统上面更改自己的个人信息，查看自己的出勤与薪资。开发团队：这是系统的开发人员，主要提供完好的系统给他们的客户（领导与管理人员），必要时会与直接使用者接触获取必要的数据。
2.2 用户需求萃取
2.2.1 展开用户需求萃取活动
随着现在计算机技术的不断完善，以及现代经济的不断发展，传统的管理技术不再满足高校的需要，越来越多的高校注重计算机信息管理系统，人事管理系统是典型的计算机信息管理系统之一，高校借助于它进行人力资源管理，达到事半功倍的效果。随着高校的雇佣人数的增加，有效地管理人员信息成为必然。高校人事管理系统的开发主要包括后台数据库的建立和维护，以及前台程序开发两个方面。
高校Z人事管理系统主要人员包括工勤人员、教师和领导。本系统实现了工勤人员与教师可查看和修改个人资料、查看在任职位、查看请假次数和考勤情况、查看工资、发起请假申请、发起信息反馈；领导审核工勤人员和教师的个人资料、管理职位、审核请假、进行考评、管理工资等功能。
2.2.2 用户需求分析
2.2.2.1 功能需求
功能需求层次：
FunctionalRequirements Analysis模式提供一种将一组需求的结构可视化到两个层次的方法，允许建模者表达这样一个事实，即一个需求由许多其他需求组成，而这些需求又由其他需求组成。它还允许系统工程师或其他涉众能够查看图中的需求id和文本。当需求或业务分析师希望提供需求及其子需求的可视化时，通常使用它。描述整个系统的需求通常是在系统描述的早期创建的；但是它可以在任何时候创建，特别是当需求描述一个子系统或系统的一部分时。
高校Z人事管理系统主要功能有资料查看与修改、岗位查看与管理、工资查看与管理、考勤情况查看与管理等功能。本系统包括两个界面，一个是工勤人员和教师使用界面，另一个是领导管理员的管理界面，而在管理员的管理界面中的各个管理板块都主要包括了新增、修改、删除、查询的功能模块。
（1）登录和注册
登录和注册都有相关的检验，用户进行注册时，可以选择账号的类型，比如工勤人员，教师，领导等，每个角色都有不同的权限，其中领导的权限最大，可以操作一切。注册时会验证填写的账号是否已经在数据库中存在，用户已存在的话就提示“该用户已存在，请换个账号试试”，若不存在，就验证其他表单数据，表单数据不能为空，注册成功后输入正确的账号密码及验证码，才能登录成功。登录成功后就跳转到系统首页。
系统首页
系统首页会显示欢迎页面，在其左上角有个面包屑菜单，点击可以进行菜单导航。
该图描述了一个参与者和两个组件之间的交互，显示了消息的时间顺序调用。消息交换是同步的，这意味着调用者将等待接收到应答。在高校人事管理系统中，教师触发登录操作，服务器开始校验，校验成功时从数据库读取数据返回，校验失败时直接返回错误信息。
（2）查看基本信息
工勤人员和教师可以在这里查看自己的个人信息、薪金发放情况以及职称评比情况，如果发现有问题可以使用本系统的反馈信息功能输入信息和提供证明材料发起提交给领导审核。
（3）发起请假申请
工勤人员和教师如果需要请假，即可在这上面发起请假申请，说明原因、请假起止时间、目的地、证明材料等，交由领导审核。
（4）发起信息反馈
如果工勤人员或教师发现有信息错误或者有建议的，可以在这里反馈给领导。
（5）岗位管理
领导（管理员）可对工勤人员或教师进行岗位管理。如撤销岗位、分配岗位、调动岗位、
（6）工资管理
领导（管理员）可对工勤人员或教师的工资进行核对、修改等操作。
（7）审核请假申请
领导（管理员）可对工勤人员或教师发起的请假进行批准或驳回操作。
（8）反馈功能
领导（管理员）可对工勤人员或教师发起的反馈信息进行审核并作出调整。
2.2.2.2 非功能需求
非功能需求分析：非功能性需求分析模式创建了一系列的包、元素和一个对非功能性需求建模的图。需求根据需求的类型进行分组，包括可用性、可比性、可扩展性和可扩展性等。
该图显示了一个包关系图，其中包含按类型对非功能性需求进行分组的包。图属性已配置为显示包及其注释中包含的元素。提供在单个图表或项目浏览器中可视化非功能性需求组的方法。预定义的包集有助于通过允许识别缺失的需求来帮助识别需求规范中的差距。当需求或业务分析师想要提供非功能性需求的可视化时，通常使用它。描述整个系统的需求通常是在系统描述的早期创建的；然而，模式可以在任何时候创建，特别是当需求描述一个子系统或系统的一部分时。高校人事管理系统的非功能需求有系统可操作性需求、性能需求、可扩展性需求。系统可操作性需求：考虑到系统的用户计算机操作能力参差不齐，并且系统的大部分用户通常都不是计算机专业人员，因此，为了提高人事管理系统的工作效率，系统在非功能需求上应该满足界面友好性。系统应该简单易操作，功能分类明确，界面应美观舒适。
性能需求：系统性能对用户的工作效率会产生一定的影响。比如，系统响应时间太长将使用户没有耐心，系统响应时间太短，用户的速度跟不上，会出现操作错误，也会降低用户的工作效率，系统的请求成功执行率太低，也会影响用户的工作效率。因此，在开发系统时应考虑系统在性能方面的需求。
可扩展性需求：考虑到系统用户在功能方面会对系统提出更多的需求，在设计人事管理系统时，应该考虑系统在扩展性方面的需求。这样，当用户提出新的功能需求时，只需对系统进行少许的改进，就可以实现新的功能需求。这既保证了系统的整体性，又满足了用户的需求。
项目的非功能需求：
所以，一个软件产品的需求不仅包括功能需求，而且还包括非功能需求。目前很多软件产品的非功能需求经常被忽视，但是非功能需求在一个软件产品中占据很大的作用。因此，本系统不仅对该高校Z人事管理系统的功能需求进行了分析，而且还对系统在非功能方面的需求进行了分析。除了满足功能需求外，该人事管理系统还应满足以下几点非功能性需求：
（1）系统可操作性需求。考虑到系统的用户计算机操作能力参差不齐，并且系统的大部分用户通常都不是计算机专业人员，因此，为了提高人事管理系统的工作效率，系统在非功能需求上应该满足界面友好性。系统应该简单易操作，功能分类明确，界面应美观舒适。
（2）性能需求。系统性能对用户的工作效率会产生一定的影响。比如，系统响应时间太长将使用户没有耐心，系统响应时间太短，用户的速度跟不上，会出现操作错误，也会降低用户的工作效率，系统的请求成功执行率太低，也会影响用户的工作效率。因此，在开发系统时应考虑系统在性能方面的需求。
（3）可扩展性需求。考虑到系统用户在功能方面会对系统提出更多的需求，在设计人事管理系统时，应该考虑系统在扩展性方面的需求。这样，当用户提出新的功能需求时，只需对系统进行少许的改进，就可以实现新的功能需求。这既保证了系统的整体性，又满足了用户的需求。
（4）可追踪性。
需求跟踪模式创建元素和一个跟踪图，显示需求和模型中其他元素之间的关系，包括拥有需求块、用例和测试用例的涉众。这显示了一个需求关系图，该图包含一个需求层次结构，该层次结构包含许多其他元素，包括：涉众、块和测试用例。其目的是让系统工程师创建一个图表，其中模型元素和它们相关的需求之间的关系可以可视化，包括其他需求。它通常在开发模型和定义诸如块、用例和测试用例等元素并与其满足的需求相关时使用。然而，图的形式可以在模型演化的任何阶段使用。管理员的需求是管理教师、后勤职工；教师和职工的需求是查看工资、打开签到、意见反馈等。
三、 项目需求分析规格书
3.1 编写目的
本文档的目的是描述高校人事管理系统需要实现的主要功能、适用的环境、面向的用户群及每一类型用户对系统的预期。该文档将最终交给软件开发人员进行具体的开发，使开发人员对本系统的功能及用户对本系统的需求有一个清楚的认识。其针对的对象是软件开发人员。
3.2 背景
本系统以基于Web的方式运行，使企业管理者和普通用户可以同时并行使用，并保证信息准确无误。主要是为企业人力资源管理者提供的平台，将管理者在管理人力资源时所需要的素材，以数据库方式，进行有效的组织管理的工具。面对的用户为企业内部员工，有助于企业人力资源管理者进行管理，提高管理的效率。本系统将在企业已有的服务器上运行，开发工具、软硬件条件均应与已有条件相适应。
Motivation Viewpoint（动机观点）
描述：
1、动机观点模式创建元素和图表，从给定的利益相关者的角度完全涵盖激励方面，定义驱动因素、评估、应用的许多目标和原则，以及限定原则所需的要求和约束。
2、一个动机图，其中包含一个利益相关者的分解，以及定义他们的目标的元素，以及指定系统必须展示的行为的需求。
3、该模式的目的是提供一个关于计划动机方面的丰富视图，显示从高层涉众到需求的细分。它为企业、业务和技术架构师、业务分析师、需求经理和其他关注架构策略和动机的利益相关者提供了一个视图。
4、该模式通常在计划的分析阶段使用，以获得对需求和约束如何与利益相关者和定义其目标的其他事物相关联的概述和洞察。
3.3 用户的特点
本系统的用户包括：系统维护人员，教师，领导，辅导员及后勤人员。本系统的用户角色有： <1)系统管理员角色：对高校人事管理系统的基本属性进行设置，实施管理和维护。 对系统用户进行权限管理。 <2）高校人事管理员角色：主要可以利用本系统进行高校人事档案信息的登记及查询，教职工职位调动登记及查询一系列操作。并可以进行客户化设置，比如机构设置，职称设置和职位设计等操作。 ❤️)普通用户角色：可以浏览个人相关的信息，修改个人基本信息，查看工资，发起意见提议等。 <4)管理层角色：掌握所有用户的情况。可以对其它用户的操作进行复审或审核。
Organization Chart （组织结构图）：
描述：
1、这是组织结构图，OrganizationChart模式创建元素和图表，为组织的角色、职责和报告线建模。各种各样的线条样式和颜色被用来帮助布局和吸引人的图表。
2、系统角色包括了普通用户、管理员和超级管理员。
3、普通用户有教师、后勤人员等。普通用户可以登录系统查看信息，进行反馈等。
4、管理员有领导和辅导员。管理员可以管理该系统的用户以及资源信息等。
5、超级管理员为系统管理员。权限最大，可以创建管理员，维护该系统等。
Basic Use Case Model（基本用例模型）
1、基本用例模型模式创建元素和用例图，描述用户角色希望从系统中实现的目标。用例都包含在系统边界内，参与者都在边界之外。
2、上图显示了一个用例图，其中包含参与者和系统边界中包含的多个用例。一个参与者表示一个系统，并使用矩形表示法。
3、该图目的是允许业务分析师和其他涉众描述参与者（用户扮演的角色）在与系统交互时想要实现的价值。
4、该模式通常用于计划的分析阶段，可用于实现任意数量的需求，并作为为实现团队提供规范的一种方式。
5、我们的高校人事管理系统主要有三个角色，管理员可以审核反馈信息、工资管理、审核请假申请、用户管理、职位管理；教师和工勤人员可以查看基本信息、查看工资和提交反馈信息。
3.4 对功能的规定
功能需求规格：
需求规格视图提供一种方法，将一组需求的结构可视化到两个级别，允许在适合非技术受众的熟悉界面中创建和管理需求。对该视图中需求的更改将导致所有其他视图(如图表)自动更新。需求规格视图模式创建元素和规格视图，它允许需求在文档或电子表格等视图中可视化，允许将复杂的需求分解为更细化的两级需求。该模式可以扩展到任何级别。需求规格视图显示了规范视图中列出的需求层次结构，允许需求结构在文档或电子表格中可视化，就像许多非技术涉众所熟悉的视图一样。
高校Z人事管理系统主要功能有资料查看与修改、岗位查看与管理、工资查看与管理、考勤情况查看与管理等功能。本系统包括两个界面，一个是工勤人员和教师使用界面，另一个是领导管理员的管理界面，而在管理员的管理界面中的各个管理板块都主要包括了新增、修改、删除、查询的功能模块。
3.4.1 登录和注册
登录和注册都有相关的检验，用户进行注册时，可以选择账号的类型，比如工勤人员，教师，领导等，每个角色都有不同的权限，其中领导的权限最大，可以操作一切。注册时会验证填写的账号是否已经在数据库中存在，用户已存在的话就提示“该用户已存在，请换个账号试试”，若不存在，就验证其他表单数据，表单数据不能为空，注册成功后输入正确的账号密码及验证码，才能登录成功。登录成功后就跳转到系统首页。
Business Process Diagram with Lanes（车道流程图）
1、车道的目的是组织和分类流动对象，通常用于指示谁执行或负责车道中包含的活动。这些通道可用于其他目的，例如指示正在执行活动的位置或谁管理一组活动。
2、模式可以在计划的任何时候使用，但通常在绘制基线（当前状态）过程或定义目标（未来状态）过程的早期使用。对于一个组织来说，在一个企业或业务单元级别开始详细描述所有基线（当前状态）过程是非常常见的，这样这些过程是可用的，并且可以被多个项目重用。
3、首先开始注册事件，教师进行注册账号，系统判断是否有该账号，如果已被注册了，就提示该账号不可用，返回重新注册，该流程2结束；如果账号没有被注册过，就由管理员进行审核，如果通过审核，就注册成功，流程结束；否侧注册失败，可以重新尝试注册。
3.4.2 系统首页
系统首页会显示欢迎页面，在其左上角有个面包屑菜单，点击可以进行菜单导航。
3.4.3 查看基本信息
工勤人员和教师可以在这里查看自己的个人信息、薪金发放情况以及职称评比情况，如果发现有问题可以使用本系统的反馈信息功能输入信息和提供证明材料发起提交给领导审核。
3.4.4 发起请假申请
工勤人员和教师如果需要请假，即可在这上面发起请假申请，说明原因、请假起止时间、目的地、证明材料等，交由领导审核。
3.4.5 发起信息反馈
如果工勤人员或教师发现有信息错误或者有建议的，可以在这里反馈给领导。
3.4.6 岗位管理
领导（管理员）可对工勤人员或教师进行岗位管理。如撤销岗位、分配岗位、调动岗位、
3.4.7 工资管理
领导（管理员）可对工勤人员或教师的工资进行核对、修改等操作。
3.4.8 审核请假申请
领导（管理员）可对工勤人员或教师发起的请假进行批准或驳回操作。
3.4.9 反馈功能
领导（管理员）可对工勤人员或教师发起的反馈信息进行审核并作出调整。
3.5 对性能的规定
3.5.1 精度
所有时间使用服务器时间精确到秒级，金额精确到分，所有的浮点数运算精确到2位小数。
3.5.2 时间特性要求
本系统属于典型的OLTP系统，对高校人力资源档案的信息进行添加、删除以及变更等内容拥有即时性，能立刻放映出现有状态。因为系统运行在互联网环境，该系统的响应时间和客户网络环境及同时在线使用的用户数量有密切的关系。 在以单核单处理器，主频3G，内存1G的台式个人电脑做服务器，应用服务器与数据库 服务器各自独立，并位于同一个100M局域内，30个客户端并发请求的环境下 （1）对于添加，删除，修改操作，达到10TPS以上 （2）对于即时查询，达到10TPS以上 （3）对于中等复杂度的报表，达到0.5TPS以上 （4）对于高复杂度的报表，达到0.1TPS以上。
3.5.3 灵活性
本高校人事管理系统采用Java语言开发，可以在多种硬件，多种操作系统环境下运行。 系统使用Hibernate框架完成数据持久化操作，不需要修改源代码，简单的修改Hibernate的配置文件就可以适用于多种不同的数据库环境。 系统采用B/S架构，各种类型的计算机，便携设备，智能手机等只要是有浏览器的客户端都可以正常访问本系统。系统的布署也非常简单，当系统升级或者修改时，只需要在应用服务器上重新发布，而不是在数量难以预计的客户端上更新。 系统使用Spring框架提供的AOP支持，可以通过修改配置文件动态改变数据库的事务 类型，LOG输出的详细程度等 系统可以部署在单机或者是集群环境下，可跟据用户数量的变化动态调整。
3.6 输入输出要求
系统要使用到的静态数据包括系统登录的密码，各数据库与素材所在位置。本系统涉及到的动态数据包括各数据库内各项显示数据，用户登录信息，系统时间。
3.7 数据管理能力要求
1、数据采集的要求
输入源：人工输入.CSV格式文件批量导入
接受者：数据库
2、数据采用的处理
数据格式：客户化设置信息、人力资源档案信息，职位调动信息，系统用户信息都在数据库中以表的形式存储。
通讯介质：因特网和企业内部局域网。
3、数据的存储要求
基本数据存储在数据库中，附件存储在服务器上。
3.8 故障处理要求
系统要有数据库备份恢复的功能，以应对数据库故障。并可以快速恢复。用户可以手动备份数据库或者定制定时任务自动备份。应用服务器和数据库服务器也可以使用集群环境来确保系统的高可用性。
3.9 其他专门要求
因为人事信息是对于公司和个人来说都是比较重要的信息。系统要有足够的安全保密性。对安全方面的要求有： 1)防止SQL注入攻击 2)防止跨站脚本攻击 3）对所有输入项要做长度，类型，有效性的检察 4) 禁止使用Cookies 5）关键信息加密存储 6)只能使用Post方式提交请求 因为系统可能会部署在集群环境下，为适应这一需求： 1)所有存储在Session中的对象要实现序列化的方法，以保证集群环境下的正常使用 2)Session中只存储用户状态相关的关键数据。
3.10 运行环境规定
设备:小型机，刀片式服务器，PC机都可以作为本系统的服务器.CPU处理能力不低于InterP4 系列主频3G的处理器.内存2G以上.数据库服务器硬盘可用空间60G以上，应用服务器硬盘可 用空间10G以上. 各种类型的计算机，便携设备，智能手机等可以正常浏览网页的客户端都可以作为本系统的客户端。
3.11 接口
高校人事管理系统对外提供一个用户身份验证的Web Service接口，因为本系统里有高校所有教职工的信息，这个接口可以作为系统集成时的单点登录入口。 本系统实现与Microsoft Excel的调用接口，可以将查询操作的结果以Excel格式导出 本系统实现一个CSV文件的接口，可以使用CSV格式文件批量导入用户信息。 本系统实现与邮件服务器的接口，当系统中信息改变，状态改变的时候以邮件通知相关人员。
3.12 涉及的软件
1、IntelliJ IDEA；
2、Tomcat；
3、JDK8。
四、 EA图档与参考文献
4.1 EA图档
1、Requirements Realization Viewpoint（需求实现观点）
描述：
1）、需求实现视点模式创建元素和图表，将目标的实现建模为需求和约束，然后通过核心元素(如业务和应用服务)来实现这些需求。引入颜色是为了增加图表的吸引力并区分元素类型。
2）、该模式的目的是允许企业、业务和技术架构师、业务分析师、需求经理对需求进行建模和可视化，这些需求是通过表示服务的元素和实现这些服务的元素来分解和实现的。
3）、该模式通常在分析阶段使用，此时已经定义了目标，阐明了需求和约束，设计了业务服务和流程以及应用服务和组件。它也可以在应用或过程重新评估阶段使用。
2、Principles Viewpoint（原则观点）
描述：
1）、原则观点模式创建元素和一个图表来模拟目标和原则之间的关系。聚合关系对目标的分解进行建模，而实现关系对原则如何与一个或多个目标相关联进行建模。
2）、该模式的目的是允许企业和信息技术架构师以及其他利益相关者将原则与目标联系起来。这些原则将构成需求表达的基础。
3）、该模式通常在计划的早期阶段使用，并且通常构成企业架构的一部分，被许多计划重用。
3、Node Instance with Deploy Dependency（具有部署依赖关系的节点实例）
描述：
1）、具有Deploy Dependency模式的节点实例创建元素和部署图，该图描述了具有单个节点（服务器）和执行环境（容器）的部署环境以及部署到它们的构件。
2）、上图显示了一个部署关系图，其中包含一个节点实例和一个部署规范的附带实例。这是工件部署的替代表示，可以通过将工件嵌套在节点内来显示。
3）、该模式的目的是允许设计师或技术架构师创建或查看虚拟或物理部署环境的模型，包括节点（如机器服务器）、执行环境（如操作系统、容器、基于软件的服务器）。工件和部署规范对软件如何部署到节点或执行环境进行建模。工件实例提供了设计和实现模型与部署环境模型之间的链接。
4）、该模式通常用于在企业级或计划级定义技术体系结构时。它可用于：
·将工件（软件）实例的部署建模到部署目标实例。
·当需要显示节点的分区时进行模型部署
·使用部署规范指定部署的属性。
4.2 参考文献
[1]骆斌，丁二玉，需求工程-软件建模与分析（第2版）。北京：高等教育出版社，2015.2。
[2][Hofmann 2001] HOFMANN H F, LEHNER F. Requirements engineering as a success factor in software projects. 2001,18(4): 58 – 66.
[3][Wiegers 2003] WIEGERS K. Software requirements. 2nd ed. Redmond: Microsoft Press, 2003.