我很好奇，因为似乎每个人对这件事都有不同的看法。在创建SRS文档时，您需要用例和功能需求还是只需要一个，因为使用功能需求是在用例上展开的?
…你是需要用例和功能需求，还是只需要一个…
如果你仔细阅读这些技术的主要作者，区别只是在方法上。
用例方法被认为是收集基本需求的更有效的方法，而功能需求方法确保了一个完整的规范，然后可以过滤掉冗余、重叠和不需要的特性。
用例方法从一开始就考虑到外部参与者(用户、过程、代理等)以及他们如何与系统交互，而功能需求从解决方案的角度来处理问题(我们如何使用这个特性来解决我们的问题?)
用例捕获参与者、用户、方法、领域知识、独特技术等。用例可以生成完整的打包解决方案。功能方法捕捉产品类别，产品变体，市场差异。功能方法可以帮助开发精细调整的发布策略，其中开发功能并在以前的版本上分层。
另一种描述的方式是，用例更多地是面向用户的规范，而功能方法是开发人员的规范。从语言和交流的角度来看，据说用例方法可以更容易地理解已经用最终用户的语言习惯表达的文档。另一方面，功能方法是使系统完整和集成的整体。
在现代SRS中，这两种视角对于一个完整的、有用的系统都是必不可少的。理想情况下，一个必须映射到另一个。无论从哪里开始，这两种方法的好处都不容忽视。
如果您需要同时使用两者(因为系统很大或很复杂)，请保持功能规范比用例更高的级别。如果您定义了功能规范(例如BFD或其他符号)，那么您可以根据您所追求的视图有效地添加流程模型，故事映射，分层dfd或较低级别的用例。dfd和实体模型相互交叉检查
完全由您决定是要其中一个还是另一个，还是两者都要。
功能需求是一组需求，主要以文本形式定义正在开发的系统功能。用例图是软件系统的需求描述。两者都可以使用，并且这样做有明显的优势。功能需求可以很容易地用作单元测试用例，而用例可以用于用户验收和集成测试。根据详细程度的不同，用例图也可以用于单元测试。
从历史的角度来看，功能需求在UML成为面向对象软件开发的标准之前就被使用了。因此，这些天用例是捕获系统功能需求的首选方法，如果两者都不使用的话。
主要的区别是用例图是系统需求的图形表示，而功能需求是文本形式的。用例也可以有文本，但主要关注的是图本身，而在功能需求中，关注的是书面文本。