要求定義の肝

まずはソフトウェア工学や開発方法論についての先達の識見です。システム開発にあくまでも数学的な美しさを求める心には、あるいは厳しく響くかもしれません。経験者であればその厳しさを踏まえた上で、それでも数学的な美しさを求めることの必要性を説くかもしれません。

• ソフトウェアの複雑さは本質的な性質であって、偶有的なものではない。したがって複雑性を取り去ったソフトウェア実体の記述は、しばしばその本質も取り去ることになる。数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、三世紀にわたって偉大な進歩を遂げた。この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。複雑性が本質である場合にはこの方法は使えない。ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。（人月の神話）
• ソフトウェア工学には、ソフトウェア開発を行っているのは人であると言う点を忘れさせる重大な問題があるのです。そしてソフトウェア工学は、私たちが体系的で定量的なプロセスを定義しさえすれば、「誰でも」ソフトウェア開発を成功させることができるということを黙約しているのです。しかし、この考え方は間違っています。事例研究が示すように、こういったプロセスがあったとしても依然として、ひときわ優れた開発者の存在がプロジェクトの成否を握っているのです。（ソフトウェア職人気質）
• ほぼ全員が、ブルックスの言う「銀の弾丸」は現れないとわかっていながら、ソフトウェア工学の革新的技術に乗り遅れまいと、飛び乗るのだ。（ソフトウェア開発55の真実と10のウソ）
• ソフトウェア工学は、ある種のプロジェクトに対しては素晴らしいアプローチとなるものの、ほとんどの商用ソフトウェア開発には不適切な選択となります。ソフトウェア工学は、商用のプロジェクトが必要としているもの、すなわち高品質で堅牢なアプリケーションを妥当なコストで調達するということを目標にして最適化されているわけではないのです。（ソフトウェア職人気質）
• 体系的なアプローチというものは、既知の理解されているものに対してしか適用できないため、ソフトウェア工学はソフトウェア開発の機械的な部分にのみ注目し、いつの間にか他の部分を過小評価、あるいは無視するようになってしまったのです。（ソフトウェア職人気質）
  
• 流れ作業というアプローチは、機械的作業に対してならうまく機能するのですが、知的作業に対してはまったく機能しないのです。（ソフトウェア職人気質）
  
• ソフトウェア工場というアイディアは、科学的管理法という考え方の延長線上にあります。つまり、流れ作業の持つ効率性は、ソフトウェア開発にとっても魅力的なのです。またこのアイディアによって、標準化されたプロセスや再利用可能なコンポーネントから恩恵を受けることもできそうです。確かにソフトウェア工場というアイディアの持つコンセプトは素晴らしいかもしれませんが、ここでまたしても肉体労働と知的労働を混乱させてしまっているのです。（ソフトウェア職人気質）
  
• 知識労働の環境では自動化が進んでいるため、さらに状況が複雑になっている。自動化を導入する際には、仕事の中でも特に機械的な要素を選ぶ（機械的だからこそ、自動化に適している）。新たに自動化を導入すると、人間がすべき仕事の全体量は減るが、残った仕事は難しくなる。これが自動化のパラドックスである。（ゆとりの法則）
  
• 経験から言って、知識労働の標準プロセスは、かならずといっていいほど肝心の中身がからっぽだ。（ゆとりの法則）
  
• 多くの開発方法論の提唱者たちは、繰り返し自分たちは問題分析を提供していると主張してきたが、その実提供されてきたものは、問題自身への探求や説明をなおざりにした、解法の概説にすぎなかった。（ソフトウェア要求と仕様）
  
• 問題そのものへの集中を欠いたことは、多くのプロジェクトに対して害を及ぼした。しかしそれ以上に開発「方法論」の進歩に対して有害であったのだ。問題について語らないということは、問題を分析も分類もしないということである。そのためわれわれは、すべての開発上の問題に適用可能な、強力で汎用的な開発方法が登場するだろう、といった幼稚な考えに陥りやすいのである。われわれは方法論に万能薬としての役割を期待しがちである。すべての病をそれ１つで治せるような。しかしそれはできない相談である。おおざっぱにいえば方法論の価値とその一般性は反比例すると考えて良い。すべての問題を解決する方法論は、特定の問題に対してはほんの少しの支援しかしてくれないものである。（ソフトウェア要求と仕様）
  
• 情報システム業界はめまぐるしく変化していくために、常に新しい手法、新しい手法へと乗り換えていく必要があると考えがちです。しかし、一貫性がなければかえって手間が増え、システム開発に暗い影を落としかねないことを認識しておきましょう。（よくわかる最新要求定義の基本と仕組み）
  
• あらゆるプロジェクトは異なるという単純な理由で、すべてのプロジェクトは異なるプロセスを必要とする。（要件プロセス完全修得法）

• 私がコンピュータ制御旅客機の乗客だったとしたら、航空管制用のソフトウェアが「体系的」かつ「規則化」された「定量的アプローチ」に則ったものであるかどうかを知りたいと思います。つまり、ソフトウェアが「最低価格で落札した業者によって開発されたもの」である場合、安心して搭乗することはできないのです。（ソフトウェア職人気質）

• それら開発手法の大部分はプロセスそのものではなく、そのプロセスの成果物に焦点を合わせている。それほど要求定義工学の形式的な記述は困難であり、これが恐らく要求モデルが次々と生まれてくる理由ともなっている。（要求定義工学入門）
  
• ソフトウェア開発における要求の導出は労働集約的なプロセスであり、（特に人間からの）知識の導出は本質的に困難な仕事のため、多くの時間と資源を必要とするものである。（要求定義工学入門）
  
• すべてのアプリケーションに対して有効な要求分析の技法はない。複雑なアプリケーションのための要求分析は、複数の技法を用いてはじめて理解することができる。（ソフトウェア開発２０１の鉄則）
  
• すべてのアプリケーションに適した１つのプログラミング言語が存在しないのと同様に、詳細な仕様を作成するのに適した方法が１つだけ存在するわけではありません。環境が異なれば必要なテクニックも異なってきます。（ソフトウェア要求管理）
  
• 生産管理や財務システムのように、工学的あるいは法的なルールで仕様が決まる部分は確かにある。しかし、多くの部分は、企業の独自の論理である。その論理は、結局その時点の組織の意思で決まる。制御系ソフトウェアや科学技術計算のように、物理や数学をよりどころとするソフトウェアと根本的に異なる点である。（要求工学）

• 要求が徐々に増大する割合は、平均して一ヶ月に１％を超え、時にはソフトウェアが何をなすべきかを最初に合意した直後の設計フェーズで、一ヶ月に２％を超えたりする。（ソフトウェアの成功と失敗）
  ある経験則に関する調査では、要求仕様作成での顧客の関与が「高い」と、生産性が平均して約５０％高くなることがわかった。（ラピッドデベロップメント）
  Capers Jonesは欠陥を防ぐための１ドルは、欠陥の修理費用を3〜10ドル減らすと報告しています。（ソフトウェア要求）
  平均的なプロジェクトの場合、要件の約３５％は要件プロセスが終了したと見なされる後に出てくるものである。（要件プロセス完全修得法）

そしてもちろん、要求定義の重要性を示すデータにも事欠きません。感覚的にわかっていることではありますが、実際に数字として示されると、確かに説得力が違います。

• 要求エラーは、最終的な欠陥のトップになっており、最終的な欠陥全体の3分の1近くを占めています。（ソフトウェア要求管理）
  
• 要求段階で作り込まれる誤りは、ソフトウェアプロジェクトで見つかる全欠陥の実に４０〜６０パーセントを占めています。（ソフトウェア要求）
  
• ソフトウェアライフサイクルの中の要求段階でエラーを発見する場合と、保守段階でエラーを発見する場合とのコスト節約比を比較すると、２００：１になる。（ソフトウェア要求管理）
  
• プロジェクトの半数以上で、当初見積りより2倍のコストがかかっている。（ソフトウェア要求管理）
  
• 開発期間中は、一ヶ月当たり１〜４％の割合で要求が変更されるのが一般的です。毎月の変更率が２％を越えると、「要求の攪乱」という現象が起き、顧客のプロジェクトがきわめて重大なリスクにさらされることになります。（ソフトウェア要求管理）
  
• 顧客に報告された要求の欠陥を修正するコストは、要求開発期間中に発見した誤りを修正するコストの約１００倍かかるという研究報告があります。（ソフトウェア要求）
  
• 要件に関する作業をいいかげんに切り上げると、後で大きなツケを払うことになる。要件を誤って特定していた場合、下流の作業であるコーディング中にこの誤りを訂正すると、コストは要件の段階で訂正したときの50〜200倍にはね上がってしまうのだ。（ソフトウェアプロジェクトサバイバルガイド）
  
• 要件定義は開発全体にかかる工数で言えば１〜２割の作業ですが、開発の成否を左右するという意味で言えば７〜８割はここまでの工程に依存します。（経営者が参画する要求品質の確保）

• ソフトウェアプロジェクトが目標を満たせずに失敗するのはよくあることです。それは、開発者や他のプロジェクト参加者が良くない計画者だからであり、良くないソフトウェア技術者だからではありません。主な計画の誤りには、共通作業を見落とすこと、工数や時間を過小評価すること、プロジェクトのリスク計上に失敗すること、手戻りを予想しないこと、根拠のない楽観で自己欺瞞することなどが挙げられます。（ソフトウェア要求）
  
• ソフトウェア開発の見積は、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積ることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。（ソフトウェア開発55の真実と10のウソ）
  
• リスク準備とは、そもそも必要ないかもしれない時間と費用のことである。スケジュールと予算にリスク準備を織り込むには勇気がいる。（熊とワルツを）

• 毎年、何千億円ものお金が要件を満たさない製品を作るのに浪費されているが、その最も大きな理由は要件を明快に理解していないことによるのである。（要求仕様の探検学）
  
• 漏れやあいまいさが残るとどういった害があるでしょうか。それらは、現象としては設計上の後戻りの発生としてフィードバックされます。そして、品質、コスト、納期の3つに悪影響を及ぼし、システムの開発プロジェクトを最悪、頓挫へと導きます。（よくわかる最新要求定義の基本と仕組み）
  
• 要求エラーは、最も起こりやすいシステム開発上のエラーであり、それを修正するには最もコストがかかる。（ソフトウェア要求管理）
  
• 要求の仕様化が不十分な状況では“予定通り”に設計工程に入っても、具体的に何ができればよいのかが見えていないために設計作業ははかどりません。（要求を仕様化する技術・表現する技術）
  
• テストが始まると、このソフトウェアが重大な性能上の問題を抱えており、さらに開発の初期段階で近道をしたことが原因の欠陥が数多くあることが明らかになった。（ソフトウェアの成功と失敗）
  
• トラブルに見舞われたプロジェクトのリカバリーの可能性は、その問題に気づくタイミングに非常に強く関係している。（ソフトウェアの成功と失敗）
  
• 設計上での誤った決定に導く誤った仮定は樹の根の近くで行われることが多い。しかもそれは葉の近くで見つかるのだ。（要求仕様の探検学）
  
• するに値しないことは正しくするに値しない。（要求仕様の探検学）

• 特急のプロジェクトでは本質的でない作業は削ろうとするものだが、要求仕様の分析、アーキテクチャ、設計などはコードを直接生み出すわけではないので削られる恰好の大将となる。（ラピッドデベロップメント）
  
• このいいかげんな推測と楽観主義がプロジェクト・スケジュールを非現実的なものにしてしまうというケースは極めて多く、それが原因で今度は開発担当者が手を抜き、システムの質を落とさざるを得なくなるといったことが起こる。（要件プロセス完全修得法）
  
• ソフトウェア開発において、最も一般的で、最も深刻な問題の多くは、要求に関連するものであるということがここで証明されています。（ソフトウェア要求管理）

要求定義、そしてそれにさかのぼるプロジェクトの計画策定に当たっては、以下のような心構えで作業にあたりたいものです。

• 要件の収集と分析を十分に行うためのコストは、貧弱な要件がもたらすコストに比較すれば取るに足らないものである。（要件プロセス完全修得法）

• システム開発ライフサイクルのどの段階であろうと、システムは変更されるし、また、それを変更しようとする欲求は、ライフサイクルを通して持続する。（ソフトウェア開発２０１の鉄則）
  
• 要求は不完全あるいは信頼できない情報に基づいて意思決定を必要としているか？もしそうであれば、このプロセス要求の決定をコンピュータシステムではなく人に委ねることを考慮する。（要求定義工学プラクティスガイド）
  
• ウォーターフォール型モデルの伝統的な解釈に従うなら、ある製品の顧客への最初の納入は、ソフトウェア開発の資源を９９％消費した後に行われる。したがって、顧客のニーズに関するフィードバックの大部分は、資源を使い切った後に起こることになる。（ソフトウェア開発２０１の鉄則）
  
• ITシステムの企画・開発の現場では、ユーザ企業とベンダ企業の相反する想いがあります。例えば、ユーザ企業は、要件はできるだけじっくり詰めたいし、予算は早期の投資判断を求められるので最終費用を早く確定してほしいとの想いがあります。他方のベンダ企業の想いはまったくその逆です。（経営者が参画する要求品質の確保）
  
• 漠然とした要件のみしか判っていない時点で行われるプロジェクトの初期見積は、4の倍数で誤差を含んでいます。しかし、いったん主たる要件が明確になれば、見積り誤差は2の倍数にまで減少させることができます。その後、要件すべてが詳細に描写されれば、見積誤差は1.5の倍数にまで減少させることができます。（ソフトウェア職人気質）
  
• なぜ、初期段階で仕様を確定するのが難しいのか。考えられる要因としてはいくつかある。まず、第一にITプロジェクトが特有のニーズのダイナミズムに支配されること、が挙げられる。ITプロジェクトの初期段階では、関係者は「目に見えない」成果物に対するイメージを正確には持っていない。むしろ成果物が形成されていく過程で、ニーズを認識していくことが多く、時にはニーズが二転三転したり、新しい可能性を見出したり、ニーズを発展させる場合もある。（先制型プロジェクト・マネジメント）

• 仕様がないと、機能仕様所に現れないので、仕様をベースにしたレビューやコード・インスペクションでもチェックできない。さらに、抜けた仕様を確認するためのテスト項目もない。（ソフトウェア開発55の真実と10のウソ）
  
• ソフトウェア産業の弱さは、その修正行動をとるのに十分なだけ早期に問題を特定できない点にある。（ソフトウェアの成功と失敗）
  
• 要件漏れというのは、新しい要件が、それが何処から来たのか、あるいはそれがシステムにどのような価値を持つものなのか、といったことが誰もわからないままに仕様として追加されてしまうことをいう。（要件プロセス完全修得法）
  
• 機能の見落としという問題はさらに面倒です。アプリケーション領域における相当な専門知識がなければ、機能の重要な部分が要求セットで見落とされているかどうかを技術担当の開発者が判断するのは難しいからです。結局のところ、機能はすべて目新しいものなので、どれだけの機能を積み残しているのかわかるはずがありません。（ソフトウェア要求管理）
  
• 通常ごく普通に利用している「当たり前」の機能であるため、それを実現してもらいたい機能として、ユーザがはっきりと自覚していないことがあります。（ソフトウェア要求管理）
  
• プロジェクトがスケジュールから遅れたとき、計画した作業に思いもよらない時間がかかったから、という場合は少ない。それよりはるかに多いのは、計画になかった作業のために、プロジェクトが進まなくなったという場合である。（熊とワルツを）
  
• また、最もよく要求として漏れてしまうのが、顧客が属している業界や企業自身の“暗黙の了解”や“商習慣”です。特に要求定義を担当する情報技術者（要求アナリスト）が、その業界に関する知識を持っていなかったり、要求を引き出すスキルが十分でない時にはこうしたことが起こります。（よくわかる最新要求定義の基本と仕組み）

• 仕様の一つ一つが問題解決上の難しさを形成し、仕様が互いに関係を持つと、問題解決の複雑性が急増する。仕様が一つ漏れると、解法を設計する際に問題全体を把握できなくなるのだ。（ソフトウェア開発55の真実と10のウソ）

• 顧客が口には出さなくても期待している暗黙の要求がないかどうか見極めることも必要です。また、要求の中から、あいまいさの元になる漠然とした不十分な言葉を見つけてください。（ソフトウェア要求）
  
• 抜けている要求を検索する厳密な手段はCRUDマトリックスを作ることです。CRUDマトリックスは、システム動作をデータエンティティ（個々のデータ項目またはデータ項目の集合体）に関連させ、各データ項目がどのシステム動作で作成、読み取り、更新、削除されるかを確認するものです。（ソフトウェア要求）

もっとも、要求の見落としを肯定的に考えることもできなくはありません。

• 信じられないほど顕著なクリープが起こるという場合は、要件クリープの問題というよりは、システム自体が本来持つべき正しい機能性に向かって動き出したものと捉えるべきである。（要件プロセス完全修得法）

• 経験が我々に教えてくれたことは、問題を見える形で示すことによって賢明な人たちの発想に火をつけると、彼らはきわめて創造的かつ想像力に富んだ存在になるということである。（要件プロセス完全修得法）
  
• プロトタイプを作る主な理由は、開発プロセスの初期に不確実性を解決しておくことです。この不確実性を利用して、システムのどの部分をプロトタイプするか、そしてプロトタイプによって何を評価するのかを決めてください。（ソフトウェア要求）
  
• プロトタイプを作る前に、評価の後でそのプロトタイプを廃棄するのか、それとも引き渡す製品の一部にするのかは、よく話し合ってはっきりと決定しておいてください。（ソフトウェア要求）
  
• もし開発者が、顧客が最初に言ったものを忠実にそのまま作ったとしたら、多分また作り直さなければならないでしょう。（ソフトウェア要求）

• プロトタイプはあくまでも「単なるプロトタイプ」にすぎないことをユーザーに理解させなければならない。ユーザーインターフェースプロトタイプの作成に伴うリスクの一つは、ユーザーに、プロジェクトの今後の進展に対し非現実的な期待を図らずも抱かせてしまうことである。（ソフトウェアプロジェクトサバイバルガイド）
  
• プロトタイプの作成目的は、システムを本格的に製造する前段階で仮の「はりぼて」を作って顧客、利害関係者に見せることで、要求を引き出すことです。したがって、純粋なプロトタイプでは作ったはりぼてを使ってシステムを継続的に作るということはありません。（よくわかる最新要求定義の基本と仕組み）

話は横にそれるかもしれませんが、要求定義が信頼ならないものであるならば、それを認めた上でうまく付き合う方法を考えるのも重要なことでしょう。

• 立派なアイディアを失敗に導きかねないことを三つ考えなかったとすれば、それはあなたがそのアイディアを考え抜かなかったということなのだ。（要求仕様の探検学）
  
• 薬と同様にソフトウェア開発においても、治療よりも予防のほうが効果的な場合が多い。（ソフトウェアの成功と失敗）
  
• このライフサイクルの初期の作業に、もう少し時間をかけることを強くお勧めします。実際にこれらの作業で費やされるコストは、プロジェクト予算のほんの数パーセント、たぶん、５％ぐらいではないかと思います。（ソフトウェア要求管理）
  
• まず、リスクごとに、それが問題となる可能性と、そのコストおよびスケジュールへの影響を評価する。それと同時に、警告となるきざし（何が起こればそのリスクが問題化する可能性が出てくるのか）について意見の統一をしておく。（要件プロセス完全修得法）
  
• 全ての取り決めは、承認ルールを明確にして、実施しなければなりません。誰が承認するとか、どのように承認するかを明確にするとともに、承認の証跡を残すことです。（経営者が参画する要求品質の確保）
  
• 変更される可能性が最も高いと思われる要求のリストを保持すべきである。もしできれば、それらの要求に関する変更可能性を予測しておく。（要求定義工学プラクティスガイド）
  
• システム開発者がシステム設計を行うときに、不安定要求をモジュールとしてまとめ、システムの他の部分からの独立性を高めておくことができる。（要求定義工学プラクティスガイド）
  
• 特に要求仕様が曖昧すぎる場合や、ベンダーにとって未経験分野で知識に乏しい場合は契約を2段階に分け、仕様確定までは「要員派遣ベースによる仕様確定契約」としてもらい、仕様確定後に「システム開発請負契約」にしてもらうのが最適だ。（曖昧性とのたたかい）

• ユーザーに提供される機能性（または性能）が多ければ多い（高ければ高い）ほど、ユーザーはもっと多い機能性（もっと高い性能）をほしがるものである。（ソフトウェア開発２０１の鉄則）
  
• 顧客というものは、製品を見るや否やもっと多い（高い）ものを欲しがる、ということを、管理及び技術の両プロセスのすべての局面から、覚悟していなければならない。（ソフトウェア開発２０１の鉄則）
  
• ソフトウェア製作者が顧客のために行うもっとも重要な仕事は、製品の要件を繰り返し抽出し、洗練していくことだ。実際のところ、顧客自身何を希望しているのか分かっていないものだ。彼らは通常、どんな質問に答えなくてはならないのかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなどほとんどない。（人月の神話）
  
• ユーザは自分の望んでいることを分かっていない。あるいは、分かってていても、それを明確に表現できない。ユーザは、自分が望んでいるといったものを形にしてもらって、はじめて本当に自分の望んでいるものに気づく。（ソフトウェア要求管理）
  
• だが、顧客はRFPをわざと曖昧に書いているわけではない。RFPを作るときには、顧客の頭の中でさえまだシステムイメージが明確になっていないことも多いのである。（曖昧性とのたたかい）
  
• 顧客というのは、どのリリースにおいても、できるだけ多くの機能を実現するよう要求してきます。（ソフトウェア要求管理）
  
• 1月にプロジェクトを開始し、10ヵ月後にXを納品することになっていたとしたら、その10ヶ月が終わる頃には、もうXはビジネス・パートナーがほんとうに求めるものではなくなっている。ほんとうに求めているのはX＋である。（熊とワルツを）
  
• 動く的を射ることは、誰もが抱える問題である。発注者が今ほしいと言ったとおりのものを未来に納品しようと考えるのは、さっきレシーバーがいた場所にフットボールを投げるようなものだ。（熊とワルツを）
  
• 利害関係者は自分たちがコンピュータシステムに対して本当は何を欲しているかをごく一般的な言葉でしか知らないことが多い。たとえ彼らがシステムに何をしてほしいか明らかな考えをもっていてもそれを表現することは難しい。彼らはまた、彼らの要求に対するコストについては分からないために、非現実的な要望を行うこともある。（要求定義工学プラクティスガイド）
  
• 顧客は自分の言葉と仕事についての暗黙的な知識に基づき要求を表現する。アナリストは顧客の領域についてあまり経験がないにもかかわらず、これらの要求を理解し、それらを開発プロセスに関与するすべての人々が理解できる形で表現しなければならない。（要求定義工学プラクティスガイド）
  
• そして、質問がほとんど出てこなかったことで、依頼側としては、「理解されている」と誤解してしまうのです。（要求を仕様化する技術・表現する技術）
  
• よくあるリスクは、初めて新システムを見て感動したユーザが、新しい要求を開発部門に殺到させることである。（アジャイルプロジェクト管理）

さて、次はスコープに関する先達の識見です。スコープは（たとえ理想論であっても）、その境界線は明確に定めなければなりません。コストやスケジュールに直接影響してくるところです。

• 慎重に機能を定義すること、細かく配慮された仕様書、そして機能の飾りやテクニックの飛躍をきっぱりと払いのけることすべてが、発見しなければならないシステムのバグの数を減らすことにつながる。（人月の神話）
  
• プロジェクトスコープは、提案されたソリューションの概念とその範囲を定義したものです。一方、限界は、製品に含めない特定の機能を、項目別に挙げたものです。スコープと限界を明らかにすることによって、ステークホルダーの期待は現実的なものになります。（ソフトウェア要求）

しかしその境界線を定めることがまた難しいのです。

• 企業のコンピュータシステムは、人間が行う業務活動の中に埋め込まれたシステムである。このことが、機械の中に埋め込まれた制御系ソフトウェアと決定的に異なる、要求獲得の難しさを生み出す。難しさの第一の理由は、コンピュータシステムと人間の情報処理の境界が最初から決まっていないことにある。例外事項や判断を伴う処理を人間が行うのか、徹底的にコンピュータシステムで自動化を狙うかで、開発するアプリケーションソフトウェアの機能は大きく異なる。（要求工学）
  
• 多くのステークホルダーが出てきて、競合する関心を持つ多くの顧客が参入してくるにつれ、スコープクリープのリスクは増大します。（ソフトウェア要求）
  
• 要求の提示者はシステムに何を含め何を含めないかについてあいまいな場合が多い。それゆえ彼らは不適切な要求を提案することがある。（要求定義工学プラクティスガイド）
  
• 通常のシステムの機能の64パーセントはめったに使われないか、あるいは全く使われない。（リーンソフトウェア開発）
  
• この業界では、開発範囲を超えたプロジェクトが日常茶飯事に行われている。（ソフトウェア要求管理）

• ほとんどのプロジェクトにおいて、成功の確率を妥当な線にもっていくには、開発範囲を半分に減らす必要がある。（ソフトウェア要求管理）
  
• プロジェクト範囲を確立するための最初のステップは、高レベルの要求合意線を確立することである。（ソフトウェア要求管理）
  
• 開発作業工数を集中させ、合理的なプロジェクトスケジュールを維持したいのであれば、潜在顧客がいつかは欲しいと思うであろうあらゆる機能をリリース１．０に入れる誘惑を避けてください。（ソフトウェア要求）
  
• 知らぬ間に発生したスコープクリープが、肥大化したソフトウェアと崩壊したスケジュールを生み出すのです。（ソフトウェア要求）
  
• 運用プロセスにかかわる要求とシステムの境界外のものであると分類した要求については、なぜこれらを除外すべきかについての技術的あるいは経済的議論の準備をしておく必要がある。（要求定義工学プラクティスガイド）
  
• 従来はすべて手作業に頼っていたシステムを自動化する場合、システムは完全に決定論的になる。新しいシステムは、その設計者が明確に意図した応答処理だけに仕事をする能力を持つ。したがって、手作業にはあった自己修復機能は失われてしまう。必要などんなささいな応答処理に対しても、最初の段階から組み込まれていなければならない。（ピープルウェア）
  
• 仕様確定が遅れると、確定後は遅延回復の責任は受注者側に移ってしまう。（曖昧性とのたたかい）

• 業務に関心を持つ理由は、業務を理解できれば、また理解できた時に初めて、業務の役に立つシステムを構築できるからである。結局、意図するところは、サポートする業務に円滑に適合するようなシステムを作るということなのである。（要件プロセス完全修得法）
  
• 業務範囲を設定するということは、システムに対する要件を決定する前にどれだけの業務について検討をくわえなければならないかを決めるという意味である。どれが対象業務でどれがそれ以外の業務かを考慮する際に、システムの目的を常に思い浮かべることが重要である。（要件プロセス完全修得法）
  
• まず業務を理解することが必要であり、どこまで自動化できるのか、あるいはどういった変更が可能なのか、といったことはその後で検討すべき課題である。もう一つ考慮すべきことは、業務範囲を拡大してみることによって、自動化や改善の可能性が他にも生まれてくるかもしれないという点である。（要件プロセス完全修得法）
  
• システムは単に業務をサポートするツールにしか過ぎない。したがって、業務を理解することは至上命令なのである。（要件プロセス完全修得法）
  
• 冗長機能のカットの提案や、代案提示ができるようになるためにはまず、業務の正確な理解に努めなければならない。正確な理解とは、その業務が何の目的で実行されなければならないのか、やらなければどういう不都合が生じるのかということまで理解することである。（曖昧性とのたたかい）
  
• 要求にかかわる問題の多くは、単に理解の欠如によるものが多い。ある利害関係者は他の利害関係者がどのようにシステムを使うか知らず、または理解しておらず、彼らが必要とするシステムの機能を認識していない。（要求定義工学プラクティスガイド）
  
• コンピュータシステムが支援しようとしているプロセスについて明快に記述することで、そのシステムに対する支援要求やシステムの利用方法に影響を与える制約が明らかになる。（要求定義工学プラクティスガイド）
  
• プロセスを定義することはそのプロセスに関与する人々の役割を特定することを意味する。これはシステム要求を提案するシステムの利害関係者を見つけ出すのに有効な方法である。（要求定義工学プラクティスガイド）
  
• コンピュータシステムを開発する目的は、顧客レポートを作成するようなビジネスプロセスの支援や、あるいは飛行機の操縦のような技術的な活動の支援などにある。要求の導出プロセスの一部としてこれらのプロセスを分析し理解し、そして文書化する必要がある。（要求定義工学プラクティスガイド）
  
• プロセスはしばしば複雑であるのに、プロセス分析が単純すぎたために、有効でない要求提案が生まれることがある。（要求定義工学プラクティスガイド）

• ユーザーに、その仕事の内容を手際よく他人に説明するプレゼンテーション能力や説明力を期待することはできない。しかし、たいていの人は、今行っていること、それをやりながら説明するのは上手である。ユーザーがいつもの仕事場でいつもの仕事をしながらであれば、仕事をしながらそれをそのまま注釈したり、他では飛ばしてしまうような詳細についても説明してくれる。（要件プロセス完全修得法）
  
• ユーザーに業務について語ってもらうためには、ユーザーを仕事から引き離してはならない。（要件プロセス完全修得法）
  
• いったんプロセスの基本的な理解ができたならば、プロセスの参加者が業務を行っているところを観察する。（要求定義工学プラクティスガイド）
  
• 観察をベースとしたアプローチの利点は、人々が重要とは考えていないような無意識的活動を発見できることであり、そしてプロセスに関与する人々の社会的な交流が重要であることを知ることである。（要求定義工学プラクティスガイド）

業務を知るためには現場に接するのが一番ですが、それ以前に、現場に接することが要求定義の基本と言えるかもしれません。ここで（範囲は広くなりますが）要求定義の作業にあたっての基本的な心構えを紹介しましょう。

• ソフトウェア技術者は永遠の楽観論者です。私たちはたいてい、前のプロジェクトで前歴があるにもかかわらず、次のプロジェクトはうまくいくと思います。実際には多数の潜在的な落とし穴があり、ソフトウェアプロジェクトは遅れたり脱線したりします。（ソフトウェア要求）
  
• 「ソフトウェアシステムを作るうえで最も難しい部分は、何を作るべきかを正確に決めることです。人間や、マシンや、他のソフトウェアシステムとの全インターフェースを含む詳細な技術的要求を確立すること以上に難しい概念的作業は他にありません。（ソフトウェア要求）
  
• 多くの人々は、要求の議論に時間を費やせば、かかった時間だけ単純に製品の引き渡しが遅れると誤解しています。しかし、品質のコストを全段階で見渡してみると、初期段階の品質を重視するプラクティスがいかに価値が高いか明らかです。（ソフトウェア要求）
  
• 開発チームは、システムの要求項目を引き出すために、もっと積極的な役割を果たす必要がある。（ソフトウェア要求管理）
  
• インタビューする側の先入観や考え方が、自由な情報交換の妨げにならないようにすることです。（ソフトウェア要求管理）
  
• 不明な点があれば質問する。不明な点がなくても、とにかく質問してみる。（ソフトウェア要求管理）
  
• 私たちのアイデアの不完全性さや不整合性は、実現段階になって初めて明白になる。したがって、書くこと、実験すること、「考えつくすこと」が理論家にとっての必須の修練ということになる。（人月の神話）
  
• ソフトウェアシステム構築でもっとも困難な部分を一つあげるなら、それは何を構築するのかを的確に決定することである。（人月の神話）
  
• 情報を集めるにつれて解決策の特質に関する仮説が展開される。経験の深い分析者は、要求保持者からより多くの事実を得るために仮説に基づく例を利用する。（要求定義工学入門）
  
• 「仕様化」という行為は“決めていく”行為です。予測する部分があってもそれを決めていき、適切に調整された結果として残されたものが「要求仕様書」です。（要求を仕様化する技術・表現する技術）
  
• ヒアリング／インタビューは複数人で行うことを勧めます。多角的な視点から質問、インタビューが行えるからです。設計をしても話が逸脱すると、一人で対処できる範囲は限られてきます。どうしても視点が偏りがちになったり、突っ込んだ質問が漏れることが考えられます。可能かな限り、複数人で行い、漏れやあいまいさをなくすようにしましょう。（よくわかる最新要求定義の基本と仕組み）
  
• 仕様の詳細を固めてゆくときは、当初予算より3割以上は仕様を膨張させない強い決意が必要であると言える。（曖昧性とのたたかい）
  
• つまり、要件とは単純に現存する業務の一部を受身で翻訳するというものではなく、その業務をより簡単でより良い、より興味深く快適なものにする工夫が含まれていなければならないのである。（要件プロセス完全修得法）
  
• 要件仕様に設計を持ち込むことは絶対に避けるべきこと（設計と要件は同じものではない）ではあるが、設計には依頼主あるいは組織が要求する強制的な要素が常に存在するものであり、それらを無視することは非現実的であり、受け入れがたいものなのである。（要件プロセス完全修得法）
  
• 常に契約条件以内にシステム仕様をまとめ上げるためには、受注者（ベンダー）主導の「提案型ナビゲーション」が必要で、受注者側は先手先手で仕様決定プロセスを先導しなければならない。（曖昧性とのたたかい）
  
• テクノロジやスキルは移ろいやすいものですが、エンジニアリングを難しくするものの核心の大半は変わっていないのです。（アート・オブ・プロジェクトマネジメント）
  
• 受注段階から続いている営業担当者と顧客との間で醸しがちな多幸感に満ちたトーンをリセットする必要がある。この時重要なのが、顧客の過大な期待に対するコントロールである。（先制型プロジェクト・マネジメント）
  
• 忙しい顧客は、要求にかかわって費やす時間はないと主張することがある。過去のプロジェクトで、不満足なシステムを引き渡し、その後で顧客の望みに対応するために高い費用がかかったことを思い出させること。（ソフトウェア要求）

• 先を急ぐあまり、解決すべき問題を十分に理解せずに技術的な解決策を提供する傾向にあります。その結果、ユーザや利害関係者のニーズを満たしていないシステムが出来上がってしまうというのは予想し難くないでしょう。（ソフトウェア要求管理）
  
• 要件の内容が解決策の形で記述されることがよくある。我々は皆、要件を語るときに無意識のうちに、どう解決すべきかという視点でそれを行いがちになる。これまでの個人的な経験に基づいて、要件ではなく解決策を語るのである。その結果として、可能な解決策の一つ（必ずしも最適解ではない）に焦点を合わせた表現となり、実際の要件が隠されてしまうことになる。（要件プロセス完全修得法）

• 人々が何を望んでいるのかわからなければ、開発プロセスが、どんなに厳密に、賢明に、効率的に行われようと、彼らを満足させることはできない。（要求仕様の探検学）
  
• グループは、システムの仕様作成や設計レビューにユーザを参加させようとしたが、不十分なサポートしか受けられなかった。時間の空いているユーザにしか接触しなかったからである。（アジャイルプロジェクト管理）
  
• さて、それでは、どうやって根本原因を判断したらよいでしょうか？それは状況によります。多くの場合、直接関連のある人々に、根本原因は何かを尋ねてみるのが簡単です。・・・ですから、何度も繰り返し尋ねてください。（ソフトウェア要求管理）
  
• 真のニーズを把握する唯一の方法は、ニーズを持つ人たちとよく話し合うことである。（ソフトウェア開発２０１の鉄則）
  
• 時間が許すかぎり、顧客に対して何度も質問し、要求事項のより正確な文書化に努めて、曖昧さを少しでも減らすべきである。（曖昧性とのたたかい）
  
• 分析者は二度三度と要約説明をして、そのたびごとに新しい疑問を引き出している。（要求定義工学入門）
  
• 問題を解こうとする前に、誰が本当の問題をかかえているのか、本当の問題は何か、をすべての代替案について確実に調べよ。（ソフトウェア開発２０１の鉄則）
  
• 設計者が犯す大きなまちがいの一つは、顧客が望んでいるものではなく、顧客が必要とするものを与えようとすることである。（要求仕様の探検学）
  
• 顧客に必要だとあなたが思っていることを、顧客が実際に必要だと信じるようにしむけること。顧客に信じるようにさせられなければ、顧客が望んでいるものを作るか、他の顧客を見つけるべきだ。（要求仕様の探検学）
  
• インタビューの前に、インタビュー対象の利害関係者や会社のバックグラウンドを調査する。（ソフトウェア要求管理）
  
• 以前の製品リリースまたは類似の製品のユーザー代表者のグループを集めてください。開発中の製品の機能と品質特性の両方に関して、そのグループから情報を集めてください。（ソフトウェア要求）
  
• ユーザーが関与することによって、ユーザーが必要とするものと開発者が引き渡すものとの間の期待のギャップを減らすことができるのです。（ソフトウェア要求）
  
• 責任を負わない部門が実現不可能なあるいは非常に高価につく要求を提案することがありうる。（要求定義工学プラクティスガイド）
  
• 要件のヒアリングは人間同士のふれあいによる作業であり、要件を記述したドキュメントが誤って解釈されることで引き起こされる誤解を避けるために、開発者はユーザと絶えず話し合いを続けなければならないわけです。（ソフトウェア職人気質）
  
• 真の顧客ニーズを徹底的に調べて文書化しない限り、そのニーズを満たすシステムが構築できる可能性はきわめて小さくなります。（ソフトウェア開発の持つべき文化）
  
• Billが廊下を30メートルも向こうへ引っ越してしまうと、私は生産性がたちまち落ちることに気づきました。もう、問題点をリアルタイムで解決できなくなってしまったからです。開発者と顧客との間のやり取りの頻度と質が低下する一方、やりなおし作業の量は増加しました。（ソフトウェア開発の持つべき文化）

• あらゆる設計者はユーザ母体を定義するだろうが、改めてユーザ包含活動をしなければ、選択の多くは暗黙のうちに行われることになる。（要求仕様の探検学）
  
• システムの導入によって影響を受けると思われるすべての人々を考えなければ、重要な要求を見落としてしまう可能性がある。（要求定義工学プラクティスガイド）
  
• もう一つの共通の誤りは、ユーザ母集団のある部分の代表者を使いながら、そのことを理解していないことだ。代表者は真のユーザではなく、代役にすぎないのである。（要求仕様の探検学）
  
• 仕様の崩壊が起きるのは、顧客やプロジェクトマネジャーが仕様に関して合意を出せなかった場合である。たとえば、社内向けの情報システムプロジェクトで、その顧客となる部署が10ある場合、その部署間でビジネスプロセスやビジネスルールについての合意が取れなければ、仕様決定のプロセスは崩壊してしまう。（アジャイルプロジェクトマネジメント）
  
• それぞれの利害関係者を見きわめ、そのそれぞれがチームに求めるサービスを確実に受け取れるように調整をしなければ、プロジェクトマネジャーは不満を持った利害関係者から不意打ちを食らう危険性を冒しているということなのだ。（アジャイルプロジェクトマネジメント）
  
• 実際には、さまざまなユーザカテゴリを識別しなければならないことがあります。たとえば、初心者、平均的ユーザ、パワーユーザ、読み書きのできないユーザ、使用する言語が母国語でないユーザ、なのです。（ソフトウェア要求管理）
  
• どんなユーザーグループのニーズも見落とさないように、製品のさまざまなユーザーのグループを明確にしてください。グループによって、使用頻度、使う機能、特権レベル、スキルレベルが違います。（ソフトウェア要求）
  
• もし要求が単一の視点からしか収集されないならば、他の利害関係者のニーズを満たしそうもない。ニーズを満たし損ねた利害関係者の影響力が大きい場合は、システムが使用されないことになる。（要求定義工学プラクティスガイド）
  
• システムによっては多様な利用者があり、異なる立場からの要求が出され、それらに優先順位がつけられたり、互いに矛盾する要求が出ることがある。その結果、最終システムは誰にも満足のいかないものであったり、妥協の産物と化してしまう。（要求工学）
  
• 分析者は、これら顧客側の各人がお互いに話し合い、引き渡されるシステムに対して合意していると思ってはいけない。（プログラミング・プロジェクトの管理）

• システムを使う可能性のある人々をカテゴリーごとに分けたチェックリストを作ることをぜひお薦めしたい。（要件プロセス完全修得法）
  
• 利害関係者は各々様々な要求を持ち、それをまたまったく違った言い方で表現する。（要求定義工学プラクティスガイド）
  
• 組織のすべての人々が共通の目標を持つ、あるいは彼らの最も関心を寄せる目標は公認されたビジネス目標である、と決めつけてはならない。個人的な目標の発見に努めなければならない。（要求定義工学プラクティスガイド）
  
• 発進会議で少々時間を割いて目的について全員のコンセンサスを得、それを明確に、曖昧さのない、しかも測定可能な形で書きとめておくということは、その後のプロジェクトにとって極めて重要なことである。（要件プロセス完全修得法）
  
• よくありがちなのは、業務要求とユーザー要求の間に矛盾が発生することです。業務要求は、ユーザーには見えない組織戦略、あるいは予算の制約を反映するときがあります。（ソフトウェア要求）
  
• 異なるユーザークラスから矛盾する要求が出た場合は、だれかがそれを解決し、不整合を調停し、発生するスコープの問題の仲裁をしなければなりません。要求問題の意思決定者がだれであるかは、プロジェクトの最初に決定してください。（ソフトウェア要求）
  
• 製品の多様な顧客が何を作るべきかについて同意しない場合、だれかが結果に不満を抱くことになります。主要な顧客を決め、製品チャンピオン法を使って適切な顧客代表者を得て、その人に関与してもらってください。（ソフトウェア要求）
  
• よく直面する問題は誰が決定権者なのかよく分からずに、重要な決定権者をリストから外してしまうということである。結果としてシステムが実際に使用されだしてから、多数の変更要求が出されることになり、看過された人たちにとってシステムが逆効果になってしまうこともある。（要件プロセス完全修得法）
  
• すべての決定に対して顧客の代表6人全員の賛成を得なければならないのでは、効率的開発などありえない。（ラピッドデベロップメント）
  
• 超上流のフェーズで、システム化の方針・狙いを浸透させておかないと、各人が勝って気ままに要件を考えるため、仕様の統一に時間がかかり、最初の構築だけでなく、その後の維持・保守においても費用と時間が増大することになります。（経営者が参画する要求品質の確保）
  
• 完成品がどんな姿で何をするかについて、共通のビジョンにたどりつく事は非常に困難です。しかし、このビジョンの共有がなければ、結局は納品したものに必ず誰かが驚くことになります。（ソフトウェア開発の持つべき文化）
  
• 人の頑固さは正しい場合もあるが、間違えているのにただ頑固なだけの場合もある。間違っているのか、それとも他の人より2歩先を行っているのかを区別することは難しい。そのようなジレンマに対して何ができるか。さらなるアドバイスを得て、合理的な意思決定アプローチを取ろう。（アジャイルプロジェクト管理）

• 多くの場合、ソフトウェアプロジェクトの開始時点では分析者は解決すべきソフトウェアの問題に関してほとんど情報をもっていない。その状況に対処する唯一の方法はその問題に関連するすべての情報を深く掘り下げることであり、またある意味でその問題の所有者になることである。（要求定義工学入門）
  
• 最初のステップは、解決しようとしている問題の定義について合意を得ることです。（ソフトウェア要求管理）
  
• 要求フェーズの最終段階では分析者はその問題領域でのエキスパートになるといっても過言ではあるまい。（要求定義工学入門）
  
• しばしばわれわれは解の構築を急ぐあまり問題自身を意識の底へと追いやってしまう傾向がある。多くのソフトウェア開発文書を読んでみれば、そのなかに書かれている事柄がほとんど解に関することであり、問題に関する記述がほとんどないことに気が付くだろう。（ソフトウェア要求と仕様）
  
• プロジェクトが進むに従って、解決したい問題が非現実的であることが判明したり、問題を単純化しすぎていたり、期待したものとは別物であることが明らかになる。あるいは、最初から何も判っておらず、何らかの手段が必要と漠然と感じていた問題に対し、解決策を模索している可能性もある。（ソフトウェア開発55の真実と10のウソ）
  
• 「コスト削減」、「品質改善」などの抽象的な関心事の定義は容易であるが、それが組織に対して正確には何を意味するかを規定することは難しい。実際は、上級マネジメントの時間が非常に限定されていて彼らと十分に議論できない場合はさらに状況は悪くなる。また、上級マネジメントはシステムに対して非現実的な期待を持ちがちであり、したがって何が現実的に可能か判断し、彼らの関心事を定義するために協働しなければならない。（要求定義工学プラクティスガイド）
  
• ニーズやWantsの分解が十分でないと設計段階になって開発規模が膨らみ、それが以降の開発に問題を起こす原因になります。SEの経験則として2-4-2-3の法則というものがあります。要求の全容が見えない中での見積もり規模を2とすると、設計段階で明らかになるに従って倍になり、開発時にそれを当初の規模に抑え込もうと努力しますが、結局最後は3で終わるというものです。（経営者が参画する要求品質の確保）
  
• あなたは、次のような経験を持っているだろう。教室で先生が質問を始めたとき、それが終わらないうちに、生半可な答の手がたくさん挙がる。数多くのプログラム・システムもこのようにして作られている。問題点が述べられていないのに、それに答えるべくプログラムは着々と進められている。（プログラミング・プロジェクトの管理）
  
• 彼らは解決すべき問題とその問題を解決する特定の手法の違いを明確にしません。つまり、本当の問題（みんなが紙の無駄遣いをする）を表現することなく、印刷時のプレビュー機能といった、自らの目に付いたものを要求するわけです。しかし、本当の問題をプロジェクトチームが理解できれば、要求された機能よりも安価で優れた解決策を数多く見つけ出せる可能性があるのです。（アート・オブ・プロジェクトマネジメント）

• 要求や設計の詳細は変わりやすくあいまいな場合もあるが、もっとも重要なビジネス目標や製品ビジョンは明確でなければならない。（アジャイルプロジェクトマネジメント）
  
• 原則がないと、プラクティスを「どのように」実践すべきかがわからない。たとえば、「シンプルにする」という原則がなければ、どのようなプラクティスであっても、過剰に形式的にあるいは儀式的に行うことになるだろう。（アジャイルプロジェクトマネジメント）
  
• 人は「目的」が気になるようにできており、それを示す証拠は大量にある。また、「目的」がないと苦しむという証拠も多くある。（リーンソフトウェア開発）
  
• 要件分析の担当者やユーザーが業務内容や提案システムについて検討をして行くうちに、システムの目的が忘れられてしまうということは常に起こり得る。（要件プロセス完全修得法）
  
• システムにおけるコンセプトの完全性こそが使いやすさを決定するものである。システムの基本的コンセプトと一致しないなら、優れた機能であれアイデアであれ、除外しておくのが一番だ。（人月の神話）

• プロジェクトを計画してこのビジョン／スコープ記述書を記述するときは、ステークホルダーが立てたすべての仮定を記録してください。あるグループが持つ仮定が他グループには共有されていないことは、よくあります。（ソフトウェア要求）
  
• 要求の導出プロセスにおいて、そのような環境とそれがシステムの有効存続期間中にどのように変わる可能性があるかを定義する必要がある。（要求定義工学プラクティスガイド）
  
• 多くのシステムの導入環境の問題は、他の導入システムとの予期しない相互作用から生じる。もし事前に環境を理解し、定義しておくならば、この種の問題のあるものは予期でき回避できる。（要求定義工学プラクティスガイド）
  
• あなたがPMなのであれば、こういった思い込みに陥ってはいけません。こまめに「なぜこれが必要なのか？」「これはどういった問題を解決するのか？」「これは誰の要求なのか？」といった疑問を持つことで、前提に光を当ててください。（アート・オブ・プロジェクトマネジメント）

• 古いことわざにあるように、「手持ちの道具が金づちだけなら、問題はすべて釘のように見える」ものです。不要な実装上の制約が知らず知らずのうちに要求に紛れ込まないように注意しなければなりません。（ソフトウェア要求管理）
  
• 制約は、システム全体に適用されるグローバルな要件で、できれば要件の収集を始める以前に定義されていることが望ましい。たとえばシステムの目的は制約であり、個々の要件はその目的に貢献するものでなければならない。（要件プロセス完全修得法）
  
• 要件がすべて出尽くさないうちに解決策がデザインされているというのは確かに遺憾なことではあるが、そうする確かな理由（販売戦略、文化的背景、期待値などによるものや、管理上、政治上、財政上等の理由によるもの）があって、一つのデザイン解決法しか受け入れられないというケースはあり得るのである。このような場合、それは仕様の一部として取り込んでおく必要がある。（要件プロセス完全修得法）
  
• 領域的制約はシステム要求を生成し、他の要求を制限する。もし領域に対する考慮を欠くならば、その要求の実施において法的、組織的または物理的な障害が生じる可能性がある。実際、多くのシステムが実世界の制約を考慮しなかったために失敗している。（要求定義工学プラクティスガイド）

• プログラミングをする者はだれでも、例外がコーディングの作業工数の大半を使うことが多いのを知っています。完成品の欠陥の多くは、例外処理（または例外処理の抜け！）の中にあります。要求引き出し中に例外条件を明記することは堅牢なソフトウェア製品を作るひとつの方法です。（ソフトウェア要求）
  
• ‘What if’シナリオを作成して、例外をすべて見つけ出すようにする。この‘What if’という呼び名は、‘もし何かがうまく行かなかったらどうなるか？’という質問に由来するものである。（要件プロセス完全修得法）

• たいていの場合、顧客は品質に対する期待を明確に示したりはしません。（ソフトウェア要求）
  
• 品質目標が検証可能でなければ、達成したかどうか判定できません。必要に応じて、それぞれの属性と目標の測定尺度、単位、最小値と最大値を示してください。（ソフトウェア要求）
  
• もし故障が発生したらその影響はどのくらいに及ぶのか、そして信頼性を最大化する費用は正当と認められるのかどうかに基づいて、定量的な信頼性要求を規定してください。（ソフトウェア要求）
  
• しかし実際の性能要求は、ワープロのスペルチェック機能か、レーダー誘導システムのミサイルかによって異なります。性能要求はまた、たとえば緊急電話システムが通話要求であふれているときのような過負荷状況でシステム性能をどう低下させていくのかを扱わなければなりません。（ソフトウェア要求）
  
• 非機能要件は機能要件から明らかにされることが多い。（要件プロセス完全修得法）
  
• ユーザーとのインタビューに臨むときには非機能要件のチェックリストを持っていることは必ず役に立つ。（要件プロセス完全修得法）
  
• 機能要件が十分に満たされていると、潜在的な顧客がシステムを買うかどうかを決めるのは非機能的な質になってくる。（要件プロセス完全修得法）
  
• どんなプロジェクトでも、開始時点で品質特性に順序付けをするのは非常に重要だ。（ソフトウェア開発55の真実と10のウソ）
  
• ゆとりがなければ、品質向上プログラムなど悪い冗談だ。予想よりはるかに時間のかかる仕事に対応する時間や人手がなければ、遅延の代償として品質を落とすことになる。（ゆとりの法則）
  
• ユーザーは、品質ほど重要なものはないと言ったり、品質の悪さに文句をつけたりするが、品質に金を払う段になると、品質に対して本当はどう考えているかはっきりする。（ピープルウェア）

• また多くの著者が、仕様書には完全性、正確性、非曖昧性、理解の容易性、変更の容易性、一貫性といった特性が必要であることを主張してきているが、これらの品質の多くは達成が難しい。たとえば仕様を検査することができる「モデル」は存在しないため完全性を検査することは非常に難しいのである。（要求定義工学入門）
  
• インスペクションは、明確に定義された多段階のプロセスです。訓練された参加者からなる小さいチームによって、参加者は作業成果物に欠陥と改善の余地がないかどうかを注意深く調べます。（ソフトウェア要求）
  
• インスペクションチームを圧倒しないように、完成された要求記述書を調べるのではなく、要求開発を通してインクリメンタルにレビューを実行してください。綿密に調べる必要のあるリスクの高い分野を明らかにし、リスクの少ないものには非公式のレビューを使ってください。（ソフトウェア要求）
  
• それぞれのインスペクタがどの立場（たとえば顧客、開発者、テスト担当者など）を代表しているか確認する。（ソフトウェア要求）
  
• 「今のシステムと同じでよい」という要件定義はトラブルの元です。「同じ」という言い方が正しく伝わるのは、具体的なプログラム、コード体系、テーブルなどそのとき存在する個別の形を持ったものについてです。実現機能レベルで同じという言葉を乱発しないようにしたいものです。「今と同じ」でも要件定義は必要です。そもそも同じでよいなら再構築する必要はありません。よくないから再構築するというところから発想したいものです。（経営者が参画する要求品質の確保）
  
• 完全なプログラム検証を行ってもプログラムが仕様書と合っていることを立証するだけだ。ソフトウェア開発作業でもっとも困難なことは、完全で一貫した仕様書に到達することであり、そして、プログラム構築の本質の多くの部分は、実際には仕様書のデバッグなのである。（人月の神話）
  
• 要求の確認における主要な問題は、その正しさを確認するための対象が何も存在しないことである。設計やプログラムは仕様書に対して確認される。しかし、要求仕様書が正しいことを証拠立てる方法はない。（要求定義工学プラクティスガイド）
  
• 確認プロセスにおいてユーザマニュアルを作ることは、要求の詳細な分析を強いることになり、システムの実際的な利用にかかわる問題を明らかにすることに役立つ。（要求定義工学プラクティスガイド）

• 要件プロセス全体の目的は開発プロセスにおけるあいまいさを減らすことだ。だから、どんな要件についても、最も基本的な試験はそのあいまいさを測定することである。（要求仕様の探検学）
  
• あいまいさを探し出す一つの方法は、異なった観点の代表者に、公式の要求のインスペクションをしてもらうことです。（ソフトウェア要求）
  
• 細かい点まではっきりさせていく作業は、長々と時間がかかる面倒な作業です。そのため、要求を大雑把であいまいなままにしておきたい誘惑に駆られます。しかし、開発中のどこかのポイントで誰かが、あいまいさと不正確さを解決しなければなりません。（ソフトウェア要求）
  
• 目的には必ず利点と測定尺度を与えるという原則を守ることは、曖昧だったり間違って定義されて目的が仕様の中にまぎれこむことを防ぐ重要な手段なのである。（要件プロセス完全修得法）
  
• そして、要件のあらゆる言葉にこだわって、ユーザーの貴重な時間を無駄にするようなことがあってはならない。あらゆることは曖昧になり得る可能性を持っているのである。キーとなるのは、どんな場合に曖昧さのリスクを取るべきなのかをはっきりと認識することであり、文脈を明確にすることによってそうしたリスクを絶えず最小限に抑えるということである。（要件プロセス完全修得法）
  
• 定量化という行為によって、要件は最初は的確に理解されていなかったことが明らかにされるということはしばしば起こる。（要件プロセス完全修得法）
  
• あいまいさとは、確かでないことです。またはあやふやなことです。もう少しいうと、定性的な情報、相対的な情報です。あいまいな単語とは、主に、形容詞や形容的な名詞、まさにあいまいな単語、よくわからない外来語、否定形で構成されます。（よくわかる最新要求定義の基本と仕組み）
  
• この仕様書はなにも明確にしていない。300ページのあいまいなほのめかしだけだ。（デッドライン）
  
• 人々は仕様書が不明確だとこぼす。しかし、どの関係者にとってもあきらかに受け入れられないものではないという利点がある。プロジェクトは、内部設計とインプリメンテーションへ進む。隠された問題はしばらくは鳴りをひそめているが、永久にそのままということはない。製品の仕様書をあいまいに作ることはできるが、製品をあいまいに作ることはできない。（熊とワルツを）

• 実際に、要求を後で検査する際、それらが達成されたかどうかを判断できるように要求を定義する必要があるということです。（ソフトウェア要求管理）
  
• それぞれの要求を、許容可能な費用と、稼働環境で可能な性能で実装できる実現可能性を評価してください。また、それぞれの要求に関連するリスクを理解してください。リスクには、他の要求との矛盾、外部要素への依存、技術的な障害などがあります。（ソフトウェア要求）
  
• レビューミーティングの席上、出席している誰もがテスト担当者に向かって、「この要求が達成されたことを検証するテストスクリプトを作成する自信がありますか」と尋ねる場面がよくあります。（ソフトウェア要求管理）
  
• 検証を実施するにあたって気をつけなければならないことは、「何もかも検証」しようとして、あまり意味のないことに時間をかけすぎないようにすることです。（ソフトウェア要求管理）
  
• 実際、多大な時間と労力をかけて、顧客のニーズを収集・理解し、システムが要求をすべて正しく満たすことを（正当性確認テストによって）明らかにした上で、実装作業を行い、ようやく最終製品を納入したというのに、希望していたものとは違うと顧客から言われてしまうことがよくあります。（ソフトウェア要求管理）
  
• 受け入れテストでは「顧客が本当に望んでいるとおりに製品が機能する」という保証を得るために、最終的な正当性確認テストに顧客を参加させます。（ソフトウェア要求管理）
  
• 特に、テストシナリオを書くことは、要求をより深く理解していなければできませんし、またテストシナリオを書くためには、要求定義に漏れやあいまいさが残っていたのでは、難しいでしょう。（よくわかる最新要求定義の基本と仕組み）
  
• すべての要素を同じ詳細レベルで調べる必要はありません。たとえば、プロジェクトの周辺に位置する重要性の低い要素に対しては、インスペクションすなわち単純なシステムテストで十分かもしれません。その反対に、プロジェクトの中核を占めるようなきわめて重要な要素には、広範なホワイトボックステストが必要になる可能性があります。（ソフトウェア要求管理）
  
• 要求の一部が安定したらすぐにテストケースを開発し始めると、修正がまだ安価なうちに問題が見つかります。（ソフトウェア要求）
  
• ユーザーに受け入れテストを考えてもらうのは、効果的な要求開発戦略です。（ソフトウェア要求）
  
• もし、要求に対してのテストケースを作成することが難しいようであれば、そこには要求の問題が存在することを意味している。（要求定義工学プラクティスガイド）
  
• 要求に対してテストケースを提案することの目的は、システムではなく要求を確認するためである。（要求定義工学プラクティスガイド）

• アナリストはそれぞれの要件に適合基準と称する達成目標を設定することになる。この適合基準が要件の測定尺度となるのである。その目的は、要件を定量的に規定し、実装が要件を満たしているか否かをテスト担当者が正確に判断できるようにするということである。（要件プロセス完全修得法）
  
• 各要件に適合基準があるということは必須である。したがって、第一の問いは「その要件には正しく定義された適合基準があるか？」ということになる。それが無い要件、まだ相当程度の不確実性があるものとして、すべて不完全であると考えなければならない。（要件プロセス完全修得法）
  
• 問題解決のエキスパートは当該要求が解決しようとしている問題と矛盾しないかどうかのチェックに根拠を用いる。もし根拠の記述に代替案やそれに対する論証の記述を含んでいるならば、根拠の情報から将来の要求変更を予測できる。（要求定義工学プラクティスガイド）
  
• ある要求ソースは要求についての真の根拠を明らかにすることを好まないかもしれない。このことは、通常彼らがシステムに対して他に公開したくない個人的な目標を持っているような場合におきる。（要求定義工学プラクティスガイド）
  
• ほとんどのシステムは重要なプロセスをサポートすることを意図している。軍組織の指令と統制、パイロットのための航空管制システム、管理者に対する財務情報の提供等がその例である。もし要求がこのような重要プロセスにかかわっていないのであれば、その要求が本当に必要かどうかを考えた方がよい。（要求定義工学プラクティスガイド）
  
• 分析や折衝の結果、却下された要求について記録しておく。同時に要求が却下された理由についても記録する。（要求定義工学プラクティスガイド）
  
• このような切り捨ては痛ましいプロセスであり、リスクを伴うのも確かだ。しかし一度テーマが決まったら、それ以外の、テーマに貢献しない特質は犠牲にしなければならない。（ソフトウェア開発のダイナミズム）
  
• 台所の流し以外のあらゆるものを詰め込んだような製品、あるいは「全部やります」をうたい文句にした製品が無残にも失敗する事例が多い。（ソフトウェア開発のダイナミズム）

• 自分のプロジェクト上の目的と顧客のビジネス上の目的を満たせるよう、プロジェクト範囲について顧客と交渉する場面に立たされることもあるかもしれません。（ソフトウェア要求管理）
  
• 顧客と交渉して、合意線を確立する際のガイドラインは、「小さく約束して、大きな結果を提供する」ことです。そうすることにより、ソフトウェア開発における突発的な出来事が起こったり、予測していなかった技術的なリスクが発見されたり、途中で要求が変更されたり、利用するコンポーネントの入手が遅れたり、重要なチームメンバーが突然退職してしまったりしても、スケジュール内で調整することが可能になります。（ソフトウェア要求管理）
  
• 原則的な交渉では、行き詰まるとそれを打破するために使用できる客観的な基準を探し出す。どの基準が最適化をそのほかの人にも説明し、その際に彼らが提案する基準についても広い心で耳を傾けなければならない。最も重要なことは、プレッシャーに屈することなく、原則に従うことである。（ラピッドデベロップメント）
  
• 誰かがチームの先頭に立ち、どの制約／要求を無視したり、克服したり、曲げたり、誤魔化すことができるのか、あるいは文字通り従うべきなのかを決定する必要があるのです。（アート・オブ・プロジェクトマネジメント）
  
• 私たちのほとんどが制約境界線から少し距離をおいて仕事をする傾向があるのは、心理学的事実だ。（要求仕様の探検学）
  
• 期限に合わせることが制約か選好かを区別するのに失敗して、多くの開発プロジェクトがひどい害を受けている。（要求仕様の探検学）
  
• プロジェクトが成立しない可能性を指摘することは、制約をゆるめる交渉をする上で、きわめて大きな効果を持つが、決してこれを脅しとして使用してはならない。（要求仕様の探検学）
  
• 設計者が結果として生じるかもしれない争いをおそれて、明示的な決定をしぶることがある。しかし、設計の本質的な部分は、議論のある領域についての話し合い、交渉する能力である。（要求仕様の探検学）

• 後になってから発生する変更コストを削減するために、最初からすべてを正しく行うことに焦点を当ててシステムを作ると、設計はもろく、変更を受け入れにくくなりがちである。（リーンソフトウェア開発）
  
• 初期段階での仕様凍結は不可能であり、仕様変更は不可避であることが前提である。大切なのはそれをどうコントロールするかである。変化・変更を正面から受け止め、変更管理プロセスを確立し、変更管理スキルを活用しながら、仕様変更を積極的に捌いていくことが最も重要である。（先制型プロジェクト・マネジメント）
  
• システム要求の変更は避けられないものであり、また必要でさえあるという認識を持たなければなりません。ある程度の変更は発生しますので、この問題をきちんと意識し、対応する変更管理計画を用意しておきます。（ソフトウェア要求管理）
  
• 初期に顧客要件を集めて分析するだけでは不十分です。要件は開発サイクルの中で変わっていくものですから、それについていくことも必要なのです。（ソフトウェア開発の持つべき文化）
  
• 「お客様はいつも正しい」とか「完全な顧客満足を達しします」という哲学は抽象的には素晴らしいのですが、その代価を支払うのはあなたです。たとえ代価を無視しても、変更は無料ではないという事実は変わりません。（ソフトウェア要求）
  
• 組織的な問題と政治的な要因がシステムの要求に影響を及ぼすことがある。（要求定義工学プラクティスガイド）
  
• 要求の導出においては、要求のソースに影響を与えたり、真のシステム要求を覆い隠しかねない組織的・政治的な要因に敏感でなければならない。（要求定義工学プラクティスガイド）
  
• 要求変更は、要求定義工学プロセスのみならず、設計または開発プロセスにおける誤りや誤解からも生じる。また利害関係者がシステムに対しての理解を深めるにつれて新たな要求が生まれる。（要求定義工学プラクティスガイド）

• いくら善意からであっても、プログラマには、ユーザのためという名目で、新しい基本要件や要求項目をコードに直接取り入れる権限はありません。同様に、マーケティング担当者にもそのような権限は与えられていません。（ソフトウェア要求管理）
  
• 開発者は新しいテクノロジーに夢中になり、実際に必要かどうかは別として、他の製品で見つけた巧みな機能を実装するために、言語や環境の新しい機能を試してみたいと思うことがある。必要以上の機能の設計、実装、テスト、ドキュメント作成、およびサポートに要する作業量はスケジュールを長引かせることになる。（ラピッドデベロップメント）
  
• スケジュールのプレッシャーが厳しいマイクロソフト社でさえも、グループ内での事後分析では、だいたいチームメンバーが新機能の追加という誘惑に負けたときにスケジュール上の大きな問題が発生した、という苦情が寄せられていた。（ラピッドデベロップメント）

• ユーザーがその後に要求を変更したいと言い出したと仮定しよう。それを他の要求に影響を与えないで安全に変更ができるかどうかを知るには、最初の要求がどういう動機で出されたかを知る必要がある。（ソフトウェア開発２０１の鉄則）
  
• 開発中の製品の中を変更が広がっていくと、アーキテクチャがゆっくりと崩壊していくこともあります。コードパッチを繰り返すと、プログラムの理解と保守がだんだん難しくなります。（ソフトウェア要求）
  
• 変更依頼を却下するときでさえ、依頼を出して、評価して、却下すると決めるまでに必要なリソースを消費します。プロジェクトステークホルダーが開発期間中に変更を管理しない限り、最終的にどんな製品が顧客に引き渡されることになるか実際にはわからず、それは「期待のギャップ」につながっていくでしょう。（ソフトウェア要求）
  
• 問題は要求が変わることではなく、遅い時期の変更がすでに実行した仕事に大きな影響を及ぼすことです。（ソフトウェア要求）
  
• 要求（あるいは目的）は通常、業務の早期フェーズでは変化するが、変更が破壊をもたらす限界の時点がある。この時点を過ぎての変更は時間と費用を無駄にし、仕事を破壊してしまう。（ソフトウェアでビジネスに勝つ）
  
• やるべきことが明らかな問題でも、解決するソフトウェアを作るのは非常に難しいのに、仕様がころころ変わると、ソフトウェアを開発するのは不可能だ。（ソフトウェア開発55の真実と10のウソ）
  
• 変更の問題が起こったとき、最も重要なことが一つある。それはあなたと顧客が変更とは何かを十分に話し合わないかぎり、変更に要するコストについては解決の道がないだろうということだ。（プログラミング・プロジェクトの管理）

• 変更が文書化されなかったり、分析されずに行われたりするのは問題です。変更は、慎重に管理されなければ、悲惨な事態を招くことになります。要求に対して行った１つの変更が、関連する他の要求、設計、あるいは他のサブシステムに「波及効果」をもたらす可能性もあります。マーケティング担当者は、このような波及効果を理解していない場合が多く、システムに「ちょっとした簡単な」変更を加えるよう、直接、プログラマに依頼したりします。（ソフトウェア要求管理）
  
• 手続きにしたがって変更を管理することは、必ずしも要件を「確定する」ことではない。むしろ、プロジェクトの目的にかなう方法でソフトウェアに対する変更する処理するように努めることなのである。この方法の対極に位置するのが、まったく無計画に変更を処理するという方法である。このような方法では、目的を達成する能力は最終的に損なわれてしまう。（ソフトウェアプロジェクトサバイバルガイド）
  
• すべての変更が単一の伝達経路を通るようにして、それがシステムに及ぼす影響を決定し、システムにその変更を加えるかどうかを正式に決定する必要があります。（ソフトウェア要求管理）
  
• 変更を一つ一つ分析するだけでなく、変更会議はそれぞれを受け入れるか、または拒否するかしなければならない。変更会議の仕事のこの部分を「トリアージ」と呼んでいる組織もある。トリアージとは緊急医療から出た用語で、治療効果の最も高い人から先に治療を受けられるように、負傷者を分類する活動を指す。トリアージとは数少ない資源を割り当てている最中であり、全員には行きわたらないことを暗示している。（ラピッドデベロップメント）
  
• 納期が近づいてくるにつれて、どのバグならシステムに残してもよいか（修正の結果、システム全体が不安定になり、リリースが危うくなる可能性があるため）と、どのバグを取り除くかという決定を意識的に行わなければなりません。（ソフトウェア要求管理）
  
• だれかが新しい要求を求めたときはいつも、要求アナリストは「これはスコープ範囲内ですか？」と尋ねる必要があることを忘れないでください。（ソフトウェア要求）
  
• 提案されたユーザー要求が現在のプロジェクトスコープ範囲内にあるかどうか、ビジョン／スコープ記述書を使って確認してください。（ソフトウェア要求）
  
• 開発側も変更要求を安易に受けつけず、ルールに従う方針が必要になる。まずは、変更要求の提出、受付、承認の権限を明確に規定して、「顧客側の変更要求は顧客のプロジェクト･マネジャーが提出する」といった役割と責任を決定する。開発側では要求を受けつける権限をプロジェクト・マネジャーに一元化して設定し、「どの程度の変更がどのレベルで承認できるか」を顧客を含めたプロジェクト関係者間で協議して決定する。（先制型プロジェクト・マネジメント）
  
• 変更のたびに「ノー」と言うよりも、コストとスケジュールへの影響を話した方がよい。（ラピッドデベロップメント）

• 仕様通りなのか、仕様追加なのか、変更なのか、削除なのか、この線引きが明確になっていてこそ、変更管理について議論できる。（先制型プロジェクト・マネジメント）
  
• 要求を管理するには情報を追跡可能な形で維持しなければならない。「誰が要求を提案したか？」「なぜその要求が存在するか？」「他のどのような要求がそれに関連しているか？」「その要求はシステム設計、開発、ユーザ用文書などの他の情報とどのような関係にあるか？」などが分かれば、要求は追跡可能である。（要求定義工学プラクティスガイド）
  
• 要求定義の変更は容易ではない。作業を遂行する詳細な計画なしにそのような変更に対してコミットすることは常に失敗を招く。（ソフトウェアでビジネスに勝つ）

さて、要求定義では顧客との折衝は不可避です。本当に、心の底から顧客のプロジェクトの成功を考えて実施する提案や交渉であっても、なかなか受け入れてもらうのは困難です。顧客を理屈で納得させようとするのは絶対にご法度ですが、義理人情だけで解決する問題でもありません。裏にしっかりとした論理を持ちつつも、それを前面に押し出さずに顧客を説得していくスキルが必要なのです。トレードオフの考え方は、常に頭の中に入れておくべき「しっかりとした論理」の一つです。

• 望んだ機能をすべて実装するために、十分な時間とリソースを持つプロジェクトはほとんどありません。どの機能が本質的で、どの機能が役に立つか、そして、どの機能がなくても顧客が生きていけるかを決定することは、要求分析の重要な一部です。（ソフトウェア要求）
  
• こういった品質に対するそれぞれの立場からの要求が、互いに両立するとは限らないというジレンマが生ずる。ある人にとっての品質を最適にすることが、他の人にとっての品質を損なうことになるかもしれない。（ソフトウェア開発２０１の鉄則）
  
• 品質に対する要求が高いほど生産性は低くなり、また、品質に対する要求が低いほど生産性は高くなる。（ソフトウェア開発２０１の鉄則）
  
• 例えば、大規模のソフトウェア・システムを、極めて高い品質で作り上げることは可能なのだが、これにはコード１行につき１０００ドルといった巨額の費用がかかる。（ソフトウェア開発２０１の鉄則）
  
• 実現できる機能の総量は、利用可能な時間（固定）と利用可能な資源（これも固定）によって、明らかに制限されます。（ソフトウェア要求管理）
  
• ソフトウェアによっては、機能の豊富なアプリケーションを迅速に開発することが最優先課題となる場合があります。この場合、競合ソフトウェアでは利用することができない便利な機能を、ユーザに対して数多く提供することと引き替えに、プログラム中のいくつかのバグを我慢してもらうという考え方ができます。（ソフトウェア職人気質）
  
• ここ近年NASAは「より早く、よりうまく、より安く」というアプローチの実験を行っています。この実験は成功し、NASAは予定通り、予算通りに作業を進めています。しかしコスト削減の代償として、失敗のリスクはずっと大きくなってしまったのです。（ソフトウェア職人気質）
  
• 実現不可能な見積にあわせようと、近道をしたり、やるべきことを飛ばすため、スケジュール的に無理なプロジェクトが、技術的にも無理なプロジェクトになる。（ソフトウェア開発55の真実と10のウソ）
  
• 開発マネジャーの立場として、あなたはたった3つの要素を相手に仕事をする。それはリソース（人と金）、機能（製品とその品質）、そしてスケジュールである。この三角形の中があなたの働く場所なのだ。これら以外に相手にすべきものはいない。この三角形のどれか1つの辺を変えれば、残りの少なくとも1つの辺、しかしほとんどの場合2つの辺に影響が出る。（ソフトウェア開発のダイナミズム）
  
• 製品から機能を完全に削除することは、つまりその機能に関連する仕様作成、設計、テスト、ドキュメンテーションなどのすべての作業の必要をなくすことになるので、ソフトウェアスケジュールを短縮する最も強力な方法の一つとなる。（ラピッドデベロップメント）

開発側にもトレードオフの問題は存在します。

• エンドユーザーは、「悪い」と「安くて早い」のトレードオフを喜んで受け入れることがある。しかし、そんな譲歩は開発者にとっては苦痛である。（ピープルウェア）
  
• 自分の家を建てるときには予算や引越しの時期との折り合いをつけるのに、システム開発では自分の懐が痛まないので、どうしても、機能＞コスト・納期の関係になりがちです。（経営者が参画する要求品質の確保）

• 多くのプロジェクトでは「後ろからのスケジューリング」を実践しています。つまり、製品の引渡し日が決まった後で製品の要求が定義されます。多くの場合、期待される品質水準で必要とされる機能のすべてを入れると、開発者が指定された引渡し日に間に合わせるのは不可能であることがわかります。詳細な計画を立てて約束する前に、ソフトウェア要求を定義する方がずっと現実的です。（ソフトウェア要求）
  
• 現代のソフトウェア文化では、実現できそうもない工程を何とか間に合わせるあまり、プログラムの完全性や品質を犠牲にするのである。（ソフトウェア開発55の真実と10のウソ）
  
• 早くヤレとせかせれば、雑な仕事をするだけで、質の高い仕事はしない。（ピープルウェア）
  
• スケジュールに時間的余裕がないことが原因でうまくいかなかったソフトウェアプロジェクトは、それ以外の原因で失敗したプロジェクト全部を合わせたものよりも多い。（人月の神話）
  
• 経験から言って、誰もがスケジュールを強気、または非常に強気としているプロジェクトは、かならず失敗に終わる。（ゆとりの法則）
  
• スケジュールプレッシャーが極端なときにリリースされた製品は、プレッシャーが少ないときに開発されたものと比べて、約４倍の不良が発生すると報告されている。（ラピッドデベロップメント）
  
• 管理者が技術者に対して生産性を改善するようにと言えば、技術者は「急げ」と言われていると受け取る。残念ながらこのことは、レビューやインスペクションあるいは単体テストのような多くの品質管理ステップを省く結果を生む。（ソフトウェアでビジネスに勝つ）
  
• 大々的に報じられたソフトウェア・プロジェクトにおける失敗の多くは、開発者が可能であると考えた初回リリース日よりも要求されていた初回リリース日が野心的すぎたがために起こったことなのです。（ソフトウェア職人気質）
  
• あなたが非現実的なスケジュールに同意すれば、顧客は心の中に非現実的な期待を作り上げることになる。（ラピッドデベロップメント）

• 正確に分析した見積を作成したからといって、その見積りが受け入れられるとか、実際にそのプロジェクトがスケジューリングされる際に、効率的開発をサポートするようなやり方でスケジュールが立てられるという保証はどこにもない。（ラピッドデベロップメント）
  
• マーケティング管理者が「君達はビジネスを駄目にするつもりなのか？ライバルはもっと良い製品を今既にマーケットに出しているんだぞ。18ヶ月も待てない」と叫びだした。そこで私は、「ライバルは既にもっと良い製品を市場に出していると言うのですか？」と尋ねた。彼は「そうだ」と言い、私はさらに「いったいライバルはその製品をいつ開発し始めたと思いますか？それは先週ではないでしょう」と尋ねた。彼は答えられなかったので、私はおそらくライバルは1年か2年前にその商品の開発を始めたのではないかと話し、さらに私は尋ねた。「あなた方はなぜそのとき開発を始めなかったのですか？あなたがマーケットを予測できなかったのなら、開発で技術者たちがそれを取り戻すことはできません」（ソフトウェアでビジネスに勝つ）
  
• まちがったスケジュールは、労働者ではなく計画者の責任である。労働者がまったくの役立たずでも、その能力不足を慎重に考慮した計画を立てれば、ダメージを最小限に抑えられるはずである。（ゆとりの法則）
  
• 責任はスケジュールを達成できなかった人ではなく、スケジュールを立てた人が負うべきである。（ゆとりの法則）

• 適切な質問をして、必ず要求に優先順位を付けなさい。すべての要求が重要であると顧客に言わせてはいけません。納期までに、すべての要求を達成することはほとんど不可能なのですから。（ソフトウェア要求管理）
  
• 効果的な意思決定を行うためには、ステークホルダーはプロジェクトの優先順位に同意しなければなりません。（ソフトウェア要求）
  
• プロジェクトマネジャーは、スケジュール、予算、要員、品質目標などの制約に対して要望されたプロジェクトスコープのバランスをとらなければなりません。これを達成する一つの方法は、新しく不可欠な要求を受け入れたとき、あるいは他のプロジェクト条件が変わったときには、優先順位が低い要求を落とす、あるいは後のリリースに延期することです。（ソフトウェア要求）
  
• 優先順位の確定は、プロジェクトの初期にプロジェクトの成功を達成するための選択肢が多いうちに行い、定期的に再確認してください（ソフトウェア要求）
  
• 優先順位を評価する一つの方法は、重要性と緊急度の二つを検討することです。（ソフトウェア要求）
  
• 多視点から要求を収集することは、要求の優先度づけに有効な方法である。すべての視点で提言されるような要求はおそらく高い優先度を持つものである。（要求定義工学プラクティスガイド）
  
• 多くの場合、個々の利害関係者は同じ要求に対して異なった優先度をつける。（要求定義工学プラクティスガイド）
  
• 優先度づけにおいて生じる重大な問題は、ある利害関係者からの非現実的な優先度の指定である。彼らは単純にすべての要求が「必須」であると言い、優先度づけを拒否するかもしれない。もしその利害関係者が顧客あるいは権限を持つ上級マネジメントであった場合には特に困難な問題が生じる。（要求定義工学プラクティスガイド）
  
• 部分最適を排除し全体最適を目指したバランスの良いシステムの実現のためには、システムの真の目的を基礎にした機能間の優先順位が正しく把握されていなければならない。（曖昧性とのたたかい）
  
• できるだけすべての要求を引き出して記述することは重要ですが、各要求の優先順位を見極めておくことも重要です。相対的な順位を付けておくことで、要求の権限を持っている担当者とエンジニアリングの権限を持っている担当者の間での交渉がずっと容易になります。（アート・オブ・プロジェクトマネジメント）

• 多くの要件仕様書は「書きっ放し」になりがちである。プロジェクト計画に要件仕様書を作成するようにという指示があるので、その指示にしたがって要件開発時に書かれはするが、その後要件に変更があってもこの仕様書が更新されることはなく、多くの場合、書かれた後には使用されることもない。（ソフトウェアプロジェクトサバイバルガイド）
  
• ベンダ企業を含むステークホルダ間の合意のベースとなるのは常に要件定義書です。設計工程以降よりも、むしろ、要件定義の合意形成時点での吟味が重要です。「決定先送り型」の要件定義では、あいまいな海図に基づく航海のようなもので、早晩プロジェクトが破綻します。（経営者が参画する要求品質の確保）
  
• 要求定義工学プロセスの成功は多くの場合、非形式的で曖昧な個々の要求をすべての要求保持者に理解され同意されうる形式的な仕様に進展させる能力に依存している。（要求定義工学入門）
  
• ユーザーから出てきたすべての要求を、無理にユースケースにあてはめてはいけない。ユースケースは、ほとんどの機能要求を表すことができるが、すべてというわけではない。（ソフトウェア要求）
  
• もし、要求仕様書に誤りがあれば、見つけるのが後になればなるほどとんでもなく高くつく。（ソフトウェア開発２０１の鉄則）
  
• 表記法上のニュアンスに過敏になったときは、地図は実際の土地ではないことを思い出し、完全な翻訳などありえないと考える。（要求仕様の探検学）
  
• 文書は決定事項を他の人に伝えるものだ。マネジャーは、自分には常識であるような方針を、チームのメンバーの中にはまったく知らない者もいるのに気づいて、驚きの連続ということになる。（人月の神話）
  
• 依頼者は要求と仕様についての認識が薄いことが多く、「仕様書」には要求と仕様が混ざってしまうことが考えられます。（要求を仕様化する技術・表現する技術）
  
• ドキュメントを完全なものにするということで、新たな難題が持ち上がってきます。すなわち実装中に要件の変更や設計の変更が発生しても、ドキュメントの整合性を保ち続けなければならないのです。（ソフトウェア職人気質）

• 問題記述では、“小さい”とか“安い”とかいった比較語に気をつけること。（要求仕様の探検学）
  
• 要求に「および／または」は決して使用しないでください。これは読み手に解釈を委ねます。「〜でない限り」や「〜を除いて」といった語も、複数の要求を示しています。（ソフトウェア要求）
  
• すべての要件が指定された通りの意味で用語を用いているかどうかを検証することである。用語を定義するだけでは不十分である。（要件プロセス完全修得法）
  
• 技術的な文書では、常に同じ概念を参照するには同じ言葉を用いなければならない。（ソフトウェア開発２０１の鉄則）
  
• 問題記述は正確でなければならない。この比較的ささいな問題の記述の相違が問題のさまざまな見方を生み出し、それがまたさまざまな解に導く。現実の状況では、このような微妙な相違がプロジェクトの成否を分けるのである。（要求仕様の探検学）
  
• 仮定や期待は必ず全部記述するようにしてください。（ソフトウェア要求）
  
• もし文書を何人かの人々によって記述するのであれば、同じ用語を文書中で異なって用いている可能性が高い。用語集はこの問題を回避するための共通マニュアルとして使用することができる。（要求定義工学プラクティスガイド）
  
• システムの利害関係者は要求定義文書の中では常に明示的に特定される必要があり、特定の要求とそれを提案した利害関係者とを結びつける適切な情報を保持する必要がある。（要求定義工学プラクティスガイド）
  
• 要求の根拠は、なぜ要求が特定されたのかの理由を要約する情報である。それはシステムで解決しようとしている問題についての要求を正当化するものである。（要求定義工学プラクティスガイド）
  
• 自然言語で書かれた要求が確実に読解されるよう、すべての要求の記述に対して構造を定義する必要がある。構造にはその要求に関連づけさせたい情報を注記する欄が組み込まれていなければならない。たとえば、要求が機能要求であれば、インプット、処理、アウトプットを要求の中で記述しなければならない。（要求定義工学プラクティスガイド）
  
• 理想的には、文書化のアクティビティをできるだけ遅く、少なくすべきである。早くから余分な文書化を行いすぎると、ソフトウェアの納品が遅れる。（アジャイルソフトウェア開発）
  
• 大切なことは、ドキュメントを受け取る人にとって、そのドキュメントが特定の目的に役立つかどうかである。（アジャイルソフトウェア開発）
  
• プロジェクトの「文書化」に言及する際は、文書化される知識がそこで知られていることのほんの一部に過ぎないことを意識しよう。（アジャイルソフトウェア開発）
  
• 必要な文書化をする、でも作り過ぎてはいけない。（アジャイルプロジェクトマネジメント）

• 「どこまで具体的に記述するか」という質問に対する答えは、「アプリケーションの種類、実装担当者が適切な判断を行えるかどうか、あるいは、あいまいな点があれば、必ず質問してくるかどうか次第」ということになります。（ソフトウェア要求管理）
  
• 要求の記述者は、多くの場合、適切なレベルの粒度を見つけるのに苦心します。このための指針は、「個別にテストできる要求」を書くということです。（ソフトウェア要求）
  
• 要求定義文書には常に、なぜシステムが必要とされ、それがそのシステムを導入する組織の全体的なビジネス目的にどのように寄与するかについての記述がなければならない。（要求定義工学プラクティスガイド）
  
• システムについてのビジネスケースは、なぜ特定の要求が含まれているかについて読者の理解を助けるものである。このことは、要求の変更が提案された場合に特に有効である。そこではなぜ特定の要求を包含することになったのかの元々の理由は既に忘れ去られている可能性があり、そのようなときでも読者はビジネスケースを通じて当初の要求の根拠について推測することができる。（要求定義工学プラクティスガイド）
  
• 要件定義書を作成する上で、極めて重要なことは、要件の技術面、運用面、コスト面、スケジュール面での前提、制約、満たせない要件（除外事項）を明記することである。これらが徹底されていると、後で発生する変更管理に関する水掛け論をある程度抑えることができる。前提、制約、除外事項の記述の仕方により、仕様変更のための追加コストの請求が可能かどうかが決まる。（先制型プロジェクト・マネジメント）

• 上級管理者が「スケジュールが長すぎる」という理由で勝手にその見積を却下するケースが想像以上に多い。（ソフトウェアの成功と失敗）
  
• 上級管理者には、常に問題を一本化し、一つの対策で一度に解決したいという悲しむべき願望がある。（ソフトウェアの成功と失敗）
  
• 製造問題において見られる問題の2/3は管理に帰すものであり、1/3のみが作業員に帰すものである。（ソフトウェアの成功と失敗）
  
• 多くの組織的行為においては、悲劇の主たる原因はもっぱら経営者、管理者、あるいは指揮官の意思決定による。これは軍の問題を見ても明らかで、多くの戦闘は勝者側の優れた戦略というよりは、むしろ敗者側指揮官の無能、または判断ミスによって勝敗が決している。軍隊自体の戦闘力の弱さが敗因となるような戦いは比較的少ない。（ソフトウェアの成功と失敗）
  
• 能力のある技術者ほどそのプロジェクトが管理者の不適切な意思決定により危機に陥りつつあることを知っている。（ソフトウェアの成功と失敗）
  
• 管理部門は、無邪気に新しいツールや方法論がスケジュールやコストを改善すると期待しているのに、実際は非常に急勾配の学習曲線が要求され、選択した技術がかえって開発を遅らせてしまうことになる。（ソフトウェアの成功と失敗）

「要求定義のチェックポイント４２７」（翔泳社）

「要求定義のエクササイズ１３６」（翔泳社）

２冊目の著書は、プロジェクトでよく発生しがちな要求定義の問題について、その予防法と対処法を書いたものです。病気は治療より予防と言いますが、これはまさにプロジェクトにもそのまま当てはまる言葉です。 コンセプトは１冊目と同じです。抽象的で一般化された理論は極力廃し、実際に取るべき具体的なアクションを記述することだけにこだわりました。事実、現場では理屈をこねまわす前に、「気分が乗らなくても、まずはカラダを持っていく」ような強い意志の力と行動力が求められます。そこで、机上の合理性でばかり問題を解決しようとする腰が重い人のために（？）、「理屈で考えるだけでは駄目なんだよ」という意味をこめて、ソフトウェア工学を「ちょっとだけ」苛めています。 テーマが問題の予防や対応策を含むだけに、内容はプロジェクトマネジメントを意識せざるを得ないものになっています。したがってマネジメント権限を有しない、純粋な要求定義の担当者には難しいアドバイスもあるかもしれませんが、プロマネ予備軍にはちょうど良い入門書の代わりになるのではないかと思います。

「要求定義実践のポイント」（秀和システム）

３冊目の現場志向の要求定義本です。これまでの著書からは意図的に省略していましたが、ＲＦＰや要求仕様書などのドキュメントについても付録的に記述しています。しかし基本はもちろん非形式的な要求定義の現場であり、具体的なアクションです。 内容は前著同様、プロジェクトマネジメント寄りになっており、人間系の記述に力を入れています。ただし本のコンセプトは前の２冊ほど強烈に意識されたものではなく、マイルドな基調になっています。したがって私個人の「思い」は若干薄められていますが、その分「万人向け」になっているかもしれません。 決して手取り足取りの初心者向けの内容というわけではありませんが、図版も多く、理解しやすい内容に仕上がっているのではないかと思います。