1

在我的上一个项目中,我们设计了一个问题文档系统组件(如错误报告工具),它应该集成到不同的客户端应用程序(桌面应用程序、移动应用程序以及独立的 Web 客户端)中。重点不是应用程序/UI 本身,而是其作为服务的功能。可以把它想象成 Google 搜索 API,它也可以集成到您的浏览器中、作为小部件、在您的手机上等等。

在定义功能性(用例)和非功能性需求时,我在没有具体 UI 的情况下定义它们遇到了很大的麻烦,因为我们想要获得一种服务。

作为一种解决方法,我们简单地定义了我们的要求以适应独立的 Web 应用程序以及所有函数调用必须通过 RESTful 服务 API 完成的非功能性要求,希望之后我们在使用这个 API 时不会错过任何函数。以桌面应用程序为例。由于事实上,我们实际上并不想要一个 webapp,而是一个服务,我对这种间接的需求分析方式不太满意,我希望我们的开发人员明白这一点。

所以我的问题是:REST API 或 Web 服务是如何设计的,开发人员知道该做什么?例如,是否有用于 Web 服务的 UML UseCase 配置文件?

4

2 回答 2

2

不要忘记:用例只是“故事的一半”

你也会有非功能性的需求。你不能用用例捕捉每一个重要的细节。

然后问自己:用例适合我吗?

用例通常适用于“交互式系统”:与用户交互的系统。它们适用于捕获“功能”需求。

用例不适用于某些系统。心胸开阔。在编写用例时,您会发现这并没有捕捉到您想要的东西,或者没有增加任何价值尝试使用 替代技术,例如简单的功能列表。

找到根本原因

问问自己“为什么我在没有获得 UI 特定细节的情况下定义我的需求时遇到了很大的麻烦”?

选择你的战斗:质量场景+建筑因素表

确定您在架构上的重要需求。定义它们的一种好方法是“质量场景”:

质量情景是 [刺激] [可测量响应] 形式的简短陈述

例如:当一个新的Bug 报告进入Bug System[刺激],它会在X 条件下在5 分钟内发送到Bug 所有者手机。[可衡量的响应]

然后可以创建一个具有质量场景的架构因素表

架构因素表是一种工具,可帮助您了解因素、优先级和可变性的影响。

这是 Craig Larman 书中的一个样本因子表:应用 UML 和模式

在此处输入图像描述

“保证软件做你想做的”...

所以先写你的测试......或者创建“可执行”规范......并沟通......

最后

没有什么比 REST API 的软件工程更好的了。:-)

于 2013-05-29T19:42:58.200 回答
2

查看软件需求规范的定义,您可以从软件接口等产品使用的角度(即总体描述、产品角度、软件接口)将 RESTful API 指定为技术需求。这不是功能要求。这只是您项目的技术要求。

没有 UML 用例配置文件,因为 UseCase 打算指定功能需求。考虑到常规用例中的功能访问和数据交换,您可以指定通过 RESTful API 访问系统的用户的交互。

预期 RESTful API 所需的所有特性都应指定为技术要求(即特定要求、外部接口要求)。考虑到应用程序的所有要求,开发人员知道该做什么。

于 2013-05-29T14:35:00.847 回答