【发布时间】:2015-12-03 09:34:50
【问题描述】:
我很好奇,因为似乎每个人对此事都有不同的看法。创建 SRS 文档时,您需要用例和功能需求,还是只需要一个,因为使用功能需求扩展了用例?
【问题讨论】:
-
我投票结束这个问题,因为它与编程无关
标签: use-case requirements system-requirements
我很好奇,因为似乎每个人对此事都有不同的看法。创建 SRS 文档时,您需要用例和功能需求,还是只需要一个,因为使用功能需求扩展了用例?
【问题讨论】:
标签: use-case requirements system-requirements
...您需要用例和功能需求,还是只需要一个...
如果要仔细阅读这些技术的主要作者,区别仅在于方法。
用例方法被认为是收集基本需求的一种更有效的方法,而功能需求方法确保了一个完整的规范,然后可以过滤掉冗余、重叠和不需要的特性。
用例方法从一开始就考虑外部参与者(用户、进程、代理等)以及他们如何与系统交互,而功能需求从解决方案的角度处理问题(我们如何使用此功能解决我们的问题?)
用例捕获参与者、用户、方法、领域知识、独特的技术等。用例可以导致完整的打包解决方案。功能方法捕获产品类别、产品变体、市场差异。功能方法可以帮助开发精细调整的发布策略,其中功能是在以前的版本上开发和分层的。
另一种描述方式是,用例更多是面向用户的规范,而功能方法则是开发人员规范。从语言和交流的角度来看,据说用例方法可以更容易地理解最终用户语言习语中已经包含的文档。另一方面,功能方法是使系统完整和集成的整体。
在现代 SRS 中,这两种观点对于一个完整、有用的系统都是必不可少的。理想情况下,一个必须映射到另一个。无论从哪里开始该过程,这两种方法的好处都不容小觑。
【讨论】:
Another way to describe is that use cases is more an user-oriented spec and functional approach is a developer spec.,想想就够形容了。
如果您需要同时使用两者(因为系统很大或很复杂),请将功能规范保持在比用例更高的级别。 如果您定义了功能规范(例如 BFD 或其他符号),则可以根据您所追求的视图在较低级别有效地添加流程模型、故事映射、分级 DFD 或用例。 DFD 和实体模型相互交叉检查。
【讨论】:
完全由您决定是否需要其中之一或两者。
功能需求是一组需求,主要以文本形式定义正在开发的系统功能。用例图是软件系统的需求引出。 两者都可以使用,这样做有明显的优势。功能需求可以很容易地用作单元测试用例,而用例可以用于用户验收和集成测试。 根据详细程度,用例图也可用于单元测试。
从历史的角度来看,在 UML 成为面向对象软件开发的标准之前,就使用了功能需求。因此,如果不同时使用这两种方法,现在用例是捕获系统功能需求的首选方法。
主要区别在于用例图是系统需求的图形表示,而功能需求是文本形式。用例也可以有文本,但主要关注的是图表本身,而在功能需求中,关注的是书面文本。
【讨论】: