これは何？
- 要望、要求、要件、仕様・制約・前提と同じ様な事柄を表す言葉があって混乱したので、まとめたもの
分類
| 用語 | 説明 | 粒度感の例（機能） | 粒度感の例（非機能） |
|---|---|---|---|
| 要望 |
＜利用者視点＞ 顧客が作って欲しいこと（もの）の抽象的な表現。（顧客観点、顧客間未合意） |
氏名を表示したい | 素早く表示してほしい |
| 要求 |
＜利用者視点＞ 顧客が作って欲しいもの（こと）の条件（顧客観点、顧客間合意済み） |
氏名を表示できること | 素早く表示できること |
| 要件 |
＜成果物視点＞ もの（こと）自身が満たすべき条件。（システム観点、顧客観点を含む、顧客とベンダ間で合意済み） |
各ページに氏名が表示できること | ●×ページは、素早く表示できること |
| 仕様 |
＜成果物視点＞ もの（こと）自身が満たすべき詳細な条件（要件に対して実現手段が明らかとなったもの） |
各ページのヘッダ部分に「○○[半角スペース]●●」と表示する。○○は姓、●●は名を表す。 | ●×ページは、2秒以内で表示できること |
・利用者視点：各利用者（ステークホルダー）がそれぞれの視点で「こうあって欲しい」を語っている視点。あくまでユーザ目線という意味。
・成果物視点：見積もり・金額に影響がある内容で、顧客と受注ベンダとの合意事項であり、「何を作るか」を全て記載した視点（抜け漏れがあると、品質・納期・費用にインパクトがある）。
・分類は主観的であり、何らかの基準に基づくものではない。
・仕様や要求はアーキテクチャを前提として記載してよい。例えば、Webシステム、スマートフォン、組み込みシステム･･･など。粒度感の例では、Webシステムを前提としている。
例示した仕様の不十分さもあることに注意する。機能面の不十分さでは、姓名だけでなく、ミドルネームを持つ人物はどうする？などが上げられる。これらを、レビューなどを繰り返すことで洗い出し、仕様の精度を高めていくプロセスも必要である。また、非機能面の不十分さでは、応答速度にしか言及していないことにある。他の観点の非機能要件もあることに注意する。他の観点として参考となるものに『IPAの非機能要求グレード』(https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html) がある。
また、要求・要件・仕様は、制約事項・前提事項と区別する必要がある。
制約事項と前提事項の違いを示す。
| 用語 | 説明 | 例 |
|---|---|---|
| 前提事項 | 計画を立てるにあたって、証拠や実証なしに真実、現実、あるいは確実であるとみなした要因。 | 人員の調達。プログラマが10名、PM2名がプロジェクトスタート時に揃っていることを前提としてプロジェクトを立ち上げる |
| 制約事項 | プロジェクトまたはプロセスの実行に影響を及ぼす制限要素。何が何でも守るべきもの。 | お客さんから提示されたカットオーバーのスケジュールやマイルストーン（期日）。予算額。提供する機能。（＝お客さんから提示されるQuality/Cost/Deliveryの3要素が主） |
制約事項は守らなければいけないことであるため、この約束事をベンダ側も了承（合意）することが必要。
その他、留意しておくべきこと
英語では「要求」「要件」は区別しない
英語では、翻訳すると下記の様になる。英語では要求と要件の違いは無い。
- 要望 ： Demands
- 要求 ： Requirements
- 要件 ： Requirements
- 仕様 ： Specification
見解の違い
- 人によって定義が様々あり、統一されていないことが分かる。
願望・要求と要件・仕様の関係性
願望・要求と要件・仕様の関係性を下図に示す。
- 要件・仕様は、構築するシステムすべてのことを定義する。従って、要件・仕様にあることを全て満たさなければシステムが完成したとはいえない。
- お客様から伺う願望・要求は、自らの関心事（＝利害関係者の関心事）しか言及しないのがが一般的である。しかし、要件・仕様化する場合は、顧客の要求だけでなく、システムとして動作させる観点で必要な事柄も整理しておく必要がある。例えば、正常フローだけでなく、エラー発生時などの例外フローや代替フローについてもヒアリングし、要件や仕様化する必要があります。他の例では、エンドユーザに使ってもらう機能だけでなく、必要なデータを出し入れする管理画面などもシステム動作には必要な要件・仕様である。
- お客様自身も気付かない機能的な要求だけでなく、「当たり前だ」と思われている要求がある。例えば、業界の規格への対応、法律対応、セキュリティの対応、競合他サービスと同じような機能など「あって当たり前」の部分は顧客自身では、「当たり前すぎて」気付きにくいものである。これも要件定義を実施する上で、確認し、要件・仕様化する必要がある。
本の紹介
- 要求工学―プロセスと環境トラック (ソフトウェアテクノロジー) https://www.amazon.co.jp/dp/4320027825/
- 要求工学知識体系 第1版 情報サービス産業協会REBOK企画WG https://www.amazon.co.jp/dp/4764904047/
- 要求開発の基礎知識 要求プロセスと技法入門 山本修一郎 https://www.amazon.co.jp/dp/B07NY66L2K
サイトの紹介
「要求工学」について興味を持たれた方は、下記サイトが参考になる。
直近の記事は途中までしか見られないが、第1回～第50回くらいまではすべての記事を見ることができる。第1回～第50回の連載だけでも、要求工学が体系的に説明されていて、かなり有用な情報である。
https://www.bcm.co.jp/site/youkyu/index.html
↑の要求工学連載の著者である山本修一郎先生の動画コンテンツも下記にあります。（2022年1月9日時点）
家を建てる夫婦とシステム構築を比較した分かりやすい一冊（４０ページほどの簡単な読み物）
IPA資料より「家づくりで理解する要求明確化の勘どころ～システム構築を成功させる要件定義のポイント～」
https://www.ipa.go.jp/files/000065172.pdf
[追記] 2021年3月現在の要求工学界隈の動向
更に最新動向を知りたい場合は、SE4BSやSWEBOKの改訂版の動きをウォッチしておくと良いだろう。
「DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦 」
https://www.slideshare.net/hironoriwashizaki/dx-swebok-se4bs