要求工学ワークショップ in 屋久島 議事録 (記録/糸賀)


--- Thu Apr 15 13:01:27 2004

海谷先生 「既存システムのユースケース図の比較を通したステークホルダと彼らのプリ ファレンスの識別」(RE'04の講演内容の紹介)

Q(佐伯先生) パラメータの定義がよくわからなかった.なにものなのか.

A 実際の例では出てこなかったが,機能を特徴付けていて変量のあるものはなん でもパラメータになる.

Q(佐伯先生) 「通話料」というパラメータは,シナリオを見ないと出てこない.NTT(アクタ) を思いつくのがはやいのか,通話料(パラメータ)を思いつくのがはやいのか? が問題.パラメータからNTTを引き出すというのが目的ではないのか?

A NFR とステイクホルダの両方を探すのが目的である.

Q(佐伯先生) 実際,非機能要求からNTTというアクタが出てきたのか?

A 実例では出てきた.「通話料がかかるなぁ」から,そのお金が電話屋さんにいっ てしまうな,と想像した.

Q(佐伯先生) 使う人が幸せなときはどんなときで,それによって不幸になるのはどんな人か というのを見ていくのが常套手段で,パラメータを探すのは逆に大変なのでは ないか?

A ユースケースには,システムのゴール的に書く作法と,インタラクション的に 書く作法がある.ここでは後者で書いて欲しい.いきなり目標を探すのは難し いので,動いているシステムのユースケースを手で書いて,差分を見つけたい.

Q(佐伯先生) 再利用を狙いたいというのが目的?

A 基本的にはPAOREの枠組を踏襲している.既存のユースケースおよびデータベー スがあって,その差分をみながら何をやりたいのか?どうありたいのか?を探 す.

Q(橋本先生) 隠れたゴールを見つけたい?

A 制約条件,TOC/Theory of Constraint.対立解消の概念.隠れた問題があって それを見つけ出す.

Q(佐伯先生) いろんな要素があって,結局どんな御利益があったのかわからない,というの がプレゼンを聞いた正直な感想.

A 対立するであろう factor を見つけ出すのが目的.対立解消プロセス自体は既 存のものを使う.

Q(妻木さん) ビジネスにおけるステイクホルダについても考えるとどうだろう.


--- Thu Apr 15 13:28:49 2004

廣田先生 「ダイアグラム変換を利用したシステム分析」

Q(海谷先生) 既存のものとの差異としては「人と組織の役割」「人と組織の責任」の分離だ と思うのですが,役割と責任の違いをもう少し詳しく.

A 実際にやる人と,それに責任を持つ人というのが直観的な言い方.

Q(海谷先生) システム要求/ソフトウェア要求で,その差異を記述することの必要性は何か?

A どこでだれがやっているのか,それに誰が責任を持っているのか,というのは 現実の世界では重要.これを明確にしたい.Object の roll と responsibility だが,プログラムになってしまうと区別が無くなると思う. 権限を委譲しないとできないことがあるから.

Q(中谷さん) ある担当者からの矢印が全部のノードに付いていた図があったが,実際は複数 の部署や役職が同じ人についている.作業を実行する権限を持っている人がだ れなのか,と分析すれば「役割名」として出てくる.

A ユースケース図までできちんとしておこうというのが目的.

Q(中谷さん) 今回のIDEF0の出力から「ルールをつくった」「プログラムをつくった」が識 別できると思う.UMLだとステレオタイピウを付けられる.のちのち使うべき リソースを生成したのか,制御に使うルールを生成したのか識別すべき.

A 本来はそういう識別ができるが,IDEFの立場としては入力で区別すべきだと考 える.

Q(中谷さん) 出力/入力の双方で識別はすべきだと思う.


--- Thu Apr 15 13:56:43 2004

中谷さん 「ビジネスモデリングから抽出する要求」

Q(大西先生) リッチピクチャに時間の表現はないのか?

A ありません.

Q(廣田先生) 提案書について,前は開発部門がやっていたのを,これからは営業がやるとい うことか?

A 営業部が溜めていくということ.

Q(廣田先生) 大学も企業と同様に,技術を持ってて売り込みたい.研究資金の調達も提案書 による.

Q(鎌田さん) 「ステイクホルダは同じ最上位ゴールを目指している」と仮定しているが,ス テークホルダ間に意識の差があったり,表面上のゴールの共有になるのではな いか.実際にはビジョンを共有していたとしても,動きが異なったりする.

A 最上位ゴールは,会社のビジョンというレベルを考えている.

Q(海谷先生) 欠落する要求が 100% になっていない.

A 複数回答で,全体の人数のうちどれだけの割合のひとが要求に関して欠落して いると考えているかの割合を表している.

Q(橋本先生) アンケートの対象者はどんな人達か?

A 要求工学イブニングチュートリアルに出席した人なので,問題意識を持ってい る人達である.

Q(廣田先生) 何人かがいろいろ書いているけど,「本来の問題が見えなくなっているのが問 題である」というのが重要だと感じる.


--- Thu Apr 15 14:30:56 2004

佐伯先生 「要求仕様のレポジトリとバージョン管理」

+CVSとの比較をすると,記述方法が図表であったり,非形式的な記述がある. +顧客はユーザなので,ユーザに見やすくなければならない. +管理対象の粒度が異なる.抽象的なものが具体的になったり,詳細化された りということが起こる. +そこで,差分に理由(rationale)を付加して,属性付きグラフで表現する.

Q(海谷先生) 管理対象を動的に定義する,というのは,メタモデルの構文も動的に変化させ るということか?

A アトミックなものだけ定義しておいて,それらを組合せて上位のコンセプトを 定義する.この組合せを切り替え可能にする.

Q 粒度の定義は?

A この例だとユースケース単位を考えているが,より細粒度の単位を定義してや ればよいと考えている.

Q(中所先生) オントロジーなどの用語レベルの粒度ではないということか?再帰構造はどう なっているのか?

A 再帰構造は何回まで許す,ということを記述しなければいけない.

Q(橋本先生) 去年の中谷さんのが使えるのではないか?

Q(海谷先生) これは要求だけではなく,設計段階のレベルでも使えるのではないか.組み込 み屋さんのところで似たような問題が起きている.

Q(中谷さん) トレーサビリティの点でも期待できると思う.


--- Thu Apr 15 15:00:38 2004

鎌田さん 「要求工学ワーキンググループ/イブニングチュートリアルアンケートにみる 問題意識」

Q(佐伯先生) 要求の欠落と,要求の課題の相関はとっていないのか?例えば,適切な方法論 がないから境界がわからない,だったら境界を明らかにする方法論についてき ちんと考えるとか.

Q(中所先生) 事例を出してもらったり,対面で詳しく分析したり,100人単位でやっていた くとかするとさらによくわかるのではないか.

Q(佐伯先生) 全数でどれくらいですか?

A 77人ですが複数回答の設問です.

議論


--- Thu Apr 15 15:25:14 2004

橋本先生 「組込みシステムの仕様化に関する研究」

Q(佐伯先生) プロジェクトの進行状況グラフの読み方は?

A 横軸が日付.Planned Requirements Value,Old_ERV1(当初のERV)を見直して ERVになった.ARVはActual Requirements Value.

Q(海谷先生) 開発過程において,要求の価値を見積ったり,見直したりする理由は?

A 期間がたつうちに,要求の価値が変わる.例えば,別の会社が似たようなもの を出してしまった.技術が陳腐化してしまった,など.

Q(海谷先生) 競合他社が同じものをだしたらARVは落ちてしまう?


--- Thu Apr 15 15:50:10 2004

大西先生

ユースケースとシナリオの進化支援

Q(海谷先生) シナリオとユースケースで,名前がはいっているかどうかのちがいとは?ペル ソナとかそういうものか?

A インスタンスレベルがシナリオで抽象化したものがユースケース、 インスタンスに注目すると指摘のようにペルソナにも使える

Q(中谷さん) 状態遷移モデルは,シーケンス図に落とせるならできそう.でもユースケース には時間関係がないので....通信関係ならやってるひともいる.

A ユースケース記述には時間関係があるので、それを利用する。

C(海谷先生) 事例から一般を出すので難しそうだ.

A そう思っているが、例外シナリオと正常シナリオのように 条件分岐を意識したシナリオの統合といった形で一般化できると 考えている

C(海谷先生) ある状態遷移図のある状態にいることを事前条件,事後条件と呼ぶのはどうも 違う気がする. 事前条件,事後条件は論理が緩い/厳しいので...となるんだけど,それがある 状態になるというのがちがう気がする.

A 教科書等で事前条件の表現を調べたが、状態として定義できる ものがほとんどであった。

C(橋本先生) 条件が,状態ではなくてもうちょっとかけるようなシステムをつくっている.

C(中所先生) 銀行口座でいうと,ローンでの引き出しが可能になった,とか.

C(中谷さん) 事前条件・事後条件をシステム側とアクタ側で書かなければいけないので たいへんそうだ.

A いくつかの事例で試みている。状態遷移を予め把握していれば 簡単だが、そうではないので難しい。初期状態といったラベルで 状態を定義するのであればできそう。


--- Thu Apr 15 16:25:18 2004

中所先生 「Webサービス連携をベースにした要求分析に関する考察」

Q(大西先生) 変換フォームの正当性の評価はどうするのか? 例外処理があったりしないか?

Q(廣田先生) 試験だけ複数の部屋になる,などの例外処理はどうするのか?

Q(大西先生) そのあたりの例外処理をユーザがどう書けるかが問題ではないか.

A ビジネスロジックとコンポーネントの組合せをフォーム変換としてどこまで組 めるか.

Q(廣田先生) コンポーネントの中身を書き換えられるなら好みに応じた表記を作成できる?

A たしかにそれはできるとうれしい.他にも試験の緊急度などのカスタマイズが できるといいと思う.今回は,学生がプログラムをつくった(つくってくれた) のでこうなっている.

(Q(海谷先生)

実際,学生にどのようにプログラムを組ませてるんですか?

A アルバイトとか.)


--- Thu Apr 15 16:46:27 2004

妻木さん 「情報システム分析設計法のビジネスモデリングへの適用」

++ ユーザの不確定性 ++ システムの自律性

Q(中谷さん) こうならばグルーピングできる/できない のところで,グルーピングするとか 新しい議題が出てくるためのプロセスがわからない.

A 社内のひとはわかっている.

Q(中谷さん) 社内ではわかっているかもしれないけど,プロセスとしてどうすればいいのか?

A こう出てきた,というのを正規化して書いてまとめておく.目的でまとめるか, 原因でまとめるか.ここでは目的でまとめた.

Q(中谷さん > 全員) ゴールの書き方として,英語では状態を書くことになっているけど,一般には 〜することのような書き方をしてしまう.ゴールが手段に見えてしまう.

A 新規顧客の獲得を例にすると,新規顧客を獲得することという手段と, 新規顧客が獲得されているという状態は違うだろう.

A(佐伯先生) 手段になったら終わる方法もあるし,手段と目的を別々に扱うという方法もあ る.

Q(中谷さん) 情報収集サブシステムがゴールを達成できるとみなせるのかわからない.


---

糸賀 「セキュリティ要求獲得支援」

Q(橋本先生) リスク管理でも事例を挙げてリストをつくっているが,安全なものが重なって 実はリスクとなる場合がある.なので,イベントと処理に分割して考えるべき ではないか.

A たしかにそのような例がある.

Q(鎌田さん) おそらく,大量の問い合わせがユーザに対して発生する.セキュリティは本来 の話題ではないのだから,テーマからずれた問い合わせは良くない.

A アスペクト指向のような技術を応用して,1個所の挙動を決めたら他の場所に も敷衍されるようにしたい.

Q(海谷先生) Super Goal の発見のようなボトムアップの解析をするよりも,トップにセキュ リティポリシーを置いて解析する通常の方法のほうが良いのではないか.


--- Thu Apr 15 17:45:13 2004

中村先生 「テキストマイニングを用いたプロジェクト管理レポートの分析」

Q(海谷先生) 「要求定義が顧客との間で合意されないため仕様変更が多発」というのは真で すか?

A 顧客要求定義ができていても後から仕様変更要求があります。修正します。

Q(橋本先生) レポートの内容(信用)は分析に耐えるものか?

A 最近は、費用の余裕がなく、競争も厳しいので、水増しの報告をする 余裕はないので信用できるものだと思う。

Q(大西先生) 変更の規模に関係があると思うが,規模は書いてあるのか?

A 金額なども書いてある.上は400億とか500億とか. 一つのプロジェクトでも大規模の場合は,営業担当と開発担当がそれぞれにレ ポートを提出する.立場により評価が異なることがある.

Q(鎌田さん) 仕様変更には追加ははいってますか?

A 「仕様変更」は同義概念語辞書の40の言葉やフレーズを登録しています. その辞書「仕様変更」に「仕様追加」もあります.

--- Thu Apr 15 18:01:42 2004 -------------------- ここまで --------------------