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

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

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

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

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

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

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

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

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

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

用户故事模板

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

  • 它是给谁的?
  • 它对系统的期望是什么?
  • 为什么它很重要(可选?)?

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

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

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

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

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

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

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

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

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

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

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

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

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

真实用户与用例参与者

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

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

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

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

编辑此自动售货机插图

相反,同一个用户可以扮演多个角色(即同一个人可以扮演不同的角色)。

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

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

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

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

注意:

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

参考

Leave a Reply

您的电子邮箱地址不会被公开。