■
雑誌「Software People vol.4」(技術評論社)に、要求の仕様化入門という記事が掲載されていたので紹介します。
１．オススメする背景
最近、要求定義に絡んでいて、顧客、開発者の双方が理解できる要求仕様書（＝ご承認仕様書）の作成の難しさ感じます。
顧客、開発者が理解しやすい要求仕様書を作成できないため、
- 要求仕様書の承認に時間がかかる。
- 考えの行き違いがあり、仕様変更が発生する。
などの問題が発生しています。
この記事は、要求仕様書の構成を、
- 要求を明確にする
- 要求と仕様の結びつけが分かりやすくする
とすることで、顧客、開発者の双方が理解しやすい文書にすることを試みています。
＜得られるかもしれない結果＞
- 要求定義の時間の短縮
- 仕様変更数の削減
- 見積精度の向上（仕様が明確になるためブレが少なくなる）
- 要求定義書の再利用
＜懐疑点／問題点＞
- 著者が組み込み系に強い人っぽいので、業務アプリケーションでどこまで通用するか？
- 文章が散文で読みにくい。
２．記事の構成
第１章 要求仕様の現実………………………………問題点が記述されている。流し読み！！
第２章 要件開発とRequirement Engineering ……興味なければ読み飛ばし！！
第３章 要求仕様書を書く技術(1) …………………メインの部分。熟読！！
第４章 要求仕様書を書く技術(2) …………………第３章の補足。大事な部分だけ読む！！
第５章 派生開発時の実践テクニック………………この記事を書籍化した「要求を仕様化する技術・表現する技術」の方が詳しくかいてあってよい。
第６章 データを利用した効果検証術………………管理職のオジサマ方必読。
３．第１章 要求仕様の現実
「要求の変更が終盤に多発して、それがスケジュールの遅れにつながって、バグの温床にもなっている」
「要件管理プロセスを導入して、要求仕様の問題を改善したい」
「プロセスを改善して品質を上げたい」
上のようなソフトウェア開発の混乱をなくすには、
- 要求の仕様化
- プロセスの明確化
…
特に、要求の仕様化の効果は大きく、プロセスの明確化の方は、仕様化の効果を倍加する方向で左右します
とのこと。
その、要求の仕様化とは何をすれば良いかというと、
要求の仕様化するには、「決めていく」ことが必要です。
要求を仕様化する方法は、とにかく決めていくことです。
とにかく、決めていく事が重要。
つまり、できる限りあいまいさを残さない事により、顧客との合意が明確になり仕様変更が減ります。
４．第２章 要件開発とRequirement Engineering
特になし！！
５．第３章 要求仕様書を書く技術(1)
要求仕様書とは？
■なぜ「要求仕様書」というのか？
…
機能仕様書は、「提供する機能の詳しいこと（＝仕様）が書かれた文書」
…
要求仕様書とは、「作ってほしいこと（＝仕様）が書かれた文書」
つまり要求仕様書とは、何を作ってほしいかが書かれた文書。
要求仕様書は、どのような構成にする？
「要求仕様書」となるには、以下の３つの要素を含む必要があります。
①機能要求
②品質要求
③制約（作業上の要求）*1
注1）開発ツールや使用する手法、使用する言語、作業場のルール、遵守すべき標準、組織体制、納期や途中のイベントに対する対応などが、作業上の要求として含まれます。
…
要求仕様書とは、個々の機能などの「要求」とそれを満たすための「仕様」で構成される。
「要求」「理由」「仕様」の関係が重要。
■「要求」の役割
要求には非常に重要な役割があります。それは、仕様を”導出”する役目です。
■要求には「理由」がある。
要求の表現を矯正する方法として、「理由」や「背景」を考える方法があります。
…
要求に対して適切な理由が見つからない場合は、要求の表現が曖昧か、あるいは要求自体が不純な場合が多く、放置すると仕様の抽出に支障をきたします。
「要求」を補足する「理由」によって、要求の解釈の誤りを防ぐ。
■仕様とは
…
仕様とは、要求を満たすべき”具体的な記述”です。
…
仕様であるといことは、関係者（たとえば、要求を発する側、要求を実現する側、実現したを検証する側など）の間で、「具体的である」という意味で合意できたものです。
そして、具体的であることによって、「検証可能」、すなわちそれが実現していることを検証するための方法が考えられるのです。
■"Specify"の意味
「”仕様であるためには、どこまで細かく書けばよいか」というのが、いつも議論になります。
…
ここで重要なことは、「どこまで細かく表現すればよいか」という事ではなく、「関係者が”Specifyできる”（特定できる）ものであるかどうか」ということです。
仕様漏れを防ぐためテクニック
■要求を階層化する
要求を一つの「集合」としてとらえたときに、その集合の範囲が大きすぎては仕様が発散してしまうので、要求の範囲を小さくします…
…
実際の仕様の抽出は階層化された要求の中で進められますので、仕様の発散を防ぐことができます。
経験的に、階層としては、２階層程度でよいと思います。それ以上階層が深くなると、逆に煩雑になってしまい、階層化のメリットが薄れてしまうからです。
■さらにグループで括る
要求を階層化したとしても、要求によっては、その中に含まれる仕様の数が多くなることがあります。
…
そのような場合、…、仕様として触れられていることの対象の違いなどからグループに分けて、さらに集合を小さくし、できるだけ混じり気のない仕様グループを作ることが大事です。
さらに、仕様と説明が混在すると、どこまでが仕様でどこまでが説明なのか分かりにくくなるので、説明も明確にわける。
■仕様と説明を区別する
…
要求には「理由」と「説明」の欄を必ず設け、要求の理由は必須とし、説明は必要を感じたときに使用するように勧めています。
また、仕様のほうでも、必要であれば【理由】や【説明】というキーワードを使って記述します。
６．要求仕様書を書く技術(2)
■要求書と要求仕様書を一体化
要求書の各要求の下に仕様を挿入することで、要求書と要求仕様書を一体化することができます。
…
「一覧性」というのは、仕様モレを防ぐのに効果があるのです。仕様を隠すことによって、どの要求が下位層に展開されているのかを一望することができます
つまり、どの要求にどの仕様書が対応しているかを一覧で見られることにより、仕様モレを防ぐ効果がある。
■品質要求について
要求されていないことは実現されません。
…
なお、「品質」という言葉自体は抽象概念で、実効性はありませんので、実際には「品質特性」（あるいは「品質属性」）という言葉を使います。
たとえば、「保守性」「操作性」「応答性」「対故障性」「理解性」「完全性」「交換性」などが、ソフトウェアの世界で使えると思われます。
つまり、品質要求を明確化しないいと、性能／拡張性に影響がでてします。
なかなか、この辺りまで、考慮するのはむずかしいですね。
■品質要求の仕様化
品質要求の場合は、機能要求と違って仕様化にはちょっと工夫が必要になります。
「…ができればその品質要求を満たすと見做す」というように、”見做す”という視点が導入されることが多いのです。
品質の場合には、測定する事が難しいため、このように”〜できれば〜見做す”のような視点を導入するそうです。
■仕様化に必要な時間を投入すること
要求の仕様化が適切なレベルで実現できるかどうかによって、その後のソフトウェア開発の命運は左右されます。
当然、仕様化作業には、それなりの時間（工数）が必要になります。この工数の投入を省けば、後でもっと多く時間が失われることになるのです。
…
私の経験では、要求の仕様化作業に、現時点で投入している工数の２倍は投入しても、プロジェクトの遅れにはなりません。
やっぱり、要件定義は時間がかかるものですね。
７．第５章 派生開発時の実践テクニック
■派生開発時の要求仕様の表現
派生開発では、…「変更要求仕様書」と「追加機能要求仕様書」の２本立てとします。
追加機能要求仕様書
・追加機能ごとにまとめる。
・基本的には新規要求と同じような表現でよい。
変更要求仕様書
・カテゴリ別に変更点を列記する。
・”変更”であることを表現することが大事
・追加機能もここでは変更として扱う
・実装レベルの変更点も拾い出す
■変更であることを表現する
変更要求で大事なのは、それが、"変更"であることを明確に表現することです。
「印刷できる最大桁数を128から192に変更する」とか、…、変更前と変更後がわかるように記述することが重要です。
■"仕様"で出される変更要求
機能要求と違って、変更の要求は、このように具体的なレベルで出されることが多く、そのままでは「変更要求仕様」が「要求」に包まれずに扱われてしまう危険があります。
変更要求仕様といえども仕様なのですから、それを包み込むような変更要求を立てて、そこに包み込むことが望ましいのです。
こうすることによって、顧客も気づかなかった変更すべき関連個所が見えてくることもあるのです。
…
つまり、この変更要求を考えることにより、顧客の本当に欲しいものを理解することができる。
その要求により、追加すべき派生の仕様が見えてくる。
■変更が5%以下を目指す
要求仕様書のベースライン設定後の要件の変更は、ベースに対して3〜5%以下になることを目指してください。
変更が10%以上もあるということは、まだまだ仕様としての出来栄えが不十分であることを意味します。
■獲得時間の集計
改善の効果として"失わずに済んだ時間"は、そのままでは見えませんので、強引にでも見える形にする必要があります。
レビューで検出（指摘）された項目は、以前ならバグになった可能性が高いと見做して、バグの平均対応時間などを乗じることで、「失わずに済んだ時間」として算出します。
この時間から、仕様化作業やレビューに投入した時間など、改善の取り組みに費やした時間を差し引いた時間が、「獲得時間」となります。つまり、取り組みの「効果」です。
