在我的上一个项目中，我们设计了一个问题文档系统组件（如错误报告工具），它应该集成到不同的客户端应用程序（桌面应用程序、移动应用程序以及独立的 Web 客户端）中。重点不是应用程序/UI 本身，而是其作为服务的功能。可以把它想象成 Google 搜索 API，它也可以集成到您的浏览器中、作为小部件、在您的手机上等等。
在定义功能性（用例）和非功能性需求时，我在没有具体 UI 的情况下定义它们遇到了很大的麻烦，因为我们想要获得一种服务。
作为一种解决方法，我们简单地定义了我们的要求以适应独立的 Web 应用程序以及所有函数调用必须通过 RESTful 服务 API 完成的非功能性要求，希望之后我们在使用这个 API 时不会错过任何函数。以桌面应用程序为例。由于事实上，我们实际上并不想要一个 webapp，而是一个服务，我对这种间接的需求分析方式不太满意，我希望我们的开发人员明白这一点。
所以我的问题是：REST API 或 Web 服务是如何设计的，开发人员知道该做什么？例如，是否有用于 Web 服务的 UML UseCase 配置文件？
不要忘记：用例只是“故事的一半”
你也会有非功能性的需求。你不能用用例捕捉每一个重要的细节。
然后问自己：用例适合我吗？
用例通常适用于“交互式系统”：与用户交互的系统。它们适用于捕获“功能”需求。
用例不适用于某些系统。心胸开阔。在编写用例时，您会发现这并没有捕捉到您想要的东西，或者没有增加任何价值尝试使用 替代技术，例如简单的功能列表。
找到根本原因
问问自己“为什么我在没有获得 UI 特定细节的情况下定义我的需求时遇到了很大的麻烦”？
选择你的战斗：质量场景+建筑因素表
确定您在架构上的重要需求。定义它们的一种好方法是“质量场景”：
质量情景是 [刺激] [可测量响应] 形式的简短陈述
例如：当一个新的Bug 报告进入Bug System[刺激]，它会在X 条件下在5 分钟内发送到Bug 所有者手机。[可衡量的响应]
然后可以创建一个具有质量场景的架构因素表
架构因素表是一种工具，可帮助您了解因素、优先级和可变性的影响。
这是 Craig Larman 书中的一个样本因子表：应用 UML 和模式
“保证软件做你想做的”...
所以先写你的测试......或者创建“可执行”规范......并沟通......
最后
没有什么比 REST API 的软件工程更好的了。:-)