需求工程领域是解决方案开发生命周期中最关键的学科之一，它对项目的成功有记录的影响。用 20 世纪著名物理学家阿尔伯特·爱因斯坦的话来说：
“如果你足够仔细地定义一个问题，那么解决方案就会突然出现在你身上。”
Enterprise Architect拥有一系列无与伦比的工具，用于开发、管理、可视化和记录需求，包括用于导入或集成并与外部需求管理系统同步的工具。
这些工具实现了 SysML 规范中定义的需求的所有方面，但工具特征远远超出了这一点，它创建了一个复杂的需求平台，其中包含与需求管理和定义相关的所有学科的工具。这些工具不仅对那些直接工作的工程师或管理人员有用，而且还有一个功能范围，例如可以帮助任何学科的设计可追溯性窗口，并且可以由架构和团队使用以确保将要求纳入设计，并因此实施到交付的产品或服务中。
开发需求
需求开发包括与发现、评估、记录、记录和验证特定项目的需求相关的所有活动和任务。需求被发现、分析、指定和验证。 Enterprise Architect拥有广泛的工具和特征来协助系统工程师开发需求。需求开发的核心是规范管理器，工程师可以通过它以文本形式输入、查看和管理需求，就像在电子表格或文档中一样。需求属性，例如状态、优先级和作者，可以在线编辑，并且可以应用过滤器来限制特定要求的显示。
规范管理器可与图表、可追溯性功能窗口、讨论区等其他管理工具平台配合使用。
管理需求
这包括维护一组要求的活动，这些要求代表项目团队和客户之间的协议或协议。它还聚焦确保设计和开发团队可以接受需求，并且它们足够具体，可以实施到工作业务、软件或硬件系统中。 Enterprise Architect是一个复杂的需求管理平台，无论领域、项目规模或所遵循的方法如何， Enterprise Architect都提供了可以轻松管理复杂项目中最大的需求存储库的工具。
需求关系
有一组丰富的需求关系允许需求元素连接到其他建模元素，包括其他需求。关系包括：
我们将在本主题的正文中探讨这些关系。
可视化需求
需求的可视化是需求过程的一个重要方面，因为在需求目录被指定、分析、开发和管理时，所有利益相关者都可以查看需求目录是至关重要的。这些要求代表了工程师对利益相关者就手头的问题或机会所做的讨论、观察和表述的解释。 Enterprise Architect具有广泛的机制，不仅可以向利益相关者社区提出这些要求，而且还允许对这些要求进行讨论、审查和策划。
记录需求
作为需求工程学科的一部分，通常会生成许多文档，例如系统需求规范和用例报告，这些文档可以使用内置模板或用户定义的模板从需求模型中自动生成。此外，可以使用内置或自定义模板生成范围广泛的其他文档。
还可以在手机、平板电脑或 PC 等便携式设备上的网络浏览器中查看模型。此功能作为专业云服务器产品的一部分提供，并提供了生成静态文档的替代方案，并允许工程团队与建模环境之外的更多受众进行交流和协作，而无需任何软件安装或配置。
8.1 需求作为一流元素
Enterprise Architect提供了广泛的功能，可用于需求作为一流元素的开发、可视化、管理和文档化。阅读一般SysML 教科书的人通常会想到用图表表达需求，但是Enterprise Architect提供了广泛的其他方法来可视化需求，这将有助于工程师将它们作为基于文本的元素使用，包括能够在浏览器窗口中以层次结构将它们可视化。
需求可以作为规范或标书的一部分创建，也可以作为合同文件的一部分，在这种情况下，它们可以很容易地导入Enterprise Architect 。然而，更常见的是，它们是作为通常通过研讨会和审查进行的启发工作的一部分来开发的。 Enterprise Architect有许多特征可用于记录这些会议的结果，例如思维导图。研讨会完成后，这些会议中记录的想法可以转换为需求或映射到会议元素，以允许协作开发。
需求通常是组织之间合同关系的一部分，或者是同一组织不同部门之间协议的一部分，因此需要严格维护和管理。 Enterprise Architect提供了多种功能来协助这种严格的审计工具，包括基线的审计工具、版本控制等等。
需求审计
审计可以在模型中打开，并可以跟踪需求更改的详细信息，包括更改时间、更改者以及更改前后的审计。可用于跟踪模型中的更改，谁更改了它以及何时更改。有多种模式，存储库管理员可以使用这些设置来指定审计中记录的内容。而一个基线可以用来显示一个模型和一个时间点之间的差异，记录每个单独的审计工具它不能用于以前的状态（但是，如果需要恢复到该工具，基线使用该工具）。
这在系统工程中尤为有用，因为流程涉及监管或合规方面，或故障需要追溯到设计或需求规范。审计通常由图书管理员或团队中的行政部门负责设置和管理。审计可以通过“设置 > 型号>审计”功能区选项来启用、设置和查看。
审计默认是禁用的，必须开启（开启）系统才会开始记录审计日志。这些功能以及其他一系列选项都可以在审计设置窗口中使用。
需求基线
基线用户在模型中启动的包的快照。基线地复制包的层次结构及其内容的分支。在随后的时间点，可以与模型的基线、模型和模型进行比较，如果模型模型了变化，这些变化将通过一个可视化工具，允许用户查看发生变化的每个部分，包括存在于基线和模型中。然后可以将内容从基线级别注入到离散变化的模型中。
基线为系统工程团队提供了方便的方式，确保模型以正确的方式演进，当模型方向需要恢复到之前版本时，基线可用于恢复模型中的原子部分。基线可以通过按Ctrl+Alt+B或从功能区位置设置和查看：
功能区：设计>包 >管理>管理基线
如前所述，基线由用户发起并存储在仓库中，因此如果仓库被复制，基线也会被复制。大多数用户通常会获得创建基线的权限，但从基线恢复的能力通常保留给图书管理员或管理员角色。
版本控制
版本控制允许模型内的包进行版本控制。要开始对模型的某一部分进行工作，用户需要先检查一个包（包括其子包），然后处理本地副本。当工作完成或在任何阶段，用户可以在包中查看，允许其他模型用户看到这些更改。
版本控制提供了一种复杂且稳健的模型工作方式，与基线不同，用户只需借阅包，无需启动版本。系统在工作完成和修改过程中自动在后台创建版本。版本控制可以通过这些功能区选项设置和查看。
设置 > 版本控制 > project-vc，package-vc
版本控制提供了管理模型内容的有效机制，使用户或团队能够对包及其内容随时间的变化保持细致控制。
8.2 需求图介绍
需求图提供了可视化需求及其关联的方式。这些图中不仅是任意两个需求之间的关系，还包括需求与其他类型元素（如用例、活动和区块）之间的关系。工具箱中提供的两个要素是：
这些元素可以相互连接，或与其他元素连接，创造丰富的表达。
在这张图中，我们看到一个需求通过满足关系与一个区块连接，描述了其他元素如何确保需求意图的实现。方块定义了一个替代形象，那就是机器人的形象。
同样，关系数量有限，但每个关系在图中都有特定含义。
与所有 SysML 元素一样，元素既有图形化，也有文本性。该需求定义有两个属性：
可以制作任意数量的需求图来描述利益相关者及其他相关者的需求和关切。
创建需求图
需求图可以从用户界面的多个位置创建，例如：
我们将使用设计色带绘制需求图。首先，在浏览器窗口中选择你希望创建需求图的位置。与所有图一样，这可以是包图或元素，但通常会将需求图插入包中。在浏览器窗口中选中包位置后，点击功能区选项“设计>图 > 添加图”。
该选项会打开“模型生成器”对话框中的“图生成器”标签页，您可以选择图的类型并指定图名——该名称最初默认为包含该图的包或元素的名称。当你选择 SysML 视角和 SysML 版本时，会显示一系列图表类型，方便你选择需求图。点击“创建图表”按钮，在浏览器窗口指定位置创建新的需求图。图示视图将被打开，允许你开始添加描述需求及其关系的元素和连接器。Enterprise Architect 还会显示工具箱中的“需求”页面，其中包含 SysML 规范中定义的元素和关系，适用于构建需求图。除了默认显示的“通用”元素和“通用关系”工具箱页面外，还可以根据需要打开任意数量的其他工具箱页面。
需求图中使用的最重要元素和连接器有：
元素
连接器
需求扩展
元素可以通过从工具箱拖拽到图示视图中来添加。关系可以通过先在工具箱中选择所需关系，然后在源元素和目标元素之间拖放来创建。通常不会制作单纯列出需求的需求图，而是绘制显示任意两个需求之间关系，或需求与其他元素（如用例、活动和模块）之间的关系的图表。
8.3 开发需求
需求开发包括发现、评估、记录、文档化和验证特定项目或工作项目需求的所有活动和任务。需求会被发现、分析、指定和验证，Enterprise Architect 拥有丰富的工具和功能，帮助系统工程师开发需求。需求开发的核心是规范管理器，允许需求工程师以电子表格形式输入、查看和管理需求。
规范管理器可与图表、可追溯性窗口、讨论功能等其他工具平台配合使用。这些窗口提供了需求的其他视图，让建模者和查看者深入了解需求与存储库的其他部分的关系，并提供通过规范管理器不可见的细节。
8.3.1 获取
获取是信息发现的过程，从中获得的信息将成为需求前身。信息通常是原始且常常异质化的，直到需求分析阶段完成后，才能从中推导出真正的需求。获取过程多种多样，需求工程师的所有技能都需要用来确定需要检查哪些文档、机器、工具、人员和流程以发现信息。
文献来源
需求通常可以从多处获取，包括以下文件：
虽然所有这些文档都可以使用文档工件功能在Enterprise Architect中开发，但它们通常是在其他工具中开发的，并且位于存储库之外。它们可以拖到图表上，然后导入到存储库中或保存为外部文档的参考或代理。
另一个，也许更有用的选项是将它们添加到模型库中，模型库是一个文档和网页库，用于创建可根据需求引用的项目目录。同时也值得考虑审查文件内容，并将其作为模型元素纳入。这让工程师能够在业务动机等元素与问题和解决方案元素（如需求、用例和组件）之间建立可追溯关系。
用户观察
观察用户工作是一种有益且不干扰的方式，有助于理解：
即使支持计划系统的过程不同，对当前流程的观察将为讨论提供有用的背景。它还能帮助工程师与用户产生共情，从而更深入地理解他们面临的问题，并为潜在解决方案的发现奠定基础。工程师经常会发现未提及的文件、清单和线索卡，帮助了解流程。配备手机或相机后，工程师还能拍摄用户工作照片，有助于工程师和其他人在需求分析阶段回忆和讨论任务。
Enterprise Architect 支持建模者直接在模型中表示照片和扫描文档等文件，创建用户工作中丰富且富有表现力的表现。你可以选择将这些图像表示为工件（只需按一次按键（F12）即可启动文件），也可以使用超链接，甚至将图像本身包含在图表中。
此图是由高级生产线机器人协助制造系统的工程师拍摄的照片。图像可以放入图表中，并且可以在机器人和系统描述的其他部分（包括需求）之间绘制关系。
利益相关者研讨会
需求工程师负责获取需求的艰巨任务，这需要与包括客户和分析团队在内的利益相关者进行良好的沟通。促进利益相关者需求的一种非常成功的方法是与所有关键利益相关者一起运行研讨会。需求工程师作为沟通者、外交官和调解者的技能对于创造一个有利于探索利益相关者需求和关注点的协作和尊重环境非常重要。工程师必须使用利益相关者理解的术语，并表现出对构成工程领域的元素的理解或学习的意愿。
有时会出现一种误解，即在这些研讨会中阐述的是一组明确定义的要求，这些要求可以作为利益相关者的需求输入到工具中。这与发生的事情相去甚远。利益相关者通常会表达广泛的想法，包括政策、业务规则、数据定义、项目管理约束、功能需求、业务需求、现有系统问题甚至建议的解决方案。即使使用外部顾问来运行这些会议，工程师也没有时间将所有这些陈述归类到会议中。需要一种方法让负责记录语句的抄写员将它们放入工具中，而不用担心正在记录什么类型的信息。将它们记录在工具中而不是在工程师的笔记本中潦草是最佳实践，因为它允许它们在会议期间显示并且利益相关者可以看到彼此的评论。
Enterprise Architect有许多功能可以帮助这些研讨会。一种非常实用的方法是使用思维导图来记录涉众的陈述，这种方法非常有效，因为它是一种众所周知的方法，并且没有引入任何建模语言（如 SysML）所附带的形式。此图显示了从可以更改以满足研讨会需要的模式创建的初始思维导图。
思维导图功能可以通过切换到该蓝图来使用，或者，如果经常使用，可以使用我的蓝图功能将其添加到用户定义的蓝图集。
这种视角和其他方法一样，需要启用相应的技术，这里就是思维导图。
由于发现了重要术语，因此可以将它们输入到项目词汇中，即使没有时间讨论和辩论商定的含义，这些词也将作为该领域中重要实体的初始列表。或者，可以将术语创建为块定义图中的模块，并通过描述术语之间重要关系的连接器相互关联。
还可以对利益相关者进行建模，并且可以在图表中描述他们彼此之间的组织关系。这是一种有用的技术，它允许关键利益相关者在模型中识别自己，从而产生认同感。
创建需求
Enterprise Architect对开发需求有广泛的支持，并为此提供了许多专门的工具。与所有模型内容一样，鼓励建模者在开始创建新需求之前先检查是否有人将需求输入到存储库中。需求也有可能已经在另一个工具（例如电子表格）中定义，并且可以导入Enterprise Architect而无需手动创建每个需求。
Enterprise Architect 有两个需求存储位置;它们可以在模型中作为一个元素创建，出现在浏览器窗口中，或者作为内部需求或责任在另一个元素中创建。
外部和内部需求
Enterprise Architect可以支持任何类型的需求过程，并允许将需求定义为模型中的元素。这些称为外部需求，但该工具还允许为特定元素定义需求，这些称为内部需求。想要定义用户需求的工程师，例如：
系统必须允许更新公交时刻表。
将使用外部需求。想要描述元件应该如何表现A部件者会使用内部需求来部件，例如：
编辑器必须支持统一码。
分析师和开发人员之间经常会争论需求应该是内部的还是外部的，而Enterprise Architect提供了一种功能，可以将内部需求转移到元素的外部。当它们被移动时，它们仍然与原始元素相关联。
需求分类
SysML 规范提供了需求类别（类型）的非规范性列表。这些是对基本 SysML需求进行改进或扩展的定型需求，提供了一种机制来创建服务于特定目的或描述系统特定方面的需求。例如，物理需求可用于描述系统的某些物理方面，例如组件的重量或大小。这些和其他用户创建的类别可以定义任意数量的附加属性，例如：
Enterprise Architect方便地将这些需求类别作为元素提供在 SysML需求的工具箱页面上。
该工具还提供了一个复杂且功能齐全的配置文件系统，允许用户创建基本 SysML需求的扩展以及适用于建模域或问题空间的任意数量的用户定义需求类别。这些定型需求可以具有添加到模型特定需求元素（或其他元素模型）所需的用户定义属性。
例如，一个团队可能决定在需求中加入波动性属性，以确保工作直到需求稳定（即不波动）才开始。再举一个例子，一个团队可能正在研发医疗器械，需要遵守各种法定标准。作为解决方案组成部分的每个组件都可能需要符合要求。可以创建一个合规级别属性，并可为组件分配一个级别，从自旋控制或下拉列表中定义的一系列值中指示其合规性。
需求属性
需求开发和管理对于任何项目的成功都至关重要，需求属性对于优先级以及它们在实施或开发团队中的详细说明和使用方式很重要。所有Enterprise Architect元素都有标准属性，例如状态、作者和相，但需求元素具有附加属性，例如难度和优先级。
一些需求过程将规定特定的属性，例如保管人和波动性（稳定性），这些可以使用可以应用于每个需求的标记值进行配置。需求的“注记”字段具有特殊意义，因为它通常包含系统必须如何运行或执行的正式和合同描述。
8.3.2 规范
需求规范是需求演变的一个重要方面。它提供了关于系统在正常和异常情况下的行为的重要陈述目录。需求将引起广泛的利益相关者的兴趣，包括：
所有这些小组都会有需求的输入，并且需要在他们的工作中使用需求目录。在Enterprise Architect中可以通过多种方式指定需求，包括：
直接在浏览器窗口中
我们将在下一节中查看规范管理器，您会看到它在处理需求和其他带有文本内容的元素时提供了极大的灵活性。
满足规范管理器
规范管理器是一种独特且高效的工具，提供电子表格或文字处理器视图，可用于管理任何元素，尤其适用于始终包含详细描述需求文本的需求。新需求可以创建带有名称和详细描述，状态和优先级等属性可从下拉列表中添加或更改。现有需求可以通过方便的视图（如图表和窗口）查看和管理，在规范管理器中更改需求会在仓库的其他所有地方发生变化。
对于那些更习惯使用文本而不是图表以及习惯于使用文字处理器或电子表格工作的分析师来说，规范管理器是完美的工具。它的另一个优点是需求是模型的一部分，并且可以追溯到其他元素，包括驱动业务驱动因素、利益相关者和解决方案组件。在该图中可以看出，需求状态和其他元素属性可以从下拉列表中进行编辑。
使用规范管理器时有多种选项，提供了极大的灵活性，包括像电子表格中那样以列形式显示笔记，或像文档中那样以内联形式显示笔记，以及调整文本大小。这些选项可通过“规范 - 指定”功能区使用，当规范管理器启动时会有条件地显示。
过滤器提供了一种有用的方式，将显示限制在选定列中包含单词或文本片段的元素。在这幅示意图中，一位建模师决定将显示限制为所有要求文本中包含“light”一词的需求。这在处理大量需求时是一个极佳的生产力工具，可以用来定位所有具有特定状态、优先级、复杂性，甚至是所有由特定利益相关者或团队拥有的需求（如果模型中已定义）。
也可以从规范管理器打开图示，使你能够作为一组编辑图中的元素。这对一些非技术人员，包括管理者和客户来说，是一个有说服力且受欢迎的观点。更多信息请参见规范管理器帮助主题。
8.3.3 分析
需求开发的分析阶段确保在引发阶段发现的需求被正确表达，具有正确的格式、细节层次和属性，并形成一个正确且连贯的集合。由于来源和提取方式各异，提取阶段记录的需求需要调整和平衡——例如，常见重复或重叠的需求，或者系统工程师无意中遗漏了一位或多个利益相关者的关切。诸如关系矩阵和可追溯性窗口等工具将帮助揭示遗漏和需求问题。讨论与审核窗口以及聊天与邮件窗口——包括模型邮件功能——还将提供与其他团队成员讨论、审查和聊天需求的功能。
优先排序要求
优先排序需求对于项目成功至关重要，因为它确保分析、开发、测试和实施资源集中在系统最关键的方面。优先级排序是一种为每个需求分配优先级的决策过程;最常见的分类标准是业务价值。业务价值通常通过对已实施需求为组织或其客户带来的价值进行成本效益分析来确定。其他因素可能包括政策或监管合规性、紧迫性、业务或技术风险以及成功的可能性。需求可以通过看板板可视化，通过将项目从待办项通道移到队列通道，并允许在通道内排序物品来表示优先级。
或者，可以使用搜索或模型视图来创建基于一些标准的需求列表，这些标准将使需求得到优先考虑。
需求优先性
可用于优先排序的标准范围广泛，每个组织和项目通常会使用某种加权平均来确定优先级。Enterprise Architect 对需求优先级设置具有灵活且完整的支持，因为每个元素都内置了“优先级”属性，可以设置以指示其优先级，允许用户从下拉列表中选择分配的优先级。
当您安装Enterprise Architect时，可以方便地预先加载优先级列表，但是可以编辑或完全修改这些优先级列表以适应组织或项目。它们甚至可以作为参考数据从以前的项目中导入，或者，如果当前项目是基于模板创建的，则可以从基础模型中预加载组织的优先级。可以使用此功能区选项设置它们：
设置 >参考>模型类型 > 常规类型 > 优先级
协同改变优先级
选择标准和分配优先级的过程通常是协作的，并且通常在与利益相关者或其代表辩论分类的研讨会中完成。在以前的时代，这是一个费力且困难的过程，但Enterprise Architect具有一些有用的特征来处理需求属性，包括优先级。有许多窗口——包括包列表和图表列表——支持处理需求和在线编辑优先级，根据新分配的优先级自动过滤或排序需求列表。规范管理器是一个有用的工具，它提供了一个基于文本的界面，可以查看需求及其注记，并可以从下拉列表中选择优先级。该界面还显示了许多其他通常对优先级有用的属性，例如状态和复杂性。
当需求属性被更改并保存在任何窗口或图表中时，该属性将在所有其他视图中更改，并且查看存储库的任何其他用户将立即能够看到更改。
仪表板图表
Enterprise Architect有一系列仪表板图，可用于创建包中需求优先级的引人注目的视图，并可选择包含子包。有许多预配置的图表可用于显示部分模型中需求优先级值的比率。过滤器添加了另一个级别的用户配置，例如，允许建模者排除特定状态的需求或相仅显示当前需求的需求。
使用看板板进行可视化
Enterprise Architect 有一个看板板图，可用于管理需求及其他规范或项目管理元素，如变更。看板板在管理需求优先级及其他要素方面尤为有用。这些元素可以简单地拖到图纸上，然后拖拽到列之间，使团队能够管理和可视化需求从规范到实现之间的进展。
看板图可以配置为当元素在列间拖动时，该元素的优先级会自动改变。
8.3.4 验证
需求验证是必要的，以确保需求符合高标准，适当地定义顾客的问题（或机会），并足以让实施团队设计和实施产品。需求必须具有所需的质量水平，并且是完成且必要的。验证需求的方法有很多种，但最常见的两种方法可能是进行团队评审和为需求分配测试用例。
团队评审通常由团队成员或其他熟悉该领域的分析师进行，但他们自己并不负责需求开发或管理。Enterprise Enterprise Architect有一个方便的工具来协助此过程，称为 Formal审阅，它适用于整个模型，并允许审阅者在讨论文档中记录他们的发现并引用模型元素。需求工具箱包的“扩展需求”页面中还有一个需求检查清单元素，它提供了一种检查需求质量的有用机制。
测试用例可以定义在多个层级，从用户验收测试到单元测试。在需求开发流程早期定义测试用例，会对需求进行双重核查，因为在定义测试用例时，需求中常常会发现问题。Enterprise Architect 提供了多种定义测试用例的功能，建模者可以选择最适合项目的测试用例。
8.4 可视化需求
需求可以使用产品的不同特征以多种不同方式可视化。一些方法允许用户创建新的和编辑现有的需求，而另一些方法只是提供一种查看需求的方法。需求，就像 SysML 中的所有元素一样，可以形成图形的一部分，许多重要的语义都在这些中表达关系；例如需求和验证它的测试用例之间的关系。然而，需求分析师、经理和其他利益相关者希望独立于需求可能参与的任何关系来查看需求是很常见的。我们现在将研究其中的一些功能，其他功能将在现在化中介绍需求关系话题。
需求图
需求图可用于直观地展示需求及其与其他元素（包括其他需求的关系。当然，您可以通过许多其他方式查看需求，但对于许多利益相关者而言，需求图更具吸引力，因为它提供了一种图形化的方式来查看需求与模型其他重要部分（包括利益相关者、架构、设计和测试）之间的联系。此图显示了如何查看需求及其与其他元素之间的联系。 A需求不允许未经授权的车辆进入停车场的需求被分配给“限制未经授权的车辆”活动，而该活动又被分配给表示 Boom门块。
需求A可以从用户界面中的多个不同位置创建，包括从功能区选项“设计>图表>添加图表”。
将显示“模型构建器”对话框，并选择“图表构建器”选项卡页。 需求图可以从 SysML 图类型列表中选择。
规范管理器
规范管理器是Enterprise Architect中处理需求的核心工具，从一开始就被设计成一个允许通过直观且功能齐全的界面创建和管理需求的工具。对于那些习惯使用电子表格或文字处理器文档的工程师或其他利益相关者来说，该工具看起来很自然，并模拟了这两种可视化模式，允许用户在电子表格模式和文档模式之间切换。
规范管理器可以从功能区打开：“设计>包>规范视图”。
规范管理器可用于查看任何类型的元素，但特别适用于文本成分较大的元素，例如需求。在工具中更改的任何元素也将在需求图表、浏览器窗口和其他目录（如库表）中自动更改。
浏览器与视图
浏览器是中央导航工具，可用于构建和探索存储库的内容，包括处理需求。浏览器有许多选项卡，允许以特定方式查看存储库的内容。我们已经在前面的主题中查看了浏览器，但将讨论它与可视化需求的相关性。
大多数系统工程师会尝试将他们对特定项目或努力的要求保持在一个位置，尽管可能存在需要将它们分开的情况；例如，出于合同或日程安排的原因。在“项目”选项卡中选择需求包后，用户可以切换到“上下文” 选项卡以获得焦点视图 - 有效地消除该时间之外的其他元素的上下文。然后可以选择一个单独的要求，并在检验员窗口上选择“详细信息”选项卡以聚焦所选要求的属性。
打开图表中包含的元素和关系也可以通过浏览器的“图表”选项卡进行可视化，提供查看图表内容的另一种方式。
任何包或图表也可以通过多种方式可视化，包括列表视图，它通常能以列表元素视图呈现，类似于电子表格，需求以行列列出，属性以列形式列出。
关系矩阵
关系矩阵是一个有价值的工具，用于可视化任意两个软件包中元素之间的联系，界面类似于带有行和列的电子表格。该工具在需求中使用时尤其有用，使工程师能够看到需求与其他元素（包括其他需求）之间的关系。
关系矩阵可以从功能区选项“设计>包>包/矩阵”打开。选择当前包是源包、目标包还是两者都有。
如果存在关系，则在源元素和目标元素的交叉处的单元中会显示一个箭头图标，箭头表示关系的方向。矩阵还可以配置为以单独的颜色突出显示没有任何关系的行或列。可以在“选项”窗口中配置此选项和其他选项（单击关系矩阵标题中的选项按钮）。
这些选项允许您定制矩阵的显示方式，包括是否对元素进行排序或其名称以包名为前缀，以及是否突出显示源和目标元素的行和不连接的列。
需求表
需求表是类似电子表格的视图，可以通过SQL语句创建，基于select语句选择需求（或其他元素），从而有效过滤掉特定需求组。例如，可以使用表格显示所有与电力子系统相关的高优先级需求，或用于性能需求分解。可以创建任意数量的表，并且随着底层属性在仓库中更新，这些表会动态刷新。这比列表视图更具灵活性，因为可以根据指定条件从存储库中任意位置选择一组需求。
