2

Specification By Example 一书指出可以使用示例指定非功能性需求（通常称为 NFR）。

一位同事还告诉我，可以使用以下格式使用 SBE 故事指定非功能性需求：

Scenario: ...
   Given ...
   When ...
   Then ...

以下是取自wikipedia的功能性和非功能性需求示例：

系统可能需要向用户显示数据库中记录的数量。这是功能要求。这个数字需要保持多长时间是非功能性要求。如果需要实时更新数量，系统架构师必须确保系统能够在记录数量变化的可接受的短间隔内更新显示的记录计数。

问题1：非功能性需求可以指定为故事吗？

问题 2：非功能性需求是否应该被指定为一个故事？

问题3：故事会是什么样子？

4

5 回答 5

6

我将通过一个例子给出答案。

假设您的团队已经实施了以下故事：

Scenario: User can log in to the website
   Given I have entered my login credentials
   When I submit these credentials
   Then I get navigated to my home screen

回答问题 1) - 可以将非功能性需求指定为故事吗？

项目利益相关者给了你一个 NFR，内容如下：

对于所有网站操作，用户不应再等待 5 秒钟的响应。

您可以为此创建一个故事，如下所示：

Scenario: User can log in to the website in a timely fashion
   Given I have entered my login credentials
   When I submit these credentials
   Then I get navigated to my home screen
   And I should have to wait no longer than the maximum acceptable wait time

请注意，我没有强制指定“5”秒，而是将场景保持为声明性，而是指定“等待时间不超过最大可接受的等待时间”。

回答问题 2) - 是否应将非功能性需求指定为故事？

NFR绝对应该被指定为一个故事。

创建故事将允许估计此任务的复杂性（以便团队可以确定相对于过去的故事的难度），此外团队可以将故事分解为任务（可以以小时为单位进行估算，以便您可以确定团队是否可以在当前 sprint 中实施这个故事）。

因此，在我设计的示例中，团队可能已经实现了登录代码，但他们随后会确定如何实现登录时间不得超过 5 秒的要求。您还可以探索这个问题的反面，即如果登录时间超过 5 秒会发生什么？例如

Scenario: User encounters a delay when logging in to the website
       Given I have entered my login credentials
       When I submit these credentials
       And I wait for over the the maximum acceptable wait time
       Then the Production team is informed
       And the problem is logged
       And I get navigated to my home screen

最后，关于问题 3) - 故事会是什么样子？

我已经详细说明了答案 1) 和 2) 中的故事的样子

于 2013-10-11T23:23:04.750 回答
1

Q1：是的，他们绝对可以。看看那篇描述在用户故事中处理非功能性需求的文章。

Q2。从我的角度来看，如果您能够创建它们，那么以这种方式保存和跟踪它们真的很值得。但是引用这篇文章

没有神奇的敏捷实践可以帮助您发现 NFR。第一步是承担责任。如果团队发现这有助于保持这些可见性，NFR 可以表示为用户故事。但是，请注意，呈现此类故事可能会围绕针对更明显特征的工作优先级产生问题。

Q3。看看第一季度提到的文章。

于 2013-10-11T10:04:38.853 回答
1

我认为 NFR 的界限还没有得到所有人的完全认同。考虑这样一个故事：“作为经理，我的员工必须在 5 秒内得到所有回复，以避免雇用第二个数据输入人员并增加 50,000 美元的工资支出。” 我认为这是一个功能齐全的业务需求，以及任何关注最终用户体验的性能需求。

我将“传统”NFR 归类为受影响的人不在最终用户或利益相关者组织中的故事。“作为支持人员，我需要网站流量日志来帮助我解决问题，”或“作为软件维护人员，我需要块架构图来帮助我进行更改。” 像在任何用户故事中一样包含角色有助于确定优先级。如果您对此有任何疑问，它还有助于确定该 NFR 的利益相关者。

NFR 可能包括性能的某些方面，至少是那些不影响最终用户的方面。“作为系统管理员，我想为数据库分配不超过 10GB 的磁盘空间，以便使用 SQL Express 并避免昂贵的 SQL Server 许可证。”

考虑一个典型的 NFR，它可能只声明“数据库限制为 10GB”。这是一个没有意义或理由的任意数字，没有办法质疑它。拥有类似故事的角色和解释可以帮助每个人理解 NFR 有正当理由，所以当你优先考虑它们时，你可以提出聪明的问题。他们引发了这样的对话：“我需要将我的表空间扩展到 20GB，但是系统管理员有这个关于数据库大小的 NFR。SQL Server 许可证真的要花多少钱？天哪，这么多？好吧，我将非规范化一些表并节省几 GB 以适应它。”

于 2013-10-15T20:13:28.550 回答
1

正如@bensmith 和@siemic 所示，是的，您可以将 NFR 捕获为故事。

您应该以这种方式捕获它们吗？

我认为您不想将 NFR 作为常规专题报道的一部分。

大多数 NFR 适用于不止一个故事。“系统必须响应”意味着每个故事都需要定义最长等待时间。“系统不得消耗超过 10GB 的磁盘空间”意味着每个故事都需要考虑磁盘空间。故事中的“和”列表即使在微不足道的情况下也会变得难以管理。

如果产品所有者和团队都对此感到满意，您可能希望将 NFR 捕获为独立的故事。

例如：

Given I have a PC with at least a dual core processor 
  and 8GB of RAM
  and a gigabit connection to the system
when I interact with the system
then I never have to wait more than 5 seconds for a response
 and 90% of attempts respond within 1 second

这提供了明确的要求和可衡量的目标。您只需要确保每个故事都考虑到所有 NFR。

于 2015-07-02T12:12:25.990 回答
1

我认为你需要看几件事，NFR 应该遵循应用程序、软件、产品等的生命周期。备份和恢复场景应该定期覆盖，安全扫描和性能应该在生产和开发中进行测量。许多 NFR 需要开发团队以外的团队进行验证，因此不应期望编写脚本或代码来验证。因此，显然安全性、性能、可扩展性、弹性等可以而且应该在开发阶段或在代码投入使用之前进行测试。大多数 NFR 都可以写成故事，但正如我所说，我认为并不是所有的 NFR 都需要开发工作来覆盖它们。问候马丁

于 2016-06-28T19:17:27.700 回答