如何在故事/特征中记录非功能性需求(NFR)?

时间:2013-10-11 07:26:04

标签: bdd specifications user-stories

Specification By Example book表示可以使用示例指定非功能性要求(通常称为NFR)。

同事也告诉我,可以使用以下格式使用SBE故事指定非功能性要求:

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

以下是wikipedia

中的功能性和非功能性示例
  

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

问题1 :可以将非功能性要求指定为故事吗?

问题2 :是否应将非功能性要求指定为故事?

问题3 :这个故事会是什么样子?

5 个答案:

答案 0 :(得分: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,上面写着:

  

对于所有网站操作,用户不应再等待五次   响应的秒数。

您可以按如下方式为此创建故事:

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秒登录的要求。您还将允许能够探索这个问题的反面,即如果登录需要超过五秒钟会发生什么? e.g。

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)中的表现。

答案 1 :(得分:1)

Q1:是的,他们绝对可以。 请查看描述处理用户故事中非功能需求的that文章。

Q2。从我的角度来看,如果你能够创建它们,那么以这种方式保存和跟踪它们确实值得。但引用this文章

  

没有神奇的敏捷练习可以帮助你发现NFR。该   第一步是承担责任。 NFR可以表示为用户   如果团队发现这有助于保持这些可见的故事。   但是,请注意,出现这样的故事可能会产生问题   对他们所做的工作优先于更明显的特征。

Q3。看一下Q1中提到的文章。

答案 2 :(得分:1)

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

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

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

考虑一个典型的NFR,它可能只声明“数据库限制为10GB”。这是一个任意数字,没有任何意义或理由,也没有办法质疑它。具有类似故事的角色和解释有助于每个人理解NFR有正当理由,因此当您对其进行优先排序时,您可以提出明智的问题。他们引发了一些对话,比如“我需要将我的表空间扩展到20GB,但系统管理员有这个NFR关于数据库大小.SQL Server许可证实际上花了多少钱?OMG,那么多?好吧,我会对一些表格进行反规范化并保存几GB以适应它。“

答案 3 :(得分:1)

正如@bensmith和@siemic都表明,是的,你可以把NFR作为故事来捕捉。

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

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

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

如果产品所有者和团队都对此感到满意,那么可能希望将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。

答案 4 :(得分:1)

我认为你需要看一些事情, NFR应遵循应用程序,软件,产品等的使用寿命。应定期涵盖备份和恢复方案,安全扫描和性能应在生产和开发中进行衡量。 许多NFR需要从开发组之外的团队进行验证,因此不会要求编写用于验证的脚本或代码。因此,显然安全性,性能,可伸缩性,弹性等可以并且应该在开发阶段或在代码被提升为实时之前进行测试。 大多数NFR可以写成故事,但据说我不认为所有人都需要开发工作来覆盖它们。 问候 马丁