SRS是否足够程序员完成他们的工作，而不需要额外的FS开销？

Question

我们总是为程序员(又名程序员)制作2个文档-- SRS (软件需求规范)和FS (功能规范)文档。

正如我已经研究过的，与只处理功能需求的FS相比，SRS更像是包含功能性和非功能性需求。

简而言之，SRS是否足以让程序员完成他们的工作？不再做FS了？

Answer 1

这可能取决于您的组织和产品的大小，但我认为客户和系统工程师的输入从一种形式转换到另一种形式的次数越多，您的产品的成本就越高，而且可能更严重的是，相对于客户来说，开发人员之间的联系就会越多。

区分功能需求和系统需求可能有一些好处，但我认为大多数情况下，我们的文档需要垂直增长(更具描述性)，而不是横向增长(更大的瀑布，更多的切换)。即使是大型的DoD项目也正在组织到系统方法系统中，这样就可以用更小的团队、更小的规格、更小的预算和更高的重用潜力来完成它们。

另一个考虑可能是你是否使用V型。在V模型中，有一个与验收测试配对的客户规范周期，与系统集成测试配对的设计周期，以及与单元测试配对的开发周期。如果您的两个需求文档与测试用例的创建不一致，这可能会导致某些病理。例如，您有这样的要求，即没有相应的测试用例强制对分流进行具体解释(例如，系统应该具有优越的性能没有任何意义，但是系统必须在200 ms内响应触摸屏按压，并且可以进行测试)，然后您可能会对产品的适用性和可交付性产生真正的分歧。

Answer 2

文档中的复制是一个数据问题。数据视图被视为数据源。关系数据库、规范化和查询都是为处理这些问题而设计的。这可能是过火了，但你可以建立一个需求数据库。过滤后的查询将产生“功能性”要求。

也许带有函数/非功能标志列的excel工作表就足够了。

Answer 3

只要程序员和QA一致认为这已经足够了，而且您很高兴所交付的内容没有花太多时间向dev/QA解释特性--我认为人们不会关心文档的名称。没有理由有两个基本上是相互重复的文档。

您需要识别SRS中的哪些需求可以追溯到特性(当用户单击A、B时)和哪些不是(Ex )。扩展性，成本)这样，您就可以得到一致，软件满足需求时，所有的说和做。