最新エントリー

 山本 修一郎

これまで，要求仕様書の書き方について説明してきました．本稿では，ユーザーストーリーを紹介して，要求仕様との関係を説明します．

■ユーザーストーリー

ユーザー視点で，顧客価値と対応付けて機能要求を定義する手法がユーザーストーリーです．ユーザーストーリーの英語構文は，次の通りです．

As a <User>, I want <Function> so that <Value>.

ここで，ユーザー<User>，機能<Function>，価値<Value>が変化する部分です．ユーザー，機能，価値は，Who，What，Whyに対応しています

ユーザーストーリーでは，この構文に従って，ユーザーが求める機能と価値を抽出することができます．日本語でユーザーストーリーを書くと，語順が変わりますが，次のようになります．

• カード会員として，商品を購入するために，カード決済したい．
• カード会員として，乗車するために，スマホでカードを利用したい．

■ユーザーストーリーの作成法^[1]

表1のようにして，ユーザーストーリーを作成できます．まずユーザー像を特定します．次いで，ユーザーが解決したい問題，すなわち機能を使う目的を明確にします．最後に，目的を実現する機能を抽出します．この各手順では，ユーザー像，目的，機能を識別するために役立つ質問を示しています．また，手順で作成するユーザー像，目的，機能を例示しています．

■ユーザーストーリーマッピング

　ユーザーストーリーを単文で記述することになるので，たくさんのユーザーストーリーができます．そこでユーザーストーリーをまとめる方法が必要になります．ユーザーストーリーマッピングは，小ストーリーを集めた中ストーリーからさらにそれをまとめた大ストーリーへと段階的にユーザーストーリーを構造化する手法です（図１）．中ストーリーで物語（ストーリー）のまとまりを作ります．中ストーリーをまとめることで，大きな物語の流れを説明できます．

図1 ユーザーストーリーマッピングの構造

■ユーザーストーリーの例

図書館の受付係が使う図書貸出管理システムを例として，ユーザーストーリーを記述してみます．図書貸出管理システムの以下の機能に対するユーザーストーリーは表2の通りです．

• 会員情報を確認する
• 会員の図書貸出状況を確認する
• 図書の貸出を登録する

表2 図書貸出管理システムのユーザーストーリー

このように，ユーザーストーリーによって，機能要求に対するユーザーとその目的を明確にできることが分かります．

■ユースケースとユーザーストーリー

ユースケースの記述では，システム機能を記述します．しかし，ユーザーによるシステム機能の操作を記述しないので，ユーザー操作とシステム機能との整合性を確認する必要があります．そこで，図2に示すように，ユーザー操作とシステム機能との対応表を用いて，イベント条件と機能を明確化することができます．図2では，ユーザー操作①に対してシステム機能②が実行され，次いでユーザー操作③が発生してシステム機能④が実行されることを示しています． 

図2　ユーザーストーリーとユースケースの関係

■例

ビデオ貸出システムに対するユーザー操作とシステム機能の関係を表3に示します．ユーザー操作では，ユーザーストーリーの記述から，ユーザーと目的を省略して，機能を使う操作を記述しています．

表3 ユーザー操作とシステム機能要求

■USDMとユーザーストーリー

表3の記述を見ると，USDM(Universal Specification Description Manner)と似ていることに気づかれた方もいると思います．USDMでも表形式で機能要求を記述します．USDMと表3の違いは，ユーザー操作をシステム機能と分離するとともに，関係を明確にしている点です．そういう意味で，USDMにユーザー操作を対応付けていることになります．また，ユーザーストーリーに基づいてUSDMを作成する方法を表3が示していることになります． 

参考文献

[1]asana, 優れたユーザーストーリーの書き方, https://asana.com/ja/resources/user-stories

  山本 修一郎

本ブログ第4回では，国際標準に基づく要求文のテンプレートの例を紹介した．

今回は，MazoとJaramillo[1]が，新たに提案しているシステム要求仕様の構文を紹介する．彼らは構成要素を8種類に分類している（表1）

これらの構成要素からなる要求仕様文に対する要求構文は次のようになる．

ここで，日本語の動詞にはサ変活用があるので，義務の部分を日本語にするのは難しい．日本語では，＜義務＞部分に，「必ず，絶対，できれば」などを使うことになる．それよりは，義務部分を表す，必須◎，望ましい〇，省略可△などの識別子を要求文の属性とすることにより，要求の優先順位を区別する方が明確になると思われる． 

以下では，この分類に従って要求仕様テンプレートの記述例を説明する．

条件

例：加熱スイッチが押下されたら

システム

例：電気ポット制御システムが

活動

例：加熱信号を送信する

対象

例：ヒータに

評価条件

例：直ちに

評価条件によって，活動に対する性能や信頼性についての非機能要求を記述できる．

活動条件

例：沸騰していない限り

対象条件

例：水タンクが空でない限り

■要求テンプレートによる記述例

上述した要素例をまとめて，要求文を記述すると，次の通りである．

 ただし，この例では，日本語として読みやすいように，要求構文の表現を改めている．このため，日本語の場合，語尾変化を考えて，要求構文を節の集まりで表現した方がいいと思われる．

【システム要求構文】

参考文献

[1]Raul Mazo, Carlos Andrés Jaramillo, Paola Vallejo, Jhon Medina. Towards a new template for the specification of requirements in semi-structured natural language. Journal of Software Engineering, Research and Development, Brazilian Computer Society, 2020, 8, pp.3. 10.5753/jserd.2020.473. hal-02502411

[2] Davies, Rachel. Format for expressing user stories. 2001.

[3] Wiegers, Karl, and Joy Beatty. Software Requirements Third Edition. Microsoft Press, 2013.

[4] Mavin, A., P. Wilkinson, A. Harwood, and M. Novak. "Easy Approach to Requirements Syntax (EARS)." International Requirements Engineering Conference RE, 2009: 317-322.

[5] ISO/IEC/IEEE. "29148 Systems and software engineering (Life cycle processes — Requirements engineering)." 2011.

 山本 修一郎

機能要求の書き方について，本ブログ第4回で要求テンプレートを紹介した．情報システムの信頼性を向上する上で，非機能要求を明確に定義することが重要である[1]．本稿では，非機能要求の書き方について紹介したい．

ロバートソン ら[2]は，非機能要求(NFR, Non Functional Requirements)を8種類に分類している（表1）．以下では，この分類に従って非機能要求の記述例を説明する．

1. 外見要求

2. 使用要求

 山本 修一郎

開発文書品質の一つに「理解性」がある．開発文書を理解することは，開発文書に含まれる用語の関係を理解することだと考えられる．そこで，用語の関係を図で表現できることに気づく．このような図にSystemigram(システミグラム)がある[1][2]．

Boardmanは，自然言語による文章表現と対応しやすい図として，Systemigramを考案した．Systemigramでは，名詞(句)と名詞(句)間の関係を次のような記述として定義する．

• 名詞(句)：ノード（点）
• 名詞(句) 間の関係を示す動詞(句)：ノード間の関係（線）

つまり，「名詞を表す点」と「動詞を表す線」の関係を使って，文章を図で理解できる．

例えば、下記の例文をSystemigramで表現してみよう．経済産業省が企業のDXに関する自主的取組を促す経営者に求められる対応をデジタルガバナンス・コードとして提示している[3]．この「デジタルガバナンス・コード」のビジョン・ビジネスモデルの柱となる考え方を説明している次の文を用いる．

 

山本 修一郎

　要求を明確に表現するには，要求仕様書などの文書の単位や，それぞれの要求を記述する文章の単位で，明確であることが求められます．その文書や文章を明確にするには，それらを構成する基本単位である個々の文の単位で曖昧性を排除することも必要です．今回は，要求記述の基本単位となる個々の要求文を明確にする方法を考えます．

　要求文を与えられて，「この要求を確認してください」と言われたら，みなさんはどうしますか？要求文の簡単な確認方法として，文を構成する部分ごとに確認する方法を紹介します．

■部分要素に分解する

• セキュリティ監視システム
• 通常の間隔では
• 少なくとも60秒おきに
• デバイスの状態
• 通知しなければならない

■部分要素を確認する

■組込み仕様への適用例

  

■まとめ

 このようにして，要求文を部分要素に分解して要求確認表を作ることによって，明確になっていない点をあぶりだすことができます．これは，要求を確認する側だけでなく，要求を書く側にとっても活用できる方法です．書く側では，要求文を記述する際に，要求確認表で予め整理することによって，曖昧な要求記述を回避することもできます．

 山本 修一郎

ソフトウェア開発における知識の流通形態として，文書化と対話を考えることができる．文書化を徹底すれば対話量を削減できる．逆に，文書量を削減すれば，必要な知識を獲得するために，多くの対話が必要になる．

アジャイル型開発では，文書化量は削減する代わりに，濃密な対話によって開発に必要な知識を補完することになる．

たとえば，アジャイル型開発では，「①プロセスとツール，②理解しやすい文書，③契約交渉，④計画順守」よりも，「⑤個人と対話，⑥動くソフトウェア，⑦顧客連携，⑧変化対応を優先すること」に価値をおいている[1]．これによって，ソフトウェア開発のさまざまな無駄を省くことを目的としている．無駄な文書やコードを作らないことと，逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がアジャイル型開発にはある．

これに対して，ウォータフォール型開発では，工程を明確に定めて工程生産物としての開発文書を作成する．曖昧さや抜け漏れのない開発文書を作成することにより，手戻りのない開発を目的としている．

以上の議論から，文書化量を横軸，対話量を縦軸として，アジャイル型とウォータフォール型の開発をプロットすると，図1のようになる．

図1 文書化と対話からみたアジャイル型とウォータフォール型の開発

アジャイル型開発を進めるためには，対話能力が開発者に要求される．しかし，現場の開発者は十分な対話能力を持っていないことも多い．そこで考えられるのが，対話能力不足を文書で補うことである．実際，ある研究会で筆者がこの図を紹介した際に，アジャイル開発の現場でウォータフォール型の手法が見直されているという話を聞いた．図1でいえば，曲線の中間に位置づけられるような開発手法が現場で求められているということであろう．

そのような中間的な手法として，エレン・ゴッテスディーナーとメアリー・ゴーマンによる発見から納品へ（Discovery to Delivery, D2D）がある．

D2Dでは，文書に基づいて対話を構造化する「構造化会話(Structured Conversation)」を提案している．D2D型開発を図1に付加すると，図2のようになる

図2 文書化と対話からみたD2D型の開発

D2Dでは，対話を構造化できるように適応した文書を提案している．すなわち，表1に示すように，D2Dでは，開発プロダクトの７側面に対して，対話で活用すべき文書を提示している．

 ここで，プランゲージ(Planguage)[3]は品質特性を可視化するためにGilbが提案したテンプレート形式の表記法である．Baasらが提案した品質特性シナリオ[4]は，①発生源，②刺激，③環境，④シナリオ，⑤システム，⑥成果物，⑦応答，⑧評価基準を記述することによって，品質特性を明らかにできる．

参考文献

[1] アジャイルソフトウェア開発宣言, http://agilemanifesto.org/iso/ja/manifesto.html

[2] Ellen Gottesdiener, Mary Gorman, Discover To Deliver: agile product planning and analysis, EBG Consulting, Inc., 2012.
    (エレン・ゴッテスディーナー，メアリー・ゴーマン，発見から納品へ- アジャイルなプロダクトの計画策定と分析，株式会社オージス総研訳，ブックウェイ，2014.)

[3] Gilb, Thomas, Competitive Engineering: A Handbool for Systems Engineering, Requirements Engineering and Software Engineering Using Planguage, Butterworth-Heinemann, 2005.

[4] Baas, Len, Paul Clements, and Rick Kazman, Software Architecture in Practice, second edition, Addison-Wesley, 2003.
   （前田他訳，実践ソフトウェアアーキテクチャ, 日刊工業新聞社，2005.)

      山本 修一郎

ASDoQでは現在，システム開発文書品質とは何か、その品質特性にはどのようなものがあるかを定義する活動を進めています．

本稿では，システム開発文書の中でも，文書としてとくに大きな役割を担う要求文書の品質に関して，これまで研究されているものを紹介します．

前稿でも紹介した国際要求工学委員会（IREB）[1]は，要求文書に関連する教育単位（EU：Education Unit）を定めています．

その中の「要求の文書化(EU4）」には，教育目標として「要求文書の品質基準(EU4.5)」(要求文書の品質を活用できる）が設定されています．今回は，IREBが定義する「要求文書の品質基準」とはどのようなものかを，解説します．

 IREBは，要求文書が満たすべき品質基準として，IEEE std.830-1998 [3] が推奨する次の4項目を参照しています[1][2]．

• 明確性と一貫性
• 修正容易性と拡張可能性
• 完全性
• 追跡性

さらに，要求文書は後続する開発工程の基礎となるので,要求文書が明確な構造をもつ必要があるとしています[4].

 以下に，それぞれの項目を説明します．

■  明確性と一貫性

要求文書が明確で一貫しているためには，個別の要求が明確で一貫していることが必要です．また，個別の要求が互いに矛盾していないことが必要です．

そのために，要求文書と要求に一意な識別子を付与しておきます．これによって，要求文書と要求との間を矛盾なく明確化できます．

ここで，「明確性」と「一貫性」とは，それぞれ次のように定義します．

【明確性】 要求が異なる複数の意味に解釈されないとき，この要求は明確である．

【一貫性】 異なる要求が互いに矛盾しないとき，これらの要求は一貫している．

■  修正容易性と拡張可能性

プロジェクトの進行に従って，要求の変更・追加・削除が発生するので，要求文書が容易に拡張できるようになっている必要があります．したがって、要求文書の構造は修正、拡張が容易である必要があります．

■  完全性

要求文書が完全であるためには，次のことが必要です．

•  適切な要求をすべて含んでおり，それらの要求が完全に文書化されていること
• システムの機能について，すべての可能な入力や環境要因に基づいて必要な応答を記述すること
• これらの記述には，入力や環境要因の逸脱に対する例外処理も含むこと
• 応答時間や可用性，操作性などの品質要求についても記述すること

また，要求文書の様式面での完全性としては，次のことが必要です．

•  図表および参考文献が番号付けられ，本文で適切に参照されていること
• 重要な用語の定義が要求文書で記述されていること

■  追跡性

要求文書と、業務プロセスやテスト計画・設計書などの他の文書との関係に基づく追跡性があることは，要求文書の重要な品質基準です．

■  明確な構造

明確な構造を持つ要求文書では，必要な部分を選択して読むことができます．そのため可読性を向上できます．明確な構造の要求文書を作成するためには，たとえば，IEEE std.830-1998が推奨するソフトウェア要求仕様の標準的な構成例などが利用できます．

  山本 修一郎

開発文書の作成のために，文書のテンプレートを用意している組織や開発チームもあるかと思います．ルールや形式を決めて，それに当てはまるように記述することは，読み手の解釈の範囲を限定しますから，複数の解釈を避けることにつながります．

本稿では，２つの国際標準機関が取り決めている要求文のテンプレートの例を紹介します．

■IREBが規定する要求文書化の項目

国際要求工学委員会（International Requirements Engineering Board, IREB）[1]が要求工学専門家を認定するための基礎レベルのシラバスを提供しています．このシラバスでは，要求文書に関連する教育単位（EU）として，次の項目を定義しています．

• 要求文書化(EU4)
• 自然言語による要求文書化(EU5)
• モデルに基づく要求文書化(EU6)

とくに，「自然言語による要求文書化(EU5)」の基礎レベルのシラバスで述べられている要求テンプレートを解説します．

■要求の義務の強さを示すための要求テンプレート

要求の定式化における言語効果を削減するために，容易に学習でき適用できる方法が要求テンプレートです．高品質な要求を作成する上で，要求テンプレートが要求執筆者を効果的に支援します．IREBは，要求テンプレートによって要求を5段階に定式化しています．

• 法的な義務を決定する
• 要求の中核を決定する
• システムの活動を特徴づける
• オブジェクトを挿入する
• 論理条件と時制条件を決定する

そして，要求文では，「shall」「should」「will」を用いて、義務を定義できます．義務が変化した場合，要求も変化します．

義務の強さは，shall  >  should  >  will   の順です．

shall :     　 （絶対義務）　 絶対に満たすべき要求であることを表す

should :  　 （義務）　　    絶対ではないが，高い確率で満たすべき要求であることを表す

will:　　　　（可能義務）　 できれば，満たすべき要求であることを表す

日本語で，shallとshouldの区別は難しいと言えます．しかし，日本語でも，要求の義務の強さによって，「shall」「should」「will」に対応して，次のように書き分けることを意識してみてはいかがでしょうか．

（絶対義務）     システムは，　処理を　絶対に行う必要がある

（義務）           システムは，　処理を　行う必要がある

（可能義務）     システムは，　処理を　可能であれば行う

 また，日本語では，英語のように使用する用語の違いで意味を書き分けることが，難しい場合もあります．副詞の有無や文末だけの記述の違いで，要求の違いを明確に示すには限界もあるかもしれません．そういったときに，属性を付与することも1つの方法と言えます．たとえば，上記の [絶対義務], [義務], [可能義務] などを属性として，各要求に付与することを決めれば，要求文に補助情報を付けて，より明確化することになります．属性の例としては，他に，[必須要求]（なくてはならないの意）, [可能要求]（あったほうがよいの意）, [期待要求]（なくてもよいの意）なども挙げられます．

こういった属性の記述は，自由度の高い自然言語の表現にある制約を付けて，意味を限定しようとするものであり，要求表現テンプレートの記述項目と言えます．

このように要求のテンプレートを決めることは，その使用を強制するわけではありません．テンプレートに合せて記述する訓練の機会を得ることによって，要求テンプレートを補助的なツールとして活用できるのではないでしょうか．

■文の構成要素を規定する要求構文

ISO/IEC/IEEE 29148:2011内「5.2.4 Requirements construct」では，下記のように３種類の要求構文の型を例示しています．この要求構文も要求テンプレートの例です．なお，日本語構文に合わせるために，助詞を補うとともに，語順を入れ替えています．

(構文の型１)　[条件] [主体] が[対象]を[制約] [活動]する必要がある．

例：信号x を受信したとき，　   [条件]

　　システムが，　　　　　　　[主体]

　　信号 xの受信ビットを 　　  [対象]

　　2秒以内で　　　　　　　　 [制約]

　　設定する　　　　　　  　　 [活動]

　　必要がある

(構文の型２)　[条件] [活動 または 制約] は[値]である必要がある．

例：海の状態が 1のとき                                      [条件]

　　レーダーシステムが目標を検知すべき範囲は，  [活動または制約]

　　100 nautical マイルである                            [値]

    .必要がある．

(構文の型３)　[主体]が [値条件]で[活動] する必要がある．

例：請求書システム が　                 [主体]

　　昇順で，                         [値条件]

　　支払いが保留中の顧客請求書を表示する　 [活動]

　　必要がある.

■要求テンプレートを使った要求文の例

たとえば，IREBによる義務の強さと，ISO/IEC/IEEE 29148:2011による要求構文を適用して，要求文を書いてみます．

（絶対義務） 

例：[主体] 交差点の信号機システムは，

　　[値条件]  一方の信号機を赤に切り替えてから，

　　[活動]        他方を青に切り替えることが，

　　　　　　　 絶対に必要である

（義務） 

例：[主体] 交差点の信号機システムは，

　　[値条件] 一定時間，

　　[活動]  両方の信号機を赤にすることが，

                      必要である

（可能義務） 

例：[条件]   両方の信号機が赤である時の一定時間は，

　  　[値]     3秒間とする

 （注）上記は、信号機システムの要求の一部のみを例示しています．要求として完全な記述ではありません．

このように，要求テンプレートを利用して，自然言語の記述の中で定型化できる箇所を整理し記述することは，読み手に対して要求を明確に伝える助けとなります．それ以上に，要求執筆者にとって，要求を整理し定義する際の１つの手立てとなります．

 山本 修一郎

開発文書の品質を確認するためには，開発文書を読むための方法が必要です．普通の小説であれば，自由に楽しみながら読めばいいのですから，特別な方法に従う必要はありません．しかし，開発文書の場合には，ただ読むだけでは品質が高いのかどうかわからないものです．本稿では，開発文書を読むための方法を紹介します．

■文書から引き出された事実を読む

文書には，何かしらの事柄と，その事柄に基づく一連の出来事が書かれています．開発文書に書かれている内容は，開発の目的と，その目的を達成するためにこれからシステムとして実現すべき事柄です．とすると，開発文書を読むということは，開発の目的がどんなことであるかということと，システムを使う一連の操作によって，その目的が確かに達成できるということの2つを理解することでもあります．

もし，開発文書を読んで，システムが開発の目的を達成できると確認できれば，開発文書の信頼性は高いといえるでしょう．これに対し，開発文書を読んで開発の目的を達成できないことが確認できたとしたら，開発文書の信頼性は高いとはいえないでしょう．

システムが開発の目的を達成できるのかできないのかを読み取るためには，開発文書から引き出された「事実」に基づいて，それらから生じる可能性のある一連の出来事によって目的が達成できるかどうかを客観的に明らかにしていくような開発文書の読み方が必要になります．この過程では，期待や憶測を排除することが大切です．そうしないと，文書に記載されていない事柄に基づいて判断してしまうことになるからです．
文書に記述された事実に基づいて「システムを操作すると，どのようなことが生じるのか」を確認する方法を，「事実に基づく読解法」と呼ぶことにします．この方法はあえて名前を付けるほどでもないくらい単純なものなので，ソフトウェア工学の教科書にも出てきません．このコラムで初めて使った名称です．

■具体例

それでは，このコラムでいつもお世話になっているNPO法人 組込みソフトウェア管理者・技術者育成研究会（SESSAME）の要求仕様書「話題沸騰ポット」[1]の要求文を，事実に基づいて読解してみましょう．

読解に使う要求文を表1にまとめました．

表1　話題沸騰ポットの要求文の一部
 

この要求文[pot-220]を読むと，このポットが沸騰行為を行うためには，蓋を閉じた際に水位が条件に合う（水量が異常でない）という事実が必要だと分かります．また，[pot-280-11]を読むと，満水センサがonだと水量異常と判断されるという事実が分かります．さらに[pot-110-12]を読むと，満水センサのデフォルトがonだと分かります．

さらに，満水センサがoffになる契機を探すと，どこを読んでも出てきません．したがって，常に満水センサはonである（水量異常である）という事実が判明します．
これを整理すると，以下の一連の事実が明らかになります．

（事実1）満水センサのデフォルトはonである[pot-110-12]
（事実2）蓋センサがonになって3sec経過した時点で，満水センサはonを検出する．すなわち，このポットの許容上限を超えている（水量異常）と判断される[pot-280-11]
（事実3）蓋が閉じられても，水量が異常な場合，状態はアイドルのままである[pot-220-31]
（事実4）一つでも条件を満たしていなければ給湯できない[pot-260-11]
 

これらの事実から，以下の2つの結論を導くことができます．

（結論1）話題沸騰ポットはいつまでたっても沸騰しないポットである
（結論2）話題沸騰ポットは給湯ボタンを押しても給湯できない
 

表1に示したのは話題沸騰ポットの要求文の一部にすぎませんが，満水センサがoffになることについては，話題沸騰ポットの要求文のどこにも記載がありませんでした．したがって，満水センサは永久にonであることが，話題沸騰ポットの要求文から導かれる事実なのです．

ここで示した話題沸騰ポットの要求仕様書（第7版）は，「できる限り曖昧さを無くした仕様書の例として作成された」とのことです．この例から分かるように，開発文書の曖昧さをなくしたとしても，開発文書に欠陥がないわけではありません．曖昧さが無くても，入れた水を沸騰できず，給湯もできないポットになっています．話題沸騰ポットを開発する目的が，水を沸騰できるポットを実現することだとすると，この仕様書には明らかに欠陥があります．

ここまで，「事実に基づく読解法」によって開発文書を読む方法について解説してきました．ここでは要求文について議論しましたが，事実に基づく読解法は，さまざまな開発文書に適用できます．なお，要求文書をレビュする方法は，ここに紹介したやり方以外にもたくさんの方法があります．これらのレビュ手法についてもっと知りたい方は，要求工学連載の第37回[2]をご覧ください．

参考文献
[1] 組込みシステム教育教材 話題沸騰ポット GOMA-1015型 要求仕様書，http://www.sessame.jp/workinggroup/Wo ... up2/POT_Specification.htm
[2] 山本修一郎, 要求工学連載第37回，要求レビュ，http://www.bcm.co.jp/site/youkyu/youkyu37.html

山本 修一郎

開発文書の複雑さを計測するにはどうしたらよいでしょうか？ 本稿では，開発文書の複雑さを，名詞句の個数に基づいて計測する方法[1]を紹介します．

■文書の複雑さの測定方法

文書を計測すると聞いてまず思いつくのは，ページ数や文字数を計測する方法です．また，文に含まれる単語を計測することもできます．単語には，接続詞や助詞などといった繰り返し出現する語も含まれます．助詞や接続詞は単独では意味を持たないので，これらを省いて名詞や名詞句，動詞だけを計測することもできます．名詞句（「寒い日」など）は，名詞（「日」）が指示する対象の属性や状態（「寒い」）を指定することができます．

基本的に，一つの文には一つの動詞が対応しているので，文の個数が動詞の個数に一致します（名詞句の中に出現する動詞は除く）．同じ個数の文を含む複数の文書を比較した場合，動詞の個数は一致しますが，名詞句（名詞を含む）の個数は異なる場合があります．したがって，動詞の個数を計測するよりも名詞句を計測するほうが，文書の複雑さを計測するのに適していると考えられています．

■名詞句の例

例として，前回も参照したNPO法人 組込みソフトウェア管理者・技術者育成研究会（SESSAME）の「話題沸騰ポット 要求仕様書」[2]第7版の要求文に含まれる名詞句を調べてみましょう．

この例文には，「設定されたモードの温度」と「ポット内の水温」という二つの名詞句があります．

■名詞句複雑度を定義する

N個の文からなる文書に，M個の名詞句が含まれているとします．同じ名詞句が文書の中で繰り返し出てくることがあります．そこで，すべての名詞句が文書の中で1回しか出てこない場合に対して，同じ名詞句が複数回出てくる場合の方が，文書の複雑さが小さいと考えると，次のように「文の名詞句複雑度」を定義できます．

[定義] 文の名詞句複雑度 NPC (Noun Phrase Complexity)
j番目の文に含まれる名詞句が，文書内で出現する回数の逆数の総和を，j番目の文に対する名詞句複雑度と呼ぶ．

わかりやすいように，具体例を挙げてみます．なお，こちらも話題要求ポット 要求仕様書の注意書きに一部手を入れて引用しました．

この文書は五つの文で構成されています．1番目の文には「要求仕様書」，「版数」，「想定している用途」という名詞句が含まれています．「要求仕様書」が文書内で出現する回数は2回なので，その逆数は1/2です．「版数」と「想定している用途」はそれぞれ文書内で1回ずつしか出現しないので，逆数もそれぞれ1です．つまり，1番目の文の名詞句複雑度は，2.5となります．ここでもし，2番目の文に含まれる「仕様書」を「要求仕様書」に変更すると，1番目の文の名詞句複雑度は2.3になります．

ここで，文についての複雑度の定義を基に，文書についての複雑度を示す指標として「文書の名詞句複雑度」を定義できます．

[定義] 文書の名詞句複雑度
文書に含まれる，文ごとの名詞句複雑度の総和を，文書の名詞句複雑度と呼ぶ．

例えば，N個の文からなる文書に名詞句が1個しかない場合（同じ名詞句を繰り返しており，動詞だけが異なる場合など），この文書の名詞句複雑度は1になります．一方，N個の文からなる文書にM個の名詞句があり，名詞句がそれぞれ1回ずつしか出現しない場合，この文書の名詞句複雑度はMになります．
したがって，文書の名詞句複雑度は，名詞句が文書内でどれだけ繰り返し出現するかによって減少するような尺度であるということができます．

■要求文の複雑度を計測する

それでは，話題沸騰ポット 要求仕様書 第7版に含まれる要求文を見ながら，この文書の複雑度を計測してみましょう．以下が，要求文の一覧となります．

話題沸騰ポットの要求文の個数は18個です．この要求文には41個の名詞句があります．この中に，1回しか出現しない名詞句が35個，2回出現する名詞句が4個，3回出現する名詞句が2個ありました（図1の青い実線を参照）．したがって名詞句の出現回数は49です．

ちなみに，2回出現する名詞句は，「蓋」「タイマボタン」「カルキ抜き」「保温行為」．3回出現する名詞句は「沸騰行為」と「タイマ」です．なお，名詞も修飾語のない名詞句として数えています．

図1　話題沸騰ポットの名詞句数と出現回数

上述した方法で，話題沸騰ポットの要求文18個に対する文書の名詞句複雑度を計算すると約41となり，名詞句の個数である41に近い結果になりました．したがって，名詞句複雑度から見ると，かなり複雑だということになります．

話題沸騰ポットの要求文に含まれる名詞句には類似するものもあるので，表現を見直すことにより，名詞句ごとの出現頻度を向上できる可能性があります．たとえば，繰り返し出現する名詞句を増やすことができれば（図1の赤い点線を参照），この要求文書に対する文書の名詞句複雑度を減らすことができます．

参考文献
[1] Chao Y. Din, Requirements Content Goodness and Complexity Measurement Based On NP Chunks, VDM Verlag Dr.Muller, 2008
[2] 組込みシステム教育教材 話題沸騰ポット GOMA-1015型 要求仕様書，http://www.sessame.jp/workinggroup/Wo ... up2/POT_Specification.htm