ソフトウェア工学でまだうまく扱えていない要求獲得の本。要求仕様書作成に関わる人は一読すると、なにかつかめるものがあると思う。 [private]・要求を獲得出来ない人は、実際に要望を集めてから分類する。 ・獲得できる人は、モデルを作ってから収集する。 ・無地のノートに手書きしてみる。 ・用語の定義は品質につながる。 ・相手の視点でモノ見る。これはこういうことでしょうか？ ・表では抜ける。モデリングでフィルタリングできるようにする。 ・要望はシステムの機能ではなく、エンドユーザーから見たシステムの利用方法 ・要望を図で結び要望の矛盾を検出する。 ・プロジェクトマネジメントのWBS ・後ろからスケジュールを引く。 ・日常的な工夫が、大きなクリエイティビティにつながる。[/private]

上流工程でつまずいていたときに社内の書架で目にして、思わず手にとってしまいました（・＿・；） ・要求は確定している ・要求はすでに存在している 要求のモデリング手法に関する研究の多くが、こうしたことを前提にしているが、 現実の場面では、そんな前提が成り立っていることはまずあり得ない。 という著者の洞察から、 確定していない、ユーザー自身も明確には意識していない要求を、 システム開発者がどのように踏み込んでいくことで獲得し、モデリングしていけるかを平易な言葉で書いた本です。 ＜以下、参考になったところのメモ＞ ・要求を獲得する際には、要求を実現性／網羅性／無矛盾性の観点で検証の上、フィルタリングしていく必要がある。 　多くのプロジェクトで、要求は実現性の観点からしかフィルタリングされておらず、これがプロジェクトの失敗の原因となっている。 　例えば、要求同士が矛盾した状態で設計に入ると、その矛盾が設計の複雑さとなって表れる。 ・要求のフィルタリングをする際に、表を使うのはよくない。 　表だと、個々の要求を独立してしか取り扱えない。 　そのため、要求間の関連性という重要な部分を見逃してしまう。 ・要求のフィルタリングをうまくできるかどうかは、実は、要求の獲得の段階ですでに決まっている。 　要求を獲得する段階で、要求のカテゴリをきちんと設定しておくこと。 　このことで、網羅性の検証が可能になる。 　（逆に、これをやっていかないと、網羅性の検証ができない。ただ「なんとなく要求がたくさんでてきたから網羅されたかな」となってしまう。） ＜メモ終わり＞ 耳が痛すぎて芳一になりそうです＞＜。 プロジェクト始める前に読んでおきたかったです。