使用用例和用户故事捕获功能需求 - IT 观察者随笔

Table of Contents hide

定义新产品、服务、流程或系统的第一步是定义需求，即特定的功能性或非功能性需求。

功能需求描述了产品或服务如何满足客户需求。这包括记录用户如何与产品或服务交互的用例中的特性和功能。
非功能性需求是有时对用户来说并不明显的操作和产品属性，包括性能、可用性、耐用性、安全性和财务（价格和成本）。

编辑此插图——功能需求与非功能需求

功能性需求可以被认为是产品需要为客户做的事情，而非功能性需求可以被认为是产品或服务在设计时需要满足的约束。

功能需求捕获系统的预期行为。这种行为可以表示为系统需要执行的服务、任务或功能。在软件开发行业，用例方法已迅速成为捕获功能需求的广泛实践。在它们起源的面向对象和 UML 社区中尤其如此，但它们的适用性并不限于面向对象的系统。

捕获功能需求的技术是什么？

功能需求通常以用例或用户场景的形式捕获。这些术语有时可以互换使用，但实际上它们的含义略有不同。

用例更多地关注系统以及它必须做什么才能满足用户的需求。
另一方面，用户故事从用户的角度展示产品功能，指定用户角色和他们想要实现的特定目标。

使用用户故事捕获功能需求

用户故事是一种快速捕获产品需求的“谁”、“什么”和“为什么”的轻量级方法。简而言之，用户故事是表达用户想要的需求的想法。用户故事很短，每个元素通常包含少于 10 或 15 个单词。用户故事是“待办事项”列表，可帮助您确定项目路径中的步骤。它们有助于确保您的流程和最终产品满足您的要求。

用户故事模板

用户故事仅捕获需求的基本要素：

它是给谁的？
它对系统的期望是什么？
为什么它很重要（可选？）？

以下是 70% 的从业者使用的简单用户故事格式：

角色 ——用户应该是与系统交互的实际人。

要尽可能具体
开发团队不是用户

动作 ——系统的行为应该写成一个动作。

通常每个用户故事都是独一无二的
“系统”是隐含的，没有写在故事中
主动语态，而不是被动语态（“我可以收到通知”）

收益 ——收益应该是一个真实世界的结果，它是非功能性的或系统外部的。

许多故事可能共享相同的利益声明。
好处可能是其他用户或客户，而不仅仅是故事中的用户。

如何用用例识别功能需求？

为了全面了解系统的功能需求，你必须知道系统是为谁服务的，即谁将使用系统？

这个问题的答案是：用例分析中的参与者

用例或用户故事捕获功能需求，其行为可以表示为系统需要执行的服务、任务或功能。用例定义了用户和系统服务之间的交互，这可以帮助定义正在开发的系统的功能需求。或者换句话说，产品或服务需要做什么才能满足客户的需求。

用例以“参与者”或“谁”开始，即产品或服务的特定用户。

参与者是在与系统交互中发挥作用的人或外部系统。参与者的实例可以是个人或外部系统；但是，每个参与者都提供了系统的独特且重要的视角，该视角对于参与者的每个实例（实际的人/用户）都是通用的。

真实用户与用例参与者

为了充分理解系统的用途，你必须知道系统是为谁服务的，即谁将使用它。不同的用户类型表示为演员（角色）。

角色和单个用户之间的区别在于，角色代表特定类别的用户，而不是实际用户。不同的用户可以扮演相同的角色，在这种情况下，每个用户构成一个参与者的实例。

参与者和参与者实例之间的这种区别如下所示：

下图显示了 Mary 和 John 是自动售货机客户的情况。当他们使用自动售货机时，每个人都由一个名为 customer 的参与者的实例表示，该参与者期望能够访问系统的某些功能（在本例中为购买食物的打印）。

编辑此自动售货机插图

相反，同一个用户可以扮演多个角色（即同一个人可以扮演不同的角色）。

例如，盖茨博士，他是计算机协会的委员会成员。他负责管理会员管理系统，例如添加和删除用户帐户。当他这样做时，他扮演一个称为管理员（Actor）的角色。然而，同样的盖茨博士也可能是计算机协会的成员。在这种情况下，他还将扮演一个名为“成员”（演员）的角色

如何通过识别系统的用例得到功能需求

可以通过向利益相关者询问以下类型的问题（他们必须从参与者的角度回答这些问题）来识别用例：

这个角色的用户想要完成什么？
为了履行这个角色，用户需要能够做什么？
担任此角色的用户的主要任务是什么？
该角色的用户需要检查、创建或更改哪些信息？
这个角色的用户需要系统通知什么？
该角色的用户需要通知系统什么？

注意：

用例通常用作发现和表示功能和系统需求的一种方式，因为用例定义了为实现特定业务目标所需执行的交互和任务。但是，它们通常不是定义非功能性需求（例如系统性能和质量）的好方法。