阿尔伯塔软件项目管理-III-笔记-全-

阿尔伯塔软件项目管理 III 笔记（全）

001：专项课程预告

在本节课程中，我们将对艾伯塔大学的软件产品管理专项课程进行整体介绍，了解课程的目标、内容以及它如何帮助你成为一名成功的软件产品管理专业人士。

我是乔纳森·舍费尔，一名计算机科学家，现任艾伯塔大学理学院院长。我很荣幸向您介绍由我校计算机科学系开发的软件产品管理专项课程。

这套系列课程将教你如何成功地引导一个软件产品从构思到交付的整个开发过程。艾伯塔大学被公认为世界领先的公立研究型与教学密集型大学之一。作为加拿大顶尖大学，我们在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。我们的热情在于为学生成功提供起点，目标是激励、转变和提升我们的学生，帮助他们实现目标。

强大的协作与沟通技能对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。考虑到这一点，我们的计算专家团队将为你提供掌握敏捷软件开发所需的过程与实践方法。我们对软件产品管理流程的实践经验理解，将为你提供直面挑战所需的一切。

我们将教你如何理解和细化客户的软件需求，以及如何将这些需求传达给开发团队。你将学习从监控项目到确保其符合客户需求、遵循项目计划并达到预期质量水平的技术。你将有机会加入一个软件产品管理社区，在那里分享经验并从他人的见解中学习。

最后一门课程是一个为期六周的毕业设计项目，它将为你提供在真实模拟环境中应用这些管理技术的机会。成功完成毕业设计后，你将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。

我很高兴你对学习我们的专项课程感兴趣。我们已经尽力使这成为一次有价值的教育体验。现在轮到你了，祝你好运。

---

在本节课中，我们一起了解了艾伯塔大学软件产品管理专项课程的总体框架、学习目标以及它为你未来职业发展带来的价值。从下一节开始，我们将正式进入客户需求与软件需求的具体学习。

002：1_客户需求和软件需求简介

🎯 课程概述

在本节课中，我们将要学习《客户需求与软件需求》课程的核心内容与结构。课程将介绍如何识别客户与用户的需求，并将其转化为清晰的软件需求，从而指导开发团队构建正确的产品。

---

课程内容预览

大家好，我是 Ken Wang，欢迎来到软件项目管理专项课程中的《客户需求与软件需求》课程。

本课程将为整个专项课程提供基础要素，并作为描绘专项课程结构的知识支柱之一。

在介绍性课程中，我曾提到，打造更好的软件涉及三个目标。这些目标是：正确的产品、正确地完成以及正确地管理。

为了识别正确的产品，你必须理解你的客户和用户的需求，而不仅仅是他们口头提出的要求。他们需要解决什么问题？他们需要完成哪些任务？谁将使用该软件？用户将如何与之交互？当你能够回答这些问题时，你就能帮助你的开发团队构建正确的产品。

为了实现“正确地完成”和“正确地管理”，软件开发必须从一套清晰的软件需求开始，这些需求随后将被规划、设计、实现和测试。

在本课程中，你将学习如何从客户和用户那里收集需求。你还将学习如何将这些需求表达为一套需求规格，以启动软件开发和规划活动。

---

模块一：需求基础与变更管理

在第一个模块中，Bradley Pette 将概述几种类型的健康需求。他将解释如何处理需求变更，以及避免范围蔓延的方法。该模块还将探讨需求与设计之间模糊边界的问题。

---

模块二：需求获取与可视化设计

在第二个模块中，Morgan Ptzel 将描述为人们制作产品时遇到的问题，并介绍获取他们需求的有效方法。她还将解释如何应用用例来捕获项目需要支持的任务。

接着，你将获得一个概览，了解如何应用两种可视化设计技术——线框图和故事板。这两种技术在关于产品的早期讨论中非常有用。

---

模块三：敏捷需求技术

在第三个模块中，Bradley 将回来讨论敏捷需求技术。具体来说，他将描述如何用用户故事来表达需求，用验收测试来验证需求，用项目待办事项列表来排定需求优先级，以及用故事地图来组织需求。

---

模块四：有效需求的特性

在第四个也是最后一个模块中，Morgan 将回来概述有效的软件需求和用户故事需要具备的几个标准。同时，她将指出需要警惕的模糊性迹象，以确保需求不会被误解。

---

课程总结

在本节课中，我们一起预览了《客户需求与软件需求》课程的全貌。到本课程结束时，你将掌握一套实用的技术，用于收集客户和用户的需求，并出色地表达这些需求。你将能够应用这些技术来构建一个更好的软件产品——即正确的产品。

003：什么是需求

欢迎来到《客户需求与软件需求》课程。

本课程是Coursera软件产品管理专项课程的一部分。在本课程中，我们将探讨软件产品管理中最关键的方面之一：需求。如果你是第一次加入我们，我是Bradley，我将作为你本课程的向导。我曾在许多软件项目中担任项目经理，并在阿尔伯塔大学学习了该领域广泛的技术。

在介绍课程中，我们提到了需求为何重要。它们帮助我们清晰地定义客户需求，在错误变得代价高昂之前及早发现它们，并最终确保你开发的产品满足客户的需求。

在本节课中，我将为你全面概述什么是需求，以及处理需求所涉及的活动。

如今，终端用户的要求越来越高，产品也变得越来越复杂。为了确保你得到正确的产品，并且产品被正确地完成，你需要确保从良好的需求开始。

关于需求有各种各样的定义，有些是技术性的，有些则不是。电气和电子工程师协会（IEEE）对需求有其详细的定义，你可以在我们的课程笔记中找到。然而，该定义并不十分简洁。

因此，在本课程及本专项课程中，需求的定义是：需求是对客户需求的具体描述。

正如你将在本节课和本课程中看到的，需求可以采取多种形式。它们可以被很好地定义，也可能定义得不好。事实上，你的需求定义和提炼的好坏会极大地影响你成功的潜力。

正确地获取需求始于了解发现它们的适当活动，以及一个良好编写需求的适当形式。到本课程结束时，你不仅将知道如何执行制定良好需求所需的活动，还将知道如何识别一个需求何时可以改进。

现在你已经了解了什么是需求，让我们看看你能否找出一些例子。

在以下选项中，你认为哪些是软件需求？

A. 作为一名酒店经理，我希望能够为客人办理入住。

B. 我要求你签署一份合同。
C. 账户持有人将在数字键盘上输入他们的银行密码。
D. 用户是男性。

答案A和C是此处的正确答案。它们都描述了客户需要实现的具体功能。其他两个则根本不是需求。

你如何确保你的需求做得好？实践需求活动是一个很好的起点。请记住，活动与软件开发的各个阶段相关联。我们将在本节课中讨论的活动，是与规格说明阶段相关的活动。这通常是流程中最早的阶段，因为在这个阶段，你需要定义你的产品将做什么以及如何做。

此阶段的五个重要活动是：需求获取、需求表达、需求优先级排序、需求分析和需求管理。

让我们首先谈谈需求获取。本质上，获取就是从客户那里获得需求的行为。然而，不要将此误认为是需求收集。需求收集和需求获取之间存在关键区别。这个区别在于你作为软件产品经理与客户互动的方式。

“收集”一词通常用于描述向客户索要他们希望完成的事项列表的行为。而“获取”则是一个涉及更多、更具互动性和调查性的过程，并能产生指数级更好的需求。更好的需求带来更好的软件，因此花时间确保你正确完成这项工作总是个好主意。

需求获取具体涉及什么？为了理解这一点，让我们看一个需求收集的例子。

想象一下，你是一名软件产品经理，被要求为客户构建一个系统。在第一次会议上，你问：“那么你想要什么？”他们准备充分，递给你一张纸，上面列出了他们希望在产品中看到的所有功能，并配有图片，详细说明了他们期望的界面外观。然后会发生什么？一个未经训练的软件产品经理及其开发团队可能会拿着这份列表，开始规划客户指定的确切产品。毕竟，你被雇来编程实现客户想要的东西，对吗？从技术上讲，是的。

然而，在大多数情况下，你的客户对软件如何构建或他们的产品成功所需的功能知之甚少。他们通常会向你提供一份他们希望产品具备的功能列表，但缺乏技术知识来了解他们真正需要什么。

接下来，让我们从行业角度看看“想要”和“需要”之间的区别。

根据我的职业生涯经验，我发现询问客户他们想要什么会得到一个答案，而在他们自己的原生环境中观察他们往往会得到一个非常不同的答案，并且常常会带来惊喜。因此，我认为，找出他们真正需要的方法，是尽可能在接近客户原生环境的地方观察他们。

正确的产品与正确的问题紧密相连。一个“做得对”的产品可能确实执行无误，但它不一定解决了正确的问题。这就是区别所在。你为确保拥有正确产品所花费的每一刻都是值得的。如果你的产品是正确的，即使有一些缺陷，人们也会采用它。客户会原谅你，他们知道随着时间的推移你会修复缺陷。但是，如果你的产品是错的，即使你以零缺陷构建了它，你也浪费了所有的努力，人们仍然不会采用你的产品。这就是“正确的产品”与“仅仅为了做得对而做得对的产品”之间的区别。

---

总结

在本节课中，我们一起学习了需求的基本概念。我们明确了需求是对客户需求的具体描述。我们区分了简单的“需求收集”与更深入的“需求获取”，并理解了后者对于发现客户真实需求的重要性。最后，我们通过行业视角认识到，构建“正确的产品”（解决正确的问题）远比仅仅“把产品做对”（执行无误但可能解决错误问题）更为关键。这是软件产品管理成功的基石。

004：需求活动

概述

在本节课程中，我们将学习软件产品管理中的核心环节——需求活动。我们将了解如何区分客户的“想要”与“需要”，并掌握需求活动的五个主要步骤：获取、表达、优先级排序、分析和管理需求。

---

作为一名软件产品经理，你的工作是梳理清楚客户的“想要”和“需要”。

想要 是指客户希望在产品中看到的期望功能。
需要 是指为解决产品预期要解决的特定问题所必需的核心功能。

这些需要具有优先性，因为它们针对的是客户和用户的真实需求，而非仅仅是他们认为有价值的东西。这并非意味着客户的愿望无效或无法实现，而是说必须从技术角度对产品进行考量，以确保产品能够成功完成。

如果你只是简单地询问客户想要什么，你只会得到一份他们期望的功能列表，而无法将范围缩小到他们真正需要的东西上。这会迫使你陷入被动应对的境地。

为了变得主动，最好始终进行需求获取这项活动。通过深入参与产品的定义过程，你能够将需要从想要中区分出来。

以下是一个例子。想象我之前描述过的相同场景。

你第一次与客户坐在桌前定义产品。你可以这样开始对话：“很高兴能与您合作，我迫不及待地希望项目启动。让我们整体谈谈您希望在产品中看到什么，我和我的团队将尽力为您提供一些关于最佳创建方式的见解。”

就像之前一样，客户拿出了他们希望在产品中看到的功能列表。在对话结束时，你已确定他们一半的功能涉及某种用户界面设计，另一半则涉及最终用户将如何使用产品来解决问题。

你们一致同意，最好首先解决这些最终用户的需求，并构建一个满足这些需求的界面。如果最终结果与之前设计的界面相同，那很好。但不要在需求中将自己限制在特定的设计里。

你可以通过客户的界面设计洞察用户需求，并据此添加更多需求。你和客户在离开会议时，都清楚地知道在项目过程中可以期待什么。更重要的是，你知道对你和团队的期望是可管理的，因为你帮助定义了这些期望。

你的客户可能得不到他们设计的同一个用户界面，但他们仍然会感到惊喜。他们相信你知道自己在做什么，并且理解他们的最终用户需求。更重要的是，他们现在将你视为一个协作、积极的领导者，而不是一个只会听从指示的人，即使那些指示不会带来最佳结果。

然而，不要轻易丢弃客户提出的用户界面设计或其他潜在的“想要”。虽然某个特定界面对于满足客户需求可能不是必需的，但它们对于讨论和发掘之前可能未被注意到的其他需求仍然非常有用。

---

让我们测试一下你的知识。以下哪一项不属于需求规格说明阶段的相关活动？
A. 获取需求
B. 收集需求
C. 表达需求
D. 管理需求

正确答案是 B. 收集需求。请记住，收集需求与获取需求在软件产品经理与客户的互动方式上是不同的。获取需求是一项正确的活动，而非收集需求。

---

现在，你已经弄清楚了客户需要什么以及你需要创建什么，这很棒。那么，你如何以团队可以用来创建产品的方式来构建这些需求呢？这就是需求表达活动的意义所在。

如果说需求获取是从“想要”中梳理出“需要”的行为，那么需求表达就是将那些“需要”转化为某种可用形式的行为。

大多数时候，你的需求最初是与客户进行需求征集会议时在记事本上记录的一系列草稿。它们通常过于简化且没有经过深思熟虑，但这没关系。毕竟，你只是刚开始与客户一起定义事物。这是一个好的开始，但有更好的方式来表达客户的需求。

这些需求可以表现为用例、用户故事、故事板以及许多其他表现形式。它们可以是文本的或图形的，详细的或简化的。不同的项目需要不同的表达方式。在本课程中，我们将涵盖许多这类表达方式。

---

现在，你已经获取了客户需求，并以团队可以用来创建产品的方式表达了它们。你有一个客户需要的大需求列表。接下来是什么？在Scrum中，下一步是对这些需求进行优先级排序。

这里的想法是，将这个大的列表进一步提炼成必须做的、应该做的和可以做的。一旦你以这种方式对需求进行了优先级排序，下一步就是计划和估算这些需求。

创建需求列表的另一项重要活动是分析它们，以确保它们是完整的、清晰的和一致的。你需要确保基于这些需求构建的产品能够满足客户的需求。你还需要确保你创建的所有需求能够很好地协同工作。

你可能会遇到一些最初看起来能很好协同的需求，但经过进一步检查，实际上存在冲突。因此，通过分析你的需求，你可以确保它们准确地反映了你打算构建的产品。这也有助于确保产品能够尽可能做到最好。

Morgan和我将尽最大努力，通过持续评估和改进，确保你知道如何创建好的需求。

---

在Scrum中，当需求从客户那里获取并表达出来，并放入一个大的列表（也称为产品待办事项列表）之后，下一步是什么？
A. 开发
B. 需求优先级排序
C. 产品架构设计
D. 进一步的需求获取

这里的正确答案是 B. 需求优先级排序。一旦你从客户那里获取并表达了所有需求，下一步就是让客户对需求进行优先级排序。

---

我要提到的创建良好需求的最后一项活动是管理它们。毕竟，需求很重要，你不想丢失它们。

每个需求都需要被开发人员从许多地方引用，比如他们的代码、测试和变更日志。当一个需求发生变化时，你需要知道它发生了，并理解对其他需求的影响。此外，你可能希望以不同的方式对需求进行分组和重组，可能在其他产品中复用子集。这些方面都属于需求管理的范畴。

---

总结

在本节课中，我们一起学习了需求的基础知识。需求是对客户需求的具体描述，可以采取多种形式。创建和管理需求涉及五个主要活动：获取、表达、优先级排序、分析和管理。

现在你已经了解了需求及其相关活动的基础知识，我们准备进行更深入的探讨。在下一课中，我将告诉你不同类型的需求。

软件产品管理课程3：《客户需求与软件需求》：3.1.2：需求类型

在本节课中，我们将要学习软件产品开发中涉及的不同类型的需求。理解这些类型有助于我们更有效地捕捉、表达和管理需求。

在上一课中，我们讨论了什么是需求以及与之相关的各种活动。我们了解到，需求本质上是一种将客户需求转化为可构建成实际产品的方式。我们还认识到，当开发团队与客户协作时，这些需求最容易地被获取和表达。

现在，我们已经有了初步了解，让我们更深入地探讨一下。为了理解如何从需求中获得最大价值，我们必须了解软件产品可能需要哪些不同类型的需求。

当你想到“需求”这个词时，脑海中会浮现什么？或许你想到的是产品最终版本应包含的功能列表。或许你想到的是关于产品在不同情况下应如何表现的一系列描述。或者，你可能想到了产品为何应该存在的根本原因。

事实证明，所有这些都是有效的需求类型。它们共同描述了产品应该是什么样子、应该如何工作以及为何应该存在。让我们更详细地讨论这些。

业务需求：产品的“为什么”

我们首先提到的需求类型，即产品为何被需要，被称为业务需求。

业务需求概述了软件项目的目的。它们为产品负责人提供了启动项目的根本理由。你可以将这些需求想象为与产品的实际开发是分开的。这些需求不仅仅是个人或道德层面的原因，例如“必须在市场上领先”或“必须被尽可能多的用户使用”。一个业务需求必须定义能提供具体、可量化商业价值的产品需求。

一个业务需求的例子是：“我需要这款产品吸引印度的服装设计师，以便每年增加5万美元的收入。”这就是一个业务需求。你的客户在制定商业战略和计划时会使用业务需求。它们是业务分析师审视产品最终商业目标的一种方式。

需要注意的是，业务需求也可能有其他名称。术语“业务需求”有时可能用来描述我们将在本课后面讨论的其他需求。就我们的目的而言，业务需求仅指构成“产品为何应该存在”的那些需求。

业务规则：产品的“约束”

有时，业务需求的概念会与预算、政策或法规等词语相关联。这些是我们所称的业务规则的例子。

这些规则比业务需求更具体。业务规则约束了产品的功能。它们还规定了项目要被视为成功甚至合适所必须遵循的规则。

以下是业务规则的一些例子：

• 一项隐私政策，要求企业必须安全存储数据，并且不与不必要的人员共享。
• 一项品牌统一性要求，规定待开发的产品在视觉上必须与客户拥有的其他产品保持一致。
• 一项政府法规，例如根据当地或国际法律，要求将用户数据及其任何操作信息保存特定时长。

所有这些都属于业务规则。它们概述了产品的一些限制。你可以将业务规则理解为规定了软件开发必须在哪些限制条件下进行。

小结与回顾

我们刚刚讨论了两种需求类型：业务需求和业务规则。

假设你正在为一个需要计算销售税的发票产品制定需求。你正在创建哪种类型的需求？A. 业务需求，还是 B. 业务规则？

答案是 B，业务规则。征收销售税是政府对进行销售的公司提出的法律要求，它约束了与销售相关的产品。最佳答案是业务规则。业务需求则更像是描述你最初为何要制作这个产品。

在本节中，我们一起学习了需求的两个基本类型：业务需求（定义产品的商业目标和存在价值）和业务规则（定义产品必须遵守的具体约束和法规）。理解这两者的区别是有效需求管理的第一步。接下来，我们将继续探讨描述产品“是什么”和“怎么做”的其他需求类型。

软件产品管理课程3：客户需求与软件需求：第3.1.2a节 用户需求

在本节中，我们将学习用户需求。用户需求描述了用户能够使用产品完成的具体任务，是连接业务目标与最终产品功能的关键桥梁。

---

上一节我们讨论了业务需求和业务规则，它们关注的是产品整体存在的原因以及构建时必须遵循的约束。了解这些术语对您的职业生涯很有帮助，即使产品经理对其创建没有直接影响。

接下来，我们将介绍一系列与产品经理及其开发团队直接相关的需求类型。首先，让我们深入了解用户需求。

用户需求明确界定了用户能够使用产品完成哪些任务。这里的“用户”指的是最终会使用您软件的个人，因此也常被称为“最终用户”。鉴于最终用户对产品成功至关重要，通常需要投入大量时间来制定这些需求。

事实上，用户需求很可能是开发团队最需要准确把握的需求类型。因为它们定义了最终用户如何与产品互动，以及产品应为用户提供什么功能。我们可以将其视为所开发产品的核心功能。

在本课程后续部分，我们将详细探讨如何恰当地获取用户需求，并将其转化为具体、可操作的开发任务。我们还将讨论如何创建高质量的用户需求，以及表达这些需求的不同方式。

用户需求的核心是用户能用您的产品做什么。它们可以通过多种形式来表达。

以下是表达用户需求的两种常见方式：

• 用例：用例是展示系统与用户之间关系的有效方式。在您看到的这个例子中，它具体展示了不同的用户场景及其与系统的交互方式。我们将在下一个模块中更深入地介绍用例。
• 用户故事：用户故事是另一种表达形式。我们将在本课程后面更详细地介绍用户故事，但其基本结构是：作为一个<角色>，我想要<进行某个操作>，以便于<实现某个价值/目标>。这种结构确保我们在思考需求时，始终将用户需求放在首位。

例如：作为一名软件产品经理，我想要创建用户故事，以便于我能更好地表达客户的需求。

然而，客户最初提出的需求往往并非如此清晰。通常，客户需求会以这种模糊、非具体的形式出现：“客户应该能够在系统中查看并支付账单。”

这当然不是客户的错，但这是软件产品经理必须解决的一个常见障碍，以确保开发团队明确知道如何最好地构建产品。对我而言，这正是软件产品管理中最有成就感的方面之一：能够将客户模糊的需求提炼成具体、实在的东西，通常会带来一种满足感和条理感，仿佛一切各归其位。

小测验：以下哪一项代表了用户故事的基本形式？
A. 作为一个<空白>，我想要<空白>。
B. 作为一个<空白>，我想要<空白>，因为<空白>。
C. 我想要<空白>，以便于<空白>。
D. 作为一个<空白>，我想要<空白>，以便于<空白>。

正确答案是 D。用户故事遵循“作为一个<角色>，我想要<操作>，以便于<价值>”的形式，这确保我们能捕捉到需求的角色（谁）、操作（做什么）和价值（为什么）。

---

在本节中，我们一起学习了用户需求。我们了解到用户需求定义了最终用户与产品的交互任务，是产品的核心功能。它们通常通过用例和用户故事（格式：作为一个<角色>，我想要<操作>，以便于<价值>）来表达。同时，我们也认识到将客户模糊的初始需求转化为清晰、具体的用户需求，是产品经理的一项关键且富有成就感的工作。

007：功能需求

在本节中，我们将学习功能需求的概念。功能需求是软件开发过程中的核心，它描述了系统“必须做什么”。我们将了解如何定义功能需求，并通过实例和图表来清晰地表达它们。

---

上一节我们介绍了需求的不同类型，本节中我们来看看其中一种关键类型——功能需求。

功能需求属于开发团队的工作范畴。它是一种描述产品应执行或支持的行为的需求。

功能需求可以通过输入、输出以及行为本身的描述来表达。

设想一个场景：一位客户向你提出一个项目构想。他们想要一款移动销售点产品，该产品能通过客户专有的信用卡读卡器接收信用卡付款，然后向用户发送包含交易详情的收据。客户还提到，该产品必须符合最高的安全和视觉设计标准。

请记住，功能需求涉及输入和输出。在这个简单的例子中，我们有一个输入（来自信用卡读卡器的数据）和一个输出（交易收据）。因此，你可以说：系统必须从信用卡读卡器读取数据，并且系统必须向最终用户发送交易收据。

为了简化说明，我们在此省略了许多功能需求。实际上，你可能会想到系统还应接收来自商家的交易信息作为输入，然后在某些确认操作后，系统应向买家展示交易信息并最终接收其PIN码信息。仅在这个例子范围内，就可以想到相当多的功能需求。

需求本身也具有一定的深度。一个声明“用户应能使用密码键盘支付”的功能需求并不具体。这可以分解为几个更深入、更具体的要求，例如：

• 用户应能刷卡（借记卡或信用卡）。
• 用户应能将信用卡或借记卡插入芯片读卡器。
• 当卡片被刷卡或插入后，用户应能输入其PIN码。

如果需求不够具体，可能会导致规划出现问题。你可能以为自己需要做的工作很少，但实际上工作量可能相当大。关于这一点，我将在本课程后面更详细地探讨。现在只需意识到需求具有深度即可。

表示功能需求的一种方法是使用信息流图，如下图所示。

信息流图为你提供了一种图形化方式，来展示系统所有组件的数据流和依赖关系。本质上，它展示了系统的各个组件是如何连接在一起的，让你了解系统作为一个整体是如何运作的。信息流图提供了一个逻辑上审视整个系统的上下文。如果你想了解更多关于信息流图的信息，请查看课程资源。

---

为了巩固理解，让我们看一个练习题。

设想一个场景：你正在建立一个非营利组织，为社区中的低收入通勤者翻新自行车。你从捐赠者那里收到自行车（由铝制成）以及用于购买工具的资金。然后，你利用这些资源让自行车恢复功能，并将它们交付给你的客户。

以下哪一项应被视为该组织的功能输入和输出？

A. 输入：捐赠的自行车和购买的工具；输出：客户。
B. 输入：捐赠的资金；输出：可用的自行车。
C. 输入：捐赠的资金和自行车；输出：可用的自行车。
D. 输入：自行车中的铝材和捐赠的资金；输出：可用的自行车。

答案是 C。该组织接收资金和自行车，然后进行维修并交付给客户。输入是捐赠的自行车和资金，因为工具是使用捐赠的资金购买的。这些工具是用于修复自行车的过程的一部分。

---

本节课中我们一起学习了功能需求。我们了解到功能需求定义了系统必须执行的行为，通常通过输入、输出和行为描述来表述。我们探讨了需求需要足够具体（具有深度）的重要性，并介绍了信息流图作为可视化功能需求和数据流的一种有效工具。最后，我们通过一个实例练习应用了这些概念。理解功能需求是准确规划和构建软件产品的基石。

008：非功能需求 🎯

在本节中，我们将学习非功能需求的概念。非功能需求描述了产品必须表现得多好，它们与功能需求互补，共同定义了产品的完整规格。

上一节我们介绍了功能需求，本节中我们来看看非功能需求。

非功能需求概述

功能需求定义了产品应该做什么，而非功能需求则定义了产品应该做得多好。非功能需求主要关注产品的质量因素，因此有时也被称为质量需求。

非功能需求示例

以下是不同类型非功能需求的几个例子：

1. 准确性与安全性需求
以驾驶辅助系统为例。系统需要感知前方车辆的距离，并在距离过近时自动刹车。这里的非功能需求是系统传感器的准确性。仅仅说“系统应读取距离并在达到阈值时刹车”是不够的。如果测量存在中等误差，后果可能是灾难性的。因此，准确性和安全性是非功能需求。

2. 可靠性需求
假设客户希望建立一个存储重要文档的数据库。该系统需要能够从灾难中恢复，以避免数据丢失。这种可靠性要求是非功能需求。

3. 安全性需求
如果上述数据库存储了包含用户个人信息的敏感文档，那么系统必须安全，不易受到攻击。这就需要建立强大的信息加密机制，并使整个系统难以被攻破。这些安全性要求是非功能需求。

4. 可用性需求
以一个简单的网站邮箱注册表单为例。表单通常会检查用户邮箱的有效性，以尽量减少输入错误。如果没有这种错误预防检查，许多邮件可能无法送达。此外，注册表单是否易于导航、各项信息填写位置是否清晰（例如有明确的姓名标签），这些易用性或可学习性要求也是非功能需求，它们统称为可用性需求。

5. 效率需求
考虑一个由客户提出的水下研究设备，它依靠电池供电。设备必须足够小巧轻便，以便存放在小船上；同时必须足够高效，能提供至少数小时的水下续航。其所有仪器都必须能够实时、无延迟地执行功能，并且电池应能快速充电。这些关于空间、功耗、时间和资源的要求，都属于以效率为核心的非功能需求。

6. 性能需求
性能需求同样是非功能需求。例如，系统需要维持特定的响应时间，或在短时间内处理一定数量的请求。

7. 可维护性需求
想象一下，客户希望开发一款软件，用于查询本地餐厅数据库并将其标注在地图上以便导航。客户还设想未来将该软件扩展用于其他产品，例如在地图上标注纪念碑和旅游景点，并在输入地点后立即显示。这种要求软件足够灵活以超越原始用途进行扩展的需求，就是可维护性需求。

非功能需求类型总结

让我们快速回顾一下提到的非功能需求类型：

• 准确性
• 可靠性
• 安全性
• 可用性
• 效率
• 性能
• 可维护性

知识检查 ✈️

每天都有飞机从加拿大温哥华国际机场飞往中国上海浦东国际机场。这些飞机必须遵守航班时刻表，其航程受所载燃油量的限制。

以下哪几项是这些飞机的非功能需求？
A. 必须消耗航空燃油。
B. 航班时刻表不得延误。
C. 必须能够单箱燃油完成从YVR到PVG的飞行。
D. 满载乘客必须在90秒内完成撤离。

正确答案是C和D。
C项是关于性能的非功能需求（续航能力）。
D项是关于可用性/安全性的非功能需求（紧急疏散效率）。
A项涉及飞机的输入（燃料类型），B项涉及航班计划，与飞机本身的性能或质量属性无关。

---

本节课中我们一起学习了非功能需求。我们了解到，非功能需求与功能需求相辅相成，它们不定义产品“做什么”，而是定义产品“做得多好”，涵盖了准确性、安全性、可用性、性能等多个关键质量维度。明确非功能需求对于构建高质量、可靠且用户满意的软件产品至关重要。

009：其他需求类型

在本节中，我们将继续探讨软件需求的其他类型，包括外部接口、物理环境设置和开发约束。这些需求为产品的最终设计和实现提供了重要的上下文信息。

上一节我们介绍了用户需求、功能需求和非功能需求等核心类型。本节中，我们来看看另外三种重要的需求类型，它们有助于更全面地定义产品。

🌐 外部接口需求

外部接口需求描述了产品在更大系统中所处的逻辑位置，以及它如何与其他外部实体连接和通信。

其核心思想很简单：你的产品通常属于一个更大的系统。外部接口需求旨在勾勒出产品在该系统中的位置。这里指的不是物理位置，而是产品在逻辑上如何置身于产品外部的其他实体之中。

这些接口还描述了通过何种媒介、协议、格式和兼容性级别来建立这些连接。简单来说，外部接口展示了产品本身如何与系统中的其他事物相关联。

假设你有一个软件应用，它向最终用户显示信息并访问远程数据库。该应用位于数据库和最终用户之间，并与两者各有一个外部接口。外部接口指明了应用与数据库交互所需的协议，以及信息应如何呈现给用户。

外部接口通常在数据流图中标识。数据流图将所有产品组件集中展示，并明确标注数据在整个系统中如何与外部实体进行传递。因此，外部接口本质上是对你的产品在整个系统内其他实体间的逻辑定位的描述。

请注意，不要将外部接口与产品的物理位置混淆。物理位置实际上是另一种独立的需求类型。

以下哪项可被视为外部接口需求？

• A. 产品必须能够与客户数据库和广告服务器通信。
• B. 产品必须能够在电池供电下运行六小时。
• C. 产品必须能够承受从不少于50米高处跌落造成的冲击。
• D. 产品必须能承受每天10小时的阳光直射。

答案是 A。请记住，外部接口是一种规定产品如何与系统的其他组件通信或连接的需求。因此，通过与客户数据库和广告服务器通信，定义了产品的外部接口。

🏜️ 物理环境设置需求

物理环境设置需求描述了产品应如何围绕其物理环境进行设计。

这类需求关注产品所处的实际物理条件。例如，如果你要为撒哈拉地区的建筑设备开发一个GPS追踪器，你会希望确保它能承受极端高温、沙尘、噪音和振动。如果你是为南极洲的应用开发该系统，那么你会希望产品能承受极端寒冷。所有这些都是在指定物理环境设置需求时需要考虑的因素。

⚙️ 开发约束

开发约束概述了开发团队将使用的实现技术、规范、文档和流程。

假设你已经指定了之前讨论的所有需求，你的开发团队有能力创造出你设计的产品吗？知道这个问题的答案非常重要。

开发约束勾勒出实现技术、惯例、文档以及团队将使用的流程。它们也可能涉及开发团队将支持哪些设备或平台，或者他们在内存、带宽或处理能力的使用上受到何种限制。

通常最好在需求规格说明阶段的后期再指定这些约束，这样产品的愿景就不会被现有技术所限制。技术在进步，产品也应如此。通过最后讨论开发约束，你可以避免过早地使用旧技术和旧能力进行设计的可能性。

📝 本节总结

本节课中，我们一起学习了用于表达客户需求的不同需求类型。让我们回顾一下：

首先，我们讨论了可能影响项目的要求类型，即业务需求和业务规则。

然后，我们探讨了几种核心需求类型，包括用户需求、功能需求和非功能需求。

最后，在本节中，我们介绍了为产品的最终设计和实现提供额外上下文的几种需求，即外部接口、物理环境设置和开发约束。

接下来，我们将讨论如何管理不断变化的需求并控制产品范围。

010：控制范围

概述

在本节课中，我们将要学习软件产品管理中一个至关重要的环节：如何定义并控制项目的范围。我们将探讨产品愿景与范围的区别，理解范围蔓延的危害，并学习一系列实用的技巧来有效管理需求变更，确保项目在可控的轨道上运行。

产品愿景与范围

上一节我们介绍了不同类型的软件需求。本节中，我们来看看在形成和维护需求集合时面临的一些挑战。

定义需求时需要投入时间并保持谨慎。同时，也必须认识到需求在整个开发过程中不可能保持一成不变。需求必定会发生变化。当我们接受这一点时，就能更好地应对这些变化。根据软件工程领域的知名专家罗伯特·格拉斯所述，软件项目失控的两个最常见原因之一就是不稳定的需求。

许多项目经理都遇到过这种情况：开发团队开始根据一组特定需求进行工作，但在项目中途，客户改变了某些想法。突然间，开发团队不得不中途改变工作重点。在这种常见的情况下，你该怎么办？

如果开发团队每次客户提出变更都改变方向，项目很快就会失控。这会造成大量的开发任务积压，并降低产品质量。不仅如此，开发团队的士气也会一落千丈。然而，如果产品团队坚持原计划不做任何调整，最终产品很可能无法满足客户需求。这将浪费开发团队的时间和客户的资金。

我们需要在这两个极端之间找到一个平衡点。让我们从产品创意最初诞生时开始思考。产品的初衷是什么？客户想要解决什么问题？这就是产品愿景。软件工程领域的作家兼顾问卡尔·维格将产品愿景描述为“一个新系统最终目的和形态的长期战略构想”。本质上，产品愿景勾勒了产品对客户的价值及其在市场竞争对手中的地位。

产品愿景与你的产品有何关系？可以将产品愿景视为产品的指导原则。无论产品发生什么变化，产品的设计仍应支持其愿景。然而，这并不意味着产品愿景总是现实可实现的。

让我用一个例子来解释。假设一位客户找你开发一款手机游戏项目。根据需求，你和你的开发团队估计需要三个月时间。客户给出的产品愿景是：通过模拟项目经理的视角来创造独特的身临其境的游戏体验，以此进行项目管理。

现在，假设开发进行了一个月，一切顺利，这时客户找到你。他们告诉你，由于虚拟现实技术最近取得了进步，他们希望开始为虚拟现实平台进行开发。从技术上讲，切换平台可以让你遵循产品最初的愿景。然而，这种转变意味着产品和开发资源的重大调整，因此并不现实可行。我们将客户要求的这种转变称为范围变更。

在上面的场景中，客户通过建议你切换平台来改变了范围。那么，以下哪种情况会构成愿景变更？
A. 客户选择转向移动游戏而非虚拟现实。
B. 你的开发团队决定更改一些产品实现细节。
C. 你的项目超出预算，被迫暂停。
D. 你的客户决定产品不再是一款关于项目管理的手机游戏，而是选择创建一个允许客户设计定制家具的应用程序。

答案是 D。当你的客户选择创建一个具有完全不同指导原则的产品时，他们就是在改变愿景。通过选择制作一个家具设计应用，而不是一个关于项目管理的游戏，产品的愿景已经改变。

范围和愿景是相互关联的。愿景涵盖了产品最终将做什么以满足用户需求，而范围则涵盖了在当前项目中现实可以实现的内容。虽然客户的总体产品目的没有改变，但对开发人员的要求已经改变。因此，范围是对开发团队及其产品经理影响最大的因素。所以，范围是思考软件产品时需要考虑的最重要的事情之一。

再次引用卡尔·维格的话：“范围划定了项目中包含什么和不包含什么的界限。”

管理期望与定义边界

好的，这很简单。范围告诉你你将做什么和不做什么。但是，如何为特定项目决定这意味着什么？我们又该如何确保保持在范围内？

最好的起点是在项目的需求获取阶段。与你的客户讨论对产品的期望。如果你避免过度承诺产品的功能，就可以避免日后让客户和开发团队都感到失望。

想一想：你告诉客户你能开发什么，并且能在三个月内完成。但做到一半时，你意识到你根本无法交付那个产品。考虑到客户期望你能交付一个完整的产品，你认为他们会说什么？如果你想维持满意的客户关系，这不是正确的方法。

最好尽早管理客户的期望，以避免导致失望的情况。一种方法是识别用户可能期望但从当前项目中排除的功能。

例如，假设你正在为一个乐队创建网站。网站用户可能期望能够与其他粉丝发送消息和购买音乐会门票。然而，如果你认为在截止日期前，你的团队没有足够时间实现这些功能，那么完全可以向客户说明这一点。通过这种方式，你可以管理期望，并帮助确保项目结束时没有人感到失望。

防御范围蔓延的技巧

管理期望听起来不错，但我们具体该如何做呢？让我们来谈谈一些防御范围蔓延的技巧。顺便说一下，范围蔓延是指产品需求不断累积的情况。不受控制的范围蔓延会随着时间的推移显著降低项目成功的可能性。

在介绍防御范围蔓延的不同方法之前，你认为以下哪些是防御范围蔓延的方法？
A. 让客户对需求进行优先级排序。
B. 明确期望。
C. 与客户一起划定范围。
D. 询问“这在范围内吗？”

实际上，所有这些答案都是正确的。所有这些技巧都是有效的，尤其是当它们结合使用时。

以下是防御范围蔓延的具体技巧：

首先，在客户和你自己之间明确期望。即，确保每件事都有明确的开始和结束日期，并尽可能遵守。

其次，与客户一起划定范围。使用用例图来展示不同用户角色之间的预期交互以及产品支持的任务，并围绕此进行设计。

第三，确保客户对需求进行优先级排序。当客户指定哪些需求价值最高时，就很容易确保产品最重要的部分得到优先开发。这样，即使项目时间或资金减少，你仍然满足了关键需求。

第四，在形成需求时，询问“这在范围内吗？”。很容易忽视在细化不必要需求上浪费的时间。如果你强迫自己询问每个需求的相关性，就可以确定当前项目中包含什么，并为未来的版本记录功能。

评估与决策

在制定需求时，估算完成每个需求所需的工作量也很重要。随着你和你的开发人员在构建产品方面经验越来越丰富，这会变得更容易。随着时间的推移，你可以发现团队的平均生产力，并以此为基础进行估算。

当你估算完成产品需求所需的工作量时，可以将估算值相加，看看是否能满足截止日期。这有助于你决定一个需求是否现实可行。

当对产品提出变更时，花时间评估该变更的影响。它将如何影响你的人员资源、资金、产品质量、时间表和成功的可能性？在考虑变更时，所有这些因素都会起作用。当然，当接受一个变更时，你应该修订你的估算和计划以反映这一变化。

理解了这一点，很容易为了简单起见而走极端，拒绝所有提议的变更。变更的引入通常是为了增加项目的商业成功机会。逐个评估每个变更，并根据具体情况做出决策，将使你能够在扩展产品的同时，最大限度地提高其成功的机会。这也是敏捷宣言的核心原则之一。

总结

本节课中我们一起学习了以下内容：

1. 首先，我们定义了什么是愿景，以及它与软件项目的关系。
2. 然后，我们定义了什么是范围，以及它如何可能失控。
3. 接着，我们讨论了通过以下技巧来避免范围蔓延：
   • 管理期望。
   • 划定产品边界。
   • 设定优先级。
   • 询问“这在范围内吗？”。
   • 进行估算。
   • 评估提议变更的影响。

在下一课中，我们将讨论设计中的需求。我们下节课见。

011：需求与设计 🧩

在本节课中，我们将探讨软件项目中“需求”与“设计”的区别。理解这两者的边界对于构建成功的产品至关重要。

上一节我们讨论了需求变更如何导致范围蔓延及其管理方法。本节中，我们来看看需求与设计有何不同，以及这对软件项目意味着什么。

需求与设计的区别

在制定需求与设计产品之间，存在一个模糊的边界。

通常，需求强调产品的 “是什么”。即：客户需要开发什么才能使产品成功？

而设计则强调产品的 “如何实现”。即：开发团队将如何实现产品以满足客户需求？

历史视角：瀑布模型

如果你没有学习过《软件过程与敏捷实践》课程，可以跳过这个小测验。

问题：在哪个软件开发过程模型中，需求与设计是完全独立的两个阶段？
A. 锯齿模型
B. 螺旋模型
C. 统一过程模型
D. V模型
E. 瀑布模型

答案：E. 瀑布模型。

在瀑布模型中，需求与设计是完全独立的活动。根据该模型，需求在产品设计之前独立制定，以确保需求不受设计限制的约束。也就是说，此时的需求只关注问题本身，而不涉及解决方案。

现代开发中的融合

在现代迭代和并行开发过程中，开发团队通常同时处理需求和设计。

开发团队在构思需求时考虑设计元素是非常普遍的。同样，客户也可能带着期望的设计特性来构想产品，而非描述他们真正的问题或需求。这就是为什么需求与设计经常被结合或混淆。

例如，在产品的视觉图纸背景下放置你的需求，是理解产品的一种简单方法。这可以帮助你规划需求的正确性、一致性和清晰度。一旦你的需求以这种视觉方式组合在一起，就很容易看出它们是否作为一个逻辑整体相互契合。

模糊边界的风险与应对

模糊边界是可以的。然而，需要注意不要让这个概念走得太远。

如果你过早地关注设计解决方案，最终可能会无意中忽略根本需求，并对产品施加不必要的约束。

以下是几个需要警惕的情况：

• 过早施加技术约束：例如，假设你的任务是开发一个在用户设备上运行并与远程服务器交互的应用程序。如果你的需求规定“产品应使用Java编程语言编写”，你就是在对开发团队施加不必要的设计约束。如果开发一个Web应用程序并使用其他编程语言更有意义呢？
• 隐含特定交互方式：看看这个例子，找出需求的问题所在。你的客户说，他们希望“用户点击OK按钮来提交请求”。提示：如果产品界面只使用物理按钮进行输入呢？在这个例子中，客户对产品施加了“点击”要求。他们实质上是在说，用户必须使用非常特定的输入设备来控制如何进行选择。如果你将此需求应用于移动设备，这个术语就不能完美转化。在这种情况下，用户可能是“点击”按钮，而不是“单击”它。更好的说法是“用户提交请求”。

制定需求时的关键问题

在制定需求时，请将以下问题牢记于心：

• 某个解决方案只是一种可能的选择吗？
• 这个解决方案是唯一可能的吗？
• 这个解决方案是否针对了错误的问题？
• 这个解决方案只是为了吸引开发者的兴趣吗？
• 客户是否更关注解决方案本身？

当你在构思产品时思考这些问题，你的产品质量将得到真正提升。

总结

正如你所见，设计常常以不好的方式潜入需求。现在你知道了这种情况是如何发生的，就能更好地避免它。在构建需求时，始终要留意你是否过早地对产品施加了某些设计解决方案。

本节课以及本模块的内容到此结束。希望我对需求是什么、为什么需要需求以及创建需求时的一些注意事项给出了清晰的阐述。在下一个模块中，Morgan将与你探讨如何获取和表达用户需求。祝你学习愉快。😊

012：餐馆场景

在本节课中，我们将介绍一个贯穿课程始终的示例。通过跟随这个示例，你将能看到需求活动如何从开始到结束逐步推进。

认识客户

现在，很高兴向你介绍你的客户。

你好，我是杰米。我是名为“布拉姆顿披萨与意面”的家庭连锁餐厅的高管。我们正在寻求为我们的餐厅内部使用开发一些软件。

我的目标是优化餐厅的点餐流程，使其更高效。

我的设想是，顾客应该能够查看他们所在餐厅的菜单，并在准备好后下单。我非常希望有一个儿童页面，可以展示儿童菜单，或许还有一些小游戏供孩子们玩。但最重要的是，它应该足够简单易用，让孩子们能够自己下单。

此外，顾客应该能够指定他们对餐食的任何修改要求，并且在下单到厨房之前，能够列出他们可能有的任何饮食限制。

厨房应该能够实时查看这些订单。

顾客应该能够在系统内查看并支付账单。

我想就这些了。我期待在这个项目上与你们合作。

开始构建需求

好了，现在你已经认识了你的客户并听取了他们的初步构想，接下来让我们开始构建一些需求。

在本节中，我们引入了一个具体的餐馆场景作为后续学习的案例。通过客户杰米的描述，我们初步了解了项目的目标和核心功能设想。

---

本节课中我们一起学习了贯穿本课程的餐馆示例场景，并初步认识了客户及其对软件系统的核心期望。在接下来的章节中，我们将以此为基础，逐步展开客户需求与软件需求的分析与定义工作。

013：3.2.2 用户考虑因素

在本节课中，我们将要学习软件开发过程中一个至关重要的方面：理解并考虑最终用户。我们将探讨用户、利益相关者等核心概念，并学习如何将他们纳入产品设计考量。

开发软件时，最重要的事情之一是考虑最终用户。你为谁制作这个产品。谁会使用这个产品。你可能开发出你认为有史以来最伟大的产品。但如果用户不喜欢这个产品，或者他们无法操作这个产品，它就会失败。尤其是在技术行业，用户有非常多的选择。如果市场上存在一个对最终用户来说更容易使用的类似产品。他们会选择那个产品。想想市场上所有的任务管理应用程序。花点时间在你手机的应用商店里搜索“任务管理器”。有成千上万种不同的应用程序，有些很棒，有些很糟糕。但正如你所见。如果用户不喜欢一个应用程序，他们有很多选择，他们会转向下一个。对于网络应用程序来说，这一点可能更为关键。竞争对手只需点击一下即可访问。无需下载和安装新的应用程序。由此可见。时刻牢记你的最终用户非常重要。这就是我们本节课要讨论的内容。

当你开发产品时，必须考虑哪些用户方面？首先。让我们回顾一下我将要使用的一些术语。

👥 核心术语定义

最终用户或用户是指将直接使用产品的任何人。利益相关者是指任何受项目成功影响或对项目成功有影响的人。这包括最终用户，但也包括其他人，例如客户、最终用户的管理员和系统管理员。

用户界面或UI是最终用户将与之交互的任何东西。以一个应用程序为例。后台有许多东西在运作以使其正常工作。但其中没有一个是用户界面。用户界面是你在使用应用程序时能看到的一切。例如，像窗口、按钮、滚动条、复选框和文本框这样的元素共同构成了用户界面。

🎯 利益相关者类型

上一节我们介绍了利益相关者的基本概念，本节中我们来看看利益相关者的具体分类。利益相关者通常分为三种类型的用户：主要用户、次要用户或三级用户。

主要用户是实际将使用产品的人。我们将主要用户称为最终用户。次要用户是偶尔使用产品或通过中介使用产品的人。

以下是三种用户类型的简要说明：

• 主要用户：产品的直接、频繁使用者。
• 次要用户：产品的间接或偶尔使用者。
• 三级用户：受产品使用影响或为产品做决策的人。

让我们看一个次要用户的例子。在我们的餐厅点餐系统示例中。服务员可以被视为次要用户。他们不是产品的目标用户。但他们必须具备产品的工作知识才能协助顾客。他们也可能使用应用程序来帮助顾客下单。

三级用户是那些会受到产品使用影响或为产品做出决策的人。你的客户就是三级用户。让我们再看一下我们的例子。具体来说是面向4至12岁儿童的儿童友好页面。客户指定此页面应显示儿童菜单，包含可玩的游戏，并且足够简单，让儿童可以自己选择食物。对于这个页面。孩子是主要用户，因为他们是页面的预期使用者。孩子的监护人将是次要用户。监护人需要知道页面如何工作，以便他们可以帮助孩子。但他们可能不会成为大部分时间使用该页面的人。你的客户杰米。是三级用户，但餐厅老板也是三级用户，因为他们受到应用程序成功与否的影响。

成功的产品会考虑到所有利益相关者的需求。

🔍 深入分析利益相关者影响

让我们更详细地看看我们的儿童菜单例子。如果主要用户，即孩子。无法弄清楚如何使用菜单，他们会失去兴趣。孩子的注意力持续时间不是很长，所以你必须快速吸引他们。如果食物选择不适合儿童，或者如果孩子能够选择不止一份餐食。那么监护人，即次要用户，可能不会允许孩子使用该应用程序。如果应用程序太难使用并影响了餐厅老板的生意。那么他们不会满意并会拒绝该产品。

让我们看另一个利益相关者的例子。你为一家美发沙龙制作了一个在线预订系统。该系统由沙龙老板请求并资助。该系统允许沙龙的顾客致电或到访，让接待员在系统上为他们预订预约。顾客也可以选择创建一个在线账户，并通过沙龙的网站自己预订预约。发型师也可以要求接待员查看他们在特定日期是否有预约。

那么，如果有的话，谁是系统的主要用户？A，沙龙老板。B，接待员，C。顾客和/或D，发型师。由于沙龙老板请求并资助了该系统。他们是客户和三级用户。发型师通过中介（接待员）使用系统，所以他们是次要用户。当顾客致电沙龙并让接待员为他们预订预约时，顾客也可以被视为次要用户。接待员和顾客都直接访问系统。

如果他们定期使用它，那么他们都是主要用户，因此。答案B和C是正确答案。

📝 总结

本节课中我们一起学习了在软件开发中考虑用户的重要性。我们定义了最终用户、利益相关者和用户界面等核心概念，并将利益相关者细分为主要用户、次要用户和三级用户。通过餐厅点餐系统和美发沙龙预订系统的例子，我们分析了不同用户类型如何与产品互动，以及他们的需求如何影响产品的成败。记住，一个成功的产品必须平衡并满足所有利益相关者的需求。

014：用户考虑因素 👥

在本节中，我们将学习如何根据目标用户的需求来定制产品。我们将探讨识别主要用户群体的重要性，并理解在开发过程中考虑用户能力与限制的必要性。

---

上一节我们明确了产品的目标用户。本节中，我们来看看如何根据他们的需求来调整产品。

识别产品的主要受众至关重要。这有助于我们根据用户的导航和功能需求来定制产品设计。以儿童菜单为例，我们的主要用户是儿童。有许多方法可以让产品迎合儿童，例如使用鲜艳的色彩、图像和声音。

研究最终用户如何与技术产品互动的学科被称为人机交互。人机交互本身可以是一门课程。我们将介绍一些基础知识，但如果你对此感兴趣，建议你进一步研究。这是一个非常引人入胜的计算领域，我对此充满热情。关于这个主题有大量可用资源，你可以在我们的课程资源中找到一些。

为最终用户开发产品可能令人沮丧，原因有很多。用户往往难以表达他们的需求，但他们通常会告诉你他们不喜欢什么。这通常源于他们不知道软件可以实现什么。开发人员必须创造性地思考，以开发出新颖、引人入胜的产品。

用户可能会受到已知事物的影响。用户通常更愿意使用他们知道如何操作的劣质产品，而不是对他们来说是新的、更优质的产品。这让我思考，我们在这里试图做什么？为什么我们要为那些只会使用旧产品的客户开发新产品？这就是为什么开发用户友好、直观的用户界面如此重要。它鼓励用户走出他们的舒适区。但这只有在产品易于学习和使用的情况下才有效。

开发人员常常在创建直观、用户友好的产品方面遇到困难。你可能已经注意到的一件事是，工程师、科学家和程序员并不能代表主流人群。所以，欢迎来到“非正常”的世界。我想说的是，开发人员的思维方式与普通最终用户不同。对开发人员来说完全合理的事情，对外行人来说可能毫无意义。开发人员可能优先考虑后端技术的进步，因此他们有时很难为更广泛的人群设计出直观的产品。

作为软件产品经理，理解用户的思维方式非常重要。有建议认为，为初学者和专家这两个极端设计产品是理想的。如果你这样做，中间部分往往会自行解决。当你与开发人员一起设计产品或测试产品时，请牢记最终用户：他们能够理解这个产品是如何工作的吗？

---

以下是关于为特定用户群体设计的思考练习：

一个代表患有糖尿病的老年人的协会联系了你的团队，希望开发一款移动应用程序，让老年人能够跟踪他们的血糖水平。该协会的代表明确指出，用户年龄将在65岁以上。此外，应用程序必须足够简单，无需协助即可使用。

你可以为产品添加哪些功能以更好地适应其最终用户？
A. 语音命令
B. 多层菜单
C. 大号文本
D. 音频提醒

---

为老年人开发产品可能很困难。他们的感官可能不太好，这可能会限制他们能做的事情。由于他们不是在技术时代长大的，他们的技术技能往往不太先进；因此，一个拥有多层菜单的产品可能让他们难以操作。

添加语音命令和大号文本等功能是适应老年最终用户的好方法。语音命令可以帮助那些无法在小键盘上打字的人，而大号文本则更容易阅读。为他们设置提醒将是一个很棒的功能。但是，你可能希望通过多种模式发送通知，而不仅仅是音频。也许可以让手机发出声音、在屏幕上显示弹出窗口并振动。这会吸引大多数用户的注意力。因此，最佳答案是A和C。

---

现在，让我们讨论更多关于人类局限性的内容。

---

本节课中，我们一起学习了如何根据主要用户群体的需求来定制产品设计。我们探讨了人机交互的基本概念，理解了开发人员与普通用户在思维上的差异，并通过一个具体案例分析了如何为老年人设计易用的应用程序功能。记住，始终将最终用户放在心上，是创造成功产品的关键。

015：客户需求与软件需求

第3.2.2b节 用户考虑因素 👤

在本节中，我们将探讨人类的各种局限性，并了解这些局限性如何影响用户与软件产品的交互。理解这些限制对于设计出包容性强、用户体验良好的产品至关重要。

人类存在许多局限性。我们阅读的速度、奔跑的距离或玩电子游戏的时长都是有限的。许多人类特征会限制用户使用产品的能力。在设计软件时，考虑这些局限性非常重要。优秀的软件产品会适应其目标用户群体。

以下是一些人类局限性的例子：感知局限、生理局限、认知局限和文化局限。

感知局限 👁️

上一节我们介绍了人类局限性的几个大类，本节中我们首先来看看感知局限。我们五种感官的限制影响了我们感知周围环境的能力。因此，感知局限是指那些受我们感官限制的局限性。感知局限有时也被称为感官局限。许多感知局限会影响人们与技术交互的方式。

以下是感知局限的一些常见例子：

• 色盲：大约4.5%的人口有色盲问题。约8%的男性是色盲，而女性中只有0.5%。色盲人士难以区分某些颜色，因此彩色图像在他们看来可能不同。从开发角度，应对色盲的最佳方法是增加产品的对比度。使用浅色背景配深色文字（或反之），不仅能适应色盲，还能适应大多数视觉局限。你也可以通过模拟不同形式的色盲来测试配色方案是否可接受。许多UI库和图形设计工具支持此功能。
• 其他感官局限：我们可以开设一整门课程来讲解如何为感知局限进行设计。例子包括使用视觉提示或振动来适应听觉局限。

生理局限 🏃

现在让我们谈谈生理局限。这指的是任何影响用户与产品进行物理交互的因素。

以下是生理局限的一些例子：

• 儿童与成人差异：专为儿童设计的产品应考虑他们较低的手部灵活性、较矮的身高和较小的手掌。他们需要大按钮和能够触及并抓握的控件。
• 左利手与右利手：通过提供左手选项，可以使产品对用户更友好。许多界面设计得便于右利手人士使用，将大部分按钮和菜单放在右侧，便于右手拇指点击。你可以设计一个选项，将按钮和菜单放在屏幕左侧，从而使产品易于左利手用户使用。

认知局限 🧠

接下来，我们讨论认知局限。认知局限通常基于记忆限制。

以下是认知局限的一些关键点：

• 识别与回忆：识别某物通常比从记忆中回忆更容易。因此，用户界面应具有可见的、熟悉的或具有提示性的元素以促进识别。
• 短期记忆容量：哈佛心理学家乔治·A·米勒提出了关于“神奇数字七”的著名概念。他认为普通人的短期记忆容量足以容纳7±2个项目。基本上，这个概念告诉我们，人类的工作记忆一次可以容纳5到9个项目。在有干扰的情况下，情况会更糟。在开发过程中应牢记此限制。例如，你不希望最终用户在你的产品中从一个屏幕到下一个屏幕时，需要在记忆中携带一堆任意项目。

文化局限 🌍

最后，我们来谈谈文化局限。这些本身往往不是局限，而更像是文化差异。

以下是文化差异的一些例子：

• 颜色含义：例如，考虑颜色在不同文化中的含义。在西方文化中，白色用于婚礼，代表和平。然而，在许多其他文化中，白色代表死亡和哀悼。同样，粉色在许多文化中被视为女性化的颜色，但并非所有文化都如此。
• 设计元素：除了颜色，设计的许多方面都可能因文化而异。例如语言翻译、符号和图标、布局和多媒体都可能因文化而不同。
• 交互符号：另一个与软件开发相关的文化差异例子是复选框中使用“X”。想想选举选票，你在候选人名字旁边用“X”标记你的选择。我了解到在日本，他们使用一个称为“丸印”的圆圈来表示选择。他们用“X”标记代表拒绝。因此，“X”可能具有非常模糊的含义。因此，现代用户界面现在在复选框中使用对勾标记来表示选择。

总结

本节课中，我们一起学习了影响软件设计的四类主要用户考虑因素：感知局限、生理局限、认知局限和文化局限。理解这些因素有助于我们设计出更包容、更易用、更能满足全球多样化用户需求的软件产品。记住，优秀的设计始于对用户的深刻理解。

016：让客户参与

在本节课程中，我们将学习如何有效地与客户互动以获取需求。我们将探讨如何开启对话、应该提出哪些问题、应该避免哪些问题，以及在互动中需要牢记的关键事项。通过本节学习，你将能够自信地与客户沟通，并有效地引导出软件需求。

在本专项课程中，我们已经多次强调了客户沟通的重要性。现在，是时候具体谈谈如何与客户对话了。你应该说什么？从哪里开始？

初次发起客户互动确实可能令人望而生畏，但本课程将提供一些好的提问范例、需要避免的问题，以及与客户互动时的注意事项。学完本节后，你将能够自信地与客户交谈，并有效地引导出需求。

与客户协作，而非单纯收集

想象一下，你和你的开发团队第一次与客户会面。你需要将他们脑海中的想法转化为一个软件产品。需要牢记的一个重要点是，你是在那里与他们一起探索各种可能性，而不是简单地收集他们的想法。客户互动应该是互动的。

这不像在餐厅，你是服务员，只是记下订单并交付他们点的东西。这更像是邀请客户进入厨房，介绍他们认识厨师，并让他们看看食材。然后，你、厨师和客户一起讨论可以用现有食材制作的所有美味菜肴。作为一个团队，你们为客户创造出一道完美的新颖餐点。

需求引导是一个持续的过程

现在，需求引导并非仅在开发前进行一次的活动。正如我们在本专项课程中多次提到的，你需要经常重新审视需求。你不可能第一次就获取所有正确的需求。

凭空创造一个想法是很困难的。一旦你有了可以向客户展示的模型和原型，客户就更容易说出他们喜欢什么、想要什么以及讨厌什么。为了获得正确的需求，从而开发出正确的产品，你必须频繁地进行需求引导。

有效管理需求

既然你会经常重新审视需求，我建议你为需求编号，使用一些唯一的标识符。这将使所有参与者在整个开发过程中更容易引用它们。此外，需求不一定必须直接来自客户。

有多种方法可以引导出额外的需求。例如，你可以采访最终用户，了解他们的工作方式、需求和喜好。你可以与焦点小组进行可行性研究。

你可以观察最终用户，看他们如何使用产品。如果最终用户使用过之前的产品，你可以查阅该产品的用户手册，了解他们习惯的操作方式。这些引导技术有助于为最终用户交付更好的产品。

建立术语表以提升清晰度

另一个可以简化客户互动的工具是为产品建立一个术语表。这个术语表呈现了产品特有的信息。一旦一个术语被纳入术语表，每个人都应该使用它。这提高了清晰度，因为不会对同一事物使用不同的术语。

开发团队为一个元素起一个名字，而客户却叫它别的名字，这种情况很常见。这会导致混淆，难以确定大家谈论的是否是同一件事。

案例分析：凯尔的第一场客户会议

凯尔是一名新的软件产品经理，他迎来了职业生涯中的第一次客户会议。他内心非常紧张，但还是自信地走进房间，与客户握手，并介绍了自己和开发团队。他询问客户产品的目标，并获得了一些有见地的回答。

然后他问客户希望在产品中看到什么。客户开始列出她希望看到的功能。凯尔记录下了答案。会议结束后，凯尔与开发团队会面，将请求的功能列表转化为需求待办列表。他将待办列表通过电子邮件发送给客户，并请她对需求进行优先级排序。

开发团队收到优先级排序后的待办列表后，便开始了开发工作。两周后，凯尔和开发团队与客户会面，展示了一个原型。这个原型正是客户所要求的，但使用起来相当困难。开发团队对他们的工作成果也不太满意。

是什么导致了这种情况？
A. 询问客户产品的目标。
B. 仅基于客户建议来确定需求。
C. 让客户对需求进行优先级排序。
D. 两周后向客户提供原型。

当你与客户会面以引导需求时，这应该是所有参与者之间的对话。你需要了解产品的愿景、目标或目的，凯尔做到了这一点。然后，你需要开发团队和客户讨论可能的方法。让他们共同达成一个既能满足客户，又能保证产品质量的解决方案。

让客户对需求进行优先级排序并向他们提供原型，是满足客户需求的绝佳方式。尽管如此，需求不应仅仅基于客户的初始请求；因此，B是正确答案。

客户互动中的关键考量

客户互动将是你作为软件产品经理工作的重要组成部分。在互动时，有几个注意事项需要牢记。现在让我们来回顾其中一些。

首先，确保与客户找到正确的平衡。你不想表现得过于被动。就像我之前说的，你不是记下订单的服务员。你需要提出新的想法和观点。

你也不想表现得过于激进。你需要避免告诉客户他们想要什么，或者为了细节和决定而盘问他们。你需要找到一个平衡点，在这个点上你既自信又乐于助人。

找到这种平衡的一个好方法是提出好的问题。通过你的问题，你希望引导出不仅仅是“是”或“否”的回答。提出好的开放式问题。专注于产品的目标和目的，并尽可能保持与技术无关。

“为什么”对你来说将是一个非常重要的问题。不断问你的客户“为什么？”他们为什么想要那样？他们为什么需要这个产品？为什么会有人使用它？西蒙·斯涅克有一个关于“为什么”这个问题的力量的精彩TED演讲，我们已在课程资源中分享给你，你一定要去看看。

需要避免的问题

除了“是/否”问题，还有一些问题你应该避免。例如，尽量避免问“你想要什么？”或“你的需求是什么？”。这些问题有点过于开放。它们会导致随机、结构松散但重要的想法。

想想庭审律师与证人互动的方式。你可能在电视或电影中见过。律师只问封闭式的“是/否”问题。他们不希望证人详细阐述，因为这可能会破坏他们的论点。作为软件产品经理，你需要以与庭审律师相反的方式行事。尝试构建对话，以允许更有条理的想法，这将使将想法转化为需求变得更容易。

避免过早导向解决方案

确保你没有将客户导向一个过早构想的解决方案。如果客户在没有探索其他想法的情况下过早同意某个解决方案，他们可能最终对结果不太满意。你需要探索替代方案。

客户可能会试图导向某个特定的解决方案。如果你曾经从事过零售工作，你可能熟悉“顾客永远是对的”这句话。但在软件开发中，情况并非总是如此。有时客户是错的，有时客户不知道什么是可能的，或者他们可能会提出一些让最终用户更难学习产品的想法。

重要的是，你要尊重他们的观点，并理解他们想法背后的理由。再次强调，问“为什么”。尝试提出可能的替代方案，并礼貌地指出他们的方法可能行不通的原因。归根结底，客户做出关键的需求层面决策。如果你把需求完全交给开发团队决定，那将允许他们构建任何他们想要的东西，而不是客户需要的东西。

实践场景：宠物用品网站

你和你的开发团队正在为一家在线销售宠物用品的公司创建一个在线购物网站。客户对他们的要求非常具体。她想要绿色背景配红色文字。她想要动物图片做成动画，看起来像在跳舞。她希望所有产品都显示在首页，并按价格从高到低排序。

你的开发团队对这个设计有些不安，他们试图说服她放弃这些功能。一位开发人员解释说，绿色背景上的红色文字很难阅读，色盲用户可能完全无法阅读。她最喜欢的颜色是红色和绿色，所以她犹豫是否改变主意，但最终她同意使用绿色背景配蓝色文字。不理想，但更好。

然后，开发团队试图说服她放弃按价格从高到低排序。他们认为跳舞的动物无害，是最不需要担心的问题。他们向客户解释说，用户应该能够按动物类型或产品类型（如食物、玩具等）进行排序。他们解释说，这将使网站对用户来说更容易使用，并且主页不会那么拥挤。她拒绝更改排序系统。

在这种情况下，开发团队下一步应该采取什么方法？

A. 按照她的所有要求创建网站，交付她想要的产品。
B. 提供实验数据，以确保更好的排序系统可以增加销售额。
C. 让动物的舞蹈动作不恰当，以此反对她。
D. 创建一个视觉吸引人且具有出色排序功能的网站。

在这种情况下，团队需要有勇气。他们的下一步方法应该是进行实验或找到一些数据来支持开发团队的立场。你可以利用这些数据来做出数据驱动的决策。再次强调，你需要思考产品被需要的“原因”。如果“原因”是为了增加销售额或满足客户，那么产品就应该反映这一点。一个理性的客户会被正确的数据和经济论证所说服，因此B是正确答案。

然而，如果你的客户完全不讲道理，并且没有任何方法能改变他们的想法，那么最好只是交付他们想要的产品。

本节总结

在本节课程中，我们一起学习了如何有效地让客户参与需求引导过程。我们了解到，与客户的互动应该是协作式的对话，而非单向的信息收集。我们探讨了提出开放式问题（尤其是“为什么”）的重要性，以及需要避免的提问方式。我们还学习了通过建立术语表来确保沟通清晰，并认识到需求引导是一个需要在整个开发周期中反复进行的持续活动。最后，我们讨论了如何在尊重客户意见的同时，以数据和理性论证为基础，引导客户做出更优的产品决策。掌握这些技巧，将帮助你更自信、更专业地与客户合作，共同打造成功的软件产品。

017：让客户参与

概述

在本节中，我们将学习如何通过让客户参与需求澄清过程，将模糊的需求转化为清晰、具体的功能描述。我们将通过一个餐厅点餐系统的例子，演示如何提出直接的问题来理解客户的真实意图。

从模糊需求到具体细节

上一节我们讨论了需求的不同类型，本节中我们来看看如何通过与客户互动来细化这些需求。客户最初提出的需求往往比较模糊，需要产品经理通过提问来挖掘具体细节。

让我们回顾本模块开始时提到的餐厅点餐系统例子。你的客户提出的一个功能是：顾客可以使用系统下单。这个描述非常模糊，因为实现这个需求的方式有很多种。这是一个提出更直接问题的好机会，以弄清楚Jamie究竟设想这个功能如何工作。

以下是你可以提出的一些问题：

• 顾客如何选择菜品？
• 一桌有多位顾客时，系统应如何处理？
• 每桌的点餐是否有最低或最高限额？
• 顾客如何将订单发送到厨房？

客户的具体设想

通过提问，我们可以获得客户清晰、具体的设想。例如，客户Jamie可能会这样回应：

“我为之前描述得如此模糊而道歉。我设想的是，每张餐桌上应有一台或多台平板电脑供顾客点餐。顾客可以浏览食物图片；如果他们想了解某道菜的更多信息，可以点击它；如果他们想点这道菜，就点击‘下单’按钮。这会将他们带到另一个页面，在那里他们可以指定对餐点的修改以及可能有的任何饮食限制，然后再将订单发送到厨房。”

“当一桌有多位顾客时，我希望它能像在线购物系统的购物车一样工作。我希望当平板电脑在餐桌上传递时，每位顾客都可以选择自己的订单。或者，也可以由一个人输入所有人的订单，这都没关系。同一账单上的所有订单必须从一台平板电脑提交。额外的平板电脑是供人们浏览菜单或为不同账单下单用的。”

“点餐不应有最低或最高限额。当所有订单都已输入并定制完成后，顾客可以通过点击‘提交订单’将订单发送到厨房。”

客户持续参与的重要性

在听到对直接问题的回应后，你就能更清楚地理解当客户说“顾客可以使用点餐系统下单”时的实际含义。让你的客户参与进来并考虑最终用户，是你工作中非常重要的一部分。

即使在需求获取之后，你的客户也应该在整个开发过程中持续参与。他们应该在那里回答问题，就设计选择提供建议，并对可工作的版本给出反馈。

我们为你提供了一份资源，列出了许多你可以向客户提出的好问题。如果你在客户会议中遇到困难，可以带上这份资料并参考它。你可以在课程资源中找到它。

总结

本节课中，我们一起学习了如何通过主动提问让客户参与需求澄清过程。我们看到了一个将模糊的“顾客可以下单”需求，通过具体问题转化为关于交互流程、多人场景和订单提交机制等清晰描述的完整例子。记住，让客户持续参与是确保软件产品符合预期、减少返工的关键。现在你已经获取了需求，接下来需要学习如何表示它们，这将是本模块剩余部分的内容。

018：用例

在本节课中，我们将要学习一个重要的需求分析工具——用例。用例是一种描述产品功能所支持任务的有效方式，它能帮助我们识别、澄清和组织任务的细节。

什么是用例？

用例是由伊瓦尔·雅各布森在1986年提出的概念。自此，它成为一种描述产品功能所支持任务的流行方法。用例是一种识别、澄清和组织任务细节的方式。

用例由用户与系统之间一系列可能的顺序交互组成。它发生在特定的环境中，旨在实现一个特定的目标。这些描述可能听起来有些抽象，但通过实际例子会更容易理解。

用例描述的构成要素

让我们深入了解一个任务用例描述的具体构成要素。一个典型的用例由以下几部分组成：用例名称、参与者、目标、触发器、前置与后置条件、基本流程、异常情况和质量要求。

以下是每个要素的详细说明：

• 名称：首先，你需要为用例起一个名字。这个名字应该能描述任务，并且简单、简短。
• 参与者：接下来，需要识别参与者。参与者应该是角色，角色是个人承担的职责。例如：餐厅顾客、厨房厨师或服务员。参与者的名称应描述他们使用产品做什么，而不是参与者的真实姓名，我们需要的是通用情况。
• 目标：如前所述，用例的目的是实现一个特定目标。因此，你需要在用例中明确这个目标。
• 触发器：你还需要识别触发器。触发器是促使用例开始的事件。这可能是类似按下按钮这样的动作。
• 前置与后置条件：接下来，需要识别前置条件和后置条件。前置条件是在该用例发生前必须满足的条件。后置条件是在用例完成后满足的条件。
• 基本流程：基本流程是用例的重要组成部分，它是对用例中所有发生步骤的逐步说明。基本流程应代表一个“晴天场景”。“晴天场景”是最佳情况，或描述一切正常运行的场景。如有必要，任何其他场景可以作为替代流程来概述。
• 异常情况：你还需要概述任何异常情况。异常情况突出了该用例无法工作的任何情形。对于异常，你需要识别在基本流程中异常会发生的步骤，然后提供解决问题的替代步骤。
• 质量要求：最后，质量要求是你希望满足的任何质量规范。这些可能是非功能性需求，例如在特定时间内完成场景，或使用特定数量的内存。

总的来说，用例描述从相关参与者的角度概述了任务。它不涉及产品内部幕后的运作。同时，描述应该是技术无关的，因此不依赖于特定的用户界面平台。

用例示例分析

杰克正在使用一个即时通讯应用程序。他想给他的朋友莎莉发一条消息，告诉她他参加她的派对要迟到了。他打开应用程序，搜索她的名字。他点击他们的对话，然后输入消息：“嘿，莎莉，我要迟到了。待会儿见。”然后他按下发送键。莎莉看到了消息并回复了杰克。

如果你要为这个场景编写一个用例，你会列出哪些参与者？A. 消息发送者。B. 消息接收者。C. 莎莉 和/或 D. 杰克。

当你定义参与者时，你希望他们是通用情况，因此你不应该使用真实姓名。尽管莎莉和杰克是这个特定场景的最终用户，但并非每次用例发生时他们都是最终用户。我们需要更通用的描述。消息发送者和消息接收者是很好的参与者名称，因为两个用户都参与了这个场景。这意味着答案A和B是正确的。

应用：餐厅应用用例

既然你知道了用例描述的结构，让我们进一步将其应用到我们的餐厅应用示例中。一个好的起点是创建一个用例图。这是产品支持的所有任务的高级可视化表示。它识别了参与者以及他们参与的用例。

在餐厅场景中，我们有顾客、儿童顾客和厨房员工。他们各自的用例在图中与他们相连。边界内是产品可以支持的所有用例。

让我们选取其中一个任务并将其转化为一个用例。我们将查看允许顾客查看账单的需求。假设这是第一个用例，对应于产品待办列表中的需求，因此我们将给这个用例分配ID号1。

• 名称：我们将这个用例称为“查看账单”。
• 参与者：这个故事中唯一的参与者是最终用户，在我们的场景中，我们称他们为“顾客”。
• 目标：这个用例的目标是查看他们订单的账单。
• 触发器：如前所述，触发器是促使这个用例发生的事件。在这个场景中，顾客在应用程序中请求查看他们的账单。
• 前置条件：这个动作发生的前置条件包括：菜单上有菜单项、用户选择了一道菜、用户下了订单。
• 后置条件：这个动作的后置条件是顾客可以查看账单并支付账单。
• 基本流程：这个用例的基本流程是：1. 用户从应用程序请求查看账单。2. 用户查看账单。
• 替代流程：这个动作的替代流程是用户让服务员打印并带来账单。这不是“晴天场景”，因为它需要更多工作，但它完成了相同的任务。
• 异常情况：可能发生的异常情况是没有点任何菜。因此，用例的目标没有实现。在这种情况下，应该显示一条错误消息。我们基本流程的第2步是“顾客查看账单”。如果他们的订单没有菜，那么我们希望显示一条错误消息。我们会在用例中这样写：步骤2a：如果未点任何菜，则显示错误消息。
• 质量要求：一个质量要求可能是账单加载时间少于10秒。通常，质量要求是非功能性需求。它们有助于在整个开发过程中设定质量标准。

另一个练习

你正在使用一个允许用户创建和使用群组消息线程的软件产品。群聊参与者可以被添加到群聊中，这些参与者都可以看到在该线程中发送的消息。以下哪一项会是“向群聊发送消息”这个用例的触发器？

A. 参与者有一条想要发送给群组的消息。B. 参与者输入消息。C. 参与者打开群聊。或 D. 参与者点击发送按钮。

触发器是促使用例发生的事件。在这个场景中，我们的用例是“发送消息”。要触发这个事件，参与者会有一条想要发送给群组的消息。这促使参与者打开群聊、输入消息并按下发送键。因此，A是正确答案。答案B、C和D都是会发生的基本流程步骤。

总结

本节课中我们一起学习了用例。用例是你在建立需求时可以使用的绝佳工具。它们有助于组织和详细说明任务及其步骤，并指导开发。用例图可以帮助你获得整个产品的整体视图，包括它支持的所有任务和角色。

接下来，我们将看一些设计技术，这些技术可以帮助你组织和可视化产品的需求。

019：线框图 🎨

在本节中，我们将学习线框图这一在软件开发中非常有用的技术。我们将了解它的定义、作用、创建原则以及如何在实际项目中应用它。

线框图是产品的基本视觉表示。线框图的另一个名称是模型。

可以把它想象成房屋的蓝图。承包商在建造房屋之前需要绘制房屋的黑白图像。这能让所有相关人员对将要建造的东西达成共识。

线框图不仅是开发团队可视化需求的好工具，也是向客户展示想法的宝贵技术。在开发团队讨论需求后，他们可以快速制作一个线框图模型给客户看。这样，客户就能在流程的早期看到产品的雏形。这使他们能够提出修改意见，并通常能确保每个人对产品有共同的愿景。

你需要保持线框图非常简单。这不是界面的详细演示，而是产品的演示。不应在线框图中放入将在界面中实现的华丽颜色和图像。线框图侧重于要支持的基本功能和最终用户任务。它们可以帮助你思考按钮、文本字段和图像的放置位置。它们从上到下的布局应遵循用户执行每个任务的流程。基于这些想法，在项目的设计和实施阶段后期，才会完全模拟或完全实现用户界面设计。

再次以房屋蓝图为例。你无法知道墙壁的颜色，也无法知道照明或管道装置的外观。你只能了解轮廓的基本概念以及装置将放置的位置，但你无法了解房屋的完整外观。

我们使用线框图来创建本课程。我们会确定演示者站立的位置以及图像和文本字段出现的位置。以下是本课程的一个线框图。如你所见，我们的线框图与实际课程看起来非常不同。我们没有包含图像的具体样子，只是简单地指出了我们希望它放置的位置并描述了它将代表什么。演示者的图像也完全不像我，但这没关系。你能明白那是正在说话的人。我们会将这些线框图发送给我们的制作团队，以便他们了解我们对课程的大致构想。然后他们进行制作，创造出你所看到的精美课程。

让我们看一个线框图示例。这是一个提供作者传记的网站的线框图。

你认为带有X的白色方框代表什么？A，一个按钮；B，一个标题；C，文本；或D，一个图像。在线框图中，内部带有X的方框代表图像；因此，D是正确答案。你无需指定有关图像的任何细节。在线框图中，这种表示形式只是作为图像放置位置的占位符。我们将在本课后面介绍如何表示按钮、标题和文本。

因此，如你所见，线框图可以用于许多事情。你可以使用它们来设计将要开发的内容、向客户演示以及与团队沟通。

线框图的另一个常见用途是让客户与你沟通。客户通常对产品的功能和外观有一个想法。有时，客户通过绘制线框图来表达他们的想法会更容易。我以前就有客户这样做过，这使得从他们的线框图中提取需求变得容易。如果你的客户难以表达他们真正想要的东西，你可以考虑这种方法。

在上一个模块中，布拉德利谈到了需求与设计之间的细微界限。在通过线图获取需求时，请确保不要越过这条线。进行一些设计是可以的，但你需要小心，不要过早地开发解决方案。线框图应该引发关于问题是什么以及最终用户需要执行哪些任务的讨论。

有许多不同的工具可用于开发线框图。你可以在纸上绘制它们并进行数字扫描，也可以使用计算机上的任何绘图工具。无论哪种方式，你都应该允许纸质和数字版本，以便于沟通和讨论。我们使用谷歌文档来绘制线框图。像PowerPoint这样的演示工具也常用于绘制线框图。还有许多专门用于绘制线框图的网络应用程序，我们将在课程资源中发布其中一些。

让我们回到餐厅的例子。以下是主菜页面部分内容可能的样子。在线框图中，图像通常用内部带有X的正方形表示。文本通常用阴影框模拟。你可以在按钮和标题上添加文本，以便与客户有更多讨论内容。使用阴影框表示通用文本。按钮通常用正方形模拟。

接下来，我们将看一种类似的设计技术——故事板。

在本节中，我们一起学习了线框图。我们了解到线框图是产品的基本视觉蓝图，用于在开发早期与团队和客户沟通需求、功能和布局，避免过早陷入细节设计。它使用简单的占位符（如带X的框代表图像）来聚焦于核心任务流，是确保项目各方对产品愿景保持一致的重要工具。

020：分镜头剧本 📖🎬

在本节课中，我们将要学习分镜头剧本这一工具，了解它如何帮助我们将用户需求与软件功能可视化，从而更好地规划产品开发。

---

如果你曾听说过“分镜头剧本”，那很可能是在电影行业的语境中。这是因为这项实践起源于电影行业。想一想制作一部电影所涉及的所有角色。分镜头剧本有助于让每个人都围绕导演的愿景达成一致。

分镜头剧本是对交互过程的顺序视觉化呈现。连环漫画就是一种分镜头剧本，它按顺序视觉化地讲述一个故事。在电影行业，分镜头剧本用于规划画面中的元素位置、镜头如何移动，并提供场景的氛围感。他们会在投入服装、道具、摄影、特效和剪辑之前完成这项工作。

在软件开发中，分镜头剧本可以通过几种不同的方式使用。无论如何使用，它们都按顺序讲述了最终用户如何与产品交互的故事。

---

电影风格的分镜头剧本 🎥

第一种使用方式类似于电影分镜头剧本。这种类型的分镜头剧本梳理的是高层次的用户体验。

以下是创建此类分镜头剧本的步骤：

首先，你需要识别涉及的角色以及他们将如何使用产品。这里指的不是电影演员。如果你还记得关于用例的课程，你会记得我们将情境中的主动用户称为“参与者”。如果产品有多个功能，那么你需要为每个参与者在每种情境下使用产品的情况创建一个新的序列。

让我们用一个餐厅应用的例子来看看。

史密斯一家决定去Brampton Pasta餐厅。他们坐在餐桌旁，使用桌上的平板电脑浏览菜单。他们在应用上浏览菜品并下单。厨房的厨师收到了他们的订单。食物准备好后被送到餐桌，史密斯一家享用了一顿美味的晚餐。用餐结束后，母亲在应用上查看并支付了账单。

这种类型的分镜头剧本涵盖了产品被使用的各种情境。通过观察每个用户何时以及如何使用产品，你的开发团队可以创建或改进功能。正如之前所说，考虑用户是开发的重要组成部分。

你还可以通过为每个用户赋予一个“用户画像”来扩展分镜头剧本，增加更多关于用户的背景故事。例如，在我们刚刚看到的史密斯一家的场景中，你可以详细说明他们的年龄、喜欢的菜肴、过敏史、文化背景和/或收入水平。你可以细化这个场景，展示分镜头剧本和需求如何扩展以解决某些问题。

如果产品有多个功能，你需要为每个功能制作一个分镜头剧本。例如，这个应用有一个儿童菜单，就需要一个新的分镜头剧本。你还需要用另一个分镜头剧本来涵盖账单支付功能。

这种电影风格的分镜头剧本对于让整个开发团队达成共识也很有用。它有助于让大家牢记产品的愿景。分镜头剧本的另一个用途是用于营销或演示目的，你可以轻松地向他人展示产品的预期使用方式和时机。

---

示例分析

你正在开发一个道路救援应用。该应用有一个检查路况的功能。你的开发团队为你提供了这个功能的电影风格分镜头剧本。

弗兰克即将开始一段公路旅行，他望向窗外，看到正在下雪。他想知道道路是否因此被雪覆盖且湿滑。弗兰克打开他的道路救援应用，检查他路线的路况。应用告诉他最短路线有危险，他应该选择替代路线。弗兰克采纳了建议的路线，安全抵达目的地。

以下哪些（如果有的话）会是与此分镜头剧本相关的需求？
A. 作为司机，我希望输入出发地和目的地，让应用计算路线。
B. 作为司机，我希望应用能追踪我的行程，如果我没有到达目的地，就通知紧急联系人。
C. 作为司机，我希望危险路线用红色高亮显示。
D. 作为司机，我希望建议更安全的路线。
E. 作为司机，如果我的车辆在高速公路上静止45分钟，我希望自动向我的位置派遣道路救援。

从这个分镜头剧本中，我们可以看到路线是根据提供的出发地和目的地计算的。高风险路线用红色高亮显示，并且建议了更安全的路线。因此，A、C和D是正确答案。B和E可能是应用的功能，但并未在此特定分镜头剧本中描绘。

---

软件设计风格的分镜头剧本 💻

上一节我们介绍了用于高层次用户体验规划的电影风格分镜头剧本。本节中，我们来看看另一种更深入软件设计的分镜头剧本。

这种分镜头剧本的目的是更详细地展示用户将如何与产品的用户界面交互。这种类型的分镜头剧本展示了用户与产品之间所有交互的顺序。它是线框图和用例基本流程的结合。它展示了产品的每个状态，以及用户如何到达该状态。在大多数产品中，每个状态将由用户界面中的一个独立线框图或页面来描绘。每个状态之间的用户转换点用带箭头的线表示。

让我们继续使用餐厅的例子，看看这种类型的分镜头剧本是什么样子。

顾客看到的第一个屏幕是主页。从该页面，顾客可以点击一道菜进入菜品详情页，或点击儿童菜单按钮进入儿童菜单页。在菜品详情页，顾客可以点击下单该菜品，然后进入菜品定制页面。菜品定制完成后，顾客可以点击下单并返回主页。

这种类型的分镜头剧本是在开发前可视化需求的好方法。它提供了一个机会来讨论支持用户任务可能需要的额外或缺失的元素。用户应该能直观地知道他们在产品中的位置以及下一步该做什么。分镜头剧本展示了线框图。在分镜头剧本中，只要有箭头存在，线框图中就需要一个用户界面元素（如按钮）来进入下一个线框图。技术作者也可以使用分镜头剧本来指导和构建培训材料。

---

示例分析

你拿到一个包含10个不同页面的分镜头剧本。从主页出发，有四个箭头，每个箭头指向一个不同的页面。有两个页面有箭头指向主页。分镜头剧本上总共有18个箭头。从主页可以直接访问多少个页面？
A. 10个页面
B. 4个页面
C. 2个页面
D. 18个页面

在分镜头剧本中，每个屏幕代表一个页面。从特定页面可以直接访问的页面，有从该页面出发并指向可访问页面的箭头。因此，既然有四个箭头从主页出发并指向四个不同的页面，那就意味着有四个页面可以直接从主页访问，所以正确答案是B。

---

总结 📝

本节课中，我们一起学习了两种类型的分镜头剧本。

两种类型的分镜头剧本都很有价值，因为它们有助于形成需求，并且都关注用户做什么以及产品中需要什么。你会发现产品的视觉化呈现，在与客户和开发人员讨论时非常有帮助。用分镜头剧本演示功能将帮助你引出更多需求并完善现有需求。

电影风格的分镜头剧本擅长在高层面上模拟用户与产品的交互。它也是让整个团队在产品目标上达成共识的好方法。第二种类型的分镜头剧本是增强版的线框图，用于更详细地确定与产品的交互。这种类型更多地被开发团队用来设计需求。它是确保整个开发团队了解产品功能和流程的有用技术。

在下一个模块中，Bradley将带你了解一些用于表达需求的敏捷实践。

软件产品管理课程3：客户需求与软件需求：3.3.1 敏捷需求

概述

在本节中，我们将探讨如何在敏捷软件开发框架下理解和表达客户需求。我们将回顾敏捷的核心原则，并重点分析其中与需求管理最相关的部分，理解需求在敏捷开发中的动态角色。

---

在上一模块中，摩根详细介绍了用户考量，包括如何让客户和最终用户参与进来以确保构建正确的产品，以及如何通过用例、线框图和故事板来表达这些需求。该模块主要关注如何确定客户需求。在本节中，我将重点介绍如何将这些需求置于敏捷框架内进行表述。

我将展示需求如何融入敏捷软件开发的范畴，介绍多种表达需求的方式，以及如何管理它们。

敏捷原则回顾

在入门课程中，摩根曾讨论过敏捷及其12条核心原则。让我们快速回顾一下摩根介绍的这些原则：

1. 通过早期和持续交付有价值的软件来使客户满意。
2. 频繁地交付可工作的软件。
3. 将可工作的软件作为衡量进度的主要标准。
4. 欢迎需求变更。
5. 关注技术卓越和良好设计。
6. 以可持续的开发节奏开展工作。
7. 专注于简洁性，以最大化未完成的工作量。
8. 围绕有动力的个体构建项目。
9. 关注自组织团队。
10. 业务人员与开发者之间每日协作。
11. 鼓励面对面的交流。
12. 定期反思团队行为并相应调整。

与需求相关的敏捷原则

在12条敏捷原则中，哪些与需求最相关？
A. 欢迎需求变更
B. 鼓励面对面的交流
C. 专注于简洁性
D. 频繁地交付可工作的软件

实际上，以上所有答案都是正确的。它们各自以不同的方式反映了需求。然而，为了讨论需求与敏捷，我想特别指出其中两条。

第一条是“欢迎需求变更”。 这可能显而易见，但至关重要。敏捷基于这样一个理念：软件是动态的、开放式的，无法一次性定义完毕然后基于这个单一定义进行构建。在开发过程中，客户经常会对产品功能产生新的想法。对于那些没有考虑到需求变更必然性的项目来说，这可能是灾难性的。在构思需求时，“欢迎需求变更”这一敏捷原则至关重要。要带着贯彻执行的意图去制定需求，但不要自欺欺人地认为随着产品发展需求不会改变。这只是软件开发的自然规律。

第二条是“鼓励面对面的交流”。 这对于获取正确的需求同样关键。根据敏捷思想，需求应在开放、协作的环境中从客户那里获取。产品的愿景应由客户决定。然后，作为软件产品经理，你的工作是共同解决问题，细化该愿景，以确定项目中哪些需求在范围内。这需要所有人聚在一起，公开讨论产品中希望包含的功能，识别可以或必须完成的事项。这不仅能在当下更有效地确定有价值的内容，也为团队与客户未来的沟通设定了先例。

需求在敏捷中的角色

以下哪项表述了需求在敏捷中的角色？
A. 需求中等重要，定义截止日期更重要。
B. 需求完全不重要，敏捷是编写代码的过程。
C. 需求应预先定义且不改变。
D. 需求很重要，并且应能在整个开发过程中变更。

需求在敏捷中极其重要。它们帮助我们理解客户，确保我们为客户构建正确的产品，同时也帮助我们确保正确地构建产品。因此，正确答案是D。

与客户坐下来讨论那些必然会变化的需求，是Scrum中经常使用的实践。Scrum是一种敏捷方法论，我们在“软件过程与敏捷实践”课程中有详细讲解。

总结

本节课中，我们一起学习了需求是敏捷不可或缺的一部分。同时，敏捷也为需求管理增添了许多质量保证，前提是你在创建需求时遵循其实践。既然我们已经建立了敏捷与需求之间的联系，接下来我们将进入下一课，在那里我将详细介绍表达敏捷需求最常见的形式：用户故事。

022：用户故事 📖

在本节课中，我们将要学习敏捷开发中表达需求的核心技术之一：用户故事。我们将了解用户故事的定义、结构、重要性，并通过实例分析来掌握如何编写高质量的用户故事。

上一节我们介绍了如何将传统需求与敏捷实践相结合。本节中，我们来看看一种具体的敏捷需求表达方式。

什么是用户故事？

用户故事是一种表达需求的简单方式。在之前的课程中，我们学习了用例、线框图和故事板等需求表达技术。用户故事是另一种实现相同目的的方法。

用户故事旨在将系统的所有需求保持为一致的格式。它们易于编写、阅读和评估。

用户故事的结构

用户故事遵循一个非常具体的格式：As a <角色>, I want <功能>, so that <价值>。

• As a <角色>：这部分指明了需求是为哪个利益相关者角色而制定的。例如，可以是“管理员”或“访客用户”。在我们的餐厅菜单应用示例中，利益相关者是顾客和厨房员工。这有助于明确需求旨在支持谁，它指定了需求的“谁”。
• I want <功能>：这部分指明了利益相关者希望使用产品解决的任务或功能。这是需求的核心，通常也是人们想到“需求”时最先想到的部分。它指定了需求的“什么”。
• so that <价值>：这部分指明了最初为何需要这个用户故事。它提供了关于需求所提供的价值或好处的背景，并与产品的目标或愿景保持一致。它指定了需求的“为什么”。

一个完整的用户故事示例如下：

As a child customer, I want to see the kids menu, so that I see what meals and games interest me.

你可以看到它如何作为一个整体结合在一起。

知识测验

假设你正在与客户合作一个手机游戏项目。他们给出了一个需求：“I want to be able to control my character using the arrow keys.”（我希望能够使用方向键控制我的角色。）

如何将这个需求构建成符合用户故事格式？以下是选项：
A. As a gamer, I want to be able to control my character using a directional input method so that I can navigate the game world.
B. I want to be able to control my character using a directional input method.
C. In order to navigate around the world, a character should be able to move using the arrow keys.
D. 不做任何更改，这已经是一个用户故事。

正确答案是 A。一个用户故事应该符合 As a <角色>, I want <功能>, so that <价值> 的格式。请注意，这个用户故事在描述输入设备时更加通用，专注于实际需求而非特定解决方案。

用户故事的优势

现在，将用户故事与一种常见的需求表达方式进行比较。通常，你会看到需求用模糊的语言表达，缺乏足够的描述。例如：“The user should be able to see a kid‘s menu.”（用户应该能够看到儿童菜单。）

了解了用户故事的创建方式后，你是否理解了它们为何如此结构化？它们为需求带来了极大的清晰度，而不会陷入技术细节的泥潭。你可以在一个简洁的小包裹中获得“谁”、“什么”和“为什么”。

拥有简短、简洁的用户故事还有一个额外的好处：你可以轻松地将它们写下来以便跟踪。事实上，用户故事的设计初衷就是足够紧凑，可以写在索引卡或便利贴上。

这样，所有的用户故事都可以以一种非常直观、物理化和信息丰富的方式被展示和组织。通过将故事写在索引卡上，它们可以轻松地按相关主题分组，并在需求不可避免地发生变化时进行重组。

本节课中，我们一起学习了用户故事。我们明确了用户故事是一种遵循 As a <角色>, I want <功能>, so that <价值> 格式的、简洁的需求表达方式。它明确了需求的利益相关者、具体功能和商业价值，使得需求更清晰、易于管理和沟通。掌握编写高质量用户故事的技巧，是进行有效敏捷产品管理的重要基础。

023：用户故事 📖

在本节中，我们将学习如何编写有效的用户故事。用户故事是描述软件需求的一种简洁方式，它从用户角度出发，说明他们希望通过产品完成什么任务。我们将重点介绍优质用户故事的特征，并了解如何避免创建过于庞大或模糊的“史诗级”故事。

---

用户故事本应由您的客户来撰写，因为客户通常最清楚他们希望产品具备什么功能。

然而，软件产品经理最终常常需要负责撰写用户故事。

这并非因为客户对指定产品功能不感兴趣。

通常是由于客户缺乏创建用户故事的经验或培训。

但这并不意味着您不应该请客户创建用户故事。

这意味着您和您的开发团队可能需要帮助他们以用户故事的形式表达需求。

这固然很好，但归根结底，您必须知道如何编写出真正有用的用户故事。

您可以将一个构思不佳的需求套入用户故事的形式。

但这并不会让它突然变成一个好的需求。那么，什么才是好的用户故事呢？

摩根将在下一个模块详细讲解优质需求的构成要素。

因此，这里我只简要介绍优质用户故事的特点。

一个好的用户故事应能清晰地勾勒出产品中一个具体的软件需求。

我们已经明确了这一点，但如何做到呢？业界广泛使用一个由比尔·韦克提出的助记符，可以帮助您记住优质需求的要素。

这个助记符是 INVEST。我将先解释每个字母代表什么，然后再详细说明。

• I 代表 独立。
• N 代表 可协商。
• V 代表 有价值。
• E 代表 可估算。
• S 代表 小。
• T 代表 可测试。

INVEST 中的 S 代表什么？A. 简单。B. 聪明。C. 稳定。D. 小。答案是 D。需求当然应该简单，但这不是我们这里要找的词。

---

上一节我们介绍了INVEST助记符，现在让我们逐一详细解读其含义。

I 代表独立
当一个用户故事是独立的，意味着它可以独立于任何其他用户故事进行开发，无论何时实施。这很重要，因为它允许您重新安排用户故事的开发顺序。如果两个用户故事紧密相关且相互依赖，您可以将它们合并成一个独立的用户故事。但需要注意平衡，避免用户故事变得过于庞大。

N 代表可协商
这意味着用户故事应该足够通用，以便您的团队和客户围绕其实现方式进行协商。由于可能没有唯一正确的实现方式，因此不要专注于满足需求的具体技术细节。相反，应关注需求的主要重要方面。情况可能会发生变化，这是可以接受的。

V 代表有价值
每个故事都应该为客户带来某种价值。不要制造空洞的、无意义的工作。

E 代表可估算
您应该能够估算设计和实现该需求需要多长时间。如果您无法估算开发所需时间，您可能指定了一个所谓的“史诗”。我将在本课稍后讨论什么是史诗。

S 代表小
这与需求应该可估算的理念相关。然而，即使您能估算某件事需要多长时间，这本身并不能使其成为一个好需求。如果您估算一个用户故事需要三个月开发，您会希望将其分解成更小的故事。用户故事之所以要小，是因为每个用户故事都旨在短时间内开发完成。此外，较小的故事其估算也应更确定。如果您遇到一个大型故事，请尝试尽可能将其分解，否则您将面临处理一个史诗的风险。

T 代表可测试
基本上，您需要验证每个用户故事在被视为“完成”之前是否符合一组特定的标准。这通常通过定义和使用验收测试来实现，我将在下一课中详细说明。

以上就是INVEST：独立、可协商、有价值、可估算、小和可测试。

---

我们已经多次提到要避免创建史诗。那么，究竟什么是史诗呢？

正如您可能从上下文中猜到的，史诗是一个几乎无法克服的巨大用户故事。

史诗肯定无法在短时间内完成。史诗是对需求的模糊、宽泛描述。

即使是最成熟的软件开发团队，其需求待办列表中也会出现史诗。

那么，史诗是如何产生的呢？通常，在项目最初描述未来要开发的功能时，史诗就被引入了。当客户希望在未来完成某项功能时，可能很难确切知道它应该是什么样子或应该如何完成。通常的做法是构建一个用户故事，大致勾勒出客户想要的功能。

如果您学习过《软件过程与敏捷实践》课程，请回想一下开发阶段。在大多数流程共有的哪个阶段中，会首次创建史诗？

A. 规格说明阶段。B. 架构设计阶段。C. 构建阶段。D. 过渡阶段。

正确答案是 A. 规格说明阶段。这是与客户创建和讨论需求的阶段。其他阶段构成了后续要完成的工作。如果您没有学习过《软件过程与敏捷实践》课程，您将在那里了解更多相关内容。

---

在本节课中，我们一起学习了用户故事的核心概念。我们了解到，优质的用户故事应符合 INVEST 原则：即具备独立性、可协商、能为客户带来价值、可估算、足够小且可测试。同时，我们认识到应避免创建过于庞大和模糊的“史诗”，它们通常产生于项目初期的需求规格说明阶段。掌握这些原则，将帮助您更有效地与客户沟通并管理软件需求。

024：用户故事 📝

在本节课中，我们将学习用户故事的概念，了解如何编写高质量的用户故事，并认识什么是“史诗”以及如何避免它。

什么是用户故事？

上一节我们介绍了需求的不同表达形式，本节中我们来看看用户故事。用户故事是从用户角度描述软件功能的一种简洁方式。它通常遵循一个简单的模板：作为[某类用户]，我想要[执行某个操作]，以便于[达成某个目标或获得某种价值]。

在我们的餐厅应用示例中，一个用户故事可能如下所示：

作为一名顾客，我想要支付我的账单，以便于我能快速结清欠款。

如何编写高质量的用户故事？

一个看似简单的用户故事可能包含许多未明确的细节。例如，用户是在应用内支付账单吗？接受哪些支付方式？这些问题在故事中都没有得到解答。因此，实现这个故事所需的工作量是不明确的。

为了编写出高质量的用户故事，我们可以使用一个名为 INVEST 的助记符。以下是其核心原则：

• 独立的：每个故事应尽可能独立，不依赖于其他故事的完成。
• 可协商的：故事是需求的占位符，其细节应在开发团队和客户/产品负责人之间讨论确定。
• 有价值的：每个故事必须为最终用户或客户提供明确的价值。
• 可估算的：开发团队应能估算完成故事所需的工作量。
• 小的：故事应足够小，以便在一个迭代或冲刺中完成。
• 可测试的：必须能够定义明确的验收标准来验证故事是否完成。

一个好的实践是提供足够的信息，让开发人员能够理解并实现它，但又不能过多，以至于开始指定实现细节。

什么是“史诗”以及如何避免？

当一个用户故事过于庞大、模糊，以至于无法准确估算或在一个迭代内完成时，它就被称为“史诗”。我几秒钟前提到的故事“作为一名顾客，我想要支付我的账单”就是一个史诗。

问题在于，估算通常遵循一种称为“不确定性锥”的模式。我们将在敏捷规划课程中详细介绍它。但基本思想是：开发一个用户故事的时间估算，距离其计划开发的时间越远，准确性就越低。因此，如果你计划在几个月后开发一个功能，你的估算肯定不如你为本周要开发的功能所做的估算准确。

为了避免编写史诗，第一步是要意识到你可能正在创建一个。如果你将史诗分解为多个更小的故事，你会发现管理起来更容易。

以下是将“支付账单”这个史诗分解的一种方式：

• 作为一名顾客，我想要能够看到包含该订单所有项目的账单，以便于我能了解我的订单将花费多少钱。
• 作为一名顾客，当我查看账单时，我想要能够选择“立即支付”选项，以便于我能立即支付账单。
• 作为一名顾客，我想要能够输入Visa或Mastercard信用卡的支付信息，以便于我能使用一种便捷的方式付款。

所有这些都属于“支付账单”这个广泛主题，但它们更加具体和有用。

练习与总结

想象一下，你正在构建一个软件产品，用户可以从客户网站上选择眼镜进行购买。以下哪个用户故事会被视为该产品的“史诗”？

A. 作为一名戴眼镜的人，我想要看到，以便于我能屠龙。
B. 作为一名戴眼镜的人，我想要购买新眼镜，以便于我能快速收到它们。
C. 作为一名戴眼镜的人，我想要查看可供购买的眼镜列表。
D. 作为一名戴眼镜的人，我想要查看可供购买的眼镜的价格。

正确答案是 B。A不是一个史诗，因为它甚至不是一个与产品相关的用户故事。C和D都是概述了特定功能而没有深入技术细节的故事。

本节课中我们一起学习了用户故事。它是表达客户需求的另一种方式。然后，我介绍了构成一个好用户故事的标准，引入了代表“独立、可协商、有价值、可估算、小、可测试”的 INVEST 助记符。最后，我讲解了什么是史诗以及如何避免它。

在下一课中，我将讨论如何使用户故事可测试，并介绍用户故事验收测试的概念。我们下节课见。

025：验收测试 🧪

在本节课中，我们将要学习一个与用户故事直接相关的概念——验收测试。我们将了解什么是验收测试，它与验收标准有何区别，以及如何编写有效的验收测试来确保用户故事被正确实现。

在上一节中，我们介绍了用户故事，并讲解了如何使用“INVEST”助记符来编写一个好的用户故事。本节中，我们将聚焦于“INVEST”中的最后一个字母“T”，即可测试性。既然用户故事应该是可测试的，那就意味着我们需要为它们编写测试。

什么是验收测试？

验收测试本质上是一种检查，用于验证某个需求是否被满足。这种测试方法几乎应用于所有工程领域，软件工程也不例外。验收测试具体说明了你的客户将如何验证一个用户故事是否已得到满足。如果验收测试通过，那么该用户故事就被认为是已完成的。

验收测试是基于验收标准创建的。验收标准是一个必须满足的特定条件，而验收测试则是验证该条件是否已满足的方法。

如何编写验收测试？

与用户故事一样，验收测试也应使用简单、直接的语言编写。每个验收测试都应该是一个易于理解的操作，并附带一个可验证的条件，以确保用户故事被正确实现。每个测试应验证用户故事的一小部分。如果所有测试都通过，那么验收标准就被视为已满足。

还记得我们在上一课中创建的用户故事吗？

作为一个客户，我希望能够使用Visa和Mastercard信用卡输入我的付款信息，以便我能通过便捷的方式付款。

以下是为这个用户故事编写的一些验收测试示例：

以下是该用户故事的一些验收测试示例：

• 付款可以使用Visa信用卡完成。
• 付款可以使用Mastercard信用卡完成。
• 付款可以使用在线金融服务完成。
• 当使用信用卡付款时，填写卡号字段会自动检测卡类型。
• 客户根据所选的付款方式，仅看到相关的输入字段。

这些只是几个例子，实际可能会有更多，验收标准的内容通常由客户的具体需求决定。请注意，所有这些标准都遵循相似的结构：它们简单、易于验证，并且都与用户故事中指定的不同付款类型相关。

从标准到测试

既然这些都是标准，我们就需要验收测试来验证它们。让我们以“能够使用Visa信用卡付款”这个标准为例。

为了将这个标准转化为验收测试，我们可能会为此标准编写几个测试，例如：

1. 将Visa卡插入芯片读卡器。
2. 输入Visa卡的PIN码。
3. 确认付款被接受。

通过执行这些步骤，你就验证了验收标准。当你通过了所有的验收测试，那么该验收标准就被视为已满足。如果一个用户故事的所有验收标准对应的测试都通过了，那么这个用户故事就成功地通过了验收测试。

知识测验

现在你已经了解了验收标准和验收测试是如何创建的，让我们来测试一下你的理解。

你正在与客户合作开发一个酒店管理应用程序，并收到了以下用户故事：

作为一名客房服务人员，我希望能够在房间概览屏幕上将房间标记为已清洁，以便我能跟踪我的清洁进度。

以下哪一项可被视为该用户故事的验收测试？
A. 从房间概览屏幕中，选择“将房间标记为已清洁”。
B. 房间可以从房间概览屏幕标记为已清洁。
C. 房间应该被清洁。
D. 作为一名客房服务人员，我希望能够清洁一个房间。

正确答案是 A。它概述了使用应用程序将房间标记为已清洁的一个基本步骤。它可能是众多步骤之一，但它仍然是一个测试。

B 是一个验收标准，因为它是一个必须满足的通用条件。其他两个选项既不是验收测试也不是验收标准。事实上，D 完全是另一个用户故事。

验收测试的价值

示例中的验收标准规定了用户故事中未提及的细节。通过列出验收标准，你为开发团队提供了一个参考框架，让他们知道如何将故事分解为开发任务并最终完成。

当验收标准和测试与它们所伴随的用户故事一起编写时，你就能确保你想要实现的功能确实可以验证其实现。

与用户故事一样，验收标准和测试也应由你的客户来制定。然而，让开发人员与客户一起创建验收测试也是一个好主意。这能让客户就他们希望需求如何运作提供意见，同时也让开发团队能够从用户的角度来思考每个需求的具体表现。

因此，客户对产品功能有很大的发言权，而开发团队也能够设想每个功能将如何构建。通过这样仔细思考每个需求，也有助于你避免创建那种令人畏惧的“史诗级”用户故事。一个用户故事有太多的验收标准，可能意味着你可以把这个用户故事再拆分得更细一些。

总结

本节课中，我们一起学习了验收测试。它只是一个简单的条件列表，用于检查用户故事是否正确实现。它们可以以直接的方式进行验证，并使项目中的每个人都能轻松地思考每个功能的具体作用。

在下一课中，我将介绍产品待办事项列表，这是一种用于跟踪需求的流行Scrum实践。我们下节课见。

026：产品积压工作 📋

在本节课中，我们将要学习敏捷开发中的一个核心概念——产品积压工作。我们将了解它的定义、构成要素以及它在项目规划中的关键作用。

上一节我们介绍了验收测试，它是验证用户故事是否被满足的一种手段。本节中，我们来看看如何组织和管理这些用户故事，这正是产品积压工作的职责所在。

产品积压工作是一个在Scrum敏捷方法中至关重要的流行技术。本质上，它是一个你和你的团队计划开发的软件功能列表。实际上，产品积压工作最初是一个未排序的大型待办事项列表，随后会随着时间的推移变得更加精细。

产品积压工作主要由用户故事构成，我在之前的课程中已经定义过用户故事。然而，积压工作并不局限于用户故事，你还可以包含其他事项，例如工作任务、知识任务和缺陷。

以下是产品积压工作中可以包含的几种事项类型：

• 工作任务：包括诸如“设置产品测试服务器”这类事项。它们基本上是物理性的待办事项，与直接开发产品功能没有直接关系。
• 知识任务：与之类似，它是针对需要学习的事项的待办项。例如，“评审数据库连接的编程选项”可以作为一个知识项。
• 缺陷：这指的是产品代码中需要关注的错误。

那么，以下哪些项可以包含在产品积压工作中？A. 用户需求；B. 与工作无关的职责；C. 缺陷；D. 产品愿景。正确答案是A和C。用户需求以用户故事的形式进入积压工作，缺陷也会被列在其中。产品愿景可能指导用户需求的创建，但它不会明确列在积压工作中。与工作无关的职责也是如此。

用户故事是产品积压工作中迄今为止最常见的项目。当你与客户一起编写用户故事时，对它们做的第一件事就是将其放入这个列表中。

产品积压工作是一种Scrum技术，这也意味着它是一种敏捷技术。既然如此，产品积压工作应该是动态的，并专注于客户互动。你与客户一起编写的初始用户故事被收集起来并放入积压工作中。它没有特定的顺序。事实上，积压工作在最初阶段的全部意义在于，它是一个无序的集合，包含了所有理想情况下应构建到最终产品中的事项。

当你创建每个要放入积压工作的用户故事时，请确保为其分配一个唯一的用户故事标识符。这很重要，因为它为项目中的每个人提供了一个参考框架。每当引用某个故事时，你无需复述每个故事的内容，只需引用其标识符即可。为任何给定故事分配什么标识符并不重要，一个简单的方法是使用顺序数字。将你想到的第一个故事分配为1，第二个为2，依此类推。

一旦你有了列表，接下来要做的就是请你的客户为每个故事指定优先级。然后，客户将之前无序的用户故事列表按优先级从高到低进行排序。目标是让最有价值的功能列在积压工作的顶部，最不重要的列在底部。这会打乱你按标识符排序的用户故事顺序，但这没关系。用户故事标识符更多是一种跟踪机制，而非排序工具。

这为你的开发人员提供了开发重点的指引，给了他们视角和焦点。他们只需要担心从任务堆的顶部提取任务即可。这也为你的客户提供了视角和焦点。通过梳理项目中的每一个用户故事，客户被迫去思考他们需要什么和想要什么。这常常会引发客户与开发团队之间的对话。客户告诉开发团队他们真正需要什么，而开发团队则根据可用的技术和资源向客户展示可以做什么。

然而，仅仅因为这种对话可能发生，并不意味着它总会发生。你可能会遇到客户只专注于对产品积压工作进行优先级排序，而开发人员只专注于估算实现每个用户故事所需的工作量。这可能会在他们之间造成一种隔阂。在敏捷开发中，应该有讨论和协作。这能让客户和开发人员都理解为什么一个用户故事具有特定的优先级，以及为什么工作量估算具有特定的数值。你能做的最好的事情就是尽可能与客户协作，并允许你的开发团队在整个优先级排序和规划过程中与客户沟通。

现在，你已经与客户一起创建了一个已排好优先级的积压工作。所有的用户故事都已编号，并根据对客户的优先级从高到低排序。下一步就是开始以这些优先级为参考点来规划你的项目。我不会深入探讨细节，因为这将在《敏捷规划与软件产品》课程中涵盖。但可以说，用户故事会从积压工作中取出，并放入称为“冲刺”的特定时间间隔内要完成的工作块中。

在Scrum中，哪个角色负责创建用户故事并为其确定优先级？A. 产品负责人；B. 开发团队；C. 客户；D. 团队领导。答案是A，产品负责人。在Scrum中，产品负责人负责确保产品积压工作是最新的。客户、团队领导或开发团队的成员可能担任产品负责人的角色，但如果他们要负责更改产品积压工作，他们必须是产品负责人。

本节课中我们一起学习了产品积压工作的概念。我们了解到它是一个动态的、包含用户故事、工作任务、知识任务和缺陷的列表，并且需要与客户协作进行优先级排序，以为开发团队提供清晰的工作指引。这是连接客户需求与开发实施的关键桥梁。

027：产品积压工作 📋

在本节课程中，我们将学习Scrum框架中的一个核心工具——产品积压工作。我们将了解它的构成、动态特性以及如何在敏捷开发中有效使用它来管理用户故事和项目需求。

产品积压工作的规划与动态性

上一节我们介绍了用户故事，本节中我们来看看如何通过产品积压工作来组织和管理它们。

客户设定为高优先级的用户故事计划被更早完成。重要性较低的故事则计划在后期发布。然而，由于Scrum专注于一次一个冲刺的开发方式，这为当前冲刺之后的计划留下了很大的调整空间。

开发团队只需专注于规划下一个冲刺。当该冲刺完成后，客户可以添加新的用户故事、重新评估优先级，并相应地调整冲刺计划。这意味着需求可能改变其最初计划的优先级。

事实上，这种情况非常普遍。开发团队经常会在一个冲刺中愉快地开发一组用户故事时，客户决定需要做出改变。可能一个之前低优先级的需求现在变得极其紧急。可能一个之前高优先级的需求现在完全不再需要。或者客户可能想到一个新功能，从而有更多用户故事被添加到积压工作中。这最终可能导致其他事项的优先级发生变动。

当然，团队也肯定会发现需要解决的缺陷。产品积压工作必然会随着时间的推移而演变。它会变动、增长、缩减并改变顺序。这完全正常。在Scrum中，唯一不允许这种变动的地方是正在进行开发的当前冲刺期间。除此之外，根据需求变化调整计划是完全可行的，事实上，这是被鼓励的。不要认为事情从一开始就一成不变。这不仅不现实，还会给项目带来大量问题。

行业实践访谈：产品积压工作的应用

接下来，让我们通过一段访谈，看看产品积压工作在行业中是如何被使用的。

产品积压工作通常是一个按优先级排序的工作项列表，旨在交付客户在特定版本或产品中期望的价值。进入产品积压工作的内容包括新功能、增强功能，甚至是现有产品版本中导致缺陷的问题。其他如架构工作、技术债务等也可能是产品积压工作包含的项。

产品积压工作中的需求形式通常被指定为用户故事。用户故事通常由角色（客户）、需求（需要或想要的东西）以及该用户故事将为他们带来的价值或理由组成。

积压工作的优先级排序可以被认为是通过一个称为“积压梳理”的过程来完成的。这个过程包括检查产品积压工作的内容，并尝试使其与业务优先级、技术可行性以及代码本身的实际情况保持一致。

产品积压工作本身是相当动态的。在版本发布之初，它可能与发布结束时看起来大不相同。其中的事项可能会通过积压梳理过程本身发生转变，也会因为不断变化的业务需求和优先级，以及团队自身发现了之前未知的新技术依赖关系而改变。这些也是需要放入积压工作并确保得到处理的事项，以满足积压工作所涵盖的整体工作目标。

产品积压工作的构成

以下是关于Scrum产品积压工作构成的一个小测试。

问题： 以下哪些是Scrum产品积压工作的组成部分？你可以选择多个答案。
A. 缺陷
B. 客户邮件
C. 知识任务
D. 工作任务
E. 业务需求

答案： A、C 和 D。缺陷、知识任务和工作任务都可以包含在Scrum产品积压工作中。

总结与展望

本节课中我们一起学习了产品积压工作。它是一个非常有价值的工具，对Scrum至关重要。它帮助你组织工作，清晰地看到项目的优先级所在，并基于这些优先级进行规划。产品积压工作在敏捷环境中运行良好，因为它为你的客户和团队提供了很大的灵活性。

在下一课中，我将讨论另一种用于组织用户故事的方法——故事地图。我们下节课见。

软件产品管理课程3：客户需求与软件需求：3.3.5：故事地图 🗺️

在本节课中，我们将要学习一种用于组织和可视化需求的新工具——故事地图。上一节我们介绍了Scrum产品待办事项列表，本节中我们来看看故事地图如何以更直观的方式呈现和管理用户故事。

故事地图是一种将产品待办事项列表中的用户故事，按照更具体的功能类别进行分组和可视化的方法。它本质上是一个二维结构，能够更清晰地展示产品功能的整体脉络和用户故事的关联性。

以下是一个故事地图的构建示例。假设你正在开发一个简单的电子邮件程序，客户提供了一系列用户故事，例如：

• 作为一名作者，我希望能够撰写纯文本消息，包含收件人、主题行和正文，以便我能以基本方式传达消息内容。
• 作为一名读者，我希望在收到邮件时能够打开它们，以便阅读最新消息。
• 作为一名读者，我希望能够将消息存储到存档中，以便将来参考。
• 作为一名读者，我希望能够在我的存档中搜索消息，以便快速找到相关消息，而无需手动浏览。
• 作为一名作者，我希望能够将文件附加到我的消息中，以便为消息添加额外信息。
• 作为一名读者，我希望能够打开消息中的任何附件，以便查看接收到的消息中的额外信息。

你可以根据产品的基本功能来创建类别标题，对上述故事进行分组。例如，基本功能可以是“撰写与发送”、“阅读、接收与存储”以及“搜索”。将每个故事放入相应的类别后，你就能立即看出哪些功能已覆盖，哪些可能缺失。随后，客户可以在各个类别内根据其判断对这些故事进行优先级排序。这样一来，一个可能令人望而生畏的需求列表，就变成了一套组织有序、便于管理的待实现功能集。

现在你已经了解了故事地图的创建过程。请思考一下，创建故事地图能为你的项目带来哪些好处。

以下是故事地图可能带来的益处，请选择你认为正确的选项：
A. 在初始规划阶段节省时间。
B. 简化优先级排序。
C. 让你对项目将如何发展有一个整体视图。
D. 提供详细的开发计划。

正确答案是B和C。故事地图能简化优先级排序，并让你对项目的发展有一个整体视图。它不会在初始规划阶段节省太多时间，但可能会在后续阶段节省时间。同时请记住，故事地图本身并不是一个开发计划。

与经典的产品待办事项列表相比，故事地图还提供了许多改进。首先，它赋予待办事项列表更强的可追踪性和视觉感受。你不再需要费力管理一个庞大列表的优先级，而是被迫将事项分解到不同类别中。

另一个改进是，它让你能够看清各个用户故事之间的关系。故事地图允许你看到这些需求是如何组合在一起的，而不是处理一堆按优先级排序的孤立需求。通过可视化需求之间的联系，你可以非常容易地发现是否有遗漏之处，从而相应地填补这些空白。

故事地图的另一个巨大好处是，它能让你的开发人员了解产品应如何作为一个整体来构建。许多产品都有多个可被视为主要功能的类别或功能组。在经典的一维产品待办事项列表中，来自一个功能组的用户故事很容易压倒来自另一个功能组的故事。然而，在故事地图中，位于地图顶行的所有用户故事都具有相同的重要性级别。这不仅简化了优先级排序，还让你能了解产品在每次迭代中实现了什么。

如果你将每个水平行视为产品的一个发布版本，那么你就可以看到产品如何随着你逐行向下移动地图而演进和增长。例如，在你之前看到的例子中，产品可能会从仅支持基于文本的交互，发展到支持多媒体文件的传输。故事地图确保你将开发精力均匀地分配到各个功能上，而不是只专注于构建某一个类别（这可能无法完全满足客户需求）的功能。它为开发人员的工作提供了上下文，表明在转向更复杂的工作之前，最好先实现简单的功能。你不会构建一个能发送多媒体和文本邮件，却无法阅读它们的电子邮件系统。故事地图提供了有时识别这些依赖关系所需的上下文。

这是敏捷原则中“构建可工作的软件”的一个绝佳实践示例。你不是在构建一个任意的需求列表，而是在实际展示整个产品在各个阶段如何组合在一起。

如果你之前学习过我们的软件过程与敏捷实践课程，你应该见过看板（Kanban board）的样子。这里需要特别指出，故事地图并不是看板的替代品。看板是一种展示项目当前状态和跟踪任务进展的方式，而故事地图是一种在二维结构中规划和组织用户故事的方式。实际上，你可以同时使用故事地图和看板来规划和跟踪项目，这并不少见。

因此，故事地图的核心是一种让你的需求变得更好的方法。它为项目中的每个独立需求提供了上下文，并为项目带来了更强的组织结构。当然，故事地图仍然支持软件产品中不可避免的变更。甚至可以说，它比经典的产品待办事项列表更好地支持变更。它让开发人员和客户对产品的整体性有所感知，快速了解各个部分是如何组合在一起的。

在本节课中，我们一起学习了故事地图的概念、构建方法及其优势。故事地图通过将用户故事按功能分组并可视化，简化了优先级排序，提供了产品发展的整体视图，并帮助识别需求间的依赖关系和潜在遗漏。它是一种强大的工具，能为开发团队提供必要的上下文，确保产品均衡发展。在下一个模块中，Morgan将与你探讨更多改进需求的方法。

029：用户故事标准

在本节中，我们将学习如何确保用户故事具备高质量。上一节我们介绍了INVEST助记符，它概括了用户故事应满足的标准。本节中，我们将扩展讨论编写用户故事时需牢记的其他质量标准。

首先，快速回顾一下INVEST助记符的含义：

• I 代表 独立
• N 代表 可协商
• V 代表 有价值
• E 代表 可估算
• S 代表 规模小
• T 代表 可测试

高质量的用户故事有助于保持开发进度，避免错误和混乱。例如，用户故事应定义得规模小、易于理解、有价值，并能被清晰地测试是否完成。

除了INVEST标准，为确保质量，需求（尤其是用户故事）还应满足其他几项标准。你的用户故事还应做到：正确、完整、清晰、一致、可行和可追溯。

接下来，我们将逐一探讨这些标准，并解释为何用户故事满足这些标准至关重要。我们也会重温餐厅示例，并通过测试来检验你能否判断某些用户故事是否符合标准。

现在让我们开始。首先，讨论正确的用户故事。可以想象，用户故事正确非常重要。如果用户故事是错的，开发团队将花费时间开发一个并非客户本意的功能。

因此，你必须与客户仔细评审用户故事，确保所有故事表述正确，并且是需要开发的正确故事。

例如，考虑这个用户故事：

作为一名顾客，我希望在向厨房提交订单后，能够修改我点的菜品，以便我能根据自己的喜好定制其制作方式。

这是一个不正确的需求。在场景描述中，顾客可以在下单前修改菜品，但从未提及允许在之后修改。

想象一下，如果你的开发团队实现了这个错误的用户故事。当你向客户演示时，他们会不满意。他们可能会说：“这对厨房员工来说将是一场噩梦。”😊。你的开发人员因此浪费了宝贵的开发时间，这些时间本可用于开发正确的功能。

回顾一下客户的请求：

我为表述模糊道歉。当我设想顾客与应用程序交互时，我设想每张餐桌应配有一台或多台平板电脑供顾客点餐。我看到他们浏览食物图片。如果他们想了解更多关于某道菜的信息，可以点击它；如果他们想点这道菜，就按“下单”。这应该会带他们到另一个页面，在那里他们可以在将订单发送到厨房之前，指定对餐点的修改以及他们可能有的任何饮食限制。当一张餐桌有多位顾客时，我希望它像在线购物系统的购物车一样工作。我希望每台平板电脑在餐桌上传阅时，每位顾客都能选择自己的订单。或者，餐桌上的一个人可以输入每个人的订单，这没关系。同一账单上的所有订单必须从一台平板电脑提交，额外的平板电脑将用于人们浏览菜单或为另一个账单下单。不应有最低或最高订单限制。当所有订单都已输入并定制后，顾客可以通过点击“提交订单”将订单提交给厨房。

那么，以下哪些用户故事是正确的？

A. 作为一名顾客，我希望浏览所在餐厅的菜单，以便查看他们提供哪些菜品和饮品。
B. 作为一名顾客，我希望能够向厨房说明我的饮食限制，以便避免菜肴中的某些成分。
C. 作为一名顾客，我希望能够定制菜单上没有的菜品，以便获得独特的用餐体验。
D. 作为一名顾客，我希望能够查看营养信息，以便选择适合我饮食的菜肴。

根据客户的请求，只有答案A和B正确地体现了客户的要求。因此，它们是正确的答案。答案C不正确，因为顾客应该能够修改现有菜品，但不能定制菜单上没有的菜。答案D不正确，因为这不是客户提到的功能。

---

接下来，我们看看完整的用户故事。完整意味着用户故事包含所有必要信息，使开发团队能够理解需要构建什么，而无需进一步澄清。一个不完整的用户故事会导致开发停滞，因为团队需要等待更多细节。

考虑这个用户故事：

作为一名顾客，我希望能够支付账单。

这个用户故事缺少关键细节，例如支付方式（现金、信用卡、移动支付？）、支付流程、是否支持分单付款等。一个更完整的版本可能是：

作为一名顾客，我希望能够使用信用卡或借记卡支付我的账单，以便快速结账离开。

---

现在讨论清晰的用户故事。清晰意味着用户故事易于理解，没有歧义。模糊的语言会导致不同的解释，从而产生错误的功能。

例如：

作为一名顾客，我希望系统快速响应。

“快速”是模糊的。多快才算快？一个更清晰的版本应包含可衡量的标准：

作为一名顾客，我希望从点击“提交订单”到收到确认消息的时间不超过2秒，以便我知道订单已成功发送到厨房。

---

一致的用户故事意味着故事之间或故事内部没有矛盾。矛盾的需求会导致混乱和返工。

例如，如果一个用户故事说“顾客必须登录才能下单”，而另一个故事说“顾客可以匿名浏览菜单”，这通常是一致的（浏览与下单不同）。但如果一个故事说“所有功能都无需登录”，而另一个说“下单需要登录”，这就产生了不一致，必须解决。

---

可行的用户故事在技术、时间和预算约束下是可以实现的。提出一个技术上不可能或资源上不可行的用户故事是没有意义的。

例如，在当前技术下：

作为一名顾客，我希望通过意念控制平板电脑点餐。

这可能被认为是不可行的。

---

最后，可追溯的用户故事意味着每个故事都能追溯到其来源（如客户访谈、市场研究），并能向前追踪到实现它的具体开发任务和测试用例。这有助于管理变更和确保覆盖。

例如，用户故事“浏览菜单”应能追溯到客户请求中的相关描述，并能链接到实现该功能的UI设计和测试场景。

---

在本节课中，我们一起学习了确保用户故事高质量的多个关键标准：正确、完整、清晰、一致、可行和可追溯。结合之前学习的INVEST标准，这些准则将帮助你编写出优秀的用户故事，从而为开发团队提供清晰、可靠的指导，最终交付符合客户期望的软件产品。记住，在编写和评审用户故事时，始终从这些角度进行审视和提问。

030：客户需求与软件需求

第3.4.1a节：用户故事标准 📝

在本节课中，我们将学习如何评估和撰写高质量的用户故事。用户故事是描述软件需求的简洁方式，但为了确保开发过程顺利并最终交付符合期望的产品，它们需要满足一系列明确的标准。

上一节我们介绍了用户故事的基本概念，本节中我们将深入探讨用户故事应满足的具体质量标准。

用户故事应完整

首先，我们希望用户故事是完整的。这意味着描述问题所必需的所有需求都应被包含在内。

由于您的开发团队将根据产品待办事项列表中的用户故事来开发解决方案，如果缺少某些需求，相应的功能将无法被实现。

像故事地图这样的工具对于判断是否遗漏用户故事非常有用。

用户故事应清晰

接下来，让我们看看如何使用户故事清晰。这意味着用户故事应易于理解、精确无误，并且只有单一的解释。

这个标准要求很高。当您仔细审查用户故事中的歧义时，会发现一个句子竟然可以有多种不同的理解方式，这非常令人警醒。

希望您能理解一个可被多种方式解读的用户故事所带来的风险。如果客户以一种方式理解，程序员以另一种方式理解，而测试人员又有不同的理解，那么很难判断谁是正确的，以及究竟应该开发什么。

一项有助于减少歧义的重要实践是进行需求技术评审与修复练习。在这个练习中，最好由项目外部人员根据本课的所有标准来评审需求，其中就包括审查需求的歧义性。

我们将在下一课详细讲解如何撰写无歧义的用户故事，但这里先看一个例子。

假设有一条需求是：“作为一名顾客，我希望成人和儿童菜单上都有游戏，以便我们在等待食物时有有趣的事情可做。”

“都有”这个词在这个用户故事中造成了歧义。这个用户故事可能意味着儿童菜单上有儿童游戏，成人菜单上有成人游戏；但也可能被解释为儿童菜单和成人菜单上的游戏是相同的。

为了使需求更清晰，除了依赖自然语言描述，另一种方法是使用视觉描述（如线框图和故事板）来补充您的需求。

我们将在本模块的后续部分进一步探讨如何识别和修复有歧义的需求。

用户故事应一致

现在我们来谈谈用户故事的一致性。保持用户故事一致意味着各项需求之间互不冲突。这显然会在后续开发过程中引发问题。

您的客户和开发团队已经完成了一份用户故事列表，并希望您在下次讨论会前进行评审。在这次评审中，您需要确保用户故事是一致的。

以下是判断练习：

您的客户和开发团队已完成一份用户故事列表，并希望您在下次讨论会前进行评审。在这次评审中，您需要确保用户故事是一致的。

以下哪些用户故事彼此冲突？请选择两个互不一致的用户故事。

A. 作为一名儿童顾客，我希望可以自己点餐，以便得到我想吃的食物。
B. 作为一名顾客，我希望在点餐后能查看订单，以确保我们点得正确。
C. 作为一名厨房员工，我希望查看已接收的订单，以便知道需要准备哪些菜品。
D. 作为一名顾客，我希望能够为我的家人点餐，以便监控他们吃了什么。

答案 A 和 D 不一致。 因为在答案 A 中，儿童顾客可以自由点餐，而在 D 中，顾客（家长）要为家人点餐以监控饮食，这两者存在矛盾。其他组合彼此一致。因此，答案 A 和 D 是正确答案。

用户故事应可行

接下来，我们讨论用户故事的可行性。这意味着每项需求都能够在指定的成本和进度约束内，利用现有的技术、工具、资源和人员来实现。

如果您经常遇到不切实际的用户故事，我欣赏您的雄心，但这是一个不满足就会带来风险的标准。您需要诚实地审视您的资源、团队、进度和预算。您真的能完成所有承诺的需求吗？

不满足此标准将导致额外成本和客户不满。我个人非常希望避免这两点。

用户故事应可追踪

我们希望满足的最后一个标准是用户故事的可追踪性。这意味着每项需求都以某种可追踪的方式与相关的设计和实现工件（如代码、测试）相关联。

简单来说，对于每项需求，都有对应的代码和测试。同时，每一段源代码都对应某项需求，并且每一段源代码都有测试。

保持用户故事可追踪意味着只编写必要的代码，并且所有需求都经过测试。这两点都是开发过程中期望具备的优秀品质。

您可以为每项需求设置一个唯一标识符，以帮助开发人员在代码、测试、错误报告和变更日志中引用它。

课程总结

现在您已经了解了用户故事应满足的标准。

在上一个模块中，您学到用户故事应满足 INVEST 标准，即独立、可协商、有价值、可估算、小规模和可测试。

在本节课中，您进一步学习了用户故事还应是正确、完整、清晰、一致、可行和可追踪的。

改进您的用户故事以满足这些标准，将能防止项目中出现错误或不必要的工作。高质量的用户故事最终将导向高质量的产品。

031：含糊需求

概述

在本节课中，我们将学习什么是含糊需求，以及它们为何会导致问题。我们将探讨11类容易引发歧义的词语，并通过实例学习如何识别和避免它们，以确保开发人员能准确理解需求。

---

含糊需求的问题

上一节我们介绍了需求管理的重要性，本节中我们来看看含糊需求带来的具体问题。

含糊需求指那些可以用多种方式解释的需求。它们通常缺乏清晰或足够的细节来做出正确解读。这会导致沟通误解，最终造成软件构建错误，从而浪费时间和金钱等资源。

识别含糊需求的方法

为了识别含糊需求，我们可以关注一些特定类别的词语。以下是11类可能导致歧义的词语。请注意，使用这些词语并不总是导致歧义，但需要仔细考虑，并可能需要添加额外信息来消除歧义。

我们的11个类别是：间接词语、模糊词语、劝说词语、完成词语、限定词、比较词、数量词、代词、方位词、时间词和连接词。

1. 间接词语

这类词语暗示某事可能发生，但未具体说明如何或何时发生。例如：should、could、may、will。

如果陈述没有解释事件应该或可能发生的具体条件，那么“should”和“could”就可能意味着含糊。同样，“may”也是如此。

考虑以下用户故事示例：

作为一个在线扑克玩家，我可能会赢钱，这样我就能因赢得游戏而获得奖励。

在这个例子中，不清楚在线扑克玩家在何种情况下会赢钱。可以通过指定这些信息来澄清这个用户故事。

更好的写法是：

作为一个在线扑克玩家，当我在扑克游戏中战胜对手时，我会收到钱，这样我就能因赢得游戏而获得奖励。

最后，间接词语类别中的最后一个词是“will”。如果陈述没有具体说明事件何时发生，那么“will”就是含糊的标志。它是始终发生还是仅有时发生？如果事件每次都会发生，最好使用“must”。如果事件只在一定条件下发生，请指定这些条件。

2. 模糊词语

模糊词语通常是描述中缺乏细节的动作、对象名称或说法。问题不在于存在多种解释可供选择，而是没有足够的细节来做出任何解释。

以下是模糊词语的例子：

• 模糊动作：processed（处理）、handled（处理）、operated（操作）。
• 模糊对象名称：item（项目）、entity（实体）、unit（单位）。
• 模糊说法：as appropriate（酌情）、where applicable（如适用）、within reason（在合理范围内）。

对于模糊对象名称，要么用更具描述性的名称替换这些术语，要么确保该术语在产品术语表中定义并一致使用。对于模糊说法，需要明确具体是什么决定了“适当性”、“适用性”或“合理性”。

3. 完成词语

这类词语的例子包括：and so on（等等）、and so forth（等等）、etc.（等等）、also（也）。

“and so on”这类词通常暗示列表中还有更多可以命名的成员，但为了简洁而没有列出。确保在列出事物时，提供列表包含内容的必要细节。通用的归属规则可能并不明显，因此不要将规则留待解释。

“also”这个词也属于这一类。它通常出现在对现有陈述的补充中。如果脱离上下文理解添加的从句，或者与前面的陈述不一致，就可能导致歧义。因此，如果在需求中使用“also”，请务必提供上下文来说明“also”从句的含义。

考虑以下用户故事：

作为一个文档创建者，我也想将文本文档存储在桌面文件夹中，以便我可以轻松访问它。

关于这个用户故事，以下哪种解释可能是正确的？
A. 文本文档出现在桌面文件夹以外的其他地方。
B. 另一个文档与文本文档一起出现在桌面文件夹中。
C. 除了我正在做的事情之外，我还将文本文档存储在桌面文件夹中。
D. 以上所有。

实际上，所有三种情况都可能同时发生。因此，D是正确答案。由此可见，在使用“also”时提供上下文非常重要。

4. 劝说词语

这类词语包括：clearly（显然）、certainly（当然）、obviously（显然）。

如果一个陈述是“显然的”，它对所有读者来说都真的显然吗？读者为什么要相信它？这个陈述是在断言观点而不是事实吗？用户故事不需要说服，因此应避免使用这些词语。

5. 限定词

到目前为止，我们看到的类别和例子都是因为缺乏信息而导致歧义。现在我们将看看那些因为限定或修饰某些条件而可能意味着含糊的词语。

限定词的例子包括：all（所有）、every（每个）、only（仅）、no/none（无）、never（从不）、always（总是）、sometimes（有时）、often（经常）、usually（通常）。

“all”和“every”导致歧义的原因相似。考虑以下用户故事：

作为管理员，我希望所有社交媒体用户都使用一个帐户，以便我可以跟踪他们的使用情况。
作为管理员，我希望每个社交媒体用户都使用一个帐户，以便我可以跟踪他们的使用情况。

这两个用户故事都可能意味着所有社交媒体用户使用同一个帐户，也可能意味着每个用户都有自己的帐户。

接下来，我们看看“only”这个词。使用时要小心，尤其是在英语中，因为根据“only”在句子中的位置，可能会导致含义完全不同。

考虑句子：

Premium account holders are allowed to read the full online article.
（高级帐户持有者被允许阅读完整的在线文章。）

我们可以插入“only”来使句子表达不同的意思。

1. Only premium account holders are allowed to read the full online article.
   （只有高级帐户持有者被允许阅读完整的在线文章。）这意味着不允许其他帐户持有者阅读完整的在线文章。
2. Premium account holders are only allowed to read the full online article.
   （高级帐户持有者只被允许阅读完整的在线文章。）这意味着高级帐户持有者除了完整的文章外，不允许阅读任何其他内容。
3. Premium account holders are allowed to read the full online article only.
   （高级帐户持有者被允许阅读仅完整的在线文章。）这也能表达与第2点相同的意思。
4. Premium account holders are allowed to read the only full online article.
   （高级帐户持有者被允许阅读唯一的完整在线文章。）这意味着只有一篇完整的在线文章可用，并且高级帐户持有者被允许阅读它。

使用“only”时，请确保你用它来修饰句子以表达正确的含义。

6. 比较词

比较词是用于比较两个或更多事物的短语。它们也是含糊的标志。

如果我们用比较两辆车大小的例子，可能会使用以下短语：

• Car A is the same as car B. （车A与车B相同。）
• Car A is bigger than car B. （车A比车B大。）
• Car A is the biggest. （车A是最大的。）
• Car A is more spacious than car B. （车A比车B更宽敞。）
• Car A is as big as a truck. （车A和卡车一样大。）

这些短语中的每一个都是含糊的或缺乏细节。当我们将车A与车B进行比较时，我们指的是物理整体尺寸、高度、宽度、内部空间、载货容量、头部空间还是发动机尺寸？比较两个对象时，请务必具体说明正在比较对象的哪个特定属性。

同时，注意使用以“-er”结尾的单词，如bigger（更大）、smaller（更小）、wider（更宽），或以“-est”结尾的单词，如biggest（最大）、smallest（最小）、widest（最宽）。

7. 数量词

涉及数量的词语也可能导致歧义。例如：a/an（一个）、some（一些）、most（大多数）、few（少数）。

“a”或“an”是你经常遇到的词。考虑以下例子：

作为一个填字游戏解谜者，我希望应用程序有一个填字游戏，这样我就可以在我喜欢的消遣中挑战自己。

“一个填字游戏”是指应用程序上只有一个填字游戏，还是指应用程序上至少有一个填字游戏？为了避免“a”或“an”带来的歧义，可以使用诸如具体数字或“至少某个最小数量”之类的量词。

例如，你可以说：

作为一个填字游戏解谜者，我希望应用程序至少有一个填字游戏，这样我就可以在我喜欢的消遣中挑战自己。

如果陈述没有给出具体的数量或涉及哪些项目，那么“some”、“most”和“few”就表示含糊。

8. 代词

代词是诸如 he（他）、she（她）、it（它）、we（我们）、you（你/你们）、they（他们）、us（我们）、our（我们的）、this（这个）、that（那个）等词语。

代词可能导致含糊的短语，因为可能不清楚代词代表的是哪个名词。

例如，在用户故事中：

作为一个虚拟农场主，我希望它能生长，这样我就可以卖掉它换取虚拟资金。

这里不清楚“it”指的是什么。“it”可能指的是虚拟农场本身、虚拟作物或虚拟农场动物。为了避免混淆，应该定义并使用更具体的术语，而不是使用代词。

9. 方位词

方位词的例子包括：after（在…之后）、before（在…之前）、following（跟随）、last（最后的/上一个）。

对于这些词，我们以数据库条目为例。如果我们说“条目A出现在数据库中的条目B之前”，这可能意味着条目A直接出现在条目B之前，也可能意味着条目A出现在数据库中条目B之前的任何位置。类似地，我们可以说“条目B出现在数据库中的条目A之后”，或者“条目B出现在数据库中跟随条目A”。所有这些短语出于同样的原因都是含糊的，需要更明确地指定条目的出现位置。

现在看看这个短语：“I am making changes to the last entry.”（我正在修改最后一个条目。）这里的“last”一词导致了很多歧义。这可能意味着我正在修改上一个条目，也可能意味着我正在修改出现在最末尾的条目，还可能意味着不会再添加更多条目，而这个条目将是最终的条目。

10. 时间词

这类词与时间或事件相关，类似于方位词（如果指的是时间而非位置，方位词也可归入此类）。时间词的例子包括：when（当…时）、for（持续）、until（直到）、from（从…起）、current（当前的）、latest（最新的）。

首先看看“when”。考虑以下例子：

作为一个跑步者，我希望当我开始绕跑道跑一圈时，圈速计时器会设置为0，这样我就可以监控我的配速。

这可以解释为：计时器在跑步者开始跑一圈的时刻设置为0。它也可能意味着：计时器在跑步者第一次开始跑一圈时设置为0。但它还可能意味着：计时器在跑步者每次开始绕跑道跑一圈时都设置为0。

接下来，看看例子中的“for”：

作为一个露营者，我希望产品能显示未来三天的天气，这样我就能看到露营期间的天气情况。

这个用户故事可以有两种不同的解释。一种方式是产品显示三天的天气预报。另一种方式是产品在接下来的三天里显示每日天气，之后就不再显示。

11. 连接词

连接词是连接两个或多个短语或对象的词语。例如：and（和）、or（或）、both（两者都）。

首先，看看“and”可能引起的歧义。考虑用户故事：

作为一个零售商人，我想打印清仓标识，这样当商店商品过多和季节变化时，商店就可以进行促销。

那么，这是否意味着当商店商品过多时进行促销，并且在季节变化时也进行促销？还是暗示了一个双重条件，即商店只有在同时商品过多并且季节正在变化时才进行促销？在第一种情况下，明确地将需求分解为两个独立的需求来分别满足是更好的做法。

最后，“or”也会引起歧义。“or”的问题在于它没有区分在两个条件都成立的情况下会发生什么。

其他发现歧义的方法

在你的用户故事中扫描特定词语作为含糊的标志，并不是确定你是否有不明确需求的唯一方法。

另一个确保你的需求和术语表都没有歧义的好方法是，用术语表中的定义替换用户故事中的术语。你的用户故事仍然有意义吗？你的术语表定义是否恰当地代表了该术语？通过这样做，你可能会发现需要向术语表中添加更多术语、重新定义术语表中的术语，或者重写一些用户故事。

总结

在本节课中，我们一起学习了含糊需求的定义及其危害。我们深入探讨了11类容易导致需求含糊的词语，包括间接词、模糊词、劝说词等，并通过具体实例分析了每类词语的问题所在以及如何修正。最后，我们还介绍了通过术语表验证等方法来发现和消除歧义。掌握这些知识，将帮助你编写出更清晰、更准确的需求，从而与开发团队进行更有效的沟通，确保软件产品正确构建。

032：课程总结 🎯

在本节课中，我们将对《客户需求与软件需求》课程的全部内容进行回顾与总结。

恭喜你完成了关于客户需求与软件需求的课程。

如果你也学习了我们的《软件过程与敏捷实践》课程，那么你现在已经完成了我们在导论课程中提到的“INiP”结构中的两条“腿”。你已经拥有了一个可以继续构建知识的良好基础。

接下来，我们将为“INoKSH”结构添加的“身体”部分，这代表了《软件产品的敏捷规划》课程。如果你尚未学习《软件过程与敏捷实践》课程，你需要在继续前进之前完成那部分学习旅程。

现在，让我们花些时间来回顾一下本课程所涵盖的内容。

课程内容回顾

在本课程中，Bradley 在第一个模块首先介绍了需求的定义。他将需求定义为对客户需求的特定描述。你还学习了五个需求活动，分别是：需求获取、需求表达、需求优先级排序、需求分析以及需求管理。

Bradley 还在第一个模块中带你了解了不同类型的需求。这些类型包括：业务需求、业务规则、用户需求、功能需求、非功能性需求、外部接口需求、物理环境需求以及开发者约束。

接下来，你学习了软件开发中涉及范围变更的问题，以及需求与设计之间的区别。

在模块2中，我们回顾了不同类型的用户。以下是主要的用户类型：

• 主要用户：直接与产品交互的用户。
• 次要用户：偶尔使用产品或通过中介与产品交互的用户。
• 三级用户：受产品使用影响或对产品做出决策的人。

我们还讨论了用户可能遇到的约束或限制，以及如何设计产品以适应这些限制。

接着，我们探讨了如何在需求获取活动中让用户和客户参与进来。我们研究了应该向客户提出的好问题以及应避免的问题，并为你下一次客户会议做好了准备。

然后，我们介绍了在需求表达活动中表达需求的三种不同方式。这些方法是：用例、线框图和故事板。

随后，你进入了模块3。在这个模块中，Bradley 向你展示了更多表达需求的方法，以及它们如何融入敏捷开发。之后，Bradley 向你介绍了用户故事。你将在敏捷开发中频繁使用用户故事。

一个用户故事的结构如下：作为一个 <角色>，我想要 <功能>，以便于 <价值>。用户故事是一种简洁地展示“谁”、“什么”和“为什么”的便捷方式。

Bradley 还向你展示了产品待办事项列表，以及如何使用故事地图来对已获取和表达的用户故事进行优先级排序和组织。

在最后一个模块中，我们探讨了要使你的需求和用户故事被视为高质量所应满足的标准。我们还回顾了需求中常见的模糊语言，并向你展示了识别和澄清这些模糊语言的方法。

总结与展望

至此，本课程的内容已全部结束。

如果你也完成了《软件过程与敏捷实践》课程，那么你现在已经准备好进入《软件产品的敏捷规划》课程了。在那门课程中，你将学习许多用于规划软件产品的敏捷实践。这些技术在今天行业中普遍使用。

你将体验的一些实践将侧重于估算、故事点和速度。你还将学习如何创建发布计划和迭代计划，这有助于组织需求和开发任务。最后，你将有机会研究风险计划。我们已在本专项课程中多次提到风险管理，在下一门课程中，你将学习并应用一些风险管理技术。

我们期待在《软件产品的敏捷规划》课程中与你相见。

033：专项课程预览

在本节课程中，我们将预览艾伯塔大学软件产品管理专项课程的整体内容与目标。该专项课程旨在教授如何成功地将一个软件产品从概念构思引导至最终交付。

艾伯塔大学是世界领先的公立研究型与教学密集型大学之一。作为加拿大顶尖大学，我们在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。我们的热情在于为学生成功提供起点，目标是激励、转变和提升学生，并帮助他们实现目标。

强大的协作与沟通技能对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。基于此，我们的计算专家团队将为您提供掌握敏捷软件开发所需的流程与实践方法。

我们对软件产品管理流程的实践理解，将为您提供直面挑战所需的一切。我们将教您如何理解并细化客户的软件需求，以及如何将这些需求传达给开发团队。

以下是您将在课程中学到的关键技能：

• 学习监控项目的技术，以确保项目符合客户需求。
• 学习确保项目遵循计划并达到预期质量水平的技术。

您将有机会加入一个软件产品管理社区，在那里您可以分享经验并从他人的见解中学习。最后的课程是一个为期六周的顶点项目，它将为您提供在真实模拟中应用这些管理技术的机会。成功完成顶点项目后，您将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。

我们很高兴您对我们的专项课程感兴趣。我们已经尽力使这成为一次有价值的教育体验。现在轮到您了，祝您好运。

---

本节课中，我们一起预览了艾伯塔大学软件产品管理专项课程的全貌，了解了课程目标、教学团队背景以及您将学习到的核心技能与最终收获。

034：课程介绍

概述

在本节课中，我们将学习《客户需求与软件需求》课程的核心内容。课程将介绍如何理解客户与用户的需求，并将其转化为清晰的软件需求，以指导软件开发。

课程结构预览

我是Ken Wang，欢迎来到软件产品管理专项课程中的《客户需求与软件需求》课程。本课程是该专项课程的基础组成部分，描绘了专项课程结构中的一个支柱。

在介绍性课程中，我们提到开发更好的软件涉及三个目标：做正确的产品、正确地做产品以及正确地管理产品。

为了识别“正确的产品”，你必须理解你的客户和用户的需求。这不仅仅是他们想要什么，还包括他们需要解决什么问题、需要完成什么任务、谁将使用软件以及用户将如何与之交互。当你能够回答这些问题时，你就能帮助你的开发团队构建正确的产品。

为了实现“正确地做产品”和“正确地管理产品”，软件开发必须从一套清晰的软件需求开始，这些需求随后将被规划、设计、实现和测试。

在本课程中，你将学习如何从客户和用户那里收集需求。你还将学习如何将这些需求表达为一套需求规格，以启动软件开发和规划活动。

各模块内容简介

以下是本课程四个模块的主要内容介绍。

第一模块

在第一模块中，Bradley Pette将概述几种类型的健康需求，并解释如何处理需求变更以及避免范围蔓延的方法。该模块还将讨论需求与设计之间模糊边界的问题。

第二模块

在第二模块中，Morgan Ptzel将描述为人们制作产品时遇到的问题，并介绍收集他们需求的有效方法。她还将解释如何应用用例来捕获项目需要支持的任务。随后，你将了解如何应用两种视觉设计技术——线框图和故事板，这些技术在产品早期讨论中非常有用。

第三模块

在第三模块中，Bradley将回来讨论敏捷需求技术。具体来说，他将描述用于表达需求的用户故事、用于验证需求的验收测试、用于确定优先级的项目待办事项列表以及用于组织需求的故事地图。

第四模块

在第四也是最后一个模块中，Morgan将回来概述有效的软件需求和用户故事需要具备的几个标准。同时，她将指出需要注意的歧义迹象，以确保需求不会被误解。

总结

在本节课中，我们一起预览了《客户需求与软件需求》课程的全貌。到本课程结束时，你将掌握一套实用的技术，用于收集客户和用户的需求，并清晰地表达这些需求。你将能够应用这些技术来构建更好的软件产品，即“正确的产品”。

035：什么是需求？

欢迎来到《客户需求与软件需求》课程。

本课程是Coursera软件产品管理专项课程的一部分。在本课程中，我们将探讨软件产品管理中最关键的方面之一：需求。如果你是第一次加入我们，我是Bradley，我将作为你本课程的向导。我曾在许多软件项目中担任项目经理，并在阿尔伯塔大学学习了该领域广泛的技术。

在介绍课程中，我们提到了需求为何重要。它们帮助我们清晰地定义客户需求，在错误变得代价高昂之前及早发现它们，并最终确保你开发的产品满足客户的需求。

在本节课中，我将为你全面概述什么是需求，以及处理需求所涉及的活动。

如今，终端用户的要求越来越高，产品也变得越来越复杂。为了确保你得到正确的产品，并且产品被正确地完成，你需要确保从良好的需求开始。

存在多种定义，有些是技术性的，有些则不是。电气与电子工程师学会（IEEE）对需求有其详细的定义。你可以在我们的课程笔记中找到该定义。然而，该定义并不十分简洁。

因此，在本课程及本专项课程中，需求的定义是：需求是对客户需求的具体描述。

正如你将在本节课和本课程中看到的，需求可以采取多种形式。它们可以被很好地完成，也可能不尽如人意。事实上，你的需求定义和提炼的好坏，会极大地影响你成功的可能性。

正确获取需求始于了解发现它们的适当活动，以及编写良好需求的适当形式。在本课程结束时，你不仅将知道如何执行制定良好需求所需的活动，还将知道如何识别一个需求何时可以改进。

既然你已经了解了什么是需求，让我们看看你能否找出一些例子。

在以下选项中，你认为哪些是软件需求？
A. 作为酒店经理，我希望能够为客人办理入住。

B. 我需要让你签署一份合同。
C. 账户持有人将通过数字键盘输入其银行密码。
D. 用户是男性。

答案A和C是正确答案。它们都描述了客户需要实现的具体功能。其他两个则根本不是需求。

你如何确保你的需求做得好？实践需求活动是一个很好的起点。请记住，活动与软件开发的各个阶段相关联。我们将在本节课中讨论的活动，是与规格说明阶段相关的活动。这通常是流程中最早的阶段，因为在这个阶段，你需要定义你的产品将做什么以及如何做。

此阶段的五个重要活动是：需求获取、需求表达、需求优先级排序、需求分析和需求管理。

让我们首先谈谈需求获取。本质上，获取就是从客户那里获得需求的行为。然而，不要将此误认为是需求收集。收集和获取之间存在关键区别。这个区别在于你作为软件产品经理如何与客户互动。

“收集”一词通常用于描述向客户索要他们希望完成的事项列表的行为。而“获取”则是一个涉及更多、更具互动性和调查性的过程，能带来指数级更好的需求。更好的需求带来更好的软件。因此，花时间确保你正确完成这一点总是个好主意。

需求获取具体涉及什么？为了理解这一点，让我们看一个需求收集的例子。

想象一下，你是一名软件产品经理，被要求为客户构建一个系统。在第一次会议上，你问：“那么你想要什么？”他们准备充分，递给你一张纸，上面列出了他们希望在产品中看到的所有功能，并配有图片，详细说明了他们期望的界面外观。然后会发生什么？一个未经训练的软件产品经理及其开发团队可能会拿着这份列表，开始规划客户指定的确切产品。毕竟，你被雇来编程实现客户想要的东西，对吗？从技术上讲，是的。

然而，在大多数情况下，你的客户对软件如何构建或他们的产品成功所需的功能知之甚少。他们通常会向你提供一份他们希望产品包含的功能列表，但缺乏技术知识来了解他们真正需要什么。

接下来，让我们从行业角度看看“想要”和“需要”之间的区别。

🎼。😊，🎼嘟嘟嘟嘟嘟。

根据我自己的职业生涯经验，我发现询问客户他们想要什么会得到一个答案，而在他们自己的原生环境中观察他们往往会得到一个非常不同的答案，并且常常会显示出意想不到的情况。因此，我认为，找出他们真正需要的方法，是尽可能在接近客户原生环境的地方观察他们。

🎼正确的产品与正确的问题紧密相连。一个做得正确的产品可能确实做得正确，但它不一定解决了正确的问题。这就是区别。而你为确保拥有正确产品所花费的每一刻都是值得的。如果你的产品是正确的，即使它有一些缺陷，人们也会采用它。客户会原谅你，他们知道随着时间的推移你会修复缺陷。但是，如果你的产品是错误的，即使你以零缺陷构建了它，你也浪费了所有的努力，人们仍然不会采用你的产品。这就是一个正确的产品与一个仅仅为了做得正确而做得正确的产品之间的区别。

---

上一节我们介绍了需求的基本概念和重要性，本节中我们来看看如何确保需求做得好，以及“想要”与“需要”的根本区别。关键在于通过深入的互动和调查（即“获取”而非简单的“收集”）来理解客户的真实需求，并确保产品解决的是正确的问题，而不仅仅是正确地构建一个可能错误的产品。

036：需求活动

在本节课中，我们将要学习软件产品经理如何通过一系列核心活动来处理客户需求。我们将重点探讨如何区分客户的“想要”与“需要”，并介绍需求处理的五个主要活动：启发、表达、优先级排序、分析和管理。

作为软件产品经理，你的工作是梳理清楚客户的“想要”和“需要”。

“想要”是客户希望在产品中看到的期望功能。
“需要”是产品为解决特定问题所必需的核心功能。

这些“需要”具有优先性。因为它们处理的是客户和用户的真实需求，而不是那些仅仅被认为有价值的东西。这并非意味着客户的愿望无效或无法实现。这只是说明，必须从技术角度对产品进行考量，以确保产品能够成功完成。

如果你只是简单地询问客户想要什么，你只会得到一份他们期望的功能列表，而无法聚焦到他们真正需要的东西上。这会迫使你陷入被动应对的境地。

为了变得主动，最好始终进行需求启发这项活动。通过深入参与产品的定义过程，你能够将“需要”从“想要”中剥离出来。

以下是一个例子。想象我之前描述过的相同场景。

你第一次与客户坐在桌前定义产品。你可以这样开始对话：“我很高兴能与您合作，并期待这个项目启动。让我们整体谈谈您希望在产品中看到什么，我和我的团队将尽力为您提供创建它的最佳方案。”

就像之前一样，客户拿出了他们希望在产品中看到的功能列表。在对话结束时，你确定他们一半的功能涉及某种用户界面设计，另一半则涉及最终用户将如何使用产品来解决问题。

你们一致同意，最好首先解决这些最终用户的需求，并构建一个满足这些需求的界面。如果最终结果与之前设计的界面相同，那很好。但不要在需求中将自己限制在特定的设计里。

你可以通过客户的界面设计洞察用户需求，并据此添加更多需求。你和客户在离开会议时，都清楚地知道项目过程中可以期待什么。更重要的是，你知道对你和团队的期望是可管理的，因为你帮助定义了这些期望。

客户可能无法得到他们设计的同一个用户界面，但他们仍然会感到惊喜。他们确信你知道自己在做什么，并且理解他们的最终用户需求。更重要的是，他们现在将你视为一个协作、积极的领导者，而不是一个只会听从指示的人，即使那些指示不会带来最佳结果。

然而，不要轻易丢弃客户提出的用户界面设计或其他潜在的“想要”。虽然某个特定界面对于满足客户需求可能不是必需的，但它们对于讨论和发掘之前可能未被注意到的其他需求仍然非常有用。

让我们测试一下你的知识。以下哪一项不属于需求规格说明阶段的活动？

A. 启发需求
B. 收集需求
C. 表达需求
D. 管理需求

正确答案是 B. 收集需求。请记住，“收集需求”与“启发需求”的区别在于软件产品经理与客户的互动方式。启发需求是一项正确的活动，而非“收集需求”。

---

上一节我们介绍了如何启发需求，现在你刚刚弄清楚了客户需要什么以及你需要创建什么。那么，你如何以一种团队可以用来创建产品的方式来构建这些需求呢？这就是需求表达活动的核心。

需求启发是从“想要”中梳理出“需要”的行为。需求表达则是将这些“需要”转化为某种可用形式的行为。

大多数时候，你的需求最初是与客户进行需求征集会议时在记事本上记录的一系列草稿。它们通常过于简化且没有经过深思熟虑，但这没关系。毕竟，你只是刚开始与客户一起定义事物。这是一个好的开始，但有更好的方式来表达客户的需求。

这些需求可以表现为用例、用户故事、故事板以及许多其他表现形式。它们可以是文本的或图形的，详细的或简化的。不同的项目需要不同的表达方式。在本课程中，我们将涵盖许多这些表达方式。

---

现在你已经启发了客户的需求，并以团队可用的方式表达了它们。你拥有一个客户需要的大需求列表。接下来是什么？在Scrum中，下一步是对这些需求进行优先级排序。

这里的思路是，将这个大的列表进一步提炼成必须做的、应该做的和可以做的。一旦你以这种方式对需求进行了优先级排序，下一步就是计划和估算这些需求。

创建需求列表的另一项重要活动是分析它们，以确保它们是完整的、清晰的和一致的。你需要确保基于这些需求构建的产品能够满足客户的需求。你还需要确保你创建的所有需求能够很好地协同工作。你可能会遇到一些最初看起来能很好协同的需求，但经过进一步检查，实际上存在冲突。因此，通过分析你的需求，你可以确保它们准确地反映了你打算构建的产品。这也有助于确保产品能够尽可能做到最好。

Morgan和我将尽最大努力，通过持续评估和改进，确保你知道如何创建好的需求。

在Scrum中，当需求从客户那里被启发和表达出来，并放入一个大的列表（也称为产品待办事项列表）之后，下一步是什么？

A. 开发
B. 需求优先级排序
C. 产品架构设计
D. 进一步的需求启发

这里的正确答案是 B. 需求优先级排序。一旦你从客户那里启发并表达了所有需求，下一步就是让客户对需求进行优先级排序。

---

我要提到的创建良好需求的最后一项活动是管理它们。毕竟，需求很重要，你不想丢失它们。

每个需求都需要被开发人员从许多地方引用，比如他们的代码、测试和变更日志。当一个需求发生变化时，你需要知道它发生了，并理解对其他需求的影响。此外，你可能希望以不同的方式对需求进行分组和重组，可能在其他产品中复用需求的子集。这些方面都属于需求管理的范畴。

---

本节课中我们一起学习了，需求是对客户需求的具体描述，可以采取多种形式。处理需求有五个主要活动：启发、表达、优先级排序、分析和管理。

现在你已经了解了需求的基础知识和相关活动，我们准备进行更深入的探讨。在下一课中，我将告诉你不同类型的需求。

037：需求类型

在本节课中，我们将要学习软件产品管理中不同类型的需求。理解这些类型有助于我们更有效地收集、表达和管理需求，从而确保最终产品能够满足客户的真实需要。

在上一课中，我们讨论了什么是需求以及与之相关的不同活动。我们了解到，需求本质上是一种将客户需求转化为可执行产品方案的方式。我们还认识到，当开发团队与客户协作时，这些需求最容易获取和表达。

既然我们已经有了初步了解，现在让我们更深入地探讨一下。为了理解如何从需求中获得最大价值，我们必须了解软件产品可能需要的不同类型的需求。

当你想到“需求”这个词时，脑海中会浮现什么？或许你想到的是产品最终版本应包含的功能列表。或许你想到的是产品在不同情境下应如何表现的一系列描述。或者，你可能想到了产品为何应该存在的根本原因。

事实证明，所有这些都是有效的需求类型。它们共同描述了产品应该是什么样子、应该如何工作以及为何应该存在。让我们更详细地讨论这些。

业务需求

我们首先提到的需求类型，即产品为何被需要，被称为业务需求。

业务需求概述了软件项目的目的。它们为产品负责人提供了启动项目的根本理由。你可以将这些需求想象为与产品的实际开发是分开的。这些需求不仅仅是个人或道德层面的原因，例如“必须在市场上首发”或“必须被尽可能多的用户使用”。

一个业务需求必须定义能提供具体、可量化商业价值的产品需求。业务需求的一个例子是：“我需要这个产品吸引印度的服装设计师，以便每年增加5万美元的收入。”这就是一个业务需求。

你的客户在制定商业战略和计划时会使用业务需求。它们是业务分析师审视产品最终商业目标的一种方式。需要注意的是，业务需求也可能有其他名称。术语“业务需求”有时也用来描述我们将在本课后面讨论的其他需求。就我们的目的而言，业务需求仅指构成“产品为何应该存在”的那些需求。

业务规则

有时，业务需求的概念会与预算、政策或法规等词语相关联。这些是我们所称的业务规则的例子。

这些规则比业务需求更具体。业务规则约束了产品的功能。它们还规定了项目要被视为成功甚至合适所必须遵循的规则。

以下是业务规则的一些例子：

• 隐私政策：业务要求数据必须安全存储，并且不与不必要的人员共享。
• 品牌统一性要求：待开发的产品在视觉上必须与客户拥有的其他产品保持一致。
• 政府法规：例如，根据当地或国际法律，要求将用户数据及其任何操作信息保存特定时间。

所有这些都属于业务规则。它们概述了产品的一些限制。你可以将业务规则理解为规定了软件开发必须在哪些限制条件下进行。

我们刚刚讨论了两种需求类型：业务需求和业务规则。

假设你正在为一个需要计算销售税的发票产品制定需求。你正在创建的是哪种类型的需求？A. 业务需求，还是 B. 业务规则？

答案是 B，业务规则。征收销售税是政府对进行销售的公司提出的法律要求，它约束了与销售相关的产品。最佳答案是业务规则。业务需求更像是描述你最初为何要制作这个产品。

---

本节课中，我们一起学习了软件产品管理中两种基础的需求类型：业务需求和业务规则。业务需求定义了产品的根本目的和商业价值，回答了“为什么”要开发这个产品。而业务规则则规定了产品开发过程中必须遵守的具体约束和条件，例如法律、政策或内部标准。理解这两者的区别对于清晰定义项目范围和目标至关重要。在接下来的课程中，我们将继续探讨其他类型的需求。

038：客户需求与软件需求

概述

在本节课中，我们将要学习软件需求的不同类型，特别是用户需求。我们将了解用户需求是什么，为什么它们至关重要，以及如何以清晰、结构化的方式来表达它们。

---

上一节我们讨论了业务需求和业务规则，它们关注的是产品的整体存在原因和构建规则。本节中我们来看看与产品用户直接相关的需求类型。

用户需求

用户需求明确规定了用户能够使用产品完成哪些任务。用户是指最终会使用你软件的个人，因此他们常被称为“最终用户”。由于最终用户对产品的成功至关重要，通常需要花费大量时间来制定这些需求。

事实上，用户需求很可能是开发团队最需要正确把握的需求。因为这些需求定义了最终用户如何与产品互动，定义了产品应为用户做什么。它们可以被视为正在开发产品的核心功能。

在本课程后面，我们将花时间讨论如何恰当地获取用户需求，并将其转化为具体的、可操作的开发任务。我们还将讨论如何创建好的用户需求，以及表达它们的一些不同方式。

所以，用户需求就是用户能用你的产品完成的任务。

以下是表达用户需求的两种常见方式：

1. 用例
   用例是展示系统与用户之间关系的好方法。我们将在下一个模块中更详细地介绍它们。请注意，在用例中，我们具体展示了不同的用户场景以及他们与系统交互的方式。

2. 用户故事
   用户故事的一般结构是：作为一个 <角色>，我想要 <功能>，以便于 <价值>。
   这种结构允许我们以确保首先考虑用户需求的方式来表述需求。例如：作为一名软件产品经理，我想要创建用户故事，以便于我能更好地表达客户的需求。

---

然而，客户需求通常以这种形式出现：“客户应该能够在系统中查看和支付账单。” 需求常常以模糊、非具体的术语给出。这当然不是客户的错，但这是软件产品经理必须解决的一个常见障碍，以确保他们的开发团队知道如何最好地构建产品。

对我而言，这是软件产品管理中最有回报的方面之一。能够将客户的需求提炼成具体、实在的东西，通常会带来一种满足感和条理性，就像一切都各归其位。

---

知识检查

以下哪项代表了用户故事的基本形式？
A. 作为一个 <角色>，我想要 <功能>。
B. 作为一个 <角色>，我想要 <功能>，因为 <原因>。
C. 我想要 <功能>，以便于 <价值>。
D. 作为一个 <角色>，我想要 <功能>，以便于 <价值>。

正确答案是 D：作为一个 <角色>，我想要 <功能>，以便于 <价值>。它遵循这种形式，以确保我们捕捉到需求的“谁”（角色）、“什么”（功能）和“为什么”（价值）。

---

总结

本节课中我们一起学习了用户需求。我们了解到用户需求定义了最终用户能够用产品做什么，是产品的核心功能。我们探讨了表达用户需求的两种主要方式：用例和用户故事，并重点掌握了用户故事“作为一个...，我想要...，以便于...”的标准结构。理解并清晰定义用户需求，是将模糊的客户需求转化为可执行开发任务的关键一步。

039：功能需求 🔧

在本节课中，我们将要学习一种由开发团队负责的需求类型——功能需求。我们将了解它的定义、如何描述它，并通过实例来加深理解。

---

功能需求的定义

上一节我们介绍了需求的不同类型，本节中我们来看看功能需求。

功能需求是指产品应该执行或支持的行为。它们可以通过输入、输出以及对行为本身的描述来表达。

---

一个简单的例子

想象一个场景：客户向你提出一个项目构想。他们想要一个移动销售点产品，该产品能通过客户专有的信用卡读卡器接收信用卡付款，然后向用户发送包含交易详情的收据。客户还提到，该产品应满足最高的安全和视觉设计标准。

请记住，功能需求涉及输入和输出。在这个简单的例子中，我们有一个输入（来自信用卡读卡器的数据）和一个输出（交易收据）。因此，你可以说：系统必须从信用卡读卡器读取数据，并且系统还必须向最终用户发送交易收据。

请注意，为了简化，我们省略了相当多的功能需求。你可能会想到，系统应该接收来自商家的交易信息作为输入。然后，经过某些确认操作，系统应向买家展示交易信息，并最终获取他们的PIN码信息。在这个例子范围内，你可以想到相当多的功能需求。

---

需求的深度

需求本身也具有一定的深度。一个声明“用户应能使用密码键盘支付”的功能需求并不具体。这可以分解为几个更深入、更具体的要求，例如：

• 用户应能刷卡（借记卡或信用卡）。
• 用户应能将信用卡或借记卡插入芯片读卡器。
• 当卡片被刷卡或插入时，用户将能够输入其PIN码。

如果你不够具体，可能会导致规划中的问题。你可能以为自己要做的工作很少，但实际上却有很多。关于这一点，我将在本课程后面更详细地探讨，现在只需意识到需求具有深度即可。

---

如何表示功能需求

表示功能需求的一种方法是使用信息流图，如下图所示。

信息流图为你提供了一种图形化方式来显示系统所有组件的数据流和依赖关系。基本上，它展示了系统的各个组件是如何连接在一起的，让你了解系统作为一个整体是如何运作的。信息流图提供了你可以逻辑地审查整个系统的上下文。

如果你想了解更多关于信息流图的信息，请查看课程资源。

---

练习：识别功能输入与输出

想象一个场景：你正在建立一个非营利组织，为社区中的低收入通勤者翻新自行车。你从捐赠者那里收到铝制自行车以及用于购买工具的资金。然后，你使用这些东西让自行车重新工作，并将它们交付给你的客户。

以下哪一项应被视为该组织的功能输入和输出？

A. 输入：捐赠的自行车和购买的工具；输出：客户。
B. 输入：捐赠的资金；输出：可工作的自行车。
C. 输入：捐赠的资金和自行车；输出：可工作的自行车。
D. 输入：自行车中的铝材和捐赠的资金；输出：可工作的自行车。

答案是 C。该组织接收资金和自行车，然后进行维修并交付给客户。输入是捐赠的自行车和资金，因为工具是使用捐赠的资金购买的。这些工具是用于修复自行车的过程的一部分。

---

总结

本节课中我们一起学习了功能需求。我们了解到功能需求描述了产品应执行或支持的具体行为，通常通过输入、输出和行为描述来定义。我们通过移动支付和自行车翻新组织的例子，练习了如何识别功能需求及其输入输出。同时，我们认识到需求具有深度，需要具体化以避免规划问题，并简要介绍了使用信息流图来表示功能需求的方法。

040：非功能性需求 🎯

在本节课中，我们将要学习软件需求中的另一个核心类别：非功能性需求。我们将通过具体例子来理解什么是非功能性需求，以及它与功能性需求有何不同。

上一节我们介绍了功能性需求，本节中我们来看看非功能性需求。

我们以移动销售点系统为例，回顾了客户提出的功能性需求。客户还提到，该产品应满足最高的安全标准和视觉设计标准。这最后一部分，关于产品满足最高安全标准和视觉设计的要求，就是我们所说的非功能性需求。

非功能性需求用于描述产品必须达到的性能水平。你可以将非功能性需求视为对功能性需求的补充。如果说功能性需求定义了产品应该做什么，那么非功能性需求则定义了产品应该做得多好。非功能性需求实际上关注的是产品的质量因素，因此有时它们也被称为质量需求。

以下是几种常见的非功能性需求类型及其示例：

准确性需求
假设客户希望你构建一个驾驶辅助系统。该系统能感知用户车辆与前车之间的距离，并在距离过近时自动刹车。该系统的一个非功能性需求就是传感器必须达到极高的精度。仅仅说“系统应读取距离并在达到阈值时刹车”是不够的。因为如果系统精度存在中等偏差，结果可能是灾难性的。因此，准确性和安全性要求是非功能性需求。

可靠性需求
考虑一个客户希望创建一个存储重要文档的数据库系统。该系统需要能够从灾难中恢复，以避免数据丢失。像这样的可靠性要求是非功能性需求。

安全性需求
如果这个数据库存储的是包含用户个人信息的敏感文档，那么让系统处于不安全、易受攻击的状态可能是不明智的。在这种情况下，你需要为信息建立强加密，并使整个系统难以被攻破。这些安全要求是非功能性需求。

可用性需求
以一个简单的网站邮箱注册表单为例。你可能见过这样的表单，它会检查用户邮箱的有效性，以最大程度减少拼写错误的风险。如果没有这种错误检查，许多邮件可能无法送达预期收件人。注册表单是否易于导航和填写？表单上应该有标签指示姓名应填写的位置，以防止信息填错。这两个要求——错误预防和易用性/可学习性——当然也是非功能性需求，它们也被称为可用性需求。

效率需求
假设客户希望你开发一款水下研究设备，该设备由电池供电。它必须足够小巧轻便，以便存放在小船上，同时又必须足够高效，能提供至少数小时的水下续航。其所有仪器必须能够实时、无延迟地执行功能。并且其电池应能快速充电。所有这些关于空间、功耗、时间和资源的要求，都是以效率为中心的非功能性需求。

性能需求
性能要求也是非功能性需求。性能需求的例子包括：系统需要维持特定的响应时间，或在短时间内处理特定数量的请求。

可维护性需求
想象一下，客户希望你开发一款软件，它能查询本地餐厅数据库并将其标注在地图上以便导航。客户还提到，他们设想未来将此软件扩展到另一个产品中，最终希望产品能标注其他地点，如纪念碑和旅游景点，并且当输入一个地点时，它应该能显示在地图上。要求软件足够灵活，能够扩展超出原始用途，这就是一个可维护性需求。这同样是非功能性需求。

由此可见，非功能性需求在软件规划中也占据了很大一部分。

让我们快速回顾一下我们提到的非功能性需求类型：准确性、可靠性、安全性、可用性、效率、性能和可维护性。

---

练习题 ✍️

飞机每天从加拿大温哥华国际机场飞往中国上海浦东国际机场。这些飞机必须遵守航班时刻表，其航程受所携带燃油量的限制。

以下哪项是飞机从YVR飞往PVG的非功能性需求？

A. 必须消耗航空燃油。
B. 航班时刻表不得延误。
C. 必须能够单箱燃油完成YVR到PVG的飞行。
D. 满载乘客必须在不超过90秒内完成撤离。

C和D是正确答案。它们分别是性能和非功能性可用性需求。其他两个答案不是非功能性需求：A涉及飞机的输入（燃料类型），B涉及航班时刻表，与飞机本身的性能或质量无关。

---

本节课中我们一起学习了非功能性需求的概念及其多种类型。我们了解到，非功能性需求关注的是产品的“质量”和“表现”，它定义了系统运行的好坏程度，是功能性需求的重要补充，共同构成了完整的软件需求规格。

041：客户需求与软件需求

概述

在本节课中，我们将学习软件需求的不同类型，特别是外部接口、物理环境设置和开发约束这三种补充性需求。理解这些需求有助于我们更全面地定义产品，并为其设计和实现提供必要的上下文。

---

外部接口需求 🖇️

上一节我们介绍了用户、功能和非功能等核心需求类型，本节中我们来看看外部接口需求。

这种需求背后的概念很简单。通常，你的产品属于一个更大的系统。外部接口需求旨在勾勒出产品所处的位置。这里指的不是物理位置，而是指产品在逻辑上如何与产品外部的其他实体相关联。

这些接口还描述了通过何种媒介、协议、格式和兼容性级别来建立这些连接。简而言之，外部接口展示了产品本身如何与系统中的其他部分产生联系。

假设你有一个向最终用户显示信息并访问远程数据库的软件应用程序。该应用程序位于数据库和最终用户之间，并与两者各有一个外部接口。这些外部接口指明了应用程序与数据库交互所需的协议，以及信息应如何呈现给用户。

外部接口通常在数据流图上标识。数据流图在一个地方显示产品的所有组件，并明确展示在整个系统中数据如何与外部实体进行传递。

因此，外部接口只是对产品在整个系统内其他实体间的逻辑位置的一种描述。不要将外部接口与产品的物理位置混淆，后者实际上是一种单独的需求类型，称为产品的物理环境设置。

以下是外部接口需求的一个示例：

• 产品必须能够与客户数据库和广告服务器通信。

---

物理环境设置需求 🌡️

了解了产品如何与外界连接后，接下来我们需要考虑产品所处的物理环境。

物理环境设置需求描述了产品应如何围绕其物理环境进行设计。例如，如果你要为撒哈拉沙漠的建筑设备开发一个GPS追踪器，你会希望确保它能承受极端高温、灰尘、噪音和振动。如果你是为南极洲的应用开发这个系统，那么你会希望产品能承受极端寒冷。所有这些都是在指定物理环境设置需求时需要考虑的因素。

以下是物理环境设置需求的示例：

• 产品必须能够承受从不少于50米的高度跌落造成的冲击。
• 产品必须能够承受每天10小时的阳光直射。

---

开发约束 🛠️

在指定了之前讨论的所有需求之后，你的开发团队是否有能力创造出你设计的产品？知道这个问题的答案非常重要。

开发约束概述了实现技术、约定、文档以及你的团队将使用的流程。它们也可能涉及开发团队将支持哪些设备或平台，或者他们在内存、带宽或处理能力方面受到的使用限制。

通常最好在规范阶段的后期再指定这些约束，这样产品的愿景就不会被现有技术所限制。技术在进步，产品也应如此。最后讨论开发约束，可以避免你过早地使用旧技术和能力进行设计。

以下是开发约束的示例：

• 产品必须能够在电池供电下持续运行六小时。

---

课程总结

本节课中，我们一起学习了用于表达客户需求的不同需求类型。让我们回顾一下：

1. 首先，我们讨论了可能影响你项目的需求类型，即业务需求和业务规则。
2. 然后，我们讨论了几种核心需求类型，即用户需求、功能需求和非功能需求。
3. 最后，我们讨论了几种为产品的最终设计和实现提供额外上下文的需求，即外部接口、物理环境设置和开发约束。

接下来，我们将讨论如何管理不断变化的需求并控制产品范围。

042：控制范围

概述

在本节课中，我们将要学习软件项目中与需求相关的挑战，特别是如何定义和维护需求集。我们将探讨产品愿景与范围的概念，并学习如何有效控制项目范围，防止其失控。

课程内容

上一节我们介绍了不同类型的需求及其示例。既然我们已经了解了各种需求类型，本节中我们来看看与形成和维护需求集相关的一些挑战。

定义需求时，投入时间并保持谨慎非常重要。同时，认识到需求在整个开发过程中不可能保持稳定，这一点同样重要。需求必然会发生变化。当我们接受这一点时，就能更好地应对这些变化。

根据软件工程领域的知名专家罗伯特·格拉斯所述，软件项目失控的两个最常见原因之一就是需求不稳定。许多项目经理会遇到这种情况：开发团队开始根据一组特定需求进行工作，但在项目进行到一半时，客户改变了主意。突然间，开发团队不得不中途改变工作重点。

在这种常见的情况下，你该怎么办？如果开发团队每次客户提出变更就改变方向，项目很快就会失控。这会造成大量的开发任务积压，并降低产品质量。不仅如此，开发团队的士气也会一落千丈。然而，如果产品团队坚持原计划不做任何调整，最终产品很可能无法满足客户需求。这将浪费开发团队的时间和客户的资金。

我们需要在这两个极端之间找到一个平衡点，本课程将帮助你找到它。

让我们从产品创意最初诞生时开始。产品的初衷是什么？客户想要解决什么问题？这就是产品愿景。软件工程领域的作家兼顾问卡尔·维格斯将产品愿景描述为“一个新系统最终目的和形态的长期战略概念”。基本上，产品愿景概述了产品对客户的价值及其在市场竞争对手中的地位。

愿景与你的产品有什么关系？请将产品愿景视为产品的指导原则。无论产品发生什么变化，产品的设计仍应支持其愿景。然而，这并不意味着产品愿景总是现实可实现的。

让我用一个例子来解释。想象一下，一位客户带着一个手机游戏项目找到你。根据需求，你和你的开发团队估计需要三个月时间。你收到的产品愿景是：通过模拟项目经理的视角来管理项目，创造一种独特的沉浸式游戏体验。

现在，假设开发进行了一个月，一切进展顺利，这时你的客户找到你。他们告诉你，由于虚拟现实技术最近取得了进步，他们希望开始为虚拟现实平台进行开发。从技术上讲，切换平台可以让你遵循产品最初的愿景。然而，这种转变意味着产品和开发资源的重大调整，因此并不现实可行。我们将客户要求的这种转变称为范围变更。

在之前的场景中，客户通过建议你切换平台来改变了范围。以下哪种情况会构成愿景的改变？A. 客户选择转向移动游戏而非虚拟现实。B. 你的开发团队决定更改一些产品实现细节。C. 你的项目超出预算，被迫暂停。D. 你的客户决定产品不再是一款关于项目管理的手机游戏，而是选择创建一个允许客户设计定制家具的应用程序。

答案是D。当你的客户选择创建一个具有完全不同指导原则的产品时，他们就是在改变愿景。通过选择制作一个家具设计应用程序，而不是一个关于项目管理的游戏，产品的愿景已经改变。

范围和愿景是相互关联的。愿景涵盖了产品最终将做什么来满足用户需求，而范围则涵盖了在当前项目中现实可以实现的内容。虽然客户的总体产品目的没有改变，但对开发人员的要求已经改变。因此，范围对开发团队及其产品经理的影响最大。所以，当我们考虑软件产品时，范围是需要考虑的最重要的事情之一。

让我们再次引用卡尔·维格斯的话：“范围划定了项目中包含什么和不包含什么的界限。” 好的，很简单。范围告诉你你将做什么和不做什么。但是，你如何决定这对一个特定项目意味着什么？我们又如何确保保持在范围内？

最好的起点是在项目的需求获取阶段。与你的客户讨论对产品的期望。如果你避免过度承诺产品的功能，就可以避免日后让客户和开发团队失望。

想一想。你告诉客户你能开发什么，并且你可以在三个月内完成。但进行到一半时，你意识到你根本无法交付那个产品。考虑到客户期望你能够交付一个完整的产品，你认为他们会说什么？如果你想维持满意的客户，这不是正确的方法。

最好尽早管理客户的期望，以避免导致失望的情况。实现这一点的一种方法是，识别用户可能期望但从当前项目中排除的产品功能。

例如，假设你正在为一个乐队创建一个网站。网站用户可能期望能够与其他粉丝发送消息和购买音乐会门票。然而，如果你认为在截止日期前，你的团队没有足够时间实现这些功能，那么完全可以向客户说明这一点。通过这种方式，你可以管理期望，并帮助确保项目结束后没有人感到失望。

管理期望听起来不错，但我们具体该怎么做呢？让我们谈谈一些防止范围蔓延的技术。顺便说一下，范围蔓延是指产品需求不断累积的情况。未加管理的范围蔓延会随着时间的推移显著降低项目成功的可能性。

在我们介绍防御范围蔓延的不同方法之前，你认为以下哪些是防御范围蔓延的方法？A. 让客户对需求进行优先级排序。B. 明确期望。C. 与客户划定范围。D. 询问“这在范围内吗？”。

实际上，所有这些答案都是正确的。所有这些技术都是有效的，尤其是当它们结合使用时。

以下是防御范围蔓延的技术：

首先，明确客户与你之间的期望。也就是说，确保每件事都有明确的开始和结束日期，并尽可能遵守。

其次，与客户划定范围。使用用例图来展示不同用户角色之间的预期交互以及产品支持的任务，并围绕此进行设计。

第三，确保客户对需求进行优先级排序。当客户明确哪些需求价值最高时，就很容易确保产品最重要的部分得到优先开发。这样，即使项目时间或资金减少，你仍然满足了关键需求。

第四，在形成需求时，询问“这在范围内吗？”这个问题。很容易忽视在细化不必要需求上浪费的时间。如果你强迫自己询问每个需求的相关性，就可以确定当前项目中包含什么，并为未来的版本记录功能。

第五，在制定需求时，估算完成每个需求所需的工作量也很重要。随着你和你的开发人员在构建产品方面经验越来越丰富，这会变得更容易。随着时间的推移，你可以发现团队的平均生产率，并以此为基础进行估算。

第六，当你估算完成产品需求所需的工作量时，你可以将估算值相加，看看是否能满足截止日期。这有助于你决定一个需求是否现实可行。

第七，当对产品提出变更时，花时间评估该变更的影响。它将如何影响你的人员资源、资金、产品质量、时间表和成功的可能性？在考虑变更时，所有这些因素都会起作用。当然，当变更被接受时，你应该修改你的估算和计划以反映变更。

理解了这一点，很容易为了简单起见而过度反应，拒绝所有提议的变更。变更的引入通常是为了增加项目的商业成功机会。逐个评估每个变更，并根据具体情况做出决定，将使你能够自由地扩展产品，同时最大限度地提高其成功的机会。这也是敏捷宣言的核心原则之一。

总结

本节课中我们一起学习了以下内容：首先，我们定义了什么是愿景以及它与软件项目的关系。然后，我们定义了什么是范围以及它如何可能失控。接着，我们讨论了通过以下方式避免范围蔓延的技术：管理期望、划定产品边界、设定优先级、询问“这在范围内吗？”、进行估算以及评估提议变更的影响。

在下一课中，我们将讨论设计中的需求。我们下节课见。

043：客户需求与软件需求

概述

在本节课中，我们将要学习软件项目中“需求”与“设计”的区别，以及为何清晰地区分两者对项目成功至关重要。我们将探讨过早引入设计决策可能带来的问题，并提供如何保持需求纯粹性的实用建议。

需求与设计的区别

上一节我们讨论了需求变更如何导致范围蔓延。本节中，我们来看看需求与设计有何不同，以及这对软件项目意味着什么。

在形成一组需求与设计一个产品之间，存在一个模糊的边界。通常，需求强调产品的 “是什么”。即，我的客户需要我开发什么，产品才能成功？而设计则强调产品的 “如何实现”。即，开发团队将如何实现产品以满足客户的需求？

如果你没有学习过《软件过程与敏捷实践》课程，可以跳过这个测验。

在哪个软件开发过程模型中，需求和设计是两个完全独立的阶段？
A. 锯齿模型
B. 螺旋模型
C. 统一过程模型
D. V模型
E. 瀑布模型

在瀑布模型中，需求和设计是完全独立的活动。根据这个模型，需求在产品设计之前独立制定，以确保需求不受设计限制的约束。也就是说，这里的需求只关注问题本身，而不涉及解决方案。

现代开发中的模糊边界

在现代迭代和并行开发过程中，开发团队通常会同时处理需求和设计。开发团队在构思需求时考虑到设计元素是非常普遍的。此外，客户也可能带着期望的设计特性来设想他们的产品，而不是关注他们真正的问题或需求。这就是为什么需求和设计经常被结合或混淆。

例如，理解产品的一个简单方法是将你的需求置于产品草图的背景中。这可以帮助你规划需求的正确性、一致性和清晰度。一旦你的需求以这种视觉方式放在一起，就很容易看出它们是否作为一个逻辑整体组合在一起。

模糊这个边界是可以的。然而，要注意不要让这个概念走得太远。

过早设计的风险

如果你过早地关注设计解决方案，最终可能会无意中忽略根本需求，并对你的产品施加不必要的约束。

例如，假设你的任务是开发一个在用户设备上运行并与远程服务器交互的应用程序。如果你的需求规定“产品应使用Java编程语言编写”，那么你就是在对开发团队施加不必要的设计约束。如果编写一个Web应用程序并使用不同的编程语言更有意义呢？本质上，你不希望仅仅因为当时看起来最好，就过早地为产品做出设计决策。

这个原则可以扩展到超越编程语言等总体设计原则的层面。

请看这个例子，看看你能否找出这个需求有什么问题。你的客户说，他们希望用户点击“确定”来提交请求。给你一个提示：如果产品界面只使用物理按钮进行输入呢？

识别并避免设计渗入需求

这些小的设计影响可能很棘手。在这个例子中，客户对产品施加了一个“点击”要求。他们本质上是在说，用户必须使用非常特定的输入设备来控制如何进行选择。如果你将这个需求应用到移动设备上，这个术语并不能完美地转化。在那种情况下，他们可能是“点击”按钮，而不是“单击”它。更好的说法是类似“用户提交请求”。

在制定需求时，请记住以下问题：

• 解决方案只是一种可能的选择吗？
• 解决方案是唯一可能的吗？
• 解决方案是否针对了错误的问题？
• 解决方案只是为了吸引开发者的兴趣吗？
• 客户是否更关注解决方案？

当你在构思产品时思考这些问题，你的产品质量将真正得到提高。

总结

本节课中，我们一起学习了设计如何以不良方式渗入需求。现在你知道了这种情况是如何发生的，你就能更好地避免它。在构建需求时，要时刻注意如何避免过早地对产品施加特定的设计解决方案。

这就是本节课，也是本模块的全部内容。希望我对什么是需求、为什么需要需求，以及在创建需求时需要考虑的一些事情，给了你一个清晰的认识。在下一个模块中，Morgan将与你讨论如何获取和表达用户需求。祝你学习愉快。😊

044：课程概述与客户介绍

在本节课中，我们将学习如何将客户的需求转化为具体的软件需求。我们将通过一个贯穿整个课程的连贯示例，来展示需求活动从开始到结束的完整过程。

客户介绍与项目背景

现在，你已经认识了你的客户并听取了他的初步构想，让我们开始构建一些需求。

以下是客户Jamie的自我介绍与项目初步想法：

• Jamie是一家名为Brampton‘s Pizza and Pasta的家庭连锁餐厅的高管。
• 他们希望为旗下餐厅开发一套内部使用的软件。
• 项目的核心目标是使餐厅的点餐流程更加高效。

客户的初步需求

上一节我们介绍了客户的基本情况，本节中我们来看看客户提出的具体想法。

以下是Jamie描述的系统应具备的功能：

• 顾客应能查看所在餐厅的菜单。
• 顾客准备好后可以下单。
• 应有一个儿童页面，展示儿童菜单，可能包含一些游戏，但最重要的是易于使用，让儿童可以自己下单。
• 顾客应能指定对餐点的任何修改要求。
• 顾客在向厨房提交订单前，应能列出他们可能有的任何饮食限制。
• 厨房应能查看实时进来的订单。
• 顾客应能在系统内查看并支付账单。

本节课中我们一起学习了客户Jamie的背景及其对餐厅点餐系统的初步构想。这些想法是我们后续进行需求分析、细化并最终形成软件需求文档的起点。在接下来的课程中，我们将逐步把这些想法转化为清晰、可执行的需求。

045：客户需求与软件需求

🧑‍💻 课程概述

在本节课中，我们将要学习软件开发过程中一个至关重要的环节：用户考量。我们将探讨谁是产品的最终使用者，以及如何通过理解不同用户的角色和需求来构建成功的产品。

---

👥 核心概念：用户与利益相关者

开发软件时，最重要的事情之一是考虑最终用户。你为谁制作这个产品？谁将使用这个产品？你可能开发出自己认为有史以来最棒的产品，但如果用户不喜欢这个产品，或者他们无法操作这个产品，那么它就会失败。

在科技行业尤其如此，用户拥有众多选择。如果市场上存在一个对最终用户来说更容易使用的类似产品，他们就会选择那个产品。想想市场上所有的任务管理应用程序。花点时间在你手机的应用商店里搜索“任务管理器”。有成千上万种不同的应用，有些很棒，有些很糟糕。但正如你所见，用户有选择权，如果他们不喜欢某个应用，就会转向下一个。

对于网络应用来说，这一点或许更为关键。竞争对手仅需一次点击即可访问，无需下载和安装新的应用程序。由此可见，时刻牢记你的最终用户非常重要。这就是我们本节课要讨论的内容。

在开发产品时，你必须考虑哪些用户方面？首先，让我们回顾一下我将要使用的一些术语。

• 最终用户或用户：指任何将直接使用产品的人。
• 利益相关者：指任何受项目成功影响或对项目成功有影响的人。这包括最终用户，但也包括其他人，例如客户、最终用户的管理员和系统管理员。
• 用户界面：指最终用户将与之交互的任何东西。以一个应用程序为例，后台有许多东西在运作以使其正常运行，但这些都不是用户界面。用户界面是你在使用应用程序时能看到的一切，例如窗口、按钮、滚动条、复选框和文本框等元素共同构成了用户界面。

---

🔍 深入解析利益相关者

上一节我们介绍了用户和利益相关者的基本概念，本节中我们来看看利益相关者的具体分类。利益相关者通常被分为三类用户：主要用户、次要用户或三级用户。

• 主要用户：指实际使用产品的人。我们将主要用户称为最终用户。
• 次要用户：指偶尔使用产品或通过中介使用产品的人。
• 三级用户：指受产品使用影响或对产品做出决策的人。

让我们看一个次要用户的例子。在我们的餐厅点餐系统示例中，服务员可以被视为次要用户。他们不是产品的目标用户，但他们必须具备产品的工作知识以便协助顾客。他们也可能使用应用程序来帮助顾客点餐。

你的客户将是三级用户。让我们再看一下我们的例子，特别是针对4至12岁儿童的儿童友好页面。客户指定此页面应显示儿童菜单，包含可玩的游戏，并且简单到足以让儿童自己选择食物。对于这个页面，儿童是主要用户，因为他们是页面的预期使用者。儿童的监护人将是次要用户。监护人需要知道页面如何运作，以便他们可以帮助孩子，但他们可能大部分时间不会使用这个页面。你的客户杰米是三级用户，但餐厅老板也是三级用户，因为应用程序的成功与否会影响他们。

成功的产品会考虑到所有利益相关者的需求。

让我们更详细地看看我们的儿童菜单例子。如果主要用户（儿童）无法弄清楚如何使用菜单，他们就会失去兴趣。儿童的注意力持续时间不是很长，所以你必须迅速吸引他们。如果食物选择不适合儿童，或者如果儿童能够选择不止一份餐点，那么监护人（次要用户）可能就不会允许孩子使用该应用程序。如果应用程序太难使用并影响了餐厅老板的生意，那么他们就不会满意并拒绝该产品。

---

💡 案例分析：美发沙龙预约系统

为了加深理解，我们来看另一个利益相关者的例子。你为一家美发沙龙制作了一个在线预约系统。该系统由沙龙老板请求并资助。该系统允许沙龙的顾客致电或到访，并由接待员在系统上为他们预约。顾客也可以选择创建一个在线账户，并通过沙龙的网站自行预约。发型师也可以请接待员查看他们在特定日期是否有预约。

那么，谁是这个系统的主要用户（如果有的话）？A. 沙龙老板；B. 接待员；C. 顾客；D. 发型师。

以下是分析：

• 由于沙龙老板请求并资助了该系统，他们是客户和三级用户。
• 发型师通过中介（接待员）使用系统，所以他们是次要用户。
• 当顾客致电沙龙并让接待员为他们预约时，顾客也可以被视为次要用户。
• 接待员和顾客都直接访问系统。如果他们定期使用它，那么他们都是主要用户。

因此，正确答案是 B 和 C。

---

📝 课程总结

本节课中，我们一起学习了在软件开发中考虑用户的重要性。我们定义了最终用户、利益相关者和用户界面等核心术语，并详细分析了主要用户、次要用户和三级用户这三类利益相关者。通过餐厅儿童菜单和美发沙龙预约系统的例子，我们明白了成功的产品必须平衡并满足所有利益相关者的需求，尤其是直接使用产品的主要用户。牢记这一点，是避免产品失败、在竞争激烈的市场中脱颖而出的关键。

046：13_02_3-2-2a-用户考量

在本节课中，我们将学习如何根据已确定的目标用户群体，来调整和设计产品以满足他们的特定需求。我们将探讨人类与计算机交互的基础概念，并分析在面向不同用户群体（如儿童和老年人）进行开发时需要考虑的关键因素。

明确主要受众

上一节我们确定了产品的目标用户。本节中我们来看看如何根据主要受众的需求来定制产品。

识别产品的主要受众至关重要。这有助于我们根据用户的导航和功能需求来量身定制产品的设计。

以儿童菜单为例，我们的主要用户是儿童。有许多方法可以使产品迎合儿童，例如使用鲜艳的色彩、图像和声音。

人机交互基础

研究最终用户如何与技术产品互动的学科被称为人机交互。HCI本身可以是一门课程。我们将介绍一些基础知识，但如果你对此感兴趣，建议你进一步研究。这是一个非常引人入胜的计算领域。

以下是关于面向最终用户开发的一些挑战：

• 用户难以表达需求：用户通常很难说出他们需要什么，但他们往往会告诉你他们不喜欢什么。这通常源于他们不了解软件的可能性。
• 开发者需要创新：开发者必须创造性地思考，以开发出新颖、有吸引力的产品。
• 用户的习惯偏见：用户通常更习惯使用他们知道如何操作的劣质产品，而不是对他们来说是新的、更优质的产品。

这引出一个问题：我们在这里试图做什么？为什么我们要为那些只会使用旧产品的客户开发新产品？这就是为什么开发用户友好、直观的用户界面如此重要。它鼓励用户走出他们的舒适区。但这只有在产品易于学习和使用的情况下才有效。

开发者的视角

创建直观、用户友好的产品是开发者经常面临的一个挑战。

你可能已经注意到，工程师、科学家和程序员并不能代表主流人群。开发者不像普通最终用户那样思考。对开发者来说完全合理的事情，对外行人来说可能毫无意义。开发者可能优先考虑后端技术的先进性，因此有时他们很难为更广泛的人群设计出直观的产品。

作为软件产品经理，理解用户的思维方式非常重要。有一种建议认为，为初学者和专家这两个极端进行设计是理想的。如果你能做到这一点，中间群体往往就能自行适应。

当你与开发者一起设计产品或测试产品时，请牢记最终用户：他们能够理解这个产品是如何工作的吗？

案例分析：为老年人设计应用

现在，让我们通过一个案例来具体应用这些考量。

一个代表患有糖尿病的老年人的协会联系你的团队，希望开发一款移动应用程序，让老年人能够追踪他们的血糖水平。协会代表明确指出，用户年龄将在65岁以上。此外，应用程序必须足够简单，无需协助即可使用。

为了更好适应其最终用户，你可以为产品添加哪些功能？A. 语音命令，B. 多层菜单，C. 大号文字，和/或 D. 音频提醒。

为老年人开发可能很困难。他们的感官可能不太好，这可能限制他们能做的事情。由于他们不是在技术时代长大的，他们的技术技能往往不太先进；因此，一个拥有多层菜单的产品可能让他们难以操作。

添加语音命令和大号文字等功能是适应老年最终用户的好方法。语音命令帮助那些无法在小键盘上打字的人，大号文字则更易于阅读。为他们设置提醒将是一个很棒的功能，然而，你可能希望通过多种模式（不仅仅是音频）进行通知。例如，让手机发出声音、在屏幕上显示弹出窗口并振动。这将引起大多数用户的注意。因此，最佳答案是A和C。

更多人类限制因素

本节课中我们一起学习了如何根据主要用户群体定制产品，探讨了人机交互的基本概念以及开发者与用户在思维上的差异，并通过一个为老年人设计应用的案例进行了实践分析。理解并适应最终用户的能力和限制，是创造成功软件产品的关键。

047：客户需求与软件需求

概述

在本节课中，我们将要学习在软件设计过程中需要考虑的用户限制。理解这些限制有助于我们开发出更包容、更易用的产品。

人类存在许多限制。我们阅读速度有限，奔跑距离有限，玩电子游戏的时间也有限。

许多人类特征会限制用户使用产品的能力。设计软件时，考虑这些限制非常重要。优秀的软件产品会适应其目标用户。

人类限制的一些例子包括：感知限制、身体限制、认知限制和文化限制。

感知限制

上一节我们介绍了人类限制的几种类型，本节中我们首先来看看感知限制。

我们五种感官的约束影响了我们感知周围环境的能力。因此，我们的感知限制就是那些受我们感官约束的限制。感知限制有时也被称为感官限制。许多感知限制会影响人们与技术交互的方式。

以下是感知限制的一些常见例子：

• 色盲：约4.5%的人口有色盲。约8%的男性有色盲，而女性只有0.5%。色盲人士难以区分某些颜色，因此彩色图像在他们看来可能不同。从开发角度看，适应色盲的最佳方法是增加产品的对比度。使用浅色背景配深色文字（或反之），不仅能适应色盲，还能适应大多数视觉限制。你也可以通过不同类型的色盲模拟来测试配色方案是否可接受。许多UI库和图形设计工具支持此功能。
• 其他感官限制：我们可以开设一整门课程来讲解如何为感知限制进行设计。例子包括使用视觉提示或振动来适应听觉限制。

身体限制

接下来，我们谈谈身体限制。这指的是任何影响用户与产品进行物理交互的因素。

以下是身体限制的一些例子：

• 儿童与成人差异：为儿童专门设计的产品应考虑他们较低的操作灵活性、较矮的身高和较小的手。他们需要能够触及和抓握的大按钮和大控件。
• 左撇子与右撇子：你可以通过提供左手操作选项使产品更友好。许多界面为方便右撇子使用而设计，将大部分按钮和菜单放在右侧，便于右手拇指点击。你可以设计一个选项，将按钮和菜单放在屏幕左侧，从而使产品易于左撇子用户使用。

现在，让我们通过一个例子来巩固理解。霍华德开发了一款在移动设备上玩的游戏。游戏要求用户在彩色圆圈消失前点击它们。当圆圈即将消失时，游戏音乐会加速。点击圆圈时手机会振动。他收到的游戏反馈大多是正面的，但也有几条关于可用性的抱怨。

以下是这些抱怨，哪一条代表了身体限制？

A. 我看不清一些圆圈，因为圆圈和背景颜色太相似了。
B. 我听力有限，感觉处于劣势，因为我听不清音乐。
C. 我讨厌按下气泡时手机振动，这真的很烦人。
D. 我只能玩一会儿游戏，手就累了。

答案分析：答案A、B和C都代表了感知限制，因为它们与感官交互有关。答案A是视觉限制，答案B是听觉限制，答案C是触觉限制。答案D是正确的，因为它代表了身体限制。用户无法长时间进行物理交互而不感到疲劳。

认知限制

现在，我们来探讨认知限制。认知限制通常基于记忆限制。

例如，识别某事物通常比从记忆中回忆更容易。因此，用户界面应具有熟悉的或具有提示性的可见元素，以促进识别。

哈佛心理学家乔治·A·米勒提出了一个关于“神奇数字七”的著名概念。他认为普通人的短期记忆有足够的容量来容纳七个项目，上下浮动两个。基本上，这个概念告诉我们，人类的工作记忆一次可以容纳五到九个项目。在有干扰的情况下，情况会更糟。在开发过程中，你应该牢记这个限制。

例如，你不希望最终用户在你的产品中，从一个屏幕到下一个屏幕时，需要在记忆中携带一堆随意的项目。

文化限制

最后，我们来谈谈文化限制。这些本身往往不是限制，而更像是文化差异。

例如，思考一下颜色在不同文化中的含义。在西方文化中，白色用于婚礼，代表和平。然而，在许多其他文化中，白色代表死亡和哀悼。同样，粉色在许多文化中被认为是女性化的颜色，但并非所有文化都如此。

除了颜色，设计的许多方面都可能因文化而异。语言翻译、符号和图标、布局和多媒体等都可能因文化而不同。

另一个与软件开发相关的文化差异例子是复选框中“X”的使用。想想选举选票，你在候选人名字旁边用“X”标记你的选择。我读到在日本，他们使用一个称为“丸印”的圆圈来表示选择。他们用“X”标记来表示拒绝。因此，“X”可能具有非常模糊的含义。因此，现代用户界面现在使用复选标记（√）在复选框中进行选择。

请查看我们的课程资源，获取更多关于文化限制和软件开发的信息。

总结

本节课中，我们一起学习了在软件设计中需要考虑的四种主要用户限制：感知限制、身体限制、认知限制和文化限制。理解并适应这些限制是创建用户友好、包容性强的软件产品的关键。现在，我想向大家开放讨论。我们有一个国际化的课堂，学员来自世界许多不同地区。让我们在讨论区谈谈一些文化差异。在开发软件时，需要考虑的你们文化中的哪些元素？也许我们可以请来自日本的同学详细说明一下“丸印”。

048：与客户互动

概述

在本节课中，我们将要学习如何有效地与客户互动以获取软件需求。我们将探讨如何开启对话、应该提出哪些问题、应该避免哪些问题，以及在互动中需要牢记的关键原则。

与客户互动的重要性

在本课程中，我们已经多次强调了客户沟通的重要性。现在，是时候具体谈谈如何与客户对话了。你应该说什么？从哪里开始？

初次发起客户互动确实可能令人望而生畏，但本节课将提供一些好的提问方式、需要避免的问题，以及与客户互动时需要牢记的事项。在本节课结束时，你将能够自信地与客户交谈并有效地获取需求。

互动式探索，而非单向收集

想象一下，你和你的开发团队第一次与客户会面。你需要将他们脑海中的一个想法转化为一个软件产品。

需要牢记的一个重要事项是，你是在那里与他们一起探索各种可能性，而不是简单地收集他们的想法。客户互动应该是互动的。

这不像在餐厅里你是服务员，你不仅仅是接受他们的点单并交付他们要求的东西。这更像是邀请他们进入厨房，把他们介绍给厨师，并让他们看看食材。然后，你、厨师和客户一起讨论可以用现有食材制作的所有美味菜肴。作为一个团队，你们为客户创造出一道完美的新颖餐点。

需求获取是一个持续的过程

现在，需求获取并不是只在开发前发生的事情。正如我们在本课程中多次提到的，你需要经常重新审视需求。

你不可能第一次就获得所有正确的需求。凭空创造一个想法是很困难的。一旦你有了可以向客户展示的模型和原型，他们就能更容易地说出他们喜欢什么、想要什么以及讨厌什么。

为了获得正确的需求，从而开发出正确的产品，你必须频繁地进行需求获取。

管理需求的技巧

由于你会经常重新审视需求，我建议你为需求编号，使用一些唯一的标识符。这将使所有参与者在整个开发过程中都能轻松地引用它们。

此外，需求不一定非要直接来自客户。有很多方法可以获取额外的需求。

以下是几种获取额外需求的方法：

• 你可以采访最终用户，了解他们的工作方式、需求和喜好。
• 你可以与焦点小组一起进行可行性研究。
• 你可以观察最终用户，看他们如何使用产品。
• 如果最终用户使用过之前的产品，你可以查阅该产品的用户手册，了解他们习惯什么。

这些获取技巧有助于为最终用户交付更好的产品。

建立术语表

另一个可以简化客户互动的工具是为产品建立一个术语表。这个术语表呈现了产品特有的信息。一旦一个术语被纳入术语表，每个人都应该使用它。这提高了清晰度，因为不会对同一事物使用不同的术语。

开发团队为一个元素起一个名字，然后客户用另一个名字称呼它，这种情况很常见。这会导致混淆，难以确定每个人是否在谈论同一件事。

案例分析：凯尔的故事

凯尔是一名新的软件产品经理，他迎来了职业生涯中的第一次客户会议。他内心非常紧张，但他自信地走进房间，与客户握手，并介绍了自己和开发团队。他询问客户产品的目标，并获得了一些有见地的答案。

然后他问客户希望在产品中看到什么。客户开始列出她希望看到的功能。凯尔记录了这些答案。会议结束后，凯尔与他的开发团队会面，将请求的功能列表转化为需求待办列表。

他将待办列表通过电子邮件发送给客户，并请她对需求进行优先级排序。开发团队收到优先级排序后的待办列表后，便开始了开发工作。

两周后，凯尔和开发团队与客户会面，展示了一个原型。这个原型正是客户所要求的，但使用起来相当困难。开发团队对他们的工作成果也不太满意。

凯尔做了什么导致了这种情况？A， 询问客户产品的目标。B， 仅根据客户建议来确定需求。C， 让客户对需求进行优先级排序。或 D， 两周后向客户提供原型。

当你与客户会面以获取需求时，这应该是所有参与者之间的对话。你需要了解产品的愿景、目标或目的，凯尔做到了这一点。然后，你需要开发团队和客户讨论可能的方法。让他们达成一个既能满足客户，又能保证产品质量的解决方案。

让客户对需求进行优先级排序并向他们提供原型是满足客户的好方法。尽管如此，需求不应仅仅基于客户的初始请求；因此，B是正确答案。

与客户互动时的关键考虑因素

客户互动将是你作为软件产品经理工作的重要组成部分。当你与客户互动时，有几个注意事项需要牢记。

现在让我们来回顾其中的一些。首先是确保你与客户找到正确的平衡。你不想表现得过于被动。就像我之前说的，你不是接受点单的服务员。你需要提出新的想法和观点。

你也不想表现得过于激进。你需要避免告诉客户他们想要什么，或者为了细节和决定而盘问他们。你需要找到一个平衡点，在这个点上你既自信又乐于助人。

找到这种平衡的一个好方法是提出好的问题。通过你的问题，你希望得到的不仅仅是“是”或“否”的回答。提出好的开放式问题。专注于产品的目标和目的，并尽可能保持与技术无关。

“为什么”对你来说将是一个非常重要的问题。不断问你的客户“为什么”？他们为什么想要那样？他们为什么需要这个产品？为什么会有人使用它？

西蒙·斯涅克有一个关于“为什么”这个问题的力量的精彩TED演讲，我们已在课程资源中与你分享，你一定要去看看。

需要避免的问题

除了“是”或“否”的问题，还有一些问题你应该避免。例如，尽量避免问“你想要什么？”或“你的需求是什么？”这些问题有点过于开放。它们会导致随机、结构不佳但重要的想法。

想想庭审律师与证人互动的方式。你可能在电视或电影中看到过。律师只问封闭式的“是”或“否”问题。他们不希望证人详细阐述，因为这可能会破坏他们的论点。

作为软件产品经理，你需要以与庭审律师相反的方式行事。尝试构建对话，以允许更有条理的想法，这将使将想法转化为需求变得更容易。

避免过早导向解决方案

确保你没有将客户导向一个过早构想的解决方案。如果客户在没有探索其他想法的情况下过早地同意了一个解决方案，他们可能最终对结果不太满意。

客户可能会试图导向某个特定的解决方案。如果你曾经从事过零售工作，你可能熟悉“顾客永远是对的”这句话。但在软件开发中，情况并非总是如此。有时客户是错的，有时客户不知道什么是可能的，或者他们可能会提出一些让最终用户更难学习产品的想法。

重要的是，你要尊重他们的观点，并理解他们想法背后的理由。再次强调，问“为什么”。尝试提出可能的替代方案，并礼貌地指出他们的方法可能行不通的原因。

归根结底，客户做出关键的需求层面决策。如果你把需求完全交给开发团队决定，那将允许他们构建任何他们想要的东西，而不是客户需要的东西。

案例分析：宠物用品网站

你和你的开发团队正在为一家在线销售宠物用品的公司创建一个在线购物网站。客户对他们的要求非常具体。她想要绿色背景配红色文字。她想要动物图片做成动画，看起来像在跳舞。她希望所有产品都显示在首页，并按价格从高到低排序。

你的开发团队对这个设计有点不安。他们试图说服她放弃这些功能。一位开发人员解释说，绿色背景上的红色文字很难阅读，色盲的人根本看不清。她最喜欢的颜色是红色和绿色，所以她犹豫是否要改变主意，但最终她同意使用绿色背景配蓝色文字。不理想，但更好。

然后，开发团队试图说服她放弃按价格从高到低排序。他们认为跳舞的动物是无害的，是他们最不担心的。他们向客户解释说，用户应该能够按动物类型或产品类型（如食物、玩具等）进行排序。他们解释说，这将使网站对用户来说更容易使用，并且主页上不会那么拥挤。她拒绝更改排序系统。

在这种情况下，开发团队的下一步方法应该是什么？A)， 按照她的所有要求创建网站，并交付她想要的产品。B， 提供实验数据，以确保更好的排序系统可以增加销售额。C， 让动物的舞蹈动作变得不恰当，只是为了惹恼她。或 D， 创建一个视觉吸引人且具有出色排序功能的网站。

在这种情况下，团队需要有勇气。他们的下一步方法应该是进行实验或找到一些数据来支持开发团队的立场。你可以利用这些来做出数据驱动的决策。再次强调，你需要思考产品被需要的“原因”。如果“原因”是为了增加销售额或满足客户，那么产品就应该反映这一点。

一个讲道理的客户会被正确的数据和经济论据说服，因此B是正确答案。然而，如果你的客户完全不讲道理，并且没有任何方法能改变他们的想法，那么最好只是交付他们想要的产品。

总结

本节课中，我们一起学习了如何有效地与客户互动以获取软件需求。我们了解到，需求获取是一个互动和持续的过程，而不仅仅是单向的信息收集。我们探讨了提出开放式问题、不断追问“为什么”的重要性，以及如何避免过早导向解决方案或完全被客户不合理的请求所左右。通过建立术语表、进行实验和利用数据，我们可以更好地与客户协作，共同创造出既满足客户需求又具备高质量的产品。

049：客户需求与软件需求

概述

在本节课中，我们将学习如何通过与客户深入沟通，将模糊的需求转化为清晰、具体的软件功能描述。我们将以餐厅点餐系统为例，演示如何通过提问来明确客户需求，并了解让客户持续参与开发过程的重要性。

---

从模糊需求到具体功能

上一节我们介绍了需求获取的重要性，本节中我们来看看如何通过提问来澄清一个模糊的需求。

以本模块开始时提到的餐厅点餐系统为例。你的客户杰米提出的一个功能是：顾客可以使用系统下单。这个描述非常模糊，因为实现这个需求的方式有很多种。

这是一个通过提出更直接的问题来弄清楚杰米究竟如何设想该功能的好机会。

以下是你可以提出的一些问题：

• 顾客如何进行选择？
• 当一桌有多位顾客时，系统应如何处理？
• 每桌的点餐是否有最低或最高限额？
• 顾客如何将订单发送到厨房？

---

客户的具体设想

在听到上述直接问题后，杰米给出了更详细的回答：

“我为之前描述得如此模糊而道歉。在我设想中，顾客与应用程序交互时，每张餐桌应配备一台或多台平板电脑供顾客点餐。他们可以浏览食物图片。如果顾客想了解更多关于某道菜的信息，可以点击它；如果他们想点这道菜，就点击‘下单’按钮。这会将他们带到另一个页面，在那里他们可以指定对餐点的修改以及可能有的任何饮食限制，然后再将订单发送到厨房。当一桌有多位顾客时，我希望它的工作方式类似于在线购物系统的购物车。我希望当平板电脑在餐桌上传递时，每位顾客都可以选择自己的订单。或者，也可以由一个人输入所有人的订单，这没关系。同一账单上的所有订单必须从一台平板电脑提交。额外的平板电脑是供人们浏览菜单或为另一张账单点餐用的。点餐不应有最低或最高限额。当所有订单都已输入并定制完成后，顾客可以通过点击‘提交订单’将订单发送到厨房。”

---

客户参与的重要性

在听到对直接问题的回答后，你对“顾客可以使用点餐系统下单”这句话的实际含义有了清晰得多的理解。

让你的客户参与进来并考虑最终用户，是你工作中非常重要的一部分。即使在需求获取之后，你的客户也应该在整个开发过程中持续参与。他们应该在那里回答问题，就设计选择提供建议，并对可运行的版本提供反馈。

我们为你提供了一份资源，列出了许多你可以向客户提出的好问题。如果你在沟通中卡住了，可以将这份资料带到客户会议中并参考它。你可以在课程资源中找到它。

---

下一步：需求的表示

现在你已经获取了需求，接下来需要学习如何表示它们。这就是你将在本模块剩余部分学习的内容。

---

总结

本节课中我们一起学习了如何通过提出具体问题来澄清客户的模糊需求，并以餐厅点餐系统为例进行了详细拆解。我们认识到，让客户持续参与开发过程，对于确保软件产品符合预期至关重要。接下来，我们将学习如何有效地表示这些已明确的需求。

050：用例

在本节课中，我们将要学习一个在软件需求分析中至关重要的工具——用例。我们将了解用例的概念、核心组成部分，并通过具体示例学习如何编写一个完整的用例描述。

概述

用例是由伊瓦尔·雅各布森在1986年提出的概念。自此，它成为一种描述产品功能所支持任务的流行方式。用例是一种识别、澄清和组织任务细节的方法。它由用户与系统之间一系列可能的顺序交互组成，发生在特定环境中，旨在达成特定目标。

用例描述的构成要素

一个用例描述通常由以下几个部分组成：用例名称、参与者、目标、触发器、前置与后置条件、基本流程、异常情况以及质量要求。

以下是每个组成部分的详细说明：

1. 用例名称：需要为用例起一个描述任务、简单且简短的名字。
2. 参与者：需要识别参与用例的角色。角色是个人承担的职责，例如餐厅顾客、厨房厨师或服务员。参与者名称应描述他们与产品的交互行为，而非具体人名，以保证通用性。
3. 目标：需要明确用例旨在达成的特定目标。
4. 触发器：触发器是促使用例开始的事件，例如按下某个按钮。
5. 前置与后置条件：前置条件是在该用例发生前必须满足的条件。后置条件是在用例完成后达成的条件。
6. 基本流程：基本流程是用例中所有发生步骤的逐步说明。它应代表一个“晴天场景”，即最佳情况或一切正常运作的场景。如有必要，其他场景可作为备选流程进行概述。
7. 异常情况：异常情况突出说明了用例无法正常工作的任何情形。对于异常，需要识别其在基本流程中可能发生的步骤，并提供解决问题的替代步骤。
8. 质量要求：质量要求是希望满足的任何质量规范，例如非功能性需求，如在特定时间内完成场景或使用特定量的内存。

总体而言，用例描述从参与者的角度概述了任务。它不涉及产品幕后的运作。同时，描述应独立于技术，不绑定于特定的用户界面平台。

用例示例分析

上一节我们介绍了用例的构成要素，本节中我们通过一个具体场景来应用这些知识。

杰克正在使用一个即时通讯应用程序。他想给他的朋友莎莉发一条消息，告诉她他参加她的派对要迟到了。他打开应用程序，搜索她的名字。他点击他们的对话，然后输入消息：“嘿，莎莉，我要迟到了。待会儿见。”然后他按下发送。莎莉看到了消息并回复了杰克。

如果要为此场景编写一个用例，你会将谁列为参与者？
A. 消息发送者
B. 消息接收者
C. 莎莉
D. 杰克

在定义参与者时，我们希望它们是通用角色，因此不应使用实际姓名。尽管莎莉和杰克是这个特定场景的最终用户，但并非每次用例发生时都是他们。我们需要更通用的描述。消息发送者和消息接收者是很好的参与者名称，因为两个用户都参与了此场景。这意味着答案A和B是正确的。

构建用例图与详细用例

现在你已经了解了用例描述的结构，让我们进一步将其应用到我们的餐厅应用示例中。

一个好的起点是创建一个用例图。这是产品支持的所有任务的高级可视化表示。它识别了参与者及其参与的用例。在餐厅场景中，我们有顾客、儿童顾客和厨房员工。他们各自的用例在图中与他们相连。边界内是产品可以支持的所有用例。

让我们选取其中一个任务并将其转化为一个详细的用例。我们将查看允许顾客查看账单的需求。

假设这是第一个用例，对应产品待办列表中的需求，因此我们将给这个用例分配ID号1。

以下是该用例的详细描述：

• 名称：查看账单
• 参与者：顾客（最终用户）
• 目标：查看其订单的账单
• 触发器：顾客在应用程序中请求查看账单
• 前置条件：菜单上有菜单项；用户已选择菜品；用户已下单
• 后置条件：顾客可以查看账单并支付账单
• 基本流程：
  1. 顾客从应用程序请求查看账单。
  2. 顾客查看账单。
• 备选流程：用户让服务员打印并送来账单（这不是晴天场景，因为它需要更多工作，但完成了相同的任务）。
• 异常情况：可能发生的异常是未订购任何菜品，因此用例目标未达成。在这种情况下，应显示错误消息。在我们的基本流程中，步骤2是“顾客查看账单”。如果订单中没有菜品，我们希望显示错误消息。我们将在用例中通过写“步骤2a：如果未订购菜品，则显示错误消息”来体现这一点。
• 质量要求：账单加载时间少于10秒。通常，质量要求是非功能性需求，有助于在开发过程中设定质量标准。

触发器辨析练习

你正在使用一个允许用户创建和使用群组消息线程的软件产品。群聊参与者可以被添加到群聊中，并且这些参与者都可以看到在该线程中发送的消息。

以下哪一项是“向群聊发送消息”这个用例的触发器？
A. 参与者有一条想要发送给群组的消息。
B. 参与者输入消息。
C. 参与者打开群聊。
D. 参与者点击发送按钮。

触发器是促使用例发生的事件。在这个场景中，我们的用例是“发送消息”。要触发这个事件，参与者会有一条想要发送给群组的消息。这促使参与者打开群聊、输入消息并按下发送。因此，A是正确答案。答案B、C和D都是将发生的基本流程中的步骤。

总结

本节课中我们一起学习了用例这一强大的需求分析工具。用例是描述产品功能所支持任务的标准方法，它从用户（参与者）的角度出发，通过定义名称、参与者、目标、触发器、条件、流程、异常和质量要求，清晰地勾勒出交互场景。用例图则提供了产品支持的所有任务及其参与者的高层视图。用例有助于组织和阐述任务及其步骤，并能指导开发工作。接下来，我们将学习一些有助于组织和可视化产品需求的设计技术。

051：18_01_3-2-5-线框图

在本节课中，我们将要学习产品开发中一个非常有用的技术——线框图。我们将了解线框图是什么、它的作用、如何创建以及需要注意的事项。通过本节内容，你将掌握使用线框图来沟通需求、验证想法并与团队协作的基本方法。

什么是线框图？

线框图是产品的基本视觉表示。线框图的另一个名称是模型。

你可以把它想象成房屋的蓝图。承包商在建造房屋之前，需要绘制房屋的黑白图像。这能让所有相关人员对将要建造的东西达成共识。

线框图的作用

上一节我们介绍了线框图的基本概念，本节中我们来看看它的具体作用。

线框图不仅是开发团队可视化需求的好工具，也是向客户展示想法的宝贵技术。

在开发团队讨论需求之后，他们可以快速制作一个线框图来展示给客户。这样，客户就能在开发过程的早期看到产品的雏形。这允许他们提出修改意见，并确保所有人对产品有共同的愿景。

如何创建线框图

了解了线框图的作用后，我们来学习如何创建它。

你需要保持线框图的简洁性。这不是界面的详细演示，而是产品的演示。不应在线框图中放入将在界面中实现的华丽颜色和图像。

线框图侧重于要支持的基本功能和最终用户任务。它们可以帮助你思考按钮、文本字段和图像的放置位置。从上到下的布局应遵循用户执行每个任务的流程。

基于这些想法，在项目的设计和实施阶段后期，才会完全模拟或实现用户界面设计。

再次以房屋蓝图为例。你无法知道墙壁的颜色，也无法知道照明或管道装置的外观。你只能了解轮廓的基本概念以及固定装置将放置的位置，但无法获得房屋外观的完整画面。

线框图示例

我们使用线框图来创建本课程。我们会确定演示者站立的位置以及图像和文本字段出现的位置。

以下是本课程的一个线框图。如你所见，我们的线框图与实际课程看起来非常不同。我们没有包含图像的具体样子，只是简单地指出了我们希望它放置的位置并描述了它将代表什么。演示者的图像也完全不像我，但这没关系。你能明白那是正在讲话的人。

我们会将这些线框图发送给制作团队，以便他们了解我们对课程的大致构想。然后他们进行制作，创造出你所看到的精美课程。

让我们看一个线框图示例。这是一个提供作者传记的网站的线框图。

你认为带有X的白色方框代表什么？A， 一个按钮；B， 一个标题；C， 文本；或 D， 一张图像。

在线框图中，内部带有X的方框代表一张图像；因此，D是正确答案。你无需指定有关图像的详细信息。在线框图中，这种表示法只是作为图像放置位置的占位符。

我们将在本课后面介绍如何表示按钮、标题和文本。

线框图的其他用途

如你所见，线框图可以用于许多事情。你可以使用它们来设计将要开发的内容、向客户演示以及与团队沟通。

线框图的另一个常见用途是让客户与你沟通。客户通常对他们产品的功能和外观有一个构想。有时，客户通过绘制线框图来表达他们的想法会更容易。

我曾有客户这样做过，这使得从他们的线框图中提取需求变得容易。如果你的客户难以表达他们真正想要的东西，你可以考虑这种方法。

注意事项与工具

在上一模块中，Bradley谈到了需求与设计之间的细微界限。确保在使用线图引出需求时不要跨越这条线。进行一些设计是可以的，但你需要小心，不要过早地开发解决方案。线框图应该引发关于问题是什么以及最终用户需要什么任务的讨论。

以下是可用于创建线框图的工具类型：

• 手绘与扫描：你可以在纸上绘制它们并进行数字扫描。
• 绘图软件：你可以使用计算机上的任何绘图工具。
• 在线应用：也有许多专为绘制线框图设计的网络应用程序，我们会在课程资源中发布一些。

我们使用 Google Docs 来绘制线框图。像 PowerPoint 这样的演示工具也常用于绘制线框图。

实践案例：餐厅示例

让我们回到我们的餐厅示例。以下是主菜页面部分内容在线框图中可能的样子。

在线框图中，图像通常用内部带有X的正方形表示。文本通常用阴影框模拟。你可以在按钮和标题上添加文本，以便与客户有更多讨论内容。使用阴影框表示通用文本。按钮通常用正方形模拟。

总结与过渡

本节课中我们一起学习了线框图。我们了解了线框图是一种产品的低保真视觉表示，就像房屋的蓝图。它主要用于在早期阶段沟通需求、验证想法并与客户和团队协作，强调功能布局而非视觉细节。创建时应保持简洁，并注意不要过早陷入具体设计。

接下来，我们将要学习一个类似的设计技术——故事板。

052：故事板

概述

在本节课中，我们将要学习一种重要的需求可视化工具——故事板。我们将了解故事板的起源、两种主要类型及其在软件开发中的具体应用。通过本课，你将掌握如何使用故事板来规划用户交互、统一团队愿景并细化产品需求。

---

如果你之前听说过故事板，那很可能是在电影行业的背景下。这是因为这种实践起源于电影行业。想一想制作一部电影所涉及的所有角色。故事板有助于让每个人都围绕导演的愿景达成一致。

故事板是对交互过程的顺序视觉化呈现。连环画就是一种故事板。它按顺序视觉化地讲述一个故事。在电影行业，故事板用于规划画面中的元素位置、镜头如何移动，并提供场景的感觉。他们会在投入服装、道具、摄影、特效和剪辑之前完成这项工作。

在软件开发中，故事板可以通过几种不同的方式使用。无论如何使用，它们都按顺序讲述了最终用户如何与产品交互的故事。

---

电影式故事板

第一种使用故事板的方式类似于电影故事板。这种类型的故事板贯穿了高层次的用户体验。

以下是创建此类故事板的步骤：

1. 首先，需要识别涉及的参与者以及他们将如何使用产品。这里识别的不是电影演员。如果你还记得关于用例的课程，你会记得我们将情境中的主动用户称为参与者。
2. 如果产品具有多个功能，那么需要为每个参与者在每种情境下使用产品的情况创建一个新的序列。

让我们使用我们的餐厅应用程序来看一个例子。

史密斯一家决定去Brampton Pasta餐厅。他们坐在餐桌旁，使用桌上的平板电脑浏览菜单。他们在应用程序上浏览菜品并下单。厨房的厨师收到了他们的订单。食物准备好后被送到餐桌，史密斯一家享用了一顿美味的晚餐。用餐结束后，母亲在应用程序上查看并支付账单。

这种类型的故事板涵盖了产品被使用的各种情境。通过观察每个用户将在何时以及如何使用产品，你的开发团队可以创建或改进功能。正如之前所说，考虑用户是开发的重要组成部分。

你还可以通过为每个用户赋予角色来扩展故事板，添加更多关于用户的背景故事。例如，在我们刚刚看到的史密斯一家的场景中，你可以详细说明他们的年龄、喜欢的菜肴、过敏史、种族背景和/或收入水平。你可以细化这个场景，以展示故事板和需求如何扩展以解决某些问题。

如果产品有多个功能，你需要为每个功能制作一个故事板。例如，这个应用程序有一个儿童菜单，需要一个新的故事板。你还需要用另一个故事板来涵盖账单支付功能。

这种电影风格的故事板对于让整个开发团队达成共识也很有用。它有助于牢记产品的愿景。故事板的另一个用途是用于营销或演示目的，你可以轻松地向他人展示产品的预期使用方式和时机。

---

示例分析

你正在开发一个道路救援应用程序。该应用程序具有检查路况的功能。你的开发团队为你提供了此功能的电影风格故事板。

弗兰克即将开始公路旅行，他望向窗外，看到正在下雪。他想知道道路是否因此被积雪覆盖且湿滑。弗兰克打开他的道路救援应用程序，检查他路线的路况。应用程序告诉他最短的路线有危险，他应该选择另一条路线。弗兰克采取了建议的路线，并安全抵达目的地。

以下哪些（如果有的话）会是与此故事板相关的需求？
A. 作为司机，我希望输入出发地和目的地，让应用程序计算路线。
B. 作为司机，我希望应用程序跟踪我的行程，如果我没有到达目的地，则通知紧急联系人。
C. 作为司机，我希望危险路线用红色高亮显示。
D. 作为司机，我希望建议更安全的路线。
E. 作为司机，如果我的车辆在高速公路上静止45分钟，我希望自动向我的位置派遣道路救援。

从这个故事板中，我们可以看到路线是根据提供的出发地和目的地计算的。高风险路线用红色高亮显示，并且建议了更安全的路线。因此，A、C和D是正确答案。B和E可能是应用程序的功能，但并未在此特定故事板中描绘。

---

界面流程故事板

另一种故事板制作方式更深入地涉及软件设计。其目的是更详细地展示用户将如何与产品的用户界面进行交互。

这种类型的故事板展示了用户与产品之间所有交互的顺序。它是线框图和用例基本流程的结合。它展示了产品的每个状态以及用户如何到达该状态。在大多数产品中，每个状态将由用户界面中的一个独立线框图或页面来描绘。每个状态之间的用户转换点用带箭头的线描绘。

让我们继续使用餐厅的例子，看看这种类型的故事板是什么样子。

顾客看到的第一个屏幕是主页。从该页面，顾客可以点击一道菜进入菜品详情页，或点击儿童菜单按钮进入儿童页面。在菜品详情页，顾客可以点击订购该菜品，然后进入菜品定制页面。菜品定制完成后，顾客可以点击下单并返回主页。

这种类型的故事板是在开发前可视化需求的好方法，它提供了一个机会来讨论支持用户任务可能遗漏或多余的元素。用户应该能直观地知道他们在产品中的位置以及下一步该做什么。故事板展示了线框图。在故事板中，只要有箭头存在，线框图中就需要一个用户界面元素（如按钮）来进入下一个线框图。技术作者也可以使用故事板作为创建和组织培训材料的指南。

---

示例分析

你拿到一个包含10个不同页面的故事板。从主页出发，有四个箭头，每个箭头指向一个不同的页面。有两个页面有箭头指向主页。故事板上总共有18个箭头。有多少个页面可以直接从主页访问？
A. 10页
B. 4页
C. 2页
D. 18页

在故事板中，每个屏幕代表一个页面。可以从特定页面直接访问的页面具有从该页面发出并指向可访问页面的箭头。因此，由于有四个箭头从主页发出并指向四个不同的页面，这意味着有四个页面可以直接从主页访问，所以正确答案是B。

---

总结

本节课中，我们一起学习了故事板这一强大的需求沟通工具。我们探讨了两种主要类型：电影式故事板和界面流程故事板。两种类型的故事板都很有价值，因为它们有助于形成需求，并且都关注用户做什么以及产品中需要什么。

你会发现产品的视觉化呈现在于客户和开发人员讨论时非常有帮助。用故事板演示功能将帮助你引出更多需求并完善现有需求。电影风格的故事板适用于高层次地模拟用户与产品的交互。它也是让整个团队在产品目标上达成共识的好方法。第二种类型的故事板是增强版的线框图，用于更详细地确定与产品的交互。这种类型将更多地被开发团队用来设计需求。这是一种确保整个开发团队了解产品功能和流程的有用技术。

053：敏捷需求

欢迎来到《客户需求与软件需求》课程的本模块。

我们将基于之前模块已涵盖的内容进行扩展。在上一个模块中，摩根详细介绍了用户考量。她描述了如何让客户和最终用户参与进来，以确保为他们构建正确的产品。她还谈到了通过用例、线框图和故事板来表达这些需求的方法。

在那个模块中，我们概述了如何确定客户需求。在本模块中，我将概述如何通过将其置于敏捷框架内来表述这些需求。我将向您展示需求如何融入敏捷软件开发的范畴，以及表达和管理需求的各种方式。

敏捷原则回顾

在入门课程中，摩根谈到了敏捷及其12条核心原则。让我们快速回顾一下摩根介绍的这些原则。

以下是敏捷的12条核心原则：

1. 通过早期和持续交付有价值的软件来满足客户。
2. 频繁地交付可工作的软件。
3. 将可工作的软件作为衡量进度的主要标准。
4. 欢迎需求变更。
5. 关注技术卓越和良好设计。
6. 以可持续的步伐进行开发。
7. 专注于简洁性，最大化未完成的工作量。
8. 围绕有动力的个体构建项目。
9. 关注自组织团队。
10. 业务人员和开发人员之间每日协作。
11. 鼓励面对面交流。
12. 定期反思团队行为并相应调整。

与需求最相关的敏捷原则

在12条敏捷原则中，哪些与需求最相关？

A. 欢迎需求变更。
B. 鼓励面对面交流。
C. 专注于简洁性。
D. 频繁交付可工作的软件。

实际上，所有这些答案都是正确的。它们各自以不同的方式反映了需求。然而，为了讨论需求和敏捷，我想特别指出其中两条。

第一条是欢迎需求变更。这可能显而易见，但至关重要。敏捷基于软件是动态的这一概念。它是一个开放的事物，无法一次性定义，然后基于那个单一的定义进行构建。通常，您的客户会在开发过程中改变对产品功能的看法。对于那些没有考虑到需求变更必然性的项目来说，这可能是灾难性的。当您构思需求时，欢迎需求变更的敏捷原则至关重要。要带着贯彻执行的意图来制定它们，但不要自欺欺人地认为它们不会随着产品的成长而改变。这只是软件开发方式的本质。

第二条我想强调的原则是鼓励面对面交流。这对于获取正确的需求也至关重要。根据敏捷方法，需求应在开放和协作的环境中从客户那里获取。产品的愿景应由您的客户决定。然后，作为软件产品经理，您的工作是共同解决问题，细化该愿景，以确定项目中哪些需求在范围内。您需要一起完成这项工作。关键在于让每个人都在同一个房间里，可以公开讨论产品中希望包含的功能，识别可以或必须完成的事项。这不仅能让您更有效地当场确定有价值的事项，也为您的团队与客户之间的未来沟通树立了先例。

需求在敏捷中的角色

以下哪项表达了需求在敏捷中的角色？

A. 需求中等重要，定义截止日期更重要。
B. 需求完全不重要，敏捷是编写代码的过程。
C. 需求应预先定义且不改变。
D. 需求很重要，并且应该能够在整个开发过程中改变。

需求在敏捷中极其重要。它们帮助我们理解客户，并确保我们为客户构建正确的产品。它们还帮助我们确保我们正确地构建产品。因此，正确答案是 D。

与客户坐下来讨论那些必然会变化的需求，是Scrum中经常使用的实践。Scrum是一种敏捷方法论，我们在《软件流程与敏捷实践》课程中有详细介绍，不要错过。

总结

我想在本课中概述的是，需求是敏捷不可或缺的一部分。另一方面，敏捷也为需求增添了大量质量，只要您在创建需求时遵循其实践。

既然我们已经建立了敏捷与需求之间的一些联系，让我们进入下一课。在那里，我将告诉您关于表达敏捷需求的最常见形式：用户故事。到时见。

054：用户故事 📝

在本节课中，我们将学习敏捷开发中表达需求的核心技术之一：用户故事。我们将了解用户故事的定义、结构、重要性，并学习如何编写和评估高质量的用户故事。

上一节我们介绍了如何将传统需求与敏捷实践相结合。本节中，我们来看看一种具体的敏捷需求表达方式：用户故事。

什么是用户故事？🤔

用户故事是一种表达需求的简单方式。在之前的模块中，我们学习了用例、线框图和故事板，这些都是表达需求的技术。用户故事是另一种实现相同目的的方法。

用户故事旨在将系统的所有需求保持为一致的格式。它们易于编写、阅读和评估。

用户故事的结构 📐

用户故事遵循一个非常具体的格式：

作为 <角色>， 我想要 <功能>， 以便于 <价值>

• 第一部分（作为…）：指明需求是为哪个利益相关者角色而制定的。例如“管理员”或“访客用户”。在我们的餐厅菜单应用示例中，利益相关者是顾客和厨房员工。这有助于明确需求旨在支持谁，它规定了需求的 “谁”。
• 第二部分（我想要…）：描述利益相关者希望使用产品解决的任务或功能。这是需求的核心，通常也是人们想到“需求”时最先想到的部分。这部分规定了需求的 “什么”。
  • 例如，在餐厅应用中，具体任务可能是：“我想要浏览我所在餐厅的菜单”、“我想看到儿童菜单”或“我想查看已收到的订单”。
• 第三部分（以便于…）：说明首先为什么需要这个用户故事。这部分在创建用户故事时经常被忽略，但它提供了对需求的关键洞察。它为需求提供了关于其提供的价值或收益的背景，并与产品的目标或愿景保持一致。这部分规定了需求的 “为什么”。

因此，一个完整的用户故事可能如下所示：

作为儿童顾客，我想要看到儿童菜单，以便于我了解哪些餐食和游戏能吸引我。

你可以看到它是如何作为一个整体结合在一起的。

知识测验 ✏️

让我们测试一下你对用户故事结构的理解。

假设你正在与客户合作一个手机游戏项目。他们给出了一个需求：“我希望能够使用方向键控制我的角色。”

你会如何构建这个需求以符合用户故事的形式？

A. 作为玩家，我希望能够使用方向输入方法控制我的角色，以便我能在游戏世界中导航。
B. 我希望能够使用方向输入方法控制我的角色。
C. 为了在世界中导航，角色应该能够使用方向键移动。
D. 不做任何更改，这已经是一个用户故事了。

正确答案是 A。一个用户故事应该符合“作为…，我想要…，以便于…”的形式。请注意，这个用户故事在描述输入设备时更加通用，以专注于实际需求，而不是特定的解决方案。

用户故事的优势 💪

现在，将用户故事与常见的需求表达方式进行比较。通常，你会看到需求使用模糊的语言表达，没有太多描述。例如：“用户应该能够看到儿童菜单”。

了解了用户故事的创建方式后，你是否理解了它们为何如此构建？它们为需求带来了极大的清晰度，而不会陷入技术细节的泥潭。你可以在一个简洁的小包裹中获得“谁”、“什么”和“为什么”。

拥有这样简短、简洁的用户故事还有一个额外的好处：你可以轻松地将它们写下来以便跟踪。事实上，用户故事的设计足够紧凑，可以写在索引卡或便利贴上。

通过这种方式，所有的用户故事都可以以一种非常直观、具体且信息丰富的方式展示和组织。将故事写在索引卡上，可以轻松地将它们按相关主题分组，并在需求不可避免地发生变化时进行重组。

总结 📋

本节课中，我们一起学习了用户故事。用户故事是一种遵循 作为 <角色>， 我想要 <功能>， 以便于 <价值> 格式的敏捷需求表达技术。它明确了需求的“谁”、“什么”和“为什么”，使需求更加清晰、易于管理和沟通。通过将用户故事写在卡片上，团队可以直观地组织和调整需求，更好地适应项目变化。

055：用户故事

在本节课中，我们将要学习如何编写高质量的用户故事。用户故事是表达软件需求的一种有效方式，但并非所有用户故事都是好的。我们将了解构成一个好用户故事的关键要素，并学习如何避免创建过于庞大和模糊的“史诗级”故事。

用户故事的撰写者

用户故事本应由您的客户来撰写，因为客户通常最清楚他们希望产品具备什么功能。

然而，软件产品经理最终常常承担起撰写用户故事的责任。

这并非因为客户对指定产品功能不感兴趣。

通常是由于客户缺乏创建用户故事的经验或培训。

但这并不意味着您不应该请客户创建用户故事。

这意味着您和您的开发团队可能需要帮助他们以用户故事的形式表达需求。

好用户故事的标准

上一节我们介绍了用户故事的撰写者，本节中我们来看看什么才是一个好的用户故事。仅仅将需求套入用户故事格式是不够的，关键在于故事本身的质量。

一个好的用户故事应能清晰地勾勒出产品中一个具体的软件需求。

那么如何做到这一点呢？业界广泛使用一个由比尔·韦克提出的助记符“INVEST”，它可以帮助您记住好需求的标准。

以下是INVEST中每个字母所代表的含义：

• I 代表 独立的：一个用户故事应该是独立的，意味着它可以独立于任何其他用户故事进行开发，无论何时实施。这很重要，因为它允许您重新安排用户故事的开发顺序。如果两个用户故事紧密相关且相互依赖，您可以将它们合并成一个独立的用户故事。但需要注意平衡，避免故事变得过于庞大。
• N 代表 可协商的：用户故事应足够通用，以便您的团队和客户围绕其实现方式进行协商。由于可能不存在唯一正确的实现方式，因此不应专注于满足需求的具体技术细节，而应关注需求的主要重要方面。情况可能会发生变化，这是可以接受的。
• V 代表 有价值的：每个故事都应该为客户带来某种价值。避免创建华而不实的“忙碌工作”。
• E 代表 可估算的：您应该能够估算设计和实现该需求所需的时间。如果您无法估算开发时长，那么您可能指定了一个所谓的“史诗”。
• S 代表 小的：这与需求应该可估算的理念相关。然而，即使您可以估算某件事所需的时间，这本身并不能使其成为一个好需求。如果一个用户故事需要三个月来开发，您会希望将其分解为更小的故事。用户故事之所以要小，是因为每个故事都应在短时间内开发完成。此外，较小的故事其估算也应更为确定。如果您遇到一个庞大的故事，请尝试尽可能将其分解，否则您将面临处理一个“史诗”的风险。
• T 代表 可测试的：基本上，您需要验证每个用户故事在被视为“完成”之前都满足一套特定的标准。这通常通过定义和使用验收测试来实现。

测试：INVEST中的S代表什么？
A. 简单的
B. 聪明的
C. 稳定的
D. 小的
答案：D。需求当然应该简单，但这不是我们在这里寻找的词。

避免“史诗”

我已经多次提到我们要避免创建“史诗”。那么，究竟什么是“史诗”呢？

正如您可能从上下文中猜到的，“史诗”是一个几乎无法克服的庞大用户故事。

“史诗”肯定无法在短时间内完成。它是对需求的模糊、宽泛的描述。

即使在最成熟的软件开发团队中，“史诗”也会进入需求待办列表。

“史诗”通常是在项目初期描述未来要开发的功能时被引入的。当客户希望在未来完成某项功能时，很难确切知道它应该是什么样子或应该如何完成。通常的做法是建立一个用户故事，勾勒出客户所需功能的大致想法。

测试：回想软件开发过程和敏捷实践课程中的开发阶段。在大多数流程中，哪个阶段会首先创建“史诗”？
A. 规格说明阶段
B. 架构设计阶段
C. 构建阶段
D. 过渡阶段
正确答案是A，规格说明阶段。这是与客户创建和讨论需求的阶段。其他阶段构成了后续要完成的工作。

---

本节课中我们一起学习了用户故事的撰写责任、使用INVEST准则（独立、可协商、有价值、可估算、小、可测试）来评估和创建高质量用户故事，以及如何识别和避免创建过于庞大模糊的“史诗”。掌握这些要点，将帮助您更有效地与客户和开发团队沟通需求。

056：用户故事 📝

在本节课中，我们将要学习用户故事的概念，了解如何编写高质量的用户故事，并认识一种需要避免的、过于宽泛的故事类型——史诗。

上一节我们介绍了需求的不同形式，本节中我们来看看如何用一种更贴近用户视角的方式来描述需求，即用户故事。

什么是用户故事？

用户故事是从最终用户角度描述软件功能的一种简洁方式。它通常遵循一个简单的模板：

作为 [用户角色]，我想要 [执行某个操作]，以便于 [实现某个价值或目标]。

在我们的餐厅应用示例中，一个用户故事可能如下所示：

作为一名顾客，我想要支付我的账单，以便于我能快速结清欠款。

如何编写好的用户故事？

一个好的用户故事应该清晰、具体，并且能为开发团队提供足够的信息。为了帮助记忆好故事的特征，我们可以使用 INVEST 助记符。

以下是 INVEST 原则所代表的六个关键特性：

• 独立的：故事应尽可能独立于其他故事。
• 可协商的：故事的细节应在开发团队和客户/产品负责人之间讨论确定。
• 有价值的：故事必须为最终用户或业务带来明确的价值。
• 可估算的：开发团队应能估算完成该故事所需的工作量。
• 小的：故事应足够小，以便在一个迭代周期内完成。
• 可测试的：必须能够定义明确的验收标准来验证故事是否完成。

什么是史诗？如何避免？

虽然上面的支付账单故事看起来很简单，但它遗漏了许多关键问题：支付是在应用内完成吗？接受哪些支付方式？由于这些问题未被解答，实现该故事所需的工作量是不明确的。

这种过于庞大、模糊、无法准确估算的用户故事被称为 史诗。史诗通常在需求规格说明的初期被定义。

问题在于，对未来的估算遵循一种称为“不确定性锥”的模式。我们将在敏捷规划课程中详细讨论它。其基本思想是：对一个用户故事的开发时间估算，距离计划开发的时间越远，其准确性就越低。

因此，如果你计划在几个月后开发某个功能，可以确定你的估算将比本周要开发的功能的估算更不准确。

为了避免编写史诗，第一步是意识到你可能正在创建一个。一个好的实践是提供刚好足够的信息，让开发人员能够理解并实现它，但又不要过多，以至于开始指定实现细节。

将史诗分解为多个更小的故事，你会发现管理起来更容易。

我之前提到了一个史诗：“作为一名顾客，我想要支付我的账单，以便于我能快速结清欠款。”

分解这个史诗的一种方法是编写几个更小的故事来描述它，例如：

1. 作为一名顾客，我想要能够看到包含订单所有项目的账单，以便于我能了解我的订单将花费多少钱。
2. 作为一名顾客，在查看账单时，我想要能够选择“立即支付”选项，以便于我能立即支付账单。
3. 作为一名顾客，我想要能够输入Visa或Mastercard信用卡的支付信息，以便于我能使用一种便捷的方式付款。

所有这些都属于“支付账单”这个广泛主题，但它们更加具体和有帮助。

小测验

假设你正在构建一个软件产品，用户可以在客户网站上选择购买眼镜。

以下哪个用户故事会被视为该产品的史诗？

A. 作为一名戴眼镜的人，我想要看到，以便于我能屠龙。
B. 作为一名戴眼镜的人，我想要购买新眼镜，以便于我能快速收到它们。
C. 作为一名戴眼镜的人，我想要查看可供购买的眼镜列表。
D. 作为一名戴眼镜的人，我想要查看可供购买的眼镜的价格。

正确答案是 B。

A不是一个史诗，因为它甚至不是一个与产品相关的有效用户故事。C和D都是概述了特定功能、没有深入技术细节的故事，符合好故事的标准。

总结

本节课中我们一起学习了用户故事。

• 首先，我介绍了什么是用户故事——它是表达客户需求的另一种方式。
  
• 接着，我讲解了构成一个好用户故事的要求，并引入了 INVEST 助记符，它代表独立、可协商、有价值、可估算、小和可测试。
• 最后，我介绍了什么是史诗以及如何避免它。

在下一节课中，我将讨论如何使用户故事可测试，并介绍用户故事验收测试的概念。

057：客户需求与软件需求

概述

在本节课中，我们将要学习验收测试的概念。验收测试是验证用户故事是否被正确实现的关键工具。我们将了解什么是验收测试、如何编写它们，以及它们与验收标准、用户故事之间的关系。

---

从用户故事到验收测试

上一节我们介绍了如何使用 INVEST 助记符来编写好的用户故事。本节中，我们来看看该助记符的最后一个字母“T”所代表的“可测试的”。

既然用户故事应该是可测试的，那就意味着存在针对用户故事的测试，对吗？用户故事足够简洁，可以写在一张索引卡的正面。这不仅让用户故事简短扼要，也允许你在卡片的背面为每个故事编写测试。

写在卡片背面的这类测试，被称为验收测试。

---

什么是验收测试？

那么，什么是验收测试？验收测试本质上是检查一个需求是否得到满足的验证。验收测试几乎用于所有工程学科，软件工程也不例外。

一个验收测试规定了你的客户将如何验证一个用户故事是否已得到满足。如果验收测试通过，那么该用户故事就被认为是已完成的。

验收测试是基于验收标准创建的。验收标准是一个必须满足的具体条件，而验收测试则是验证该条件是否已满足的方法。

就像用户故事一样，验收测试也使用简单、直接的语言编写。每个验收测试都应该是一个易于理解的操作，附带一个可验证的条件，用以确认用户故事是否正确实现。每个测试应验证用户故事的一小部分。如果所有测试都通过，那么验收标准就被认为已满足。

---

验收测试示例

还记得我们在上一课创建的用户故事吗？

作为一个客户，我希望能够使用Visa和Mastercard信用卡输入我的付款信息，以便我能通过便捷的方式付款。

以下是我们为该用户故事编写的一些验收测试示例。

你可以使用以下标准来测试这个故事：

• 付款可以使用Visa信用卡完成。
• 付款可以使用Mastercard信用卡完成。
• 付款可以使用在线金融服务完成。
• 使用信用卡付款时，填写卡号字段会自动检测卡类型。
• 客户根据所选的付款方式，仅看到相关的输入字段。

这些只是几个例子。可能还有更多，验收标准的内容通常由客户的具体需求决定。

请注意，所有这些标准都遵循相似的结构：它们都简单、易于验证，并且都与用户故事中指定的使用不同付款类型付款相关。

---

从标准到测试

既然这些都是标准，我们就需要验收测试来验证它们。

让我们以“能够使用Visa信用卡付款”这个标准为例。为了将这个标准转化为验收测试，我们可能会为此标准编写几个测试，例如：

1. 将Visa卡插入芯片读卡器。
2. 输入Visa卡的PIN码。
3. 确认付款被接受。

通过执行这些步骤，你就验证了验收标准。当你满足所有验收测试时，该验收标准就被认为已通过。如果一个用户故事的所有验收标准的测试都通过了，那么这个用户故事就成功地通过了验收测试。

---

知识测验

现在你已经了解了验收标准和验收测试是如何创建的，让我们来测试一下你的理解。

你正在与客户合作开发一个酒店管理应用程序，并收到了以下用户故事：

作为一名客房服务人员，我希望能够在房间概览屏幕上将房间标记为已清洁，以便我能跟踪我的清洁进度。

以下哪一项可被视为该用户故事的验收测试？

A. 从房间概览屏幕，选择“将房间标记为已清洁”。
B. 可以从房间概览屏幕将房间标记为已清洁。
C. 房间应该被清洁。
D. 作为一名客房服务人员，我希望能够清洁一个房间。

正确答案是 A。

选项A概述了使用应用程序将房间标记为已清洁的一个基本步骤。它可能是众多步骤之一，但它仍然是一个测试。

选项B是一个验收标准，因为它是一个必须满足的通用条件。其他两个选项既不是验收测试也不是验收标准。事实上，选项D完全是另一个用户故事。

---

验收标准与开发

示例中的验收标准指定了用户故事中未提及的细节。因此，通过列出验收标准，你为开发团队提供了一个参考框架，让他们了解如何将故事分解为开发任务并最终完成。

当你的验收标准和测试与它们所伴随的用户故事一起编写时，你就在确保你想要实现的功能实际上可以验证其实现。

就像用户故事一样，验收标准和测试应由你的客户来制定。然而，让开发人员与客户一起创建验收测试也是一个好主意。这能让客户就他们希望看到需求如何运作提供意见，也让开发团队能够从用户的角度来思考每个需求的具体实现。

因此，客户对产品功能有很大的发言权，而开发团队也能够设想每个功能将如何构建。通过这样仔细思考每个需求，它还将帮助你避免创建令人畏惧的“史诗级”用户故事。一个用户故事有太多的验收标准，可能意味着你可以把这个用户故事再拆分得更细一些。

---

总结

本节课中我们一起学习了验收测试。它只是一个简单的条件列表，用于检查用户故事是否正确实现。它们可以以直接的方式验证，并使项目中的每个人都能轻松地真正思考每个功能的作用。

在下一课中，我将介绍产品待办事项列表，这是一种用于跟踪需求的流行Scrum实践。我们下节课见。

058：产品待办事项列表（Product Backlog）📋

在本节课中，我们将要学习敏捷开发中的一个核心工具——产品待办事项列表（Product Backlog）。我们将了解它的构成、作用以及如何与客户协作来创建和管理它。

上一节我们介绍了用户故事的验收测试，本节中我们来看看如何组织和管理这些用户故事。

什么是产品待办事项列表？

产品待办事项列表是您和您的团队计划开发的软件功能列表。它最初是一个未经排序的大型待办事项清单，并会随着时间的推移而不断细化。

待办事项列表包含哪些内容？

产品待办事项列表主要由用户故事构成。然而，它并不局限于用户故事，还可以包含其他类型的条目。

以下是产品待办事项列表中可以包含的内容：

• 用户故事：这是最常见的条目，以“作为[角色]，我想要[功能]，以便[价值]”的格式描述功能需求。
• 工作任务：这些是与产品功能开发不直接相关的具体待办事项。例如：设置产品测试服务器。
• 知识任务：这是需要学习或研究的事项。例如：评估数据库连接的编程选项。
• 缺陷：这是产品代码中需要关注的错误。

小测验：以下哪些项目可以包含在产品待办事项列表中？
A. 用户需求
B. 非工作相关职责
C. 缺陷
D. 产品愿景

正确答案是 A 和 C。用户需求以用户故事的形式进入待办事项列表，缺陷也会被列在其中。产品愿景可能指导用户需求的创建，但不会明确列在待办事项列表中。非工作相关职责同理。

如何创建待办事项列表？

产品待办事项列表是Scrum（一种敏捷方法）中的一项技术。因此，它应该是动态的，并专注于与客户的互动。

当您与客户一起编写用户故事时，首先要做的就是将它们放入这个列表中。最初，列表没有特定的顺序。事实上，待办事项列表在最初阶段就是一个包含所有理想中应构建到最终产品中的事项的无序集合。

在创建每个要放入待办事项列表的用户故事时，请确保为其分配一个唯一的用户故事标识符。这很重要，因为它为项目中的每个人提供了一个参考框架。引用某个故事时，您无需复述其内容，只需引用其标识符即可。

标识符的分配方式并不重要，但一个简单的方法是使用顺序数字。将想到的第一个故事标记为1，第二个为2，依此类推。

如何确定优先级？

一旦您有了列表，下一步就是请客户为每个故事指定优先级。然后，客户将之前无序的用户故事列表按照从最高到最低的优先级进行排序。

目标是让最有价值的功能排在待办事项列表的顶部，最不重要的功能排在底部。这会打乱按标识符排序的顺序，但这没关系。用户故事标识符更多是一种跟踪机制，而非排序工具。

优先级排序为您的开发团队提供了开发重点。他们只需关注从列表顶部提取任务即可。同时，这也迫使您的客户思考他们真正需要和想要什么，从而经常引发客户与开发团队之间的对话。

然而，这种对话并非总能自动发生。可能会出现客户只专注于确定优先级，而开发人员只专注于估算实现每个用户故事所需工作量的情况，这会在他们之间形成一种隔阂。在敏捷开发中，应该鼓励讨论和协作，让双方都能理解某个用户故事具有特定优先级的原因，以及某个工作量估算具有特定数值的原因。

您能做的最好的事情就是尽可能与客户协作，并允许您的开发团队在整个优先级排序和规划过程中与客户沟通。

优先级确定后做什么？

现在，您已经与客户一起创建了待办事项列表，并且所有条目都已确定了优先级。您的所有用户故事都已编号，并根据对客户的优先级从高到低排序。

下一步就是以这些优先级为参考点，开始规划您的项目。虽然这将在《敏捷规划与软件产品》课程中详细讲解，但简单来说，用户故事会从待办事项列表中取出，并放入称为“冲刺”的特定时间间隔内要完成的工作块中。

小测验：在Scrum中，哪个角色负责创建用户故事并确定其优先级？
A. 产品负责人
B. 开发团队
C. 客户
D. 团队领导

正确答案是 A，产品负责人。在Scrum中，产品负责人负责确保产品待办事项列表是最新的。客户、团队领导或开发团队成员可能担任产品负责人角色，但如果他们要负责更改产品待办事项列表，他们就必须是产品负责人。

总结

本节课中，我们一起学习了产品待办事项列表（Product Backlog）的概念。我们了解到它是一个动态的、包含用户故事、工作任务、知识任务和缺陷的列表。创建列表后，关键在于与客户协作，为所有条目确定优先级，从而为开发团队提供清晰的工作重点。产品负责人是维护和管理这个列表的关键角色。掌握待办事项列表是进行有效敏捷项目规划的基础。

059：客户需求与软件需求

概述

在本节课中，我们将要学习产品待办事项列表（Product Backlog）的核心概念、动态特性及其在Scrum敏捷开发中的重要作用。我们将了解如何通过它来管理用户故事、应对需求变化，并确保项目始终围绕最高优先级的需求展开。

---

产品待办事项列表的动态特性 🗓️

上一节我们介绍了用户故事和优先级排序。本节中我们来看看产品待办事项列表如何在实际项目中动态演变。

客户设定为高优先级的用户故事计划被更早完成。重要性较低的故事则计划在后期发布。然而，由于Scrum专注于一次一个冲刺的开发节奏，这为当前冲刺之后的计划留下了很大的调整空间。

你只需要专注于规划下一个冲刺。当该冲刺完成后，客户可以添加新的用户故事、重新评估优先级，并相应地调整你的冲刺计划。这意味着需求可能改变其最初计划的优先级。

事实上，这种情况非常普遍。你经常会发现，当你的开发团队在一个冲刺中愉快地开发一组用户故事时，客户决定需要做出一些改变。也许一个先前低优先级的需求现在变得极其紧急。也许一个先前高优先级的需求现在完全不再需要。或者，你的客户想到了一个新功能，于是更多的用户故事被添加到待办事项列表中。

这最终可能导致其他事项的优先级发生变动。当然，你也肯定会发现需要解决的缺陷。你的待办事项列表必然会随着时间的推移而演变。它会移动、增长、缩减并改变顺序。这都没问题。

在Scrum中，唯一不允许这种变动的地方，是当前正在进行开发工作的冲刺期间。除此之外，如果你为了适应需求变化而调整计划，那是完全可以的。事实上，这是被鼓励的。只是不要觉得事情从一开始就一成不变。那不仅不现实，还会给你的项目带来大量问题。

---

行业访谈：产品待办事项列表的实际应用 🏢

接下来，让我们通过一段访谈，看看产品待办事项列表在行业中是如何被使用的。

产品待办事项列表通常是一个按优先级排序的工作项列表，它交付客户在特定版本或产品中期望的价值。放入产品待办事项列表的内容类型包括新功能、增强功能，甚至是现有产品版本中导致缺陷的问题。其他如架构工作、技术债务等，也可能是产品待办事项列表包含的项。

产品待办事项列表上的需求形式通常被指定为用户故事。用户故事通常由角色、需求和价值三部分组成，其格式可以概括为：
作为一个 <角色>， 我想要 <需求>， 以便于 <价值>。

待办事项列表的优先级排序可以通过一个称为“待办事项列表梳理”的过程来完成。这个过程包括检查产品待办事项列表的内容，并尝试使其与业务优先级、技术可行性以及代码本身的实际情况保持一致。

产品待办事项列表本身是相当动态的。因此，在版本发布之初，它可能与版本发布之末的样子大不相同。其中的事项可能会通过待办事项列表梳理本身发生转变，也会因为不断变化的业务需求和优先级，以及团队自身发现了之前未知的新技术依赖而改变。这些也都是需要放入待办事项列表并确保得到处理的事项，以满足待办事项列表所涵盖的整体工作目标。

---

测验：Scrum待办事项列表的组成部分 ❓

以下是关于Scrum待办事项列表组成部分的一个小测验。

以下哪些是Scrum待办事项列表的组成部分？你可以选择多个答案。
A. 缺陷
B. 客户邮件
C. 知识性任务
D. 工作任务
E. 业务需求

正确答案是A、C和D。缺陷、知识性任务和工作任务都可以包含在Scrum待办事项列表中。

---

总结

本节课中我们一起学习了产品待办事项列表。它是一个非常有价值的工具，对Scrum至关重要。它允许你组织工作，轻松查看项目的优先级所在，并基于这些优先级进行规划。产品待办事项列表在敏捷开发中运作良好，因为它为你的客户和团队提供了很大的灵活性。

在下一课中，我将讨论另一种用于组织用户故事的方法——故事地图。我们下一课见。

软件产品管理课程3：《客户需求与软件需求》：3-3-5：用户故事地图

在本节课中，我们将要学习一个用于组织和规划需求的重要工具——用户故事地图。上一节我们介绍了Scrum产品待办事项列表，本节中我们来看看如何通过故事地图更直观地展现和管理需求。

用户故事地图是一种以更丰富的视觉细节来呈现产品待办事项列表的绝佳方式。本质上，它是一种将待办事项列表中的用户故事，按照更具体的功能类别进行分组的方法。

以下是一个故事地图的示例。假设你正在开发一个简单的电子邮件程序。你的客户提供了一份需求列表，其中包含如下用户故事：

• 作为一个作者，我希望能够撰写纯文本消息，包含收件人、主题行和正文，以便我能以基本方式指导和传达我的消息内容。
• 作为一个读者，我希望能够在收到邮件时打开它们，以便我能阅读最新的消息。
• 作为一个读者，我希望能够将消息存储到存档中，以便我能为将来参考而保留消息。
• 作为一个读者，我希望能够在我的存档中搜索消息，以便我能快速找到相关消息，而无需手动浏览。
• 作为一个作者，我希望能够将文件附加到我的消息中，以便我能为我的消息添加额外信息。
• 作为一个读者，我希望能够打开我消息上的任何附件，以便我能查看所收到消息的额外信息。

你可能已经可以看出这些故事如何被分组。你可以使用产品的基本功能作为类别标题。这里的基本功能是：撰写和发送、阅读、接收和存储以及搜索。如果将每个故事放入其相应的类别，你就能立即看出什么属于哪里，以及可能缺少什么。然后，客户可以根据自己的判断，对这些类别内的故事进行优先级排序。这样一来，一个可能令人望而生畏的需求列表，就变成了一套组织有序、易于管理的待实现功能集。

现在你已经了解了故事地图的创建方式。请思考一下，创建故事地图可能为你的项目带来哪些好处。

以下是故事地图可能带来的好处，请选择你认为正确的选项：
A. 在初始规划阶段节省时间。
B. 简化优先级排序。
C. 让你对项目将如何发展有一个整体视图。
D. 提供详细的开发计划。

正确答案是B和C。故事地图简化了优先级排序，并让你对项目的发展有一个整体视图。它不会在初始规划阶段节省太多时间，但可能会在后续过程中节省时间。请记住，故事地图不是一份开发计划。

以上是故事地图的一些好处。那么，与经典的产品待办事项列表相比，故事地图还提供了哪些改进？

故事地图在经典产品待办事项列表的基础上提供了许多改进。首先，它让你的待办事项列表更具可追踪性和视觉感。你不再需要费力管理一个大列表的优先级，而是被迫将事情分解到各个类别中。

另一个改进是，它让你能够看清各个用户故事之间的关系。故事地图让你看到这些需求是如何组合在一起的，而不是处理一堆按优先级排序的需求。通过可视化需求之间的联系，你可以非常容易地发现是否有遗漏之处，轻松识别需求中的任何缺口并相应地填补它们。

故事地图的另一个巨大好处是，它让你的开发人员对产品应如何作为一个整体来构建有了概念。许多产品都有多个可被视为主要功能的类别或功能。在经典的一维产品待办事项列表中，来自一个功能组的用户故事很容易压倒来自另一个功能组的用户故事。然而，在故事地图中，地图顶行的所有用户故事都具有相同的重要性级别。这不仅简化了优先级排序，还让你了解产品在每次迭代中能做什么。

如果你将每个水平行视为产品的一个发布版本，那么你就可以看到产品如何随着你逐行向下移动地图而演进和增长。在我之前给出的例子中，你的产品可能会从仅支持基于文本的交互，发展到支持多媒体文件的传输。你不是通过只关注一个类别来构建产品，故事地图确保你将精力均匀地分配到各个功能上。故事地图为开发人员的工作提供了上下文，而不是构建一个可能无法完全满足客户的单一类别功能。它表明，在转向更复杂的工作之前，最好先实现简单的功能。你不会构建一个能发送多媒体和文本电子邮件，却无法阅读它们的电子邮件系统。故事地图提供了有时识别这些依赖关系所需的上下文。这是敏捷原则中“构建可工作的软件”的一个绝佳例证。你不是在构建一个任意的需求列表，而是在实际展示整个产品在各个阶段如何组合在一起。

如果你之前学习过我们的软件过程和敏捷实践课程，你会看到看板是什么样子。这里需要特别指出，故事地图不是看板的替代品。看板是一种展示项目当前状态和跟踪任务进展的方式。而故事地图是一种在二维结构中规划和组织用户故事的方式。实际上，你可以同时使用故事地图和看板来规划和跟踪项目，这并不少见。

因此，故事地图的核心只是一种让你的需求变得更好的方法。它为项目中的每个独立需求提供了上下文，并为项目带来了更强的组织结构。当然，故事地图仍然支持软件产品中不可避免的变更。甚至可以说，它们比经典的产品待办事项列表更好地支持变更。它们让开发人员和客户对产品的整体性有所感知，快速了解事物是如何组合在一起的。

在本节课中，我们一起学习了用户故事地图的概念、创建方法及其优势。故事地图通过视觉化、分类和提供上下文，显著改善了需求的组织和管理方式，帮助团队更好地理解产品全貌和功能演进路径。在下一个模块中，Morgan将与你探讨更多改进需求的方法。

061：用户故事的质量标准 📋

在本节课中，我们将学习如何确保用户故事具备高质量。上一节我们介绍了INVEST助记符，它概括了用户故事应满足的核心标准。本节中，我们将扩展讨论其他几个关键质量标准。

高质量的用户故事有助于保持开发进度，避免错误和混淆。例如，用户故事应定义得足够小且易于理解，能提供价值，并能被清晰地测试是否完成。

除了INVEST标准，为确保质量，需求（尤其是用户故事）还应满足其他几项标准。我们希望用户故事同时具备正确性、完整性、清晰性、一致性、可行性和可追溯性。

接下来，我们将逐一探讨这些标准的重要性，并回顾餐厅示例来加深理解。您还将有机会测试自己的知识，判断某些用户故事是否符合这些标准。

那么，让我们开始吧。

正确性 ✅

首先，我们来讨论用户故事的正确性。可以想象，用户故事正确至关重要。如果用户故事是错误的，开发团队将花费时间开发一个并非客户本意的功能。

因此，与客户仔细审查用户故事，确保其表述正确且是真正需要开发的内容，这一点非常重要。

例如，考虑以下用户故事：

作为一名顾客，我希望在将订单提交给厨房后，能够修改我点的菜品，以便我能根据自己的喜好定制其准备方式。

这是一个不正确的需求。根据场景描述，顾客可以在下单前修改菜品，但从未提及允许在之后进行修改。

想象一下，如果您的开发团队实现了这个错误的用户故事。当您向客户演示时，他们可能会不满意，并说类似这样的话：“这对厨房员工来说将是一场噩梦。” 😊 您的开发人员因此浪费了宝贵的开发时间，而这些时间本可用于开发正确的功能。

回顾一下客户的要求：

……顾客在将订单发送到厨房之前，可以在另一个页面上指定对餐点的更改以及他们可能有的任何饮食限制……

基于此，以下哪些用户故事是正确的？

以下是需要判断的用户故事选项：

• A. 作为一名顾客，我希望浏览所在餐厅的菜单，以便了解他们提供哪些菜品和饮品。
• B. 作为一名顾客，我希望能够向厨房说明我的饮食限制，以便避免菜肴中的某些成分。
• C. 作为一名顾客，我希望能够定制一份菜单上没有的菜品，以便获得独特的用餐体验。
• D. 作为一名顾客，我希望能够查看营养信息，以便选择适合我饮食的菜肴。

根据客户的要求，只有选项 A 和 B 正确地体现了客户的请求，因此它们是正确答案。选项C不正确，因为顾客应该能够修改现有菜品，但不能定制菜单上没有的菜。选项D不正确，因为这不是客户提到的功能。

完整性 📦

上一节我们讨论了正确性，确保用户故事准确反映客户意图。本节我们来看看完整性。一个完整的用户故事应包含成功实现该功能所需的全部必要信息。

如果用户故事不完整，开发团队可能会做出错误的假设，导致最终产品不符合预期。通常，用户故事的“完成定义”有助于确保其完整性。

以餐厅应用为例，考虑这个用户故事：

作为一名顾客，我希望能够将菜品添加到我的订单中。

这个用户故事不完整。它缺少关键细节，例如：顾客如何浏览菜单以找到菜品？添加菜品时是否需要指定数量或定制要求？订单在提交前是否可见？一个更完整的版本需要涵盖这些方面。

清晰性 ✨

接下来是清晰性。清晰、明确、无歧义的用户故事对于开发团队准确理解需求至关重要。模糊的表述会导致不同的解读，从而产生错误。

例如，对比这两个用户故事：

1. 作为一名顾客，我希望快速收到我的订单。
2. 作为一名顾客，我希望在提交订单后，能在15分钟内收到菜品确认通知。

第一个表述不清晰（“快速”是主观的）。第二个表述清晰，因为它使用了可衡量的具体时间（15分钟）。

一致性 🔄

现在我们来探讨一致性。用户故事应在内部以及与项目其他需求之间保持一致。不一致的需求会导致混乱、返工和潜在的错误。

例如，考虑这两个用户故事：

• 故事A：作为一名顾客，我希望通过扫描桌上的二维码来访问菜单。
• 故事B：作为一名顾客，我希望服务员给我一个纸质菜单来点餐。

这两个故事在访问菜单的方式上存在不一致。团队需要与客户澄清哪种方式是预期的，或者是否两者都支持，并相应调整故事。

可行性 🛠️

然后是可行性。用户故事必须在给定的技术、预算和时间约束下是可实现的。提出一个无法实现的故事会浪费资源并导致挫折。

例如，这个用户故事可能不可行：

作为一名顾客，我希望应用能通过手机摄像头实时分析菜品成分，以检测过敏原。

这可能需要目前尚不成熟或成本极高的技术。团队需要评估其可行性，或许可以提出一个更简单的替代方案（如手动输入过敏原或从预定义列表中选择）。

可追溯性 🔍

最后是可追溯性。这意味着每个用户故事都应该能够追溯到其来源（如客户访谈、市场研究），并且能够向前追踪到其实现（如代码、测试用例）。这有助于理解变更的影响、进行影响分析以及在出现问题时进行调试。

例如，一个用户故事卡片或工具条目应链接到：

• 向后追溯：产生此需求的客户会议记录或功能请求票证ID。
• 向前追溯：实现该功能的代码提交、相关的单元测试和验收测试用例。

---

本节课中，我们一起学习了确保用户故事高质量的六个附加标准：正确性、完整性、清晰性、一致性、可行性和可追溯性。结合INVEST原则，这些标准将帮助您创建出能够有效指导开发、满足客户期望并最终交付成功软件产品的用户故事。记住，编写高质量的用户故事是一个迭代和协作的过程，需要与客户和开发团队持续沟通。

062：29_02_3-4-1a-用户故事的标准

在本节中，我们将学习如何评估和撰写高质量的用户故事。用户故事是描述软件需求的常用工具，但并非所有用户故事都同样有效。为了确保开发过程顺利并最终交付符合预期的产品，用户故事需要满足一系列明确的标准。

我们将逐一探讨这些标准：正确性、完整性、清晰性、一致性、可行性和可追溯性。掌握这些标准将帮助你创建出对团队和客户都有价值的用户故事。

完整性

上一节我们介绍了用户故事的正确性，本节中我们来看看完整性。完整的用户故事意味着包含了描述问题所必需的所有需求。

由于你的开发团队将根据产品待办事项列表中的用户故事来开发解决方案，如果需求缺失，相应的功能就不会被实现。

像故事地图这样的工具对于判断用户故事是否缺失非常有用。

清晰性

接下来，让我们讨论如何使用户故事清晰。这意味着用户故事易于理解、精确且只有单一的解释。

这个标准要求很高。当你为了消除歧义而审查用户故事时，会发现一个句子可以有多种不同的解释方式，这确实令人大开眼界。

希望你能看到用户故事存在多种解释方式所带来的风险。如果客户用一种方式理解，程序员用另一种方式理解，而测试人员又用第三种方式理解，就很难判断谁是正确的，以及究竟应该开发什么。

以下是减少歧义的一个重要实践：

• 进行需求技术审查与修复练习：在这个练习中，最好由项目外部人员根据本课的所有标准来审查需求。其中一部分工作就是审查需求的歧义性。

我们将在下一课详细讲解如何撰写没有歧义的用户故事，但这里先看一个例子。假设有一个需求是这样写的：“作为一个顾客，我希望成人和儿童菜单上都有游戏，以便我们在等待食物时有有趣的事情可做。”

“都有”这个词在这个用户故事中造成了歧义。这个用户故事可能意味着儿童菜单上有儿童游戏，成人菜单上有成人游戏；但也可能被解释为儿童菜单和成人菜单上有相同的游戏。

除了依赖自然语言描述，另一种使需求更清晰的方法是使用视觉描述来补充你的需求，例如线框图和故事板。

我们将在本模块后面进一步探讨如何识别和修复有歧义的需求。

一致性

现在我们来谈谈用户故事的一致性。一致的用户故事意味着需求之间不会相互冲突。

这显然会在后续开发过程中引发问题。

你的客户和开发团队完成了一份用户故事列表，并希望你在下一次讨论会议前进行审查。在这次审查中，你需要确保用户故事是一致的。

以下哪些用户故事相互冲突？请选择两个彼此不一致的用户故事。

• A. 作为一个儿童顾客，我希望自己点餐，以便得到我想要的餐点。
• B. 作为一个顾客，我希望在点餐后查看订单，以确保我们点得正确。
• C. 作为厨房员工，我希望查看已收到的订单，以便知道要准备哪些菜肴。
• D. 作为一个顾客，我希望能够为我的家人点餐，以便监控他们吃什么。

答案A和D不一致。因为在答案A中，儿童顾客有自由点餐的权利，而在D中，他们没有。所有其他组合都是彼此一致的。因此，答案A和D是正确答案。

可行性

接下来，我们讨论用户故事的可行性。这意味着每个需求都可以在指定的成本和进度约束内，利用现有的技术、工具、资源和人员来实现。

如果你经常遇到不切实际的用户故事，我欣赏你的雄心，但这是一个不满足就会带来风险的标准。你需要诚实地审视你的资源、团队、进度和预算。你真的能完成所有承诺的需求吗？

不满足这个标准将导致额外的成本和客户的不满。就我个人而言，这是我希望避免的两件事。

可追溯性

我们希望满足的最后一个标准是用户故事的可追溯性。这意味着每个需求都以某种可追踪的方式与相关的设计和实现工件（如代码、测试）相关联。

简单来说，对于每个需求，都有对应的代码和测试。同时，每一段源代码都对应某个需求，并且每一段源代码都有测试。

让你的用户故事可追溯，意味着只编写必要的代码，并且所有需求都经过测试。这两点都是你希望在开发过程中具备的优秀品质。

你可以为每个需求设置一个唯一的标识符，以帮助开发人员在代码、测试、错误报告和变更日志中引用它。

总结

现在你知道了用户故事应该满足的标准。

在上一模块中，你了解到用户故事应该满足 INVEST 标准，即它们应该是独立的、可协商的、有价值的、可估算的、小的和可测试的。

在本节课中，你学习了用户故事还应该是正确的、完整的、清晰的、一致的、可行的和可追溯的。

改进你的用户故事以满足这些标准，将能防止项目中出现错误或不必要的工作，高质量的用户故事会带来高质量的产品。

063：识别与避免模糊需求

概述

在本节课中，我们将学习模糊需求的定义、识别方法以及如何避免它们。模糊需求是指那些可以以多种方式解释的需求，它们可能导致沟通误解和资源浪费。我们将探讨11类容易导致模糊的词语，并通过实例学习如何澄清需求。

---

模糊需求的危害

上一节我们介绍了需求管理的重要性，本节中我们来看看模糊需求可能带来的具体问题。

模糊需求会引发多种问题，因为它们可以被不同方式解读。这可能导致沟通误解，并最终导致软件被错误构建。这会浪费时间和金钱等资源。

什么是模糊需求？

一个模糊需求是指可以以多种方式解释的需求。它可能不总是提供清晰或足够的细节来进行正确解读。

识别模糊需求的词语类别

我们将探讨11类可能导致需求模糊的词语。请注意，使用这些词语并不总是导致模糊，但需要仔细考虑，并可能需要添加额外信息来消除模糊性。

以下是11类词语：

1. 间接词语
2. 模糊词语
3. 劝说词语
4. 完成词语
5. 限定词
6. 比较词
7. 数量词
8. 代词
9. 方位词
10. 时间词
11. 连接词

1. 间接词语

这类词语暗示某事可能发生，但没有具体说明如何或何时。例如：should（应该）、could（可以）、may（可能）、will（将）。

如果陈述没有解释事件应该或可以发生的具体条件，那么“should”和“could”可能表示模糊。如果需求中包含了这些条件，则能消除模糊。“may”一词的作用类似。

考虑以下用户故事示例：

作为一个在线扑克玩家，我可能赢钱，以便我能因赢得游戏而获得奖励。

在这个例子中，不清楚在线扑克玩家在什么条件下赢钱。你可以通过指定这些信息来澄清这个用户故事。

更好的写法是重写这个用户故事：

作为一个在线扑克玩家，当我在扑克游戏中战胜对手时，我收到钱，以便我能因赢得游戏而获得奖励。

最后，间接词语类别中要涵盖的最后一个词是“will”。如果陈述没有指定事件何时发生，那么“will”是模糊的标志。它是一直发生还是有时发生？如果一个事件每次都发生，最好使用“must”（必须）。如果事件只有时发生，则需指定它发生的条件。

2. 模糊词语

模糊词语通常是描述中缺乏细节的动作、对象名称或说法。问题不在于存在多种解释可供选择，而是没有足够的细节来进行任何解释。

以下是模糊词语的类别示例：

• 模糊动作：例如 processed（处理）、handled（处理）、operated（操作）。
• 模糊对象名称：例如 item（项目）、entity（实体）、unit（单位）。
• 模糊说法：例如 as appropriate（酌情）、where applicable（适用时）、within reason（在合理范围内）。

对于模糊对象名称，要么用更具描述性的名称替换这些术语，要么确保该术语在产品术语表中定义并一致使用。对于模糊说法，需要明确具体是什么决定了“appropriateness”（适当性）、“applicability”（适用性）或“reason”（合理性）。

3. 完成词语

这类词语的例子包括：and so on（等等）、and so forth（等等）、et cetera（等等）。这些词语通常暗示列表中还有更多可以命名的成员，但为了简洁而没有列出。

当你列出事物时，请确保提供列表中包含内容的必要细节。通用的归属规则可能并不明显，因此不要将规则留待解释。

另一个属于此类别的词是“also”（也）。这个词通常出现在对现有陈述的补充中。如果脱离上下文理解添加的从句，或者它与前面的陈述不一致，可能会导致模糊。因此，如果你在需求中使用“also”一词，请确保提供上下文，说明“also”从句的含义。

4. 劝说词语

这些词语包括：clearly（显然）、certainly（当然）、obviously（显然）。如果一个陈述是“obvious”（明显的），它对所有读者来说都真的明显吗？为什么读者应该相信它？这个陈述是在断言观点而不是事实吗？用户故事不需要说服，因此应避免使用这些词语。

5. 限定词

到目前为止，我们看到的类别和示例因为缺乏信息而导致模糊。现在我们将看看那些因为限定或修改某些条件而可能表示模糊的词语。

限定词的例子包括：all（所有）、every（每个）、only（仅）、no（无）、never（从不）、always（总是）、sometimes（有时）、often（经常）、usually（通常）。

“all”和“every”导致模糊的原因相似。考虑以下用户故事：

作为管理员，我希望所有社交媒体用户使用一个账户，以便我能跟踪他们的使用情况。
作为管理员，我希望每个社交媒体用户使用一个账户，以便我能跟踪他们的使用情况。

这两个用户故事都可能意味着所有社交媒体用户使用同一个账户，也可能意味着每个用户拥有自己的账户。

接下来，我们看看“only”这个词。请谨慎使用这个词，尤其是在英语中，因为根据你将“only”放在句子中的位置，它可能导致含义完全不同。

考虑这个句子：

Premium account holders are allowed to read the full online article.
（高级账户持有者被允许阅读完整的在线文章。）

我们可以插入“only”一词使句子表达不同的意思。

• Only premium account holders are allowed to read the full online article.
  （只有高级账户持有者被允许阅读完整的在线文章。）
  • 这意味着其他账户持有者不允许阅读完整的在线文章。
• Premium account holders are only allowed to read the full online article.
  （高级账户持有者只被允许阅读完整的在线文章。）
  • 这意味着高级账户持有者不允许阅读完整文章以外的任何内容。
• Premium account holders are allowed to read the full online article only.
  （高级账户持有者被允许阅读仅完整的在线文章。）
  • 同样表示高级账户持有者只被允许阅读完整的在线文章。
• Premium account holders are allowed to read the only full online article.
  （高级账户持有者被允许阅读唯一的完整在线文章。）
  • 这意味着只有一篇完整的在线文章可用，并且高级账户持有者被允许阅读它。

使用“only”时，请注意你用它来修饰句子以表达正确的含义。

6. 比较词

比较词是用于比较两个或更多事物的短语。如果我们使用比较两辆车大小的例子，我们可以使用以下短语：

• Car A is the same as car B. （车A与车B相同。）
• Car A is bigger than car B. （车A比车B大。）
• Car A is the biggest. （车A是最大的。）
• Car A is more spacious than car B. （车A比车B更宽敞。）
• Car A is as big as a truck. （车A和卡车一样大。）

这些短语中的每一个都是模糊的，或缺乏细节。当我们比较车A和车B时，我们指的是物理整体尺寸、高度、宽度、内部空间、载货容量、头部空间还是发动机尺寸？比较两个对象时，请务必具体说明正在比较对象的哪个特定属性。

同时，注意使用以“-er”结尾的单词，如 bigger（更大）、smaller（更小）或 wider（更宽）；或以“-est”结尾的单词，如 biggest（最大）、smallest（最小）或 widest（最宽）。

7. 数量词

涉及数量的词语也可能导致模糊。这些词的例子有：a/an（一个）、some（一些）、most（大多数）、few（少数）。

“a”或“an”是你经常遇到的词。考虑以下例子：

作为一个填字游戏解谜者，我希望应用程序有一个填字游戏，以便我能在喜欢的消遣中挑战自己。

“一个填字游戏”是指应用程序上只有一个填字游戏，还是指应用程序上至少有一个填字游戏？为了避免“a”或“an”带来的模糊，请使用量词，如具体数字或至少某个最小数量。

例如，你可以说：

作为一个填字游戏解谜者，我希望应用程序至少有一个填字游戏，以便我能在喜欢的消遣中挑战自己。

如果陈述没有给出具体数量或涉及哪些项目，那么“some”、“most”和“few”这些词就表示模糊。

8. 代词

代词是诸如 he（他）、she（她）、it（它）、we（我们）、you（你/你们）、they（他们）、us（我们）、our（我们的）、this（这个）、that（那个）等词语。

代词可能导致模糊短语，因为可能不清楚代词代表的是哪个名词。例如，在用户故事中：

作为一个虚拟农场主，我希望它生长，以便我能卖掉它换取虚拟资金。

不清楚“it”指的是什么。“it”可能指的是虚拟农场本身、虚拟作物或虚拟农场动物。你应该定义并使用更具体的术语来避免混淆，而不是使用代词。

9. 方位词

方位词的例子有：after（在...之后）、before（在...之前）、following（跟随）、last（最后的）。对于这些词，让我们使用数据库条目的例子。

如果我们说条目A出现在数据库中的条目B之前，这可能意味着条目A直接出现在条目B之前，或者出现在数据库中条目B之前的任何位置。类似地，我们可以说条目B出现在数据库中的条目A之后，或者说条目B出现在数据库中跟随条目A。所有这些短语出于同样的原因都是模糊的：你需要更明确地指定条目出现的位置。

现在看看这个短语：“I am making changes to the last entry.”（我正在修改最后一个条目。）这个短语中的“last”一词导致了很多模糊。这可能意味着我正在修改上一个条目，也可能意味着我正在修改出现在最末尾的条目，还可能意味着没有更多条目将被添加，而这个条目将是最终条目。

10. 时间词

接下来，我们将看一个与方位词类似的类别，即时间词。它们与时间或事件相关。时间词的例子有：when（当...时）、for（持续）、until（直到）、from（从...起）、current（当前的）、latest（最新的）。如果你指的是时间而不是位置，也可以将方位词包含在此类别中。

让我们先看看“when”这个词。考虑以下例子：

作为一个跑步者，我希望当我开始绕跑道跑一圈时，圈速计时器设置为0，以便我能监控我的配速。

这可以解释为：计时器在跑步者开始跑一圈的时刻设置为0。它也可能意味着：计时器在跑步者第一次开始跑一圈时设置为0。但它还可能意味着：计时器在跑步者每次开始绕跑道跑一圈时都设置为0。

接下来，让我们看看例子中的“for”这个词：

作为一个露营者，我希望产品能显示未来三天的天气，以便我能看到露营期间的天气情况。

这个用户故事可以有两种不同的解释。一种方式是产品显示一个三天的天气预报。但另一种方式是产品在接下来的三天内显示每日天气，之后停止显示。

11. 连接词

我们要看的最后一个类别是连接词。这些是连接两个或更多短语或对象的词语。连接词的例子有：and（和）、or（或）、both（两者都）。

首先，让我们看看由“and”一词可能引起的模糊。考虑用户故事：

作为一个零售商人，我希望打印清仓标识，以便商店在有太多商品时和季节变化时进行促销。

那么，这是否意味着商店在有太多商品时进行促销，并且在季节变化时也进行促销？还是暗示了一个双重条件，即商店只有在同时有太多商品并且季节正在变化时才进行促销？在第一种情况下，将需求分解为两个独立的需求来分别满足是清晰的。

最后，“or”一词也会导致模糊。“or”的问题在于它没有区分在两个条件都成立的情况下会发生什么。

其他发现模糊的方法

在你的用户故事中扫描特定词语作为模糊迹象，并不是确定你是否有不明确需求的唯一方法。

另一个确保你的需求和术语表都没有模糊的好方法是，用术语表中的定义替换用户故事中的术语。你的用户故事仍然有意义吗？你的术语表定义是否恰当地代表了该术语？通过这样做，你可能会发现需要向术语表中添加更多术语、重新定义术语表中的术语，或者重写一些用户故事。

总结

在本节课中，我们一起学习了模糊需求的定义及其危害，并深入探讨了11类容易导致需求模糊的词语，包括间接词、模糊词、劝说词等。我们通过具体实例分析了每类词语如何引发歧义，并学习了通过提供具体条件、使用明确术语、重写用户故事等方法来消除模糊性。记住，目标是使需求或用户故事的含义能够被开发人员准确理解，而非追求语言的绝对完美。在敏捷实践中，与利益相关者进行对话是澄清需求的关键。

064：课程总结

在本节课中，我们将对《客户需求与软件需求》这门课程进行全面的回顾与总结。

恭喜你完成了关于客户需求与软件需求的课程。

如果你也学习了我们的《软件过程与敏捷实践》课程，那么你现在已经完成了我们在导论课程中提到的“INiP”结构的两条“腿”。你已拥有一个良好的知识基础，可以继续构建。

接下来，我们将为“INoKSH”结构添加的“身体”部分，代表的是《软件产品的敏捷规划》课程。如果你尚未学习《软件过程与敏捷实践》课程，你需要在继续前进之前，先完成你学习旅程中的那条“腿”。

现在，让我们花些时间来回顾一下本课程所涵盖的内容。

课程内容回顾

在本课程中，Bradley 在第一模块首先介绍了需求的定义。他将需求定义为对客户需求的具体描述。

你还学习了五个需求活动。这些活动是：

• 获取需求
• 表达需求
• 排定需求优先级
• 分析需求
• 管理需求

此外，Bradley 还在第一模块带你了解了不同类型的需求。需求的类型包括：

• 业务需求
• 业务规则
• 用户需求
• 功能需求
• 非功能需求
• 外部接口需求
• 物理环境需求
• 开发人员约束

接下来，你学习了软件开发中涉及范围变更的问题，以及需求与设计之间的区别。

在模块2中，我们回顾了不同类型的用户。

• 主要用户是直接与产品交互的用户。
• 次要用户是偶尔使用产品或通过中介与产品交互的用户。
• 三级用户是受产品使用影响或对产品做出决策的人。

我们还讨论了用户可能遇到的约束或限制，以及如何设计产品以适应这些限制。

之后，我们探讨了在获取需求活动中如何让用户和客户参与进来。我们研究了应该向客户提出的好问题以及应避免的问题，并为你准备了与客户的下一次会议。

然后，我们介绍了在表达需求活动中，表达需求的三种不同方式。这些方法是：

• 用例
• 线框图
• 故事板

接着，你进入了模块3。Bradley 向你展示了更多表达需求的方法，以及它们如何融入敏捷开发。之后，Bradley 向你介绍了用户故事。你将在敏捷开发中频繁使用用户故事。

一个用户故事的结构是：作为一个 <角色>，我想要 <功能>，以便于 <价值>。

用户故事是一种简洁明了地展示“谁”、“做什么”以及“为什么”的简便方法。

Bradley 还向你展示了产品待办事项列表，以及如何使用故事地图来对已获取和表达的用户故事进行优先级排序和组织。

在最后一个模块中，我们探讨了要使你的需求和用户故事被视为高质量所应满足的标准。我们还回顾了需求中常见的模糊语言，并向你展示了如何识别和澄清这些模糊语言的方法。

总结与展望

以上就是本课程的全部内容。

如果你也完成了《软件过程与敏捷实践》课程，那么你现在已经准备好进入《软件产品的敏捷规划》课程了。在那门课程中，你将学习许多用于规划软件产品的敏捷实践。这些技术在今天业界被广泛使用。

你将体验的一些实践将侧重于估算、故事点和速率。你还将学习如何创建发布计划和迭代计划，以帮助组织需求和开发任务。最后，你将有机会研究风险计划。我们已在本专项课程中多次提到风险管理。在下一门课程中，你将学习并应用一些风险管理技术。

我们期待在《软件产品的敏捷规划》课程中与你相见。到时见。😊