DRD 的全称是 Design Requirements Document ，直译设计需求文档，行业内叫交互（设计）说明文档。
作为 PRD 的子文档，以前有点疑惑为什么叫“交互说明文档”，在后来逐步发现 DRD 中编写的设计需求在交互逻辑上的关系后，便理解了这样的“意译”。
DRD 的编写大纲和内容行业内也有很多文章讲解，本文主要通过交互模型的解析，细聊一下文档中按照什么逻辑关系编写什么设计需求信息。
模型一（图 1 ）由 Donald Norman 提出，描述了人机交互（HCI）的基本交互框架（Interaction framework）。用户将完成的目标任务与领域知识相结合，转化为对系统界面的动作行为序列，形成界面输入。输入设备得到输入信息后，将其根据当前系统的状态解释为系统理解的交互行为，并由界面实体执行该行为所对应的任务操作，给出相应的结果反馈。最后，用户通过观察来评估系统的执行结果是否满足自己的期望。
这个模型定义了“人机”的主要行为及行为的先后顺序，结合《设计心理学》中的行为模型进一步理解人的行动逻辑后，我们要思考“机”应该如何配合“人”的行为并最终帮助人实现目标。
模型二（图 2 ）由 Ivar Jacobson 提出，描述用例中的一个步骤为一个事务（Transaction），进一步细分为四阶段——
用户请求系统做某事并附带相关（数据）信息；系统收到请求后验证用户提供的信息和请求的任务；根据验证结果系统改变内部的状态；完成后将结果信息反馈给用户。这位大师是从事软件工程开发的，模型的内容侧重点与第一个模型相反，倾向于表达“机”，进一步的细化“机”的行为，明确系统如何才能行动和行动所需要的东西，涉及的交互活动颗粒度比较大。
我们屏蔽掉模型一中的“人机”的内心活动，只关注人执行和可感知的行为及承载行为的媒介，于是提取出三个概念（图 3）：（用户）输入、（系统）输出、界面。
从模型二可知，系统会根据验证（不是所有输入都要验证）结果执行不同的动作和反馈不同的信息，在这里将验证的信息统称为“条件（图 4）”。所要验证的条件大部分继承 PRD 文档中用例的功能规约。虽然用户无法直接感知条件，但是会影响系统的输出，继而影响用户的行为。
将四个概念根据交互模型中的流程顺序，再以“交互回合”分类并串联起来得到图 5。
提取包含了四个概念的回合 2，进一步简化得到图 6.1。在实际交互的时间线中，用户是先看见输出后的界面，然后再输入，最后系统根据不同条件输出不同的结果（界面）。最终得到的一个以“输出”为起点的交互回合概念流程（图 6.2）：输出 → 界面 → 输入 → 条件，这就是 DRD 中要描述的需求及其逻辑。
交互中的媒介为电脑和手机；交互回合的颗粒度为用户的一个动作级别而非一场活动（一组动作序列）级别
