我的公司根据详细的规范文档开发了一个丰富的 GUI，编写为 100 多个用例 (UC)。这些详细的 UC 推动了发展。它们被写成带有演员和描述列的表格。我们（我和其他人）已经破坏了真正的 UC 散文风格，以支持我们应用程序的交互性。
我们还使用规范来（手动）生成测试规范，所以细节（对我来说）似乎很重要。此测试规范用于验证以进行签核。
注意：我们的产品还有更多的组件，而不仅仅是 GUI。GUI团队6-10强，项目整体，60左右。
直到最近，我一直在创建一个“故事板”文档，详细说明每个面板及其与规范相关的交互。曾经还有一个 GUI 架构，以及主要子组件的设计。哎哟! 它导致了非常缓慢的开发时间、糟糕的代码库（哈哈！）和缺乏动力的团队。
该应用程序更像是一个 IDE，允许用户使用拖放、流程图习语创建自己的测试用例（用于移动“手机测试”）。它非常复杂、成熟（7 年以上）并提供许多功能。然后运行测试用例并分析结果。作为一个免费工具（用户可以通过该工具遵循几乎无限数量的路径），它似乎使顺序用例变得毫无意义。我们使用“O”表示可选，“R”表示可重复、嵌套和许多其他“扩展”。UC 从根本上说不适合设计 IDE 的交互。将此应用程序视为提供了一个空白工作界面（如文字处理器或电子表格），用户可以在其中以任何顺序执行任何操作：这导致了 UC 膨胀。
目前希望将规范从 100 多个 UC 简化为基本 UC：“开发测试用例”、“运行测试用例”、“分析结果”（或类似的东西）。
虽然我了解我们的 UC 不是“真正的”UC（专注于商业价值），但作为 GUI 团队负责人和开发人员，我担心的是，如果没有详细信息，我的人将不知道要开发什么。三个UC似乎太抽象了。
我们遵循统一流程的形式，预先完成规范。也许我们应该改用更敏捷的流程，让开发人员自己进行交互设计。
