情報処理学会ソフトウェア工学研究会
要求工学ワーキンググループ　第１６回ワークショップ

要求工学ワークショップ 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
廣田先生「ダイアグラム変換を利用したシステム分析」

構造モデルと動的モデルの連携
ユースケース→『ペトリネット』→ER/IDEF0
実例: 入試システム，アクタを委員や会議として，集計や決定，判定におけるユースケースを記述
このユースケースをペトリネットとして表現して，始点等に同じ概念を割り付けていくと，同じノードを重ね合わせて統合されたペトリネットにできる．これをIDEF0に変換する． +人と組織の役割，責任を区別して表現できるのが特徴．

Q(海谷先生) 既存のものとの差異としては「人と組織の役割」「人と組織の責任」の分離だと思うのですが，役割と責任の違いをもう少し詳しく．A 実際にやる人と，それに責任を持つ人というのが直観的な言い方．Q(海谷先生) システム要求/ソフトウェア要求で，その差異を記述することの必要性は何か？A どこでだれがやっているのか，それに誰が責任を持っているのか，というのは現実の世界では重要．これを明確にしたい．Object の roll と responsibility だが，プログラムになってしまうと区別が無くなると思う．権限を委譲しないとできないことがあるから．Q(中谷さん) ある担当者からの矢印が全部のノードに付いていた図があったが，実際は複数の部署や役職が同じ人についている．作業を実行する権限を持っている人がだれなのか，と分析すれば「役割名」として出てくる．A ユースケース図までできちんとしておこうというのが目的．Q(中谷さん) 今回のIDEF0の出力から「ルールをつくった」「プログラムをつくった」が識別できると思う．UMLだとステレオタイピウを付けられる．のちのち使うべきリソースを生成したのか，制御に使うルールを生成したのか識別すべき．A 本来はそういう識別ができるが，IDEFの立場としては入力で区別すべきだと考える．Q(中谷さん) 出力/入力の双方で識別はすべきだと思う．
--- Thu Apr 15 13:56:43 2004
中谷さん「ビジネスモデリングから抽出する要求」

ソフトシステムメソッドとリッチピクチャ
CATWOE分析/Customer Actor Transofmation-process Weltanschauung(世界観) Owner Environment．「望ましくない状況を望ましい状況に変えることは良いことだ! と皆が認識すること」が重要．
ゴール指向分析における Weltanschauung に基づいた優先順位付け．
事例「提案書の再利用システム」

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

第1回チュートリアル 77名のアンケート
要求分析は見積りに含めている．
ビジネスルールや制約条件，機能要求，システム境界などの要求抽出はいまだ十分でない．それぞれの相関はないようだ．
ユーザが要求をわかっていない，適切な方法論がない，適切な要求仕様書が書けない，分析者の問題領域知識が貧弱である，要求が頻繁に変わるなどの問題点が挙げられている．
現在の要求工学手法は時間という観点で不適切だと判断されている．
要求仕様書を作成する観点でも現在の方法論が不適切だと判断されている．

Q(佐伯先生) 要求の欠落と，要求の課題の相関はとっていないのか？例えば，適切な方法論がないから境界がわからない，だったら境界を明らかにする方法論についてきちんと考えるとか．Q(中所先生) 事例を出してもらったり，対面で詳しく分析したり，100人単位でやっていたくとかするとさらによくわかるのではないか．Q(佐伯先生) 全数でどれくらいですか？A 77人ですが複数回答の設問です．議論

海谷先生のチュートリアルでもアンケートをしましょう．
第1回に参加しましたか？の項目をつくりましょう．
項目をしぼって，これまでの結果のフィードバックをしましょう．
5分以上かかるアンケートだと回答率が落ちるので設問をうまく考えましょう．
特に注目すべき回答には，深いヒアリングをお願いしましょう．

--- Thu Apr 15 15:25:14 2004
橋本先生「組込みシステムの仕様化に関する研究」

非正常系のぬけが頻発している．非正常系の性質として補集合の記述である．
アクタがトリガになって非正常現象が発生する．
情報フローパスの解析によって，非正常・不安定な状態を解析できる．
知識表現の粒度を考え，正常系の仕様と非正常系の仕様を合成できるように．
EVMコストの消化具合でプロジェクトの進行具合をはかる．

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サービス連携をベースにした要求分析に関する考察」

例 - 明治大学の時間割HTML + 試験時間割(仮)XML -> 試験時間割表
HTML->XML 変換，XML + XML合成，XML->HTML変換の3つのコンポーネント．このコンポーネントの組合せをワークフロー記述とする．
エンドユーザにコンポーネントの要求仕様書が書けるか?
フォーム定義+フォーム変換定義+ビジネスロジック ++ UI駆動型分析 -> フォーム定義 ++ 詳細化ワークフロー定義 -> フォーム定義群+フォーム変換定義 +上記にビジネスロジックを付加することでエンドユーザ中心の要求定義

Q(大西先生) 変換フォームの正当性の評価はどうするのか？例外処理があったりしないか？Q(廣田先生) 試験だけ複数の部屋になる，などの例外処理はどうするのか？Q(大西先生) そのあたりの例外処理をユーザがどう書けるかが問題ではないか．A ビジネスロジックとコンポーネントの組合せをフォーム変換としてどこまで組めるか．Q(廣田先生) コンポーネントの中身を書き換えられるなら好みに応じた表記を作成できる?A たしかにそれはできるとうれしい．他にも試験の緊急度などのカスタマイズができるといいと思う．今回は，学生がプログラムをつくった(つくってくれた) のでこうなっている．(Q(海谷先生)実際，学生にどのようにプログラムを組ませてるんですか？A アルバイトとか．)
--- Thu Apr 15 16:46:27 2004
妻木さん「情報システム分析設計法のビジネスモデリングへの適用」

情報システムの分析設計法をビジネスシステムの分析設計に適用できないか？
情報システムの「改造」と，ビジネスプロセスのBPR(Business Process Re-engineering)の比較
MIND SA
BSへのIS適用結果

++ ユーザの不確定性 ++ システムの自律性Q(中谷さん) こうならばグルーピングできる/できないのところで，グルーピングするとか新しい議題が出てくるためのプロセスがわからない．A 社内のひとはわかっている．Q(中谷さん) 社内ではわかっているかもしれないけど，プロセスとしてどうすればいいのか？A こう出てきた，というのを正規化して書いてまとめておく．目的でまとめるか，原因でまとめるか．ここでは目的でまとめた．Q(中谷さん > 全員) ゴールの書き方として，英語では状態を書くことになっているけど，一般には～することのような書き方をしてしまう．ゴールが手段に見えてしまう．A 新規顧客の獲得を例にすると，新規顧客を獲得することという手段と，新規顧客が獲得されているという状態は違うだろう．A(佐伯先生) 手段になったら終わる方法もあるし，手段と目的を別々に扱うという方法もある．Q(中谷さん) 情報収集サブシステムがゴールを達成できるとみなせるのかわからない．
---
糸賀「セキュリティ要求獲得支援」

セキュリティ要求は非機能的．現実は機能の組合せでギャップがある．
ログをとるなど，本来の機能以外についても考える
悪意あるアクタのユースケース/シナリオと対処方法を提示して選ばせる．
使い勝手を分析するために視点変換をしてみる．

Q(橋本先生) リスク管理でも事例を挙げてリストをつくっているが，安全なものが重なって実はリスクとなる場合がある．なので，イベントと処理に分割して考えるべきではないか．A たしかにそのような例がある．Q(鎌田さん) おそらく，大量の問い合わせがユーザに対して発生する．セキュリティは本来の話題ではないのだから，テーマからずれた問い合わせは良くない．A アスペクト指向のような技術を応用して，1個所の挙動を決めたら他の場所にも敷衍されるようにしたい．Q(海谷先生) Super Goal の発見のようなボトムアップの解析をするよりも，トップにセキュリティポリシーを置いて解析する通常の方法のほうが良いのではないか．
--- Thu Apr 15 17:45:13 2004
中村先生「テキストマイニングを用いたプロジェクト管理レポートの分析」

文書の調査をした - 「仕様変更」に関して問題があるものが多い．
Team Buildingにはあまり問題がない．
Specificationの遅れやPriceに問題が多い?

Q(海谷先生) 「要求定義が顧客との間で合意されないため仕様変更が多発」というのは真ですか？A 顧客要求定義ができていても後から仕様変更要求があります。修正します。Q(橋本先生) レポートの内容(信用)は分析に耐えるものか?A 最近は、費用の余裕がなく、競争も厳しいので、水増しの報告をする余裕はないので信用できるものだと思う。Q(大西先生) 変更の規模に関係があると思うが，規模は書いてあるのか？A 金額なども書いてある．上は400億とか500億とか．一つのプロジェクトでも大規模の場合は，営業担当と開発担当がそれぞれにレポートを提出する．立場により評価が異なることがある．Q(鎌田さん) 仕様変更には追加ははいってますか？A 「仕様変更」は同義概念語辞書の40の言葉やフレーズを登録しています．その辞書「仕様変更」に「仕様追加」もあります．--- Thu Apr 15 18:01:42 2004 -------------------- ここまで --------------------

Page updated

Google Sites

Report abuse

情報処理学会ソフトウェア工学研究会要求工学ワーキンググループ 第１６回ワークショップ

情報処理学会ソフトウェア工学研究会
要求工学ワーキンググループ　第１６回ワークショップ