Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25064 — 用户需求报告（CIF可用性）
系统和软件工程 — SQuaRE — 可用性通用行业格式：用户需求报告（ISO/IEC 25064:2013）
ISO/IEC 25064 简介
ISO/IEC 25064:2013 定义了作为 SQuaRE 系列一部分的报告用户需求的通用行业格式（CIF）。它提供了一个标准化的框架，用于在整个系统开发生命周期中记录、分析和整合用户需求信息。用户需求报告充当了使用情境分析和用户需求规格说明之间的关键桥梁——它捕获用户实现其目标所需的条件，独立于任何特定的设计解决方案。通过为需求报告提供一致的格式，该标准实现了设计师、开发人员、评估人员和其他利益相关者之间的有效沟通，确保整个开发团队在共享的用户需求理解基础上工作。
提示：结构良好的用户需求报告通过减少需求中的歧义、最小化因误解用户需求而导致的返工，以及提供将设计决策与经过验证的用户研究连接起来的审计线索，直接提高了开发效率。
用户需求报告的内容
ISO/IEC 25064 的第6章规定了构成完整用户需求报告的全面内容要素集。这些要素涵盖了从初始指标到整合需求和推荐的完整范围。
| 内容要素 | 要求 | 目的 |
|---|---|---|
| 报告主题 | 强制 | 标识系统、产品或服务及其目标 |
| 需求的初始指标 | 强制（如有） | 记录来自调查、故障报告等的已有信息 |
| 用户职责和目标 | 强制 | 确定用户在其使用情境中旨在实现的目标 |
| 识别出的用户需求 | 强制 | 每条需求陈述包括用户、预期结果、前提条件和情境 |
| 管理/利益相关者需求 | 强制（如适用） | 捕获影响用户需求的管理者和其他利益相关者的需求 |
| 绩效缺陷/问题 | 强制（如识别出） | 记录要求和实际绩效之间的差距 |
| 整合的用户需求 | 强制 | 分析和综合所有已识别的需求为可操作的要求 |
| 建议 | 适当时 | 为用户需求开发提供指导 |
| 数据收集方法 | 强制 | 描述用户需求信息的收集方式 |
| 支持信息 | 强制 | 包括系统描述、数据收集工具和数据摘要 |
每条用户需求陈述必须遵循精确的格式：包含其涉及的用户或用户组、要实现的目标结果、被识别为必要的前提条件（需求），以及适用的具体使用情境。至关重要的是，需求陈述必须独立于任何提议的解决方案——例如，”演示者需要一种知道还剩多少时间的方式”而不是”演示者需要一个闹钟”。这种解决方案中立的表述保留了设计灵活性，防止了过早的设计承诺。
标准定义了几种需求类型：信息需求（所需的特定信息）、处理需求（需要的计算方法）、愉悦需求（引人入胜和满意的体验）、环境需求（物理和社会环境要求），以及其他类型如互操作性、培训、资源和支持需求。正确分类需求有助于更有效的分析和整合。
注意：一个关键要求——每条用户需求陈述必须包含恰好一个预期结果，但可以包括实现该结果所需的多个前提条件。这种一对多的关系允许全面捕获需求，而不会混淆不同的用户目标。在单条陈述中混合多个结果会导致需求推导过程中的混乱。
目的及与其他 CIF 文档的关系
用户需求报告根据开发阶段的不同服务于多个目的：
对于现有产品： 报告基于当前系统的实际使用和体验来识别用户需求，帮助确定需要哪些修改以及是否需要新系统。这对于用户反馈推动持续改进的迭代开发尤为有价值。
对于新产品： 报告基于设想的使用情境来识别潜在的用户需求，利用初始使用情境描述（ISO/IEC 25063）。需求评估可能侧重于特定功能或整个产品，具体取决于项目范围。
用于使用情境验证： 报告可用于初始确定、验证、更改或细化使用情境描述。收集到的关于用户目标、任务和环境的信息反馈到使用情境的精化中，形成持续改进的迭代循环。
CIF 文档之间的关系本质上是迭代的。使用情境描述为用户需求评估提供了基础。用户需求报告反过来提供信息来验证和细化使用情境。整合后的用户需求随后成为用户需求规格说明（ISO/IEC 25065）的主要输入，驱动设计解决方案。评估结果反馈到所有前述文档中，形成一个真正循环的以人为中心的设计过程。
最佳实践：即使对于小型项目，正式的用戶需求报告可能过于繁琐，标准仍然建议收集相关的内容要素并提供给设计人员和开发人员。格式可以根据项目进行调整——关键在于捕获正确的信息，而不是产生文书工作。
工程实践见解
从工程角度来看，实施 ISO/IEC 25064 用户需求报告框架提供了几个实际优势：
1. 可追溯性和审计线索： 每条需求陈述都有唯一标识并链接到其来源（用户报告、专家推导或来自以前的信息来源）。这种可追溯性对于法规合规性非常宝贵，特别是在医疗器械、航空和其他安全关键领域，证明所有用户需求都已被满足是强制性的要求。
2. 冲突解决： 第6.5节中的整合过程明确解决了用户组内部和跨用户组之间的冲突需求。通过记录包含或排除每条需求的理由，报告提供了在项目演进过程中可以重新审视的决策记录。当用户需求与管理层或组织目标冲突时，这一点尤为重要——标准规定应在报告中识别和记录此类冲突，而不是在报告本身中解决。
3. 绩效缺陷分析： 标准提供了一种结构化方法来记录绩效差距，包括原因、损失和解决价值。这使得能够基于具体指标（如错误率、任务完成时间和客户满意度分数）进行数据驱动的设计改进优先级排序。
| 需求类型 | 示例 | 工程行动 |
|---|---|---|
| 信息需求 | 用户需要知道剩余演讲时间 | 在UI中设计可见的计时器/进度指示器 |
| 处理需求 | 所有满意度分数必须使用相同统计规则 | 实现一致的计算引擎 |
| 环境需求 | 护士需要安全的仪器放置表面 | 设计可折叠工作面或安装系统 |
| 愉悦需求 | 用户想要有吸引力、有挑战性的交互 | 加入游戏化元素 |
常见问题解答
问1：ISO/IEC 25064 与 ISO/IEC 25063 有何不同？
ISO/IEC 25063 侧重于描述使用情境（用户、任务、环境），而 ISO/IEC 25064 侧重于在该情境中识别和记录用户需求。使用情境描述回答”谁、什么、在哪里”，而用户需求报告回答”什么是成功所需的”。它们是互补的，通常迭代开发。
ISO/IEC 25063 侧重于描述使用情境（用户、任务、环境），而 ISO/IEC 25064 侧重于在该情境中识别和记录用户需求。使用情境描述回答”谁、什么、在哪里”，而用户需求报告回答”什么是成功所需的”。它们是互补的，通常迭代开发。
问2：用户需求陈述可以包含提议的解决方案吗？
不可以。标准明确要求每条用户需求陈述独立于任何提议的解决方案。例如，”演示者需要一个闹钟”是无效的，因为它指定了解决方案；正确的表述是”演示者需要知道还剩多少时间以按时完成演示”。解决方案中立的表述保留了设计自由度。
不可以。标准明确要求每条用户需求陈述独立于任何提议的解决方案。例如，”演示者需要一个闹钟”是无效的，因为它指定了解决方案；正确的表述是”演示者需要知道还剩多少时间以按时完成演示”。解决方案中立的表述保留了设计自由度。
问3：用户需求报告的目标用户是谁？
报告服务于多个受众：需求开发人员（指定用户需求）、可用性专家（指导设计决策）、开发人员（了解用户背景）、产品经理（评估资源）、质量经理（评估进度）和市场营销专家（监控需求满足情况）。
报告服务于多个受众：需求开发人员（指定用户需求）、可用性专家（指导设计决策）、开发人员（了解用户背景）、产品经理（评估资源）、质量经理（评估进度）和市场营销专家（监控需求满足情况）。
问4：如何处理冲突的用户需求？
整合过程（第6.5节）通过分析需求与所述使用情境的关系、相似性、重要性和可行性来解决冲突。不现实、无法满足或脱离情境的需求可能被淘汰或修改。报告应记录这些决定的理由，并维护已淘汰或修改需求的审计线索。
整合过程（第6.5节）通过分析需求与所述使用情境的关系、相似性、重要性和可行性来解决冲突。不现实、无法满足或脱离情境的需求可能被淘汰或修改。报告应记录这些决定的理由，并维护已淘汰或修改需求的审计线索。
