1

私の最後のプロジェクトでは、さまざまなクライアント アプリケーション (デスクトップ アプリケーション、モバイル アプリケーション、および Web クライアントへのスタンドアロン) に統合する問題ドキュメント システム コンポーネント (バグ報告ツールなど) を設計しました。焦点は、アプリケーション/UI 自体ではなく、サービスとしての機能にありました。Google Search API のようなものと考えてください。これは、ブラウザーに統合したり、ウィジェットとして、携帯電話などに統合したりできます。

機能 (ユース ケース) と非機能の要件を定義する際に、UI 固有のものを取得せずにそれらを定義するのに非常に苦労しました。

回避策として、スタンドアロンの Web アプリケーションに適合する要件と、すべての関数呼び出しを RESTful サービス API 経由で行う必要があるという非機能的な要件を単純に定義しました。たとえば、デスクトップアプリケーション。そもそも Web アプリケーションではなくサービスが実際に必要なため、要件分析のこの間接的な方法にはあまり満足できません。開発者が要点を理解してくれることを願っています。

私の質問は、REST API や Web サービスは、開発者が何をすべきかを理解できるようにどのように設計されているのでしょうか? たとえば、Web サービス用の UML ユースケース プロファイルはありますか?

4

2 に答える 2

2

ソフトウェア要件仕様書の定義を見ると、RESTful API をソフトウェア インターフェースなどの製品使用の観点 (つまり、全体的な説明、製品の観点、ソフトウェア インターフェース) の技術要件として指定できます。これは機能要件ではありません。これは、プロジェクトの技術的な要件にすぎません。

ユースケースは機能要件を指定することを意図しているため、UML ユース ケース プロファイルはありません。通常のユースケースでの機能アクセスとデータ交換を考慮して、RESTful API を介してシステムにアクセスするユーザーの対話を指定できます。

期待される RESTful API に必要なすべての特性は、技術的要件として指定する必要があります (つまり、特定の要件、外部インターフェイスの要件)。開発者は、アプリケーションのすべての要件を考慮して何をすべきかを知っています。

于 2013-05-29T14:35:00.847 に答える