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

信州大学院 情報工学専攻 修士二年海尻海谷研究室

北沢直幸

2

目次

1. 序論2. 既存システムに基づく要求定義法3. ツール概要4. 評価実験5. ツールの改良6. 結論

3

序論 [1/2]背景

ソフトウェアシステムは様々なドメインで使用されている。

要求分析者は馴染みの無いドメインの分析をする必要がある

ドメイン知識はそのような分析者にとって重要である。

4

序論 [2/2]目的

同ドメインの類似既存システムの仕様を比較・整理することで、ドメイン知識理解の手助けとすること。1.ドメイン特有の問題の解決法を得られる。 2.要求項目（機能）の候補とできる。

新システム開発において要求定義を行う際、この手法とツールでドメイン知識を理解することを目的としている。

5

目次

1. 序論2. 既存システムに基づく要求定義法3. ツール概要4. 評価実験5. ツールの改良6. 結論

6

要求仕様書 [1/1]

IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specification

1. はじめに1. 目的2. 範囲……

2. 全体概要説明1. 製品の背景2. 製品の機能 ……

3. 要求仕様• 外部インタフェース• 機能• 性能• データベース要求• 制約• ソフトウェアの属性

…………

要求仕様書 アウトライン

Correct （正当性）Unambiguous （非あいまい性）Complete （完全性）Consistent （一貫性）Priority （優先順位）Verifiable （検証容易性）Modifiable （修正容易性）Traceable （追跡可能性）

ソフトウェア要求仕様の特性

7

要求定義法 [1/3]

1. 類似既存システムから仕様を収集する。2. システムごとの仕様の違いを比較し、そのド

メインにとって一般的である仕様、また逆に珍しい仕様などを明らかにする。

3. 顧客からの要望から、必要とされている仕様を選択する。

8

要求定義法 [2/3]

何故、類似既存システムから仕様を収集するのか？

1. ドメイン特有の問題に対して、既に使用されている良い解決法を得られる。

2. 複数の類似既存システムの仕様を収集することで、収集したドメイン仕様の完全性を高めることが出来る。

9

要求定義法 [3/3]

何故システムの違いや共通点を明らかにする必要があるのか？ドメインにとって不可欠な仕様、あるいはオ

プション的な仕様なのかを明らかにするため。多くのシステムに共通して実装されている仕

様はドメインにとって、必要不可欠な仕様であるといえる。

10

目次

1. 序論2. 既存システムに基づく要求定義法3. ツール概要4. 評価実験5. ツールの改良6. 結論

11

ツール概要 [1/2]: ツールに要求される機能

既存システムの一覧 機能一覧 機能がどの既存システムで使用されている

か。 機能同士の関連 分析者が選択した機能一覧 分析者が付けた機能のプライオリティ一覧 選択した要求の一覧を出力

Good SRS [IEEE830]

ドメイン知識の特徴

1212

1313

既存システム

1414

要求の候補

機能を含むシステムの数

機能を含むシステム

関連機能

既存システム

1515

チェックボックス左： mandatory右： optional

要求の候補

機能を含むシステムの数

機能を含むシステム

関連機能

既存システム

1616

チェックボックス左： mandatory右： optional

要求の候補

機能を含むシステムの数

機能を含むシステム

選択した機能の階層木

テンプレート出力

関連機能

既存システム

17

目次

1. 序論2. 既存システムに基づく要求定義法3. ツール概要4. 評価実験5. ツールの改良6. 結論

18

評価実験 : 概要 [1/5]目的

• ツールは効果的に運用できるか？

• 5 つの測度から、ツールの有用性を確認する。• 仮定として、全ての測度においてツール有のグ

ループが良い結果となるとする。• 正解はドメインエキスパートが作成。

19

YX

Y

X

Z

Y

ZY

Y

XY

評価実験 ～ 評価メトリックス

完全性：再現率

修正容易性：冗長

正当性：精度

追跡可能性：ラベル付け

正解

被験者が作成した要求リスト

XY Z

時間効率

1.A は…2.B は…3.C は……………A は…

20

評価実験 : 概要 [2/5]

被験者は情報工学科の学生 25名基礎的なプログラミング技術や要求仕様書の

書き方も事前に学習済みチーム X と Y に分け， X は 13名ツール無し，

Y は 12名ツール有りで実験を行う．

21

評価実験 ～ 全体スケジュールチーム X チーム Y

1回目 要求獲得練習フィードバック

2回目 ツール無しDK=会議

ツール練習DK=音楽

3回目 ツール練習DK=音楽

ツール有りDK=会議

4回目 ツール有りDK=ブラウザ

ツール無しDK=ブラウザ

最終回 アンケート ＆ 討論

比較

ツールに慣れてから

DK = ドメイン知識

22

評価実験 : 概要 [3/5]使用した問題文

a. 査読結果を受け取り，管理する作業が煩雑である．b. 締切までに結果を返さない査読者に催促するのが面倒

である．c. 論文に査読者をバランス良く割り当てる作業が大変で

ある．d. 投稿論文に合った査読者を早めにみつけておくのが難

しい．e. カメラレディを収集しチェックするのが困難である．f. 採択候補を絞るのが面倒である．g. 採択の議論記録をとり忘れないようにしたい．h. 論文の集まり具合，査読の進み具合が気になる．

23

評価実験 : 概要 [4/5]

8 項目の問題文

system S-3 26 項目 .

25個の単語辞書

system S-2 62 項目 .system S-1 75 項目 .

機能項目リスト

被験者 X outputinputsX グループ (NoTool)

24

評価実験 : 概要 [5/5]

8 項目の問題文

system S-3 26 項目 .

25個の単語辞書

system S-2 62 項目 .system S-1 75 項目 .

機能項目リスト

被験者 Y outputinputs

ツール

Y グループ (Tool)

25

評価実験 : 結果 [1/5]H1(Correctness)

Precision ( 有意差あり )

No Tool Tool

0.0

0.2

0.4

0.6

0.8

1.0

ツール無しのグループの方が結果が良い。

被験者はツールによって安易に機能項目を選択できる。

そのため、被験者は余計な機能項目まで選択してしまった。

平均 0.90 0.66

26

評価実験 : 結果 [2/5]H2(Completeness) 仮定どおりツール有り

の方が良い結果になった。

ツールを使えば、目論見どおり、要求項目の欠落を減らすことが出来る。

これはツール無しが極端に低いだけではないか？

1 2

0.2

0.4

0.6

0.8

1.0

Recall （有意差あり）No Tool Tool

平均 0.27 0.75

27

評価実験 : 結果 [3/5]H3(Traceability)

被験者は既にラベル付けの重要性を学んでいる。

だが、ラベル付けをした被験者は少ない。

この結果からツールによるサポートが非常に有効だと言える。

No Tool

7.7%Tool

100.0%

0

20

40

60

80

100

1 2

Labeling

28

評価実験 : 結果 [4/5]H4(Priority)

ツール有りの方が良い結果になっている。

ツールならば強制的に mandatory か optional のいずれかを選択するので Priority を必ず付けることになる。

Priority (mandatory or optional)

0

20

40

60

80

100

1 2No Tool

30.8%Tool

100.0%

29

評価実験 : 結果 [5/5]H5(Efficiency)

機能一つを選択するのにかかった時間。

ツール有りの方が短い時間で選択できた。

ツールによって選択の時間効率が良くなった。

平均 4.23 1.13

Performance （ min ） （有意差あり）No Tool Tool

510

15

30

目次

1. 序論2. 既存システムに基づく要求定義法3. ツール概要4. 評価実験5. ツールの改良6. 結論

31

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

実験結果からツールを改良する。

問題点精度がツール有りの方が低い。再現率が 75% というのは低い。

32

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

実験結果からツールを改良する。

問題点精度がツール有りの方が低い。再現率が 75% というのは低い。

33

何故、こういった問題がおきるのか？ ⇒「問題文」と「選択する機能」の間に溝がある。

例： 問題文１「査読結果を受け取り，管理する作業が煩雑である．」という文章のみから、機能要求を選ぶにはドメイン知識が必要になる。

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

34

実際に、この問題を解くときは… 問題文から手順（問題を解決するシナリオ）を考え、必要な機能を選ぶ。

解決案として。 ⇒「問題文」と「選択する機能」の仲立ちにな

るもの（シナリオとか）があればいい。

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

35

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

36

目次

1. 序論2. 既存システムに基づく要求定義法3. ツール概要4. 評価実験5. ツールの改良6. 結論

37

結論 [1/1]まとめ

既存システムを利用したドメイン知識収集の手法およびツールを開発した。

ツールの有用性を評価実験によって証明することが出来た。

さらに実験によって明らかになった手法の問題点を解決するため、ユースケースシナリオを利用する手法を提案した。

38

結論 [1/1]今後の課題

再現率を上げることを目的として追加した機能の評価実験が必要。

ユースケースシナリオ以外の手法（例えば、問題フレームなど）の提案。

39

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