我是一家软件开发公司的业务分析师。在我以前的组织中,开发是使用瀑布完成的,我们编写了“业务需求文档”(,BRD)。
在我目前的角色中,团队使用敏捷Scrum和JIRA编写用户故事来捕获功能需求等等。
我的问题是,如何最好地将JIRA中的非功能性需求作为一个故事来捕捉?
在BRD中,这是非常简单的,在它自己的部分中添加非功能需求,并确保每个需求旁边都有一个唯一的ID。
ID: 001要求: web应用程序必须与以下浏览器兼容: IE11、Firework 50等。
但是在敏捷Scrum中,特别是在JIRA中,应该如何记录这些文档呢?
发布于 2018-03-04 10:43:20
非功能性需求有很多种形式,但它们有一个共同点:不描述系统的功能行为,而是对您可以做出的设计选择施加约束。
非功能性需求不适合表示为用户故事,因为当用户故事可以在短时间内实现一次(相对于整个项目的长度)并被认为完成时,它们的工作效果最好。完成一个故事之后,就没有必要定期重温这个故事了。对于非功能性需求,这是行不通的,因为对它们的坚持需要在整个项目中得到维护。您不能说在项目期间只查看一次浏览器兼容性,而在其余时间忽略它。
对于影响几乎所有(功能性)用户故事的非功能性需求,最好的地方是记录它们,这是完成的定义的一部分。
对于影响相对较小的功能子集的非功能性需求,您可以将它们作为相关用户故事的接受标准的一部分。如果这个子集对您的口味仍然相当大(或者它在将来可能会增长,并且您担心您可能错过了对未来故事的一些非功能性需求),那么您可以将非功能性需求放在某种文档中,并参考相关故事的接受标准。
至于需求本身的格式和放置它们的可能文档,请使用任何对您和您的团队最有效的方法。
发布于 2018-03-04 05:48:47
“非功能性需求”有点模糊,易于解释。就你的具体例子来说,我想说的是,这些要求应该被用作其他故事的接受标准。
如果您担心一个又一个地重复相同的非功能性需求,另一个解决方案将是将所有这些需求打包到文档中(例如:“应用程序标准”),并将“必须遵守应用程序标准”作为您定义的“完成”的一部分。
发布于 2018-03-04 10:48:16
你可以把它们纳入你的国防部“完成的定义”。
但是,在敏捷中,非功能类是有问题的,如果它们改变了,您就无法跟踪哪些故事是根据什么标准完成的。
所以我会试着把它们列为针对每一个故事的测试。即使这意味着大量的复制和粘贴。
https://softwareengineering.stackexchange.com/questions/366984
复制相似问题