通过更好地了解两者之间的区别 高级别要求（HLR） 和 详细要求（DTR）.

的 Trips-R-You案例研究 是该系列的附录，提供了使用基于电子表格的模板记录的需求的端到端示例。

在IIBA®BABOK®中  V3术语，从业务需求到利益相关者需求到解决方案和过渡需求的端到端手段。原始系列和案例研究都使用更传统的业务术语Goal，HLR和DTR。同样，这两种解决方案都只在计划交付基于IT的解决方案的项目范围内满足功能需求。

注意：企业可以选择遵循敏捷原则来组织其IT解决方案交付资源。但是，如果这些解决方案的交付是由项目经理管理的，或者敏捷团队不包括“真正的”产品所有者-有能力并可以确定用户案例的优先级和细化程度，则仍然需要记录和管理需求。

个案研究

该案例研究涉及一个虚构的组织-Trips-R-You旅行社。它主要处理同一个虚拟项目的需求阶段，该项目旨在提供基于Web的客户自助航班预订功能-通常称为“航空公司预订系统”。

根据三个层次的需求，案例研究分为三个部分。第一部分介绍组织及其面临的问题。设定了旨在消除问题的目标，并委托了一个业务案例来研究潜在的解决方案。

第二部分看到启动了一个项目，以交付业务案例建议的解决方案。显示了该项目的范围，以及它如何导致该项目的高级需求。

第三部分详细介绍了五个HLR –一个HLR涉及业务信息系统能够支持的每种主要能力类型：

• 使用者介面（UI）
• 报告
• 资料汇入
• 资料汇出
• 自动化功能

为了支持捕获上述每种能力类型中涉及的细节，使用了基于特定类型电子表格的模板。

第三部分还讨论和使用数据字典模板。在讨论给定HLR的细节时，使用此模板可以捕获涉及的特定于数据的业务需求。一旦捕获到这些数据特定的详细信息，就可以在涉及其他HLR的讨论中再​​次提出这些需求时，在其他模板中引用这些细节。

注意：“数据字典”模板结合了我在2018年“定义明确的数据系列。

详细要求与详细要求 陈述

假设每个HLR都会有一定数量的DTR，这是很自然的（也是正确的）。但是，确切的要求应该是什么样子？一种 正式 要求声明应该是包含“必须”一词的单个句子（而不是暗示诸如“必须”或“应该”之类的优先级的术语）。更典型地，为了容纳细节，文本需求声明涉及许多句子或段落。

利用“穿着得体”的UML用例的需求文档技术描述了Actor与执行给定业务活动的“系统”进行交互。该描述包括活动中的各个步骤，分为不同的流程-一个主要流程以及任意数量的替代和/或例外流程。步骤说明包括各个字段的名称和涉及的“控件”（例如按钮）。需求文档技术可以将用例中的每个流程或每个步骤视为一个单独的DTR，或将整个用例视为一个单独的DTR。

Trips-R-You案例研究使用的基于电子表格的模板可以唯一地标识各个行，每个行代表一个详细的要求（但不是“声明”形式）。三个单独的工作表（选项卡）用于捕获不同类别的详细需求。这三个类别涉及：

• 功能的操作-例如何时需要谁。
• 单个元素-例如自动化功能中的字段，控件或步骤。
• 元素分组-例如屏幕或报告上的某个区域（请参见下面的模型），正在导入或导出记录。

表格格式允许单独的列代表适用于给定项目的不同类型的详细信息（即特征）。例如。对于报告区域内的单个字段元素，特征将标识要使用的字体以及该字段是左对齐，右对齐还是居中对齐。模板还支持详细需求的可视化表示，例如屏幕或报告模型（请参见下面的示例）。

因为“交付单元”（特定的UI，报告等）的所有详细信息都捕获在单个电子表格文件中，所以这些DTR可以由单个“正式” DTR语句表示（类似于整个用例）被视为单个DTR）。以下是案例研究的一个示例，该案例研究针对一个报告的HLR语句及其对应的单个正式DTR语句，该语句代表该报告的基于模板的DTR：

REQ008（HLR）-客户应能够访问并打印预订确认信息。

REQ015（DTR）-系统应能够生成特定预订的预订确认报告-如DR015-自助预订确认报告v1.0中所指定。

此报告的基于模板的DTR包括以下内容：

电子表格文件还包括以下模型，以可视方式表示六个报告区域和每个区域中包含的元素：

个别的陈述，模板还是需求管理工具？

需求以记录时间太长而闻名。他们可能从以下项目赢得了声誉：需求是“手工制作的”需求陈述； HLR语句被允许包含太多细节；并编写了DLR文本声明，其中包含有关字段和/或字段特征的各种细节组合。

将HLR保持在特定于功能类型的级别（即特定的UI，报告等）是为了避免在提出需求的此阶段浪费时间。使用特定于能力类型的模板旨在通过表示并提供空间来捕获每种能力类型和类别需要解决的特定细节类型的值，从而节省时间。

注意：Trips-R-You案例研究中使用的模板代表了详细的需求类型和特征的结合，这是基于我作为项目分析师提供基于IT的解决方案的业务分析师的多年经验。经验包括为软件包供应商，为获取软件包的组织以及为解决方案的一部分外包的组织工作。

比价格合理的基于电子表格的模板要好，它将是可商用的需求管理（RM）或应用程序生命周期管理（ALM）工具，该工具支持本文档中介绍的与需求相关的概念。 Trips-R-You案例研究.

Trips-R-You案例研究作为工具基准

除了有助于理解与HLR和DTR相关的概念外，还希望Trips-R-You案例研究可以作为RM和ALM工具供应商使用的基准。尽管不能期望它们的工具能够立即支持所有概念，但是当前市场上的大多数工具都提供了一定程度的配置。任何希望购买商业上可用的工具来支持基于IT的项目的需求阶段的组织，都可以要求其候选工具供应商证明其工具支持此案例研究的能力。

注意：任何相信其工具能够支持Trips-R-You案例研究中表示的“上下文要求”概念的工具供应商，欢迎与我联系以获取有关基准测试的帮助。