2011年02月10日
要求とユースケース
Blogの投稿の間隔が少し空いてしまいました。
今回もまた機能紹介なのですが、以前やろうとして挫折した、設計開発の流れの話を含めた機能紹介です。
今回は、要求とユースケースの定義と整合性確保です。
何かのシステムやアプリケーションを作成しようとする際には、まず「何を作るか」を定義する必要があります。この部分については今回の話では触れません。要求開発・RDRAなどの方法論のほか、例えばマインドマップを使って抽出するような具体的な方法もあります。このあたりは、どの程度の規模のシステムなのか、ということに依存するかと思います。
今回は、もっと簡単な(適当な)方法として、Enterprise Architect内で要求を挙げていく方法です。例えば、ETロボコンのような、範囲が限定されている小規模の設計の場合には、この方法でも良いのではないかと思います。
Enterprise Architectの場合には、「要求図」を作成すれば、「要求」要素を配置することができます。ここで、以下のように、思いつくままに要求要素として作成・配置します。
粒度がばらばらだと思いますので、整理のために集約や依存の関係を利用します。クイックリンクで要求間を引っ張れば作成できますので、要求項目を出した後、項目をグループ化しながらまとめていきます。
また、USDM方式で、要求のノート欄にその要求の「理由」を書いておくというのもお勧めです。ノート欄の内容はノートサブウインドウで参照・編集できるほか、マウスを載せると表示されるポップアップウインドウでも確認できます。
要求の効率的な管理を行いたい場合や、例えば「要求」「要件」「仕様」のように詳細に分類して定義・管理する場合などは、この方法では効率が悪いので、RaQuestを使うことになります。
(RaQuestとEnterprise Architectのデータは共通なので、例えば上記の内容をそのままRaQuestで管理することができます。)
(RaQuestとEnterprise Architectのデータは共通なので、例えば上記の内容をそのままRaQuestで管理することができます。)
そして、この内容を参考にしながら、ユースケース図を作成します。アクターとユースケース要素を明確に定義することが目的です。
この時点で、要求とユースケースとの整合は取れているかどうかはわかりませんので、関係マトリックスで定義しながら確認します。Enterprise Architect方式では、要求とユースケースの間は「実現」で結ぶのが推奨です。ただし、トレーサビリティの定義には「追跡」の接続を使うので、ここでも「追跡」を使うという方法もあります。
続く。
トラックバックURL
この記事へのコメント
1. Posted by ZACKY 2011年02月10日 10:55
EA ではこのくらい現実的な手法がマッチすると私は思います．
2. Posted by こうの 2011年02月10日 21:12
コメントありがとうございました。
(こちらにも返信しておきます。)
以前重量級の内容を書いて、いきなり挫折した、というのがあります。頭の中ではETロボコンを想定しています。
(こちらにも返信しておきます。)
以前重量級の内容を書いて、いきなり挫折した、というのがあります。頭の中ではETロボコンを想定しています。
3. Posted by スカイシー 2011年02月11日 22:46
治具や簡単な仕様変更であれば、この方法が良さそうですね。
要求とユースケースの関係をどうやって表せば良いのかと悩んでいました。同様にユースケース図とクラス図も関係マトリックスで表現できるのですか？
4. Posted by こうの 2011年02月12日 02:36
コメントありがとうございます。
はい、ユースケース図とクラス図の関係も、マトリックスで表現できます。今日？その部分を書く予定です。
はい、ユースケース図とクラス図の関係も、マトリックスで表現できます。今日？その部分を書く予定です。
5. Posted by ななしのごんべえ 2011年02月14日 14:42
6. Posted by こうの 2011年02月14日 17:15
コメントありがとうございました。
個人的な考えになりますが、今回の記事の範囲では、制約は(日機能的な)要求と考え、要求要素として表現するという想定です。
この要求要素には「種類」を指定できます。種類として、「機能」「性能」「保守」など一般的に知られている分類が考えられますが、制約であることを明確にするために「制約」という種類を追加するという方法もあるかと思います。
(ただ、多くの制約は、何らかの非機能要求に分類できるのではないか、とも思います。)
含むのか含まれるのか、というのはご指摘のようにいろいろな考え方があると思いますが、ここで重要なことは、その制約がモデル全体に対して満たされているか、途中で漏れてしまうことがないか、というチェックが可能であることと、その制約が変更になる場合に影響範囲が確認可能であること、だと考えています。
個人的な考えになりますが、今回の記事の範囲では、制約は(日機能的な)要求と考え、要求要素として表現するという想定です。
この要求要素には「種類」を指定できます。種類として、「機能」「性能」「保守」など一般的に知られている分類が考えられますが、制約であることを明確にするために「制約」という種類を追加するという方法もあるかと思います。
(ただ、多くの制約は、何らかの非機能要求に分類できるのではないか、とも思います。)
含むのか含まれるのか、というのはご指摘のようにいろいろな考え方があると思いますが、ここで重要なことは、その制約がモデル全体に対して満たされているか、途中で漏れてしまうことがないか、というチェックが可能であることと、その制約が変更になる場合に影響範囲が確認可能であること、だと考えています。