149

要求工学における品質評価指標の研究
九州産業大学 情報科学部

廣田 豊彦

Toyohiko HIROTA

Faculty of Information Science, Kyushu Sangyo University

hirota@is.kyusan-u.ac.jp, http://www.is.kyusan-u.ac.jp/~hirota/

はじめにの品質が最終成果物にどのような影響を及ぼすかの評価はまだなされていない．一方，ISO/IEC 9126 (Software

2007 年度から 2008 年度にかけて，表記の研究課題で科学研究費補助金（基盤研究 (C)）が交付され，研究を実施した．以下は 2009 年 4 月に提出した研究成果報告

品質やその評価について定めている．評価指標として，機書の再録である．の特性があり，それぞれの特性には，3〜5 個の副特性がengineering − Product quality −) では，最終成果物の能性，信頼性，使用性．効率性，保守性，移植性の 6 個対応付けられている．しかし，要求仕様書特有の性質が研究成果の概要あるため，このような最終成果物の評価指標をそのまま適用することは困難である．

ソフトウェア要求仕様書の品質とソフトウェア品質の相関関係を分析し，「便利さ」「信頼性」「保守性」の３つ

1・3 要求仕様書の課題の代表的因子を抽出した．さらに仕様書の全般的品質を要求仕様書は開発作業中にも，顧客の要請や環境の変判定する手段として構成要素の欠落に着目することが有化によって，頻繁に変更が起こるため，揮発性あるいは安用であることを明らかにした．その他に，要求仕様書の定性といった評価指標が考えられる．ISO/IEC 9126 に品質を向上させるための手法を，ビジネス，組込みシスおいても，保守性の副特性として安定性があるが，これテム，ユーザインタフェース，情報システム開発教育なは将来の最終成果物の改訂に関わる性質であり，要求仕ど，それぞれの分野に応じて個別に開発した．

様書の安定性とは性格が異なっている．要求仕様書の安定性は，単に仕様書本体の性質というよりもむしろ，要1. 研究開発当初の背景
1・1 要求分析の重要性

求変更や管理といったプロセスの観点で捉えられなければならない．また，近年はコンポーネントを用いる開発が一般化しているが，その場合には，要求に適合したコソフトウェアを開発するには，まず顧客やユーザの要ンポーネントが存在するかどうか，あるいは新規開発部件や要望を十分に聞き，それをソフトウェア要求仕様書分の要求仕様が既存のコンポーネントに適合するかどうとして書き下す必要がある．この要求分析フェーズは，ソかによって「実現容易度」のような指標が重要になってフトウェア開発の最初に位置しており，このフェーズでのくる．

誤りは，以後に続くソフトウェア開発のすべてのフェーズに影響を及ぼす．すなわち，ここで作成される要求仕様書の品質が，最終成果物であるソフトウェア製品の品質や，開発コスト，開発期間に大きな影響を及ぼすことになる．たとえば，要求仕様書の誤りが修正されないま
まにソフトウェア開発が進行し，ソフトウェアの最終テストでその誤りが発見された場合，修正に要するコストは，実装フェーズの誤りと比較して 100 倍以上にもなると言われている．

1・2 品質評価指標の規格
IEEE 標準 830-1998 (IEEE Recommended Practicefor Software Requirements Specifications) では，要求1・4 品質評価指標の課題
要求仕様書の評価指標は，対象とするドメイン，採用する開発プロセスなど，開発プロジェクトの状況によっても異なってくる．現状では要求仕様書特有の品質評価指標の技術が確立されていないだけでなく，状況に応じた考慮もなされていない．要求仕様書の品質を評価するための状況に応じた適切な指標が存在しないという問題を解決するために，要求仕様書独自の品質評価指標とその計測ツールの開発を目指す必要がある．

2. 研 究 の 目 的性，非曖昧性，重要度と安定性のランク付け，検証可能性，

2・1 要求仕様書の品質評価指標
IEEE 標準 830-1998 では，妥当性，完全性，無矛盾性，変更可能性，追跡可能性の 8 個を列挙している．しかし，非曖昧性，重要度と安定性のランク付け，検証可能性，変具体的な品質評価手法は確立されておらず，要求仕様書更可能性，追跡可能性が評価指標としてあげられている．

仕様書の品質評価指標として，妥当性，完全性，無矛盾502

九州産業大学情報科学会誌
巻 1 号（(2011年11月)
2011 年 10 月）
九州産業大学情報科学会誌1010巻1号

これらは要求仕様書という文書構造を対象とした一般的

これらは要求仕様書という文書構造を対象とした一般的な評価指標である．本研究では，これら以外にも，要求な評価指標である．本研究では，これら以外にも，要求の内容本体まで考えた評価指標を，事例調査を通じて収の内容本体まで考えた評価指標を，事例調査を通じて収集する．ただし，要求の内容は，要求仕様書が対象とし集する．ただし，要求の内容は，要求仕様書が対象としているドメイン（たとえば，Web アプリケーション，機ているドメイン（たとえば，Web アプリケーション，機器組込みソフトウェアなど）によって大きく異なるため，器組込みソフトウェアなど）によって大きく異なるため，ドメイン固有の性質に応じた評価指標が必要となる．こドメイン固有の性質に応じた評価指標が必要となる．このようにして収集した評価指標について，定義をカタロのようにして収集した評価指標について，定義をカタログ化し，事例などとともにデータベース化し，評価指標グ化し，事例などとともにデータベース化し，評価指標ベースを開発する．また，ドメイン固有の評価指標につベースを開発する．また，ドメイン固有の評価指標については，そのドメインのオントロジを活用して，評価指いては，そのドメインのオントロジを活用して，評価指標を形式的に定義する手法，および計測計算方法を記述標を形式的に定義する手法，および計測計算方法を記述する手法を開発する．これによって，計測ツールの自動する手法を開発する．これによって，計測ツールの自動生成ツールを実現することが可能になる．

生成ツールを実現することが可能になる．

2・2 要求定義プロセスの品質評価

3・2 平成 19 年度 10 月〜3 月期

要求定義プロセスの質が要求仕様書の質に大きな影響

要求定義プロセスの質が要求仕様書の質に大きな影響を及ぼす．本研究では，まず一般的な要求定義プロセスを及ぼす．本研究では，まず一般的な要求定義プロセスを定義し，それに対して CMMI (Capability Maturity

Model Integration) モデルを適用することで，要求定義を定義し，それに対して CMMI (Capability Maturity

Model Integration) モデルを適用することで，要求定義プロセス一般の評価の枠組みを確定する．個別の要求定プロセス一般の評価の枠組みを確定する．個別の要求定

義プロセスは，ゴール指向分析法，シナリオ分析法など

義プロセスは，ゴール指向分析法，シナリオ分析法などなんらかの方法論の手順に従って行われる．これらに共なんらかの方法論の手順に従って行われる．これらに共通のゴール/プラクティスを定義するとともに，方法論や採用した手順ごとに，固有のゴール/プラクティスを開発

通のゴール/プラクティスを定義するとともに，方法論や採用した手順ごとに，固有のゴール/プラクティスを開発する．一般にプロセスのベンチマーキング（比較のためする．一般にプロセスのベンチマーキング（比較のために性能を評価すること）は容易ではないが，本研究では，に性能を評価すること）は容易ではないが，本研究では，定義されたゴール/プラクティスに基づいて現実の要求定定義されたゴール/プラクティスに基づいて現実の要求定

義プロセスをベンチマーキングするための要件を明らか

義プロセスをベンチマーキングするための要件を明らかにし，それに適合するプロセス記述技法を開発する．にし，それに適合するプロセス記述技法を開発する．

2・3 要求仕様書の品質が最終成果物に与える影響の分析
2・1 節で定義した要求仕様書の評価指標と ISO/IEC9126 で規定されているソフトウェアの品質特性に与える影響を，因果関係の観点からモデル化する．対象とするドメイン（たとえば，Web アプリケーション，機器組込みソフトウェアなど）によって重視する品質特性が異なるため，ドメインごとに，事例研究をもとに分析を行う．
分析結果に基づいて，代表的なドメインに関して定量的な因果関係モデルを構築し，2・1 節での研究成果である評価指標計測ツールと組み合わせることで，要求仕様書の品質からソフトウェアの品質を予測したり，低品質になりそうな部分の指摘を行ったりするツールを開発する．

3. 研 究 の 方 法
3・1 平成 19 年度 4 月〜9 月期

3・3 平成 20 年度 4 月〜9 月期
前年度に定義した要求仕様書の評価指標と ISO/IEC 9126
で規定されているソフトウェアの品質特性に与える影響を，因果関係の観点からモデル化する．対象とするドメイン（たとえば，Web アプリケーション，機器組込みソフトウェアなど）によって重視する品質特性が異なるため，ドメインごとに，事例研究をもとに分析を行う．分析結果に基づいて，代表的なドメインに関して定量的な因果関係モデルを構築し，3・1 節での研究成果である評
価指標計測ツールと組み合わせることで，要求仕様書の品質からソフトウェアの品質を予測したり，低品質になりそうな部分の指摘を行ったりするツールを開発する．

3・4 平成 20 年度 10 月〜3 月期
本研究の成果をまとめるとともに，国際会議（RE08IEEE 標準 830-1998 では，妥当性，完全性，無矛盾性，や APSEC2008）の他，国内の研究会（情報処理学会ソ非曖昧性，重要度と安定性のランク付け，検証可能性，変フトウェア工学研究会など）で，成果を発表し，会議で更可能性，追跡可能性が評価指標としてあげられている．の議論を通じて今後の課題を明らかにする．

351

要求工学における品質評価指標の研究
要求工学における品質評価指標の研究

4. 研 究 成 果
4・1 ロールに着目したビジネス領域における要求獲得手法 RODAN の提案
ビジネスとは，複数の人々が関与し，各々の人々が各と，GUI とアプリケーション処理部分の連結部分も変更する必要がある．しかし変更箇所を手動で探索し，修正することは，開発者にとって大きな労力となる．そこで本
研究では，ソフトウェアのソースコードの変更箇所を自動で探索し，修正方法を提示する手法を提案する．具体

自に与えられた責務を，自分たちの意思によって達成し，的には，ウィジェットをその利用目的ごとに分類し，GUI同時に，組織としての目的を達成する営みである．したを変更方法のパターンを定義しておく．また，GUI の書がって、ビジネスシステムの要求分析では，システムのくウィジェットが持つメソッドを，その機能に応じて分利用者だけでなく，正負の影響を受ける複数の人々の責類しておく．そして，どのように GUI を変更するかのパ務と，それへの影響を分析しなければならない．ビジネ

ターンが指定されたとき，ウィジェットやメソッドの分ス領域を分析する目的は，システムへの要求の背景を明類に応じて，ソースコード中のどの部分をどのように変らかにして，要求が発せられた根拠を示すことにある．

更すれば良いかを自動的に検索し，提示する．

我々はビジネスシステムの要求を獲得するための手法として，RODAN を開発している．RODAN を適用する
分析者は，ステークホルダが担うロールに着目し，個人へのインタビューから得られた要求の背景を明らかにすることができるようになる．本稿では，最初に RODANを適用して得られる成果物のメタモデルを示し，金庫という身近な事例に適用した結果を用いて手法を評価する．
この手法を適用した結果，要求の背景を明らかにすることによって，未定義の要求を発見できること，さらにミスユースケースを得るためのネガティブアクタを抽出できることを示すことができた．最後に，手法の実用性についても考察を行う．

4・2 正常シナリオからの例外シナリオの導出手法
シナリオ言語で記述された正常シナリオから例外シナリオを生成する手法を提案する．この手法は，(1) 例外計画の生成と (2) ユーザが選択した計画からの例外シナリ

4・5 ソフトウェア要求における代替案選択のための属性付きゴール指向分析
ソフトウェア要求分析段階では，達成すべき要求に関して多くの代替案があり，開発者とステークホルダはどれか一つを選択しなければならない．このような意思決定を支援するためには，以下の２つの点を考慮することが重要である．すなわち，(1) 代替案相互の依存関係，および (2) 複数の判定基準に基づく評価とトレードオフ，である．本論文は，ゴール指向分析を拡張することでこれらの２つの課題を扱う手法を提案する．ゴール指向分析
では，抽出された要求とそれらの依存関係は AND-OR有向非巡回グラフで表される．我々はこの技法を用いて，代替案の依存関係をモデル化する．さらにグラフの節点と枝に属性値と伝搬規則を割り当て，代替案を評価する．
属性とその計算は，開発プロジェクトに大きく依存する．

オの生成，から成る．提案手法を用いることで，ユーザ

そこで我々のアプローチでは，当該プロジェクトに適合は開発の初期段階で，ありうる例外シナリオの欠落を減しうる属性と計算法を選択する．なお，代替案とそれららすことができる．本手法を用いた事例をいくつか示す．の属性値の表示には TOPSIS 法を用いている．

4・3 既存システムのユースケース図を利用したステー
クホルダと非機能要求の獲得法
同一分野の既存システムのユースケース図の比較を通4・6 組込みシステムの非正常事象を抽出するための概念モデル

して，利害関係者や機能に関する品質要求等を識別する

組込みシステムの品質を改善するための，非正常事象手法を提案する．本手法では，最初にユースケース図間を抽出するための概念モデルを提案する．組込みソフトの差異を特徴付けている変数を識別する．次に，そのよウェアは規模と複雑さがますます増大しているが，一方うな変数の変化を意図的に想定することで，影響を受けで，開発期間を短縮することも求められている．このよる存在を識別し，ステークホルダとする．加えて，そのうな風潮は，結果的に非正常事象の見落としにつながり，変化をステークホルダがどのように評価しているかをも組込みソフトウェアの品質低下をもたらしている．我々とに非機能要求を識別する．

は非正常事象の見落としを防止するために，分析マトリッ

4・4 ウィジェットの役割と変更パターンに基づく GUIフローダイアグラム（IFD）を用いる手法を提案してきクスを用いる組込みシステム改良手法（ESIM）と，情報変更手法た．これらの２つの手法は独立に開発されたものである．

使い易いソフトウェアの実現のためには，GUI を評価・本論文では，両手法を包含する概念モデルを提案し，専改良するという過程を繰り返すことが有効である．その門の技術者が組込みシステムの非正常事象を抽出する際際には，GUI のレイアウトだけでなくウィジェットの種の抽象化機構を明らかにする．そして事例を紹介し，ド類の変更も必要となる．ウィジェットの種類を変更する

メインモデルについて議論する．

524

九州産業大学情報科学会誌
巻 1 号（(2011年11月)
2011 年 10 月）
九州産業大学情報科学会誌1010巻1号

4・7 情報システム開発教育におけるプロジェクト管理

4・10 要求品質とソフトウェア品質特性の相関

著者は 2004 年度から，九州産業大学情報科学部においソフトウェア工学研究会要求工学ワーキンググループて，システム開発演習を実施してきた．その経験からさでは，要求仕様書の品質と最終成果物であるソフトウェ

まざまな情報システム開発教育の問題点が明らかになっ

アの品質に関するアンケート調査をメンバーを対象に実た．それらの問題点を３つの観点で整理した．第１にシ施し，その結果に基づいて，両者の品質の相関に関するステム開発の観点で，学生にどのようなシステムをどの議論を行った．その時のアンケート結果を統計的に分析ように開発させるかが重要である．第２にプロジェクトした結果，要求仕様書の品質とソフトウェアの品質を関演習の観点で，学生に適切にプロジェクトを実施させる

連付ける３つの因子「便利さ」「信頼性」「保守性」を抽ことは容易ではない．第３にプロジェクト管理の観点で，出することができた．

演習の進行を把握し，制御することは，教員と学生の双方の課題である．2007 年度はこれらの問題点の解決を目

4・11 要求仕様の規格適合性指して，パーソナルソフトウェアプロセスやアーンドバ

要求分析の主な成果物は要求仕様書である．IEEE 標

リューマネジメントの導入など，さまざまな試みを実施

準 830-1998 では，ソフトウェア要求仕様書（以下 SRS）した．に書くべき内容や，SRS が持つべき性質などを定め，さ4・8 事例研究：プロジェクト全般に及ぶ要求獲得プロ

は，Web 上に公開されている教材用の要求仕様書などをらに SRS の具体的な目次を例示している．そこで我々
セス
要求変更は時としてプロジェクトの失敗の要因となることがある．現在では，多くのプロジェクトで増分的開発が実施され，新規要求や要求変更は可能な限りプロジェ対象として，IEEE 標準に適合しているかどうかを調べてみた．

5. 主な発表論文等

クトに組み込まれる．そこでは要求プロセスは他の開発プロセスと統合されており，我々はそのようなプロセスを当行要求プロセスと呼ぶ．我々は１つのプロジェクトの開始から終了までの要求プロセスを，定性的かつ定量的に調査した．ソフトウェアアーキテクチャの特定部分に含まれるコンポーネントに着目することで，要求の型を明らかにすることを目指している．それぞれの型は，要求の合理的根拠に基づいて典型的な要求プロセスに対応する．事例研究としてレストランの注文管理システムを扱った．本論文では，その事例を説明し，要求プロセスの型について述べる．そして，開発の初期段階ですべての要求を獲得できない理由について考察する．

4・9 Web サービスを用いたエンドユーザ主導型要求定義
情報技術（IT）は，持続可能社会において資源の節約と環境の保全に貢献することが期待されている．そのためにはアプリケーションソフトウェアが必要であり，ITの専門家に開発してもらうためには経費が必要になる．しかしそのような経費を捻出するのは容易ではない．このジレンマを解消するために欠かせないのが，エンドユーザ主導型開発である．本論文は，抽象フォームを用いた要求定義を述べており，ビジネスの専門家はそれを用いて自身でアプリケーションを構築する．
「一つのサービス＝一つのフォーム」という単純な概念に基づいて，抽象フォームは Web サービスのインタフェースとみなすことができる．そこでビジネスロジックは，入力フォームから出力フォームへの変換として，ビジネスの専門家が定義することができる．

［雑誌論文］（計 9 件）

(1) 中谷多哉子, 藤野晃延, ロールにロールに着目したビジネス領域における要求獲得手法 RODAN の提案, 情報処理学会論文誌, Vol.48, 2534-2550, 2007.
(2) Atsushi Ohnishi, A Generation Method of Exceptional Scenarios from a Normal Scenario, IEICE Transactions on Information and Systems,
Vol.E91-D, 881-887, 2008.
(3) Haruhiko Kaiya, Akira Osada, Kenji Kaijiri,
Identifying Stakeholders and Their Preferences
about NFR by Comparing Use Case Diagramsof Several Existing Systems, IEICE Transactions
on Information and Systems, Vol.E91-D, 890-906,
2008.
(4) Junko Shirogane, Kazuhiro Fukaya, Hajime Iwata,
Kouji Watanabe, Yoshiaki Fukazawa, GUI Change
Method according to Roles of Widgets and Change
Patterns, IEICE Transactions on Information andSystems, Vol.E91-D, 907-920, 2008.
(5) Kazuma Yamamoto, Motoshi Saeki, Attributed
Goal–Oriented Analysis Method for Selecting Alternatives of Software Requirements, IEICE Transactions on Information and Systems, Vol.E91-D,921-932, 2008.
(6) Keiichi Katamine, Yasufumi Shinyashiki, ToshiroMise, Masaaki Hashimoto, Naoyasu Ubayashi, Takako
Nakatani, A Conceptual Model for Analysis Methodof Extracting Unexpected Obstacles of Embed-553

要求工学における品質評価指標の研究
要求工学における品質評価指標の研究

ded Systems, Knowledge–Based Software Engineering, Frontiers in Artificial Intelligence andApplications, Vol.180, 22-31, 2008.
(7) Toyohiko Hirota, Project Management in Information System Development Education, Knowledge –Based Software Engineering, Frontiers inArtificial Intelligence and Applications, Vol.180,515-524, 2008.
(8) Takako Nakatani, Shouzo Hori, Naoyasu Ubayashi,Keiichi Katamine, Masaaki Hashimoto, A Case
Study: Requirements Elicitation Processes throughout a Project, IEEE International Conference onRequirements Engineering, 241-246, 2008.
(9) Takeshi Chusho, Noriyuki Yagi and Katsuya
Fujiwara, End–user Initiative Requirement Definitions Based on Web Service, The 2009 IAENG
International Conference on Internet Computingand Web Services, 1020-1026, 2009.
［学会発表］（計 2 件）

(1) 廣田豊彦, 貫大路, 要求品質とソフトウェア品質特性の相関, 情報処理学会ソフトウェア工学研究会ウィンターワークショップ, 2008 年 1 月 24 日, 愛媛大学
（愛媛県松山市）.
(2) 廣田豊彦, 橋本薫平, 要求仕様の規格適合性, 情報処理学会ソフトウェア工学研究会ウィンターワーク
ショップ, 2009 年 1 月 23 日, 宮崎市民プラザ（宮崎県宮崎市）.

6. 研 究 組 織
6・1 研 究 代 表 者
廣田 豊彦 (HIROTA TOYOHIKO) 九州産業大学・情報科学部教授

6・2 研 究 分 担 者（なし）

6・3 連 携 研 究 者∗2
中所 武司 (CHUUSHO TAKESHI) 明治大学・理工学部・教授
橋本 正明 (HASHIMOTO MASAAKI) 九州工業大学・情報工学研究科・教授
佐伯 元司 (SAEKI MOTOSHI) 東京工業大学・情報理工学（系）研究科・教授
大西 淳 (OHNISHI ATSUSHI) 立命館大学・情報理工学部・教授
中谷 多哉子 (NAKATANI TAKAKO) 筑波大学・ビジネス科学研究科・准教授∗2 肩書きは研究実施当時のものです．

海谷 治彦 (KAIYA HARUHIKO) 信州大学・工学部・准教授
白銀 純子 (SHIROGANE JUNKO) 東京女子大学・現代文化学部・講師
阿萬裕久 (AMAN HIROHISA) 愛媛大学・理工学研究科・講師