asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

要求構造 Part5:さらなる分析

要求構造について考えるシリーズの第5弾。精神が病んできたのでそろそろまとまって欲しい。


今回は、「不思議のダンジョンシリーズ」ではお馴染みの、満腹度を、新たな機能仕様として追加する場合を例として、要求構造の変化について考えたい。


まずは、「要求の構造は階層的である」ということから始めたいと思う。ルートの仕様として「システム仕様」があるとする。
req_structure_root.png


一般的に表すと、こんな感じ。
req_structure_root_general.png

要求の追加、削除、あるいは、変更は、「システム仕様」やさらにその下の階層の仕様に対するオペレーションであると考えられる。分かりやすいように、木構造で図を表現するとこうなる。
req_structure_root_diagram_general.png



したがって、要求(仕様)構造の進化の一つは、木構造の変化であると考えられる。ノード(要求)の追加や削除、ノードの内容の変更などが、要求の木構造を変化させる基本的なオペレーションである。

しかし、まだ不足な点がある。それは、ノード間の依存関係の変化。木構造の表現だと、あるノードがあるノードの親や子ノードである、という関係しか表現していない。

要求構造の進化を考える上で必要なのは次の点。
-(1)仕様や要求の種類:機能的要求、非機能的要求など。
-(2)仕様間の依存関係:依存関係仕様間の依存関係の変化と、仕様間の依存関係の種類。
-(3)要求構造の表現方法:木構造的な表現。マトリックスを用いた表現。


さて、具体的な例に戻って、「満腹度仕様」は、次の図の通り。
req_structure_hungry.png


仕様内の依存関係の分析


まず、この仕様内での依存関係を分析してみよう。前回から言っているように、上記の仕様は、ある選択肢から選ばれたものだと見なせる。
req_structure_hungry_dimenion.png


次に、選択肢が変化したときに、他の次元が変化する必要があるかどうかの観点から、依存関係を抽出する。依存関係を表現するために、DSM (Design Structure Matrix) を用いる。
req_structure_hungry_dsm.png


ステータス画面で満腹度表示仕様


次に、「満腹度仕様」をサブ仕様に分割してさらに分析する。
req_structure_hungry_hungry_status_view_sub_spec.png


req_structure_hungry_status_view_dimension.png


仕様内での依存関係を DSM で表す。この場合は、設計次元は一つしかないので依存関係はなし。
req_structure_hungry_status_view_dsm.png


親仕様との依存関係の分析。
req_structure_hungry_status_view_with_parent_dsm.png


通常画面で満腹度表示仕様


同じようにして「通常画面で満足度を%で表示する」というのもサブ仕様化してみる。基本的にはステータス表示と同じ。
req_structure_hungry_hungry_normal_view_sub_spec.png



req_structure_hungry_normal_view_dimension.png


req_structure_hungry_normal_view_dsm.png


req_structure_hungry_normal_view_with_parent_dsm.png


満腹度低下仕様


次に、「プレイヤーが行動するごとに満腹度は低下する」と「「足踏み」行動は、通常の行動よりも満腹度の低下が大きい」の2つを一つのサブ仕様としてまとめたいと思う。
req_structure_hungry_down.png


次にこのサブ仕様をさらに詳細化してみることにする。
req_structure_hungry_down2.png


仕様の変化の可能性を分析する。
req_structure_hungry_down_dimension.png

変化の可能性の分析を基に、変化の依存関係を分析する。
req_structure_hungry_down_dsm.png


ここでの疑問:値の変化と次元変化の違い
うえの満腹度低下仕様では、直接的な依存だけでなく、間接的な依存に対しても「X」をつけている。たとえば、「プレイヤーの満腹度低下」という次元には、他の次元がすべて依存している。これは、もし「プレイヤーの満腹度低下」の仕様が、「低下あり」から「低下なし」に変わったとしたら、残りの5つは、すべて変化しなければならないため。

ただし、変化は、特殊で、次元自体がなくなる、という変化。たとえば「プレイヤーの満腹度低下」の仕様が、「低下なし」になったら、「満腹度低下値」という次元自体が存在しなくなる。

まとめると、仕様の変化には、少なくとも二つの変化がある。
-(1)値の変化:ドメイン内での値(デシジョン)の変化。たとえば、「満腹度低下値」の値が10から20に変化するようなケース。
-(2)次元の変化:次元自体が存在したり、しなくなってしまうような変化。

2の場合の依存を、階層的な依存という意味で「H」で表すことにする。
req_structure_hungry_down_dsm2.png

興味深いことに、すべて「H」になった。各設計次元について次のような質問を繰り返して依存関係を考えた。

「もし、あの次元の値が変化したら、この次元の値は変化するか?」
-Yes なら X の依存関係。

「もし、あの次元の値が変化したら、他の次元は存在する/しなくなるか?」
-Yes なら H の依存関係。


空腹ペナルティ仕様


最後に、「空腹ペナルティ仕様」のサブ仕様について同様に考えてみよう。
req_structure_hungry_penalty.png

設計次元はこうなる。
req_structure_hungry_penalty_dimension.png


依存関係はこう。
req_structure_hungry_penalty_dsm.png



やり残したことと今後の予定


-(1)仕様間の依存関係の分析:他の仕様を横断するような依存関係の分析は行わなかった。

-(2)要求構造の変化の分析方法:この記事を含む今までの記事では、分析方法はアドホックだった。けれど、そろそろ分析の手順が見えてきた気がする。(1)まず、ラフに仕様を定義する。(2)サブ仕様に分割する。(3)設計空間を分析する。(4)設計空間の分析結果を基に、仕様の依存関係を分析する。

-(3)次元の分類:設計次元として要求を表した場合、いくつかのタイプに分類できると思う。たとえば、なんらかの出力を行うアルゴリズムに関する次元、なんらかの処理を行う次元、アルゴリズムの種類を決める次元、次元の階層化を決める次元などなど。
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/52-bb780150
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。