工具如何为编写功能规范提供便利？

Question

关于功能规范的C2维基建议，这可以通过工具来促进，怎么做？

功能规范是用来描述要设计和建造的产品的需求和约束的列表。用于描述软件产品的...tools已经开发到功能规范不再有任何用处的地步。

为什么不直接输入结构化的Word文档呢？

Answer 1

功能规范通常表示为文档，但根据您的目的，在Word中创建规范可能不是最佳选择。还有其他选项--字处理器、电子表格和需求管理工具(1、2)是一些常见的工具，用于创建和维护功能规范。

需求管理工具(我熟悉，但还有其他工具)本质上是支持创建、维护、跟踪和一般管理需求的需求数据库。一些工具支持从文档和电子表格导入，以及输出到这些格式。在内部，它们允许您将需求捕获为唯一的对象(考虑数据库中的一行，其中每个需求都具有不同的属性)。您还可以通过跟踪其他项(较低级别的需求、设计工件、测试)并查看需求发生变化时可能需要更改的内容来管理更改。

对我来说，电子表格比正式的需求管理工具低一步。它们支持更多的需求管理功能(可跟踪性、根据需求语句跟踪各种属性、管理更改)。

当然，你总是可以做你想做的事情--在你最喜欢的文字处理器中启动一个格式良好的文档来捕捉软件需求。然而，确保某些良好要求的各个方面更困难。具体来说，可跟踪性(通常通过需求ID实现)变得更加困难，与需求相关的文本需要更详细，才能捕获重要性和验证方法。

我不认为任何工具已经取代了功能规范。我确实认为过程和工具的使用已经取代了功能规范文档的传统思想。

在敏捷方法中，需求通常被捕获为用例和用户故事。在这种环境中，您的功能规范可能会以某种电子格式将您的用例和用户故事上传到文件存储区或wiki。即使在更多的计划驱动方法中，需求管理工具的使用也取代了文档，在文档中，只有在必要时才生成文档以向外部实体提供需求。

最终，需求规范(功能性和非功能性)的目的是以某种方式捕捉软件应该做的事情(以及在软件完成后，它在当前状态下所做的事情)。这组特性驱动测试(特别是系统测试和验收测试)。与创建功能规范文档相比，更重要的是确保客户和开发组织(设计团队、开发团队和测试团队)在系统应该做的事情上保持一致。