I am curious because it seems like everyone has different opinions on the matter. When creating an SRS document, do you need both use cases and functional requirements or just one since use functional requirements expand on use cases?
问问题
30254 次
3 回答
15
...您需要用例和功能要求，还是只需要一个...
如果要仔细阅读这些技术的主要作者，区别仅在于方法。
用例方法被认为是收集基本需求的一种更有效的方法，而功能需求方法确保了一个完整的规范，然后可以过滤掉冗余、重叠和不需要的特性。
用例方法一开始就考虑到外部参与者（用户、进程、代理等）以及它们如何与系统交互，而功能需求从解决方案的角度来处理问题（我们如何利用这个特性来解决我们的问题）问题？）
用例捕获参与者、用户、方法、领域知识、独特的技术等。用例可以导致完整的打包解决方案。功能方法捕获产品类别、产品变体、市场差异。功能方法可以帮助开发精细调整的发布策略，其中功能被开发并分层在以前的版本之上。
另一种描述方式是，用例更多是面向用户的规范，而功能方法则是开发人员规范。从语言和交流的角度来看，据说用例方法可以更容易地理解最终用户语言习语中已经包含的文档。另一方面，功能方法是使系统完整和集成的整体。
在现代 SRS 中，这两种观点对于一个完整、有用的系统都是必不可少的。理想情况下，一个必须映射到另一个。无论从哪里开始该过程，这两种方法的好处都不容小觑。
于 2015-09-07T20:41:59.367 回答
3
完全由您决定是否要其中一个或另一个或两者兼而有之。
功能需求是一组需求，主要以文本形式定义正在开发的系统功能。用例图是软件系统的需求引出。两者都可以使用，这样做有明显的优势。功能需求可以很容易地用作单元测试用例，而用例可以用于用户验收和集成测试。根据详细程度，用例图也可用于单元测试。
从历史的角度来看，在 UML 成为面向对象软件开发的标准之前，就使用了功能需求。因此，这些天用例是捕获系统功能需求的首选方法，如果两者都不使用的话。
主要区别在于用例图是系统需求的图形表示，而功能需求是文本形式的。用例也可以有文本，但主要关注的是图表本身，而在功能需求中，关注的是书面文本。
于 2019-10-04T13:40:02.463 回答
3
如果您需要同时使用两者（因为系统很大或很复杂），请将功能规范保持在比用例更高的级别。如果您定义了功能规范（例如 BFD 或其他符号），那么您可以根据您所追求的视图在较低级别有效地添加流程模型、故事映射、分级 DFD 或用例。DFD 和实体模型相互交叉检查。
于 2016-05-09T16:53:03.207 回答