在我现在的雇主,我们通常采用写传统功能需求规范,然后执行完整的技术设计的老派方法。如果应用程序很大,那么我们将它分成更小的块并一次攻击一个块,但遵循相同的基本模式。
多年来,这项技术对我很有帮助。对于用例建模,您似乎需要收集几乎相同的信息,只是组织方式不同。
所以我的问题是:遵循用例驱动的软件开发方法有什么实际好处?
在我现在的雇主,我们通常采用写传统功能需求规范,然后执行完整的技术设计的老派方法。如果应用程序很大,那么我们将它分成更小的块并一次攻击一个块,但遵循相同的基本模式。
多年来,这项技术对我很有帮助。对于用例建模,您似乎需要收集几乎相同的信息,只是组织方式不同。
所以我的问题是:遵循用例驱动的软件开发方法有什么实际好处?
虽然我们不使用非常正式的用例方法,但我发现用例和不太正式的用户故事可以帮助您从用户的角度设想您的产品。最后,我们大多数人为不是我们自己的用户编写软件。制定用例可以帮助您摆脱内部视图并专注于您正在构建的系统的外部视图。
除此之外,您还可以使用预先打包的生产单元来处理敏捷工作流程。如果您可以实现一个用例,那么您的系统就实现了一项功能。
我承认,虽然我在收集经典设计前期需求方面没有很多经验。我相信还有其他人可以为您提供更好的答案
做错了没有优势。在这种方法中,人们绘制了一堆用例的图片,并假装通过使用 UML(无用建模语言)您已经完成了设计。
正确完成后,用例是一种很好的高级思考方式,可以从以下方面考虑如何充实传统的功能规范:
在这种情况下,用户究竟想要完成什么。
软件必须如何支持这一点。
软件应该如何支持这一点。
我认为好的用例只是向利益相关者询问输入功能规范的一种方式。
你是对的 - 它是一样的,但有一个更性感的名字。在 1980 年代,我获得了 SSADM 认证(一些大型非政府组织需要认证,比如我当时的雇主 BBC),并且惊讶地发现您可以相当容易地将其流程映射到我已经熟悉的 OO 设计概念上。