スライド 1

既存システムの仕様を再利用する
要求定義支援ツールの実現と評価
信州大学院情報工学専攻修士二年
海尻海谷研究室
北沢直幸
目次
1. 序論
2. 既存システムに基づく要求定義法
3. ツール概要
4. 評価実験
5. ツールの改良
6. 結論
2
序論 [1/2]
背景

ソフトウェアシステムは様々なドメインで使用されて
いる。

要求分析者は馴染みの無いドメインの分析をする
必要がある

ドメイン知識はそのような分析者にとって重要である。
3
序論 [2/2]
目的

同ドメインの類似既存システムの仕様を比較・整理
することで、ドメイン知識理解の手助けとすること。
1. ドメイン特有の問題の解決法を得られる。
2. 要求項目（機能）の候補とできる。

新システム開発において要求定義を行う際、この手
法とツールでドメイン知識を理解することを目的とし
ている。
4
目次
1. 序論
2. 既存システムに基づく要求定義法
3. ツール概要
4. 評価実験
5. ツールの改良
6. 結論
5
要求仕様書 [1/1]
要求仕様書アウトライン
はじめに
1. 目的
2. 範囲
……
2. 全体概要説明
1. 製品の背景
2. 製品の機能
……
3. 要求仕様
•
外部インタフェース
•
機能
•
性能
•
データベース要求
•
制約
•
ソフトウェアの属性
…………
1.
ソフトウェア要求仕様の特性
Correct（正当性）
Unambiguous（非あいまい性）
Complete（完全性）
Consistent（一貫性）
Priority（優先順位）
Verifiable（検証容易性）
Modifiable（修正容易性）
Traceable（追跡可能性）
IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specification
6
要求定義法 [1/3]
1. 類似既存システムから仕様を収集する。
2. システムごとの仕様の違いを比較し、そのドメイン
にとって一般的である仕様、また逆に珍しい仕様
などを明らかにする。
3. 顧客からの要望から、必要とされている仕様を選
択する。
7
要求定義法 [2/3]

何故、類似既存システムから仕様を収集するの
か？
1. ドメイン特有の問題に対して、既に使用されて
いる良い解決法を得られる。
2. 複数の類似既存システムの仕様を収集するこ
とで、収集したドメイン仕様の完全性を高めるこ
とが出来る。
8
要求定義法 [3/3]

何故システムの違いや共通点を明らかにする必要
があるのか？
 ドメインにとって不可欠な仕様、あるいはオプショ
ン的な仕様なのかを明らかにするため。
 多くのシステムに共通して実装されている仕様は
ドメインにとって、必要不可欠な仕様であるといえ
る。
9
目次
1. 序論
2. 既存システムに基づく要求定義法
3. ツール概要
4. 評価実験
5. ツールの改良
6. 結論
10
ツール概要 [1/2]
:ツールに要求される機能
ドメイン知識の特徴







既存システムの一覧
機能一覧
機能がどの既存システムで使用されているか。
機能同士の関連
分析者が選択した機能一覧
分析者が付けた機能のプライオリティ一覧
選択した要求の一覧を出力
 Good
SRS [IEEE830]
11
12
12
既存シス
テム
13
13
要求の候補
機能を含むシ
ステム
関連機能
既存シス
テム
機能を含むシステ
ムの数
14
14
要求の候補
機能を含むシ
ステム
関連機能
既存シス
テム
チェックボックス
左：mandatory
右：optional
機能を含むシステ
ムの数
15
15
要求の候補
機能を含むシ
ステム
関連機能
既存シス
テム
チェックボックス
左：mandatory
右：optional
選択した機能の階層
木
機能を含むシステ
ムの数
テンプレート出力
16
16
目次
1. 序論
2. 既存システムに基づく要求定義法
3. ツール概要
4. 評価実験
5. ツールの改良
6. 結論
17
評価実験: 概要 [1/5]
目的
•
ツールは効果的に運用できるか？
•
5つの測度から、ツールの有用性を確認する。
仮定として、全ての測度においてツール有のグルー
プが良い結果となるとする。
正解はドメインエキスパートが作成。
•
•
18
評価実験～評価メトリックス
被験者が作成した要求リスト
正当性：
精度
完全性：
再現率
修正容易性：
冗長
Y
X Y
X
正解
Y
Y
Y Z
追跡可能性：
ラベル付け
時間効率
Z
Z
1.Aは…
2.Bは…
3.Cは…
……
……
Aは…
19
評価実験: 概要 [2/5]

被験者は情報工学科の学生25名
基礎的なプログラミング技術や要求仕様書の書
き方も事前に学習済み
 チームXとYに分け，Xは13名ツール無し，Yは12
名ツール有りで実験を行う．

20
評価実験～全体スケジュール
1回目
2回目
チームX
チームY
要求獲得練習
ツールに慣
れてから
フィードバック
ツール無し
ツール練習
DK=会議
3回目
4回目
最終回
比較 DK=音楽
ツール練習
ツール有り
DK=音楽
DK=会議
ツール有り
ツール無し
DK=ブラウザ
DK=ブラウザ
アンケート＆討論
DK = ドメイン知識
21
評価実験: 概要 [3/5]
使用した問題文
a.
b.
c.
d.
e.
f.
g.
h.
査読結果を受け取り，管理する作業が煩雑である．
締切までに結果を返さない査読者に催促するのが面倒で
ある．
論文に査読者をバランス良く割り当てる作業が大変である．
投稿論文に合った査読者を早めにみつけておくのが難し
い．
カメラレディを収集しチェックするのが困難である．
採択候補を絞るのが面倒である．
採択の議論記録をとり忘れないようにしたい．
論文の集まり具合，査読の進み具合が気になる．
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

ツール無しのグループの
方が結果が良い。

被験者はツールによって
安易に機能項目を選択で
きる。
そのため、被験者は余計
な機能項目まで選択して
しまった。
0.0
0.2
0.4
0.6
0.8
1.0
評価実験: 結果 [1/5]
H1(Correctness)
No Tool
Tool
Precision (有意差あり)
平均
0.90

0.66
25
1.0
評価実験: 結果 [2/5]
H2(Completeness)
仮定どおりツール有りの
方が良い結果になった。

ツールを使えば、目論見
どおり、要求項目の欠落
を減らすことが出来る。
これはツール無しが極端
に低いだけではないか？
0.2
0.4
0.6
0.8


1
No Tool
2
Tool
Recall （有意差あり）
平均
0.27
0.75
26
評価実験: 結果 [3/5]
H3(Traceability)
100

80

60
被験者は既にラベル付け
の重要性を学んでいる。
だが、ラベル付けをした被
験者は少ない。
40

20
0
1
No Tool
2
Tool
7.7%
100.0%
この結果からツールによ
るサポートが非常に有効
だと言える。
Labeling
27
評価実験: 結果 [4/5]
H4(Priority)
100

ツール有りの方が良い結
果になっている。

ツールならば強制的に
mandatory か optional
のいずれかを選択するの
でPriorityを必ず付けるこ
とになる。
80
60
40
20
0
No Tool
1
Tool
2
30.8%
100.0%
Priority (mandatory or optional)
28
評価実験: 結果 [5/5]
H5(Efficiency)
15

10

5

No Tool
機能一つを選択するのに
かかった時間。
ツール有りの方が短い時
間で選択できた。
ツールによって選択の時
間効率が良くなった。
Tool
Performance （min）（有意差あり）
平均
4.23
1.13
29
目次
1. 序論
2. 既存システムに基づく要求定義法
3. ツール概要
4. 評価実験
5. ツールの改良
6. 結論
30
実験後のツール改良 [1/4]

実験結果からツールを改良する。

問題点
精度がツール有りの方が低い。
 再現率が75%というのは低い。

31
実験後のツール改良 [1/4]

実験結果からツールを改良する。

問題点
精度がツール有りの方が低い。
 再現率が75%というのは低い。

32
実験後のツール改良 [2/4]

何故、こういった問題がおきるのか？
⇒「問題文」と「選択する機能」の間に溝がある。

例：

問題文１「査読結果を受け取り，管理する作業が煩
雑である．」という文章のみから、機能要求を選ぶに
はドメイン知識が必要になる。

33
実験後のツール改良 [3/4]

実際に、この問題を解くときは…

問題文から手順（問題を解決するシナリオ）を考え、
必要な機能を選ぶ。

解決案として。
⇒「問題文」と「選択する機能」の仲立ちになるもの
（シナリオとか）があればいい。

34
実験後のツール改良 [4/4]
35
目次
1. 序論
2. 既存システムに基づく要求定義法
3. ツール概要
4. 評価実験
5. ツールの改良
6. 結論
36
結論 [1/1]
まとめ



既存システムを利用したドメイン知識収集の手法お
よびツールを開発した。
ツールの有用性を評価実験によって証明することが
出来た。
さらに実験によって明らかになった手法の問題点を
解決するため、ユースケースシナリオを利用する手
法を提案した。
37
結論 [1/1]
今後の課題

再現率を上げることを目的として追加した機能の評
価実験が必要。

ユースケースシナリオ以外の手法（例えば、問題フ
レームなど）の提案。
38

ご清聴有難うございました。
39

Download Report