永久、临时与情境性障碍在需求上重合
别名: 需求重合 · shared functional need · 功能后果相同
概念解释
字幕让听不到的人跟上对话，也让车厢里把声音关掉的人跟上对话。键盘能操作，既服务不能稳定使用指针的人，也服务触控板坏了的人。需求重合（overlapping accessibility needs）说的是：三条触发原因——永久、临时、情境——落到界面上，要的常常是同一条功能结果，不是三份不同的产品需求。把需求写成「给视障用户」，只覆盖了一种传记；写成「信息不只存在于图像里」，三种触发都站得住。
机制
界面响应的是当下缺了哪条通道，不是病因。成功标准用功能结果来写（文本替代、可键盘操作、可暂停），正因为结果对病因不敏感。第二层在需求文档：诊断标签把重合切开，看起来像三个小众需求，排期时被拆散或只做其中一个；功能结果把重合收成一条，后面的设计只需证明这条结果成立。重合的是需求，不是使用熟练度——同一条字幕轨道，长期依赖它的人和偶尔打开的人，听的方式并不一样。
怎么研究
把每一条无障碍需求映射到至少一种永久、一种临时、一种情境触发，看三条是否指向同一验收条件。对照缺陷库：用诊断标签归档的条目，和用「缺通道」归档的条目，后者能合并的比例。
自变量：需求语句用诊断标签还是功能结果。 因变量：可合并的需求条数、同一验收条件覆盖的触发种类、测试计划是否只招募了一种传记。
不要用短时模拟受限来证明「需求相同」——模拟检验的是通道丢失，证明不了三份需求文档该不该写成一条。这里要看的是需求与验收文本，不是被试的完成时间。
边界
需求重合不等于测试对象可以互换。永久使用辅助技术的人有策略和配置，情境里的人往往没有装阅读器，也没打算装。疼痛、波动性疾病的需求还有「今天能不能做完」，不能全部折进同一条成功标准。语言和文化造成的理解困难不在这组重合里。若一条适配必须依赖用户已经拥有的辅助技术，情境触发就不再自动重合——需求语句里要把「不依赖额外设备」写清。
怎么落地
- 无障碍需求写成功能结果：「状态不只靠颜色」「提交可用键盘完成」，并在同一条下用三句触发故事做例子，而不是写成三个独立需求。
- 人物角色里用诊断标签的句子，改写成缺了哪条通道；改不了的，说明它其实不是这条需求。
- 验收只测功能结果是否成立，不要按「是否残障人士」分叉出三套验收。
- 验证：抽需求文档，凡是只写了一种诊断的条目，补两句另外的触发。补不上，说明写的不是功能结果，退回重写。