既存システムの仕様を再利用する要求定義支援ツールの実現と評価

既存システムの仕様を再利用する 要求定義支援ツールの実現と評価信州大学院情報工学専攻修士二年海尻海谷研究室北沢直幸

目次序論既存システムに基づく要求定義法ツール概要評価実験ツールの改良結論 2

序論 [1/2]背景 • ソフトウェアシステムは様々なドメインで使用されている。 • 要求分析者は馴染みの無いドメインの分析をする必要がある • ドメイン知識はそのような分析者にとって重要である。 3

序論 [2/2]目的 • 同ドメインの類似既存システムの仕様を比較・整理することで、ドメイン知識理解の手助けとすること。 • ドメイン特有の問題の解決法を得られる。 • 要求項目（機能）の候補とできる。 • 新システム開発において要求定義を行う際、この手法とツールでドメイン知識を理解することを目的としている。 4

要求仕様書 [1/1] 要求仕様書アウトラインソフトウェア要求仕様の特性 • はじめに • 目的 • 範囲 …… • 全体概要説明 • 製品の背景 • 製品の機能 …… • 要求仕様 • 外部インタフェース • 機能 • 性能 • データベース要求 • 制約‏ • ソフトウェアの属性 ………… • Correct（正当性） • Unambiguous（非あいまい性） • Complete（完全性） • Consistent（一貫性） • Priority（優先順位） • Verifiable（検証容易性） • Modifiable（修正容易性） • Traceable（追跡可能性） 6 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specification

要求定義法 [1/3] 類似既存システムから仕様を収集する。システムごとの仕様の違いを比較し、そのドメインにとって一般的である仕様、また逆に珍しい仕様などを明らかにする。顧客からの要望から、必要とされている仕様を選択する。 7

要求定義法 [2/3] • 何故、類似既存システムから仕様を収集するのか？ • ドメイン特有の問題に対して、既に使用されている良い解決法を得られる。 • 複数の類似既存システムの仕様を収集することで、収集したドメイン仕様の完全性を高めることが出来る。 8

要求定義法 [3/3] • 何故システムの違いや共通点を明らかにする必要があるのか？ • ドメインにとって不可欠な仕様、あるいはオプション的な仕様なのかを明らかにするため。 • 多くのシステムに共通して実装されている仕様はドメインにとって、必要不可欠な仕様であるといえる。 9

ツール概要 [1/2]:ツールに要求される機能 ドメイン知識の特徴 • 既存システムの一覧 • 機能一覧 • 機能がどの既存システムで使用されているか。 • 機能同士の関連 • 分析者が選択した機能一覧 • 分析者が付けた機能のプライオリティ一覧 • 選択した要求の一覧を出力 • Good SRS [IEEE830] 11

既存システム 13 13

要求の候補 機能を含むシステム関連機能既存システム機能を含むシステムの数 14 14

要求の候補 機能を含むシステム関連機能既存システムチェックボックス左：mandatory 右：optional 機能を含むシステムの数 15 15

要求の候補 機能を含むシステム関連機能既存システムチェックボックス左：mandatory 右：optional 機能を含むシステムの数選択した機能の階層木テンプレート出力 16 16

評価実験: 概要 [1/5]目的 • ツールは効果的に運用できるか？ • 5つの測度から、ツールの有用性を確認する。 • 仮定として、全ての測度においてツール有のグループが良い結果となるとする。 • 正解はドメインエキスパートが作成。 18

評価実験～評価メトリックス X Y 1.Aは… 2.Bは… 3.Cは… …… …… Aは… X X Y Y Z Z 被験者が作成した要求リスト正当性：精度正解完全性：再現率時間効率修正容易性：冗長追跡可能性：ラベル付け 19

評価実験: 概要 [2/5] • 被験者は情報工学科の学生25名 • 基礎的なプログラミング技術や要求仕様書の書き方も事前に学習済み • チームXとYに分け，Xは13名ツール無し，Yは12名ツール有りで実験を行う． 20

評価実験～全体スケジュール ツールに慣れてから比較 21 DK = ドメイン知識

評価実験: 概要 [3/5]使用した問題文 査読結果を受け取り，管理する作業が煩雑である．締切までに結果を返さない査読者に催促するのが面倒である．論文に査読者をバランス良く割り当てる作業が大変である．投稿論文に合った査読者を早めにみつけておくのが難しい．カメラレディを収集しチェックするのが困難である．採択候補を絞るのが面倒である．採択の議論記録をとり忘れないようにしたい．論文の集まり具合，査読の進み具合が気になる． 22

評価実験: 概要 [4/5] Xグループ (NoTool)‏ inputs 被験者X output 25個の単語辞書 8項目の問題文機能項目リスト system S-1 75 項目. system S-2 62 項目. system S-3 26 項目. 23

評価実験: 概要 [5/5] Yグループ (Tool)‏ inputs 被験者Y output 25個の単語辞書 8項目の問題文機能項目リスト system S-1 75 項目. system S-2 62 項目. ツール system S-3 26 項目. 24

1.0 0.8 0.6 0.4 0.2 0.0 No Tool Tool Precision (有意差あり)‏ 平均 0.90 0.66 評価実験: 結果 [1/5]H1(Correctness)‏ • ツール無しのグループの方が結果が良い。 • 被験者はツールによって安易に機能項目を選択できる。 • そのため、被験者は余計な機能項目まで選択してしまった。 25

No Tool Tool Recall （有意差あり）平均 0.27 0.75 評価実験: 結果 [2/5]H2(Completeness)‏ • 仮定どおりツール有りの方が良い結果になった。 • ツールを使えば、目論見どおり、要求項目の欠落を減らすことが出来る。 • これはツール無しが極端に低いだけではないか？ 26

評価実験: 結果 [3/5]H3(Traceability)‏ • 被験者は既にラベル付けの重要性を学んでいる。 • だが、ラベル付けをした被験者は少ない。 • この結果からツールによるサポートが非常に有効だと言える。 No Tool 7.7% Tool 100.0% Labeling 27

評価実験: 結果 [4/5]H4(Priority)‏ • ツール有りの方が良い結果になっている。 • ツールならば強制的に mandatory か optional のいずれかを選択するのでPriorityを必ず付けることになる。 No Tool 30.8% Tool 100.0% Priority (mandatory or optional) 28

15 10 5 No Tool Tool Performance （min）（有意差あり）平均 4.23 1.13 評価実験: 結果 [5/5]H5(Efficiency)‏ • 機能一つを選択するのにかかった時間。 • ツール有りの方が短い時間で選択できた。 • ツールによって選択の時間効率が良くなった。 29

実験後のツール改良 [1/4] • 実験結果からツールを改良する。 • 問題点 • 精度がツール有りの方が低い。 • 再現率が75%というのは低い。 31

実験後のツール改良 [1/4] • 実験結果からツールを改良する。 • 問題点 • 精度がツール有りの方が低い。 • 再現率が75%というのは低い。 32

何故、こういった問題がおきるのか？ ⇒「問題文」と「選択する機能」の間に溝がある。例：問題文１「査読結果を受け取り，管理する作業が煩雑である．」という文章のみから、機能要求を選ぶにはドメイン知識が必要になる。実験後のツール改良 [2/4] 33

実際に、この問題を解くときは… 問題文から手順（問題を解決するシナリオ）を考え、必要な機能を選ぶ。解決案として。 ⇒「問題文」と「選択する機能」の仲立ちになるもの（シナリオとか）があればいい。実験後のツール改良 [3/4] 34

実験後のツール改良 [4/4] 35

結論 [1/1]まとめ • 既存システムを利用したドメイン知識収集の手法およびツールを開発した。 • ツールの有用性を評価実験によって証明することが出来た。 • さらに実験によって明らかになった手法の問題点を解決するため、ユースケースシナリオを利用する手法を提案した。 37

結論 [1/1]今後の課題 • 再現率を上げることを目的として追加した機能の評価実験が必要。 • ユースケースシナリオ以外の手法（例えば、問題フレームなど）の提案。 38

ご清聴有難うございました。 39

既存システムの仕様を再利用する 要求定義支援ツールの実現と評価