ソフトウェア・シンポジウム2018 in 札幌

要求記述のスキル不足に対する SRS 記述ガイドの有効性評価
不破 慎之介（株）デンソークリエイト

山田 ひかり（株）デンソークリエイト

蛸島 昭之（株）デンソー

fuwa_s@dcinc.co.jp

hikari@dcinc.co.jp

akiyuki_takoshima@denso.co.jp

要旨
2. 研究の背景
ソフトウェア開発の現場では人の経験や知識に頼った開発が通用しなくなりつつあり，人に依存しない開発の仕組みが求められている．ソフトウェアの開発経験が浅い担当者(以降，非熟練者と呼ぶ)であっても一定水準の品質で要求仕様書(SRS)を記述できるようにするための仕組みとして，SRS の記述ガイドに着目する．
本経験論文では，SRS の記述ガイドを参照する非熟練者と，ガイドを参照しない熟練者の SRS の品質の比較評価を行う．評価は，評価基準に基づいた定量的評価と，第三者の主観による定性的評価の両面で評価する．非熟練者の SRS の品質が熟練者のものと比べ遜色ない結果となっていることで記述ガイドの有効性を証明する．

1. はじめに筆者が以前属していた組織では SRS の目次項目を定義した SRS テンプレートが利用されていた．しかしながら，このような目次項目のみが定義されたテンプレートは，目次の名称から意図が読み取れなかったり，具体的にどのようなことを記述すれば良いのか分からないという問題があった．特に非熟練者の場合はこのような問題を独力では解決できず，結局は質疑やレビュー等により熟練者から直接追加の情報を得ることで解決を図っていた．そのため，熟練者の経験知を仕組みに取り込めているとは言えない状態であった．このような問題を踏まえ，目次項目だけでなく，目次の意図や記述すべき内容までを解説した SRS 記述ガイドが必要であるとの結論に至った．

3. 関連研究

車載ソフトウェアの開発では，開発の短期化やコスト削減を背景として，業務委託比率の増加や人員の入れ替わり周期が短期化することで，これまでのような経験に頼った開発が通用しなくなってきている．そのため，熟練者の経験知(ノウハウ)を非熟練者が活用できるような仕組み作りが大きな課題となっている．特に，上流のソフトウェア要求分析工程においては，担当者に求められる経験知が多く，後工程への影響も大きい．本論文では，ソフトウ
ェア要求分析工程において熟練者の経験知を活用する仕組みを策定し，その効果について評価した結果を述べる．
本論文は，次のような構成になっている．2章では本研究を行うに至った背景を述べる。3章では本研究に関連する研究について述べる． 4章では SRS 記述ガイドの内容についてまとめる．5章では記述ガイドの有効性を確認するための評価内容を説明し，評価の結果は6章，評価から得られた考察については7章にそれぞれ示す．最後に8章で本論文としてのまとめと今後の課題について述べる．

自動車ソフトウェア要求仕様書のインスペクション方法に関する研究[1]の中で，SRS の品質の定量的な評価方法と参照 SRS について述べられている．参照 SRS とは，SRS に含むべき要素とその構成を定めたものである．

4. 提案手法
本論文では，参照 SRS に対して，非熟練者が熟練者の経験知を活用できるような情報を加えることで SRS 記述ガイドを策定する．以降の各節では，本研究で有効性を評価した SRS 記述ガイドの詳細を述べる．
4.1. 記述ガイドの解説項目
SRS 記述ガイドは，参照 SRS の目次項目毎に次の項目を解説している．
・項目の説明・項目が必要な理由
・書くべき内容
・書くべきではない内容
・項目がない場合のリスク

119SEA

ソフトウェア・シンポジウム2018 in 札幌

4.3. 記述ガイドの例「項目の説明」では，目次項目の目的や，何を書くかを説明し，その目次項目の全体像が分かるようにする．「項目が必要な理由」では，その目次項目が SRS に記述されていることによる嬉しさを説明し，その目次項目の必要性，重要性を理解できるようにする．「書くべき内容」はその目次項目の目的を達成するために必要な記述項目を定義することで，記述の抜け漏れを防止する．「書くべきではない内容」では，非熟練者が起こしやすい誤りを説明することで，過去に発生した誤りの再発を防止する．

例として，「ソフトウェアシステムの属性」の目次項目の信頼性に関する記述ガイドを以下に示す．
表1：ソフトウェアシステムの属性（信頼性）の記述ガイド
項目の説明

信頼性という用語は，元来は，故障等により製品が使用できなくなる状況に対応して，そうした事態が軽減される程度として考えられた．ソフトウェアでは，故障の原因は機械類のように摩耗等ではなく，主として開発過程での不具合，利用環境の変化，セキュリティ上の攻撃などから生じるの4.2. 記述ガイドの目次項目で，特有の軽減策が必要となる．
なお，信頼性と類似の言葉に「ディペンダビリティ」という考本論文で使用した記述ガイドの目次項目を以下に示す．

え方がある．

1 はじめに項目が必要

車載ソフトウェアは，リリースされてから長時間稼動し続け，な理由人命に関わる制御を行う場合もある．そのため，高い信頼1.1 目的性が求められる．

1.2 適用範囲

予めソフトウェアに求める信頼性を規定し，それを満たすよ

1.3 用語・略称の定義

うに開発，テストを行うことで，運用後もソフトウェアが適切

1.4 参考文献に稼動し続ける可能性を高めることができる．

1.5 概要書くべき内容2 全体像例として以下のものが挙げられる．
・許容しなければならない（発生してもソフトウェアが適切に2.1 場所への適合の要求稼動しなければならない）障害や環境

2.1.1 システムインタフェース

・特定の悪条件下においてソフトウェアが正常に稼動しな

2.1.2 ユーザインタフェース

ければならない割合（耐ノイズ性など）

2.1.3 ハードウェアインタフェース

・テストのカバレッジ

2.1.4 ソフトウェアインタフェース
2.1.5 通信インタフェース
2.1.6 メモリ制限

書くべきでは根拠が無い（FMEA や FTA 等の分析による裏付けが無い）

ない内容

要求は次のリスクがある．
・障害に対して適切に対応できないリスク

2.1.7 操作

・実際には起こり得ない障害に対応してしまうリスク

2.1.8 場所への適合の要求
2.2 ソフトウェアの機能製品の慣習のみに基づいた要求は次のリスクがある．

2.3 ユーザ特性

・ハードウェアの高信頼化やシステム構成の変化等により，2.4 制約条件

既に必要なくなった要求となっているリスク

2.5 前提と依存関係

・ハードウェアの高機能化により，ハードウェアで対処した

2.6 要求の割り当て方が品質やコスト面が良くなっていることを見落とすリスク

3 要求の詳細

・新たに発生する恐れのある障害に対処できないリスク

3.1 外部インタフェース

項目がない

3.2 機能場合のリスク

3.3 パフォーマンス要求・通常想定される障害が発生した場合や悪条件の下で利用された場合に，ソフトウェアが正常に動作しない．
・過剰な多重化やフェールセーフ設計により，ソフトウェア

3.4 論理データベース要求の性能や保守性が損なわれる．

3.5 設計上の制約
3.6 ソフトウェアシステムの属性

上記の例から分かるように，SRS 記述ガイドの内容は，熟練者であれば知識や経験から既に理解していることがほとんどである．しかしながら，非熟練者はガイドが無ければ「ソフトウェアシステムの属性」や「信頼性」という名前

4 補足情報4.1 目次と索引
4.2 付録図1：参照 SRS の目次項目

120

SEA

ソフトウェア・シンポジウム2018 in 札幌

だけを見て内容を想像しなければならない．そのため，ソフトウェアに必要な属性を見逃したり，要求を具体化できないリスクがある．

み込みソフトウェアの熟練者 1 名が評価者となって行う．
評価者は，作成者を伏せられた状態でパスアラウンド形式のレビューを行い，品質特性毎に 0～100 点で採点する．品質特性は，第三者インスペクション方法[1]と同様の品質特性を採用する．ただし，こちらはドキュメント品質と要求品質の両方を評価する．品質特性の対応付けと，定性的な評価で使用する採点表を以下に示す．

5. 評価内容
本章では SRS 記述ガイドの有効性の評価の内容を説明する．評価は，SRS 記述ガイドを参照するグループ(実験群)と参照しないグループ(対照群)それぞれで SRS を作成し，SRS の品質を比較する方法で行う．

表2：品質特性の対応付け

5.1. 被験者の情報
熟練者と非熟練者の経験の差が SRS 記述ガイドによって小さくなっていることを確認するため，ガイド有グルー
プには開発経験年数 5 年以下の担当者 2 名，ガイド無グ
ループには開発経験年数 10 年以上の担当者 1 名を割り当てている．
5.2. 評価の入力情報

品質特性

ドキュメント品質特性

要求品質特性

正当性

責任追跡性

正当性

無曖昧性

明確性

N/A

検証可能性

N/A

検証可能性

完全性

記述網羅性

要求網羅性

無矛盾性

N/A

無矛盾性

変更容易性

変更容易性

N/A

追跡可能性

追跡可能性

N/A

達成可能性

N/A

達成可能性

表3：ドキュメント品質の採点表

SRS の入力となる上位要求は同一のものを使用する．
組み込みソフトウェアの特徴を持った小規模なソフトウェアを題材としている．また，上位要求にはソフトウェアが搭載されるデバイスの情報とシステムの運用イメージが示されているのみであり，ソフトウェアへの具体的な要求事項については一切無い状態としている．これにより，要求の網羅性や分析の深さが担当者の能力に大きく依存する(能力の差がより顕著に SRS に現れる)ようにしている．
ガイド有グループの入力となる SRS 記述ガイドは車載ソフトウェア向けに策定したものを用いる．車載ソフトウェ
アは組み込みソフトウェアの特徴を包含しているため，策定した SRS 記述ガイドをそのまま利用できる．

品質特性
責任追跡性
明確性
記述網羅性

観点

スコア

ソフトウェアの目的が記述されているか要求が一意に識別できる表現で記述されているか
SRS で記述すべき内容が全て記述されているか

変更容易性

要求の変更がしやすい文書であるか

追跡可能性

要求の根拠が記述されているか
表4：要求品質の採点表

品質特性5.3. 評価の手順

正当性
検証可能性

ガイド有グループには上位要求と SRS 記述ガイドを渡し，ガイド無グループには上位要求のみを渡す．その後，各担当者は独力で SRS を作成する．その際，費やした時間が品質に影響を与えないよう，両グループで同一の制限時間を設けている．なお，ガイド有グループには，SRS作成時間とは別に SRS 記述ガイド読解のための時間を与えている．

観点

スコア

要求が目的を達成しているか
要求に対して現実的に評価可能な手続きが存在して検証できるか

要求網羅性

ソフトウェアが持つべき要求が過不足
無く SRS に含まれているか無矛盾性

要求間で矛盾がないか

達成可能性

要求が現実的に実現可能であるか

6. 評価結果5.4. 品質の評価方法

本章では，作成した SRS を評価基準に基づいて定量的に評価した結果と，第三者の主観により定性的に評価した結果を示す．

定量的な評価では，第三者インスペクション方法[1]を用いて SRS のドキュメント品質を評価する．
定性的な評価は，いずれのグループにも属さない組

121SEA

ソフトウェア・シンポジウム2018 in 札幌

6.1. 定量的な評価結果
各グループの担当者が作成した SRS に対して第三者インスペクションを行った結果を以下に示す．

図4：正規化スコア

各図の解説をする．図2の目次項目ヒストグラムは，インスペクション対象の SRS が参照 SRS の目次項目をどれだけ網羅しているかを表したものである．参照 SRS の各目次項目のスコアが 1 以上であれば対象の目次項目がインスペクション対象の SRS に存在することを表している．
図3および図4はドキュメント品質特性の満足度合いを評価したものである．図3の非正規化スコアはインスペクション対象の SRS の目次項目を正とし，各目次の特性の満足度合いを評価する．一方，図4の正規化スコアは参照
SRS の目次項目を正として評価する．つまり正規化スコア
は，SRS が参照 SRS の目次項目全てを網羅しており，且つ全ての目次項目が品質特性を満たしていなければ満点にならない．
図3の非正規化スコアについては担当者毎にばらつきがあり，熟練者の方が高スコアとなっている．これは，SRS記述ガイドを参照するだけでは非熟練者が品質特性を満たすように SRS を記述できないことを表している．
図4の正規化スコアについては非熟練者の方が熟練者よりも高スコアとなっている．これは，非熟練者であっても SRS 記述ガイドを参照することで，SRS として必要な項目を不足無く記述できていることを表している．
図2の目次項目ヒストグラムからも図4と同様の結果を読み取ることができる．熟練者が網羅している目次項目は全体の 30%程度であるが，非熟練者は 85%程度を網羅している．

図2：目次項目ヒストグラム

6.2. 定性的な評価結果
定性的な評価結果を以下に示す．なお，定性的な評
価は各グループにつき 1 つの SRS に対し評価している．

図3：非正規化スコア

122SEA

ソフトウェア・シンポジウム2018 in 札幌が分かる．一方で，熟練者のように表現したいことに合わせて適切なビューやモデルを選定することは困難である
ことが分かる．

表5：ドキュメント品質の採点結果
スコア

品質特性

熟練者

非熟練者

責任追跡性

100

100

明確性

100

100

記述網羅性

70

70

変更容易性

80

90

追跡可能性

10070

合計

450430

7. 考察

表6：要求品質の採点結果
スコア

品質特性

熟練者

非熟練者

正当性

100

100

検証可能性

90

80

要求網羅性

7070

無矛盾性

80

80

達成可能性

70

70

合計

410400

総合的には非熟練は熟練者と遜色無いスコアとなっている．特に，品質特性の完全性に対応する記述網羅性や要求網羅性については同点となっている．このことから，
SRS 記述ガイドを参照することによって，非熟練者でも熟練者と同程度には要求を抜け漏れなく記述できるようになることが読み取れる．また，変更容易性についても，非熟練者の方が高いスコアとなっている．これは，非熟練者の SRS は要求のタイプによって章が分けられており，変更容易性が高いと判断されたためである．
また，定性的な評価を行った評価者から，良かった点として次のようなことが挙げられている．

熟練者

良かった点

SRS 記述ガイドは，非熟練者であっても SRS に必要な項目を抜け漏れなく記述できるため SRS の品質向上に非常に有効である．その際，SRS 記述ガイドを補足するための記述サンプルを併せて作成することで，SRS 記述ガイドの理解を早められる．今後は，SRS 記述サンプルと品質特性ガイドを策定し，非熟練者が作成する SRS の品質向上への効果を評価する．

今回の評価において忙しい中協力をいただいた，当社の林氏，棚瀬氏に感謝いたします．

・要求とその動機を対応付けたモチベーショ
ンビューによって，要求の根拠が非常に分かりやすくまとめられている．

参考文献

・ソフトウェアの動作が表でまとめられており，振る舞いをイメージしやすい．
非熟練者

8. まとめと今後の課題

9. 謝辞

表7：SRS の良かった点
SRS 作成者

評価結果より，非熟練者であっても，SRS 記述ガイドを参照することで SRS に必要な項目を抜け漏れなく記述できるようになっている．一方で，項目のような構造的な品質は向上しても，品質特性のような記述そのものの品質の向上には至っていない．これは，SRS 記述ガイドが各項目の必要性や「何を書くか」については解説しているが，それらを「どう書くか」については言及していないためと考えられる．従って，更なる品質向上のためには，品質特性を満たすように SRS を記述するためのガイドが必要である．このようなガイドの例としては，INCOSE の Guide forWriting Requirements[7]が挙げられる．
その他，SRS 記述ガイドを参照した非熟練者からの意見として，SRS 記述ガイドの解説文だけでは項目をどのように表現すれば良いか分からないとの声もあった．この問題については，実際にその目次項目を記述したサンプルのようなものが有効であると考えられる．

[1] 蛸島昭之，青山幹雄，自動車ソフトウェア要求仕様書の第三者インスペクション方法の提案と適用評価,
情 報 処 理 学会論文誌 ，Vol.58 No.4 1–15 (Apr.
2017)[2] IEEE, Std. 830-1998: IEEE Recommended Practicefor Software Requirements Specifications, IEEE
Computer Society (1998).
[3] ISO/IEC/IEEE 29148:2011, Systems and software

・要求の優先度に関する記述がある．
・性能要求がある．
・実装方針に関する制約や要求がある．

上記の評価からも，SRS 記述ガイドを参照することで，SRS として重要な項目を記述できるようになっていること

123

SEA

ソフトウェア・シンポジウム2018 in 札幌

[4]
[5]
[6]

[7]

engineering —Life cycle processes — Requirements
engineering(2011)
Wiegers, K. and Beatty, J.: Software Requirements,
3rd ed., Microsoft Press (2013).
JISA, 要求工学知識体系(REBOK) 第１版(2011)
NASA: NASA-STD-2100-91, NASA Software
Documentation Standard, NASA Headquarters
Software Engineering Program (1991).
INCOSE, Guide for Writing Requirements 2.1(2017)

付録
A.1. 記述ガイドの作成方法
本節では，記述ガイドのより具体的な作成方法について説明する．
最初に，あるドメインにとって標準的な SRS の目次項目を定義する．本論文で解説している記述ガイドの目次項目は[1]の参照 SRS を元に作成している．参照 SRS に対し，IEEE Std.830[2]の後継規格である ISO/IEC/IEEE
29148[3]への準拠や，車載ソフトウェアに必要な目次項目を追加した上で構成の再編を行っている．車載ソフトウ
ェア以外の分野の場合は，これを該当分野の特徴に合わせた目次項目とする必要がある．
次に，各目次項目に対して本論文4.1に示した項目を記述する．これらを記述する際は外部の文献などを参照しながら記述することで，SRS 記述ガイド作成者の知識や経験のみに偏らないガイドとすることができる．本論文では，国際規格である ISO/IEC/IEEE 29148[3]をはじめ，複数の参考文献[4][5][6]を参照し，必要に応じて車載ソフトウェア向けに具体化したり表現の変更を行って記述している．それでも不足している部分については，熟練者の経験知により補完を行っている．
SRS 記述ガイドを作成する際の留意点として，SRS 記述ガイドを参照する組織の想定を予め決めておくことが挙げられる．理由は，組織によって解説の粒度を変える必要があるためである．例えば，性能に関する品質要求を記述する目次項目についての「書くべき内容」は，車載ソフトウェア横断の粒度では，「データ容量」や「ECU の起動時間」などの粒度で記述すべきであり，特定ドメインの粒度では具体的なデータ名称やタイミングを記述すべきである．具体化し過ぎた場合は無駄な項目ができてしまったり，逆に抽象化し過ぎた場合は非熟練者が記述内容をイメージできなかったりするため，適切な粒度での記述が必要である．

124

SEA