1,800円以上の注文で送料無料

成功する要求仕様、失敗する要求仕様 の商品レビュー

4

7件のお客様レビュー

  1. 5つ

    2

  2. 4つ

    4

  3. 3つ

    0

  4. 2つ

    1

  5. 1つ

    0

レビューを投稿

2021/01/24

要求マネジメントとは「トリアージ」をすること。優先順位をつけ、適切に妥協し、顧客の望むシステムを作り上げる ●感想  面白い本だった。やはり、本のタイトル・イシュー設定からかなり絞り込まれているだけははる。筆者はさすが大学教授というべきか、要件定義プロセスを抽象化し、読書に取り...

要求マネジメントとは「トリアージ」をすること。優先順位をつけ、適切に妥協し、顧客の望むシステムを作り上げる ●感想  面白い本だった。やはり、本のタイトル・イシュー設定からかなり絞り込まれているだけははる。筆者はさすが大学教授というべきか、要件定義プロセスを抽象化し、読書に取り扱いやすいフレームを提供してくれている。図表が何度も登場し、筆者の言いたいことが伝わりやすい。図表が分かりやすいため、結構軽快に読める。ただ、その図表にオリジナリティがあるので面白い。真似しやすくなる。要件定義プロセスにおける「要求抽出」はその後の設計・開発にかなり影響するため、SEとして、この本を読んでおいてよかった。本棚に保存しておきたい本。  本書にあった、納期を確率で示す「スケジュール対確率グラフ」というアイデアが面白い。これ、実際の開発プロジェクトに導入したいくらいだ。エクセルで、マクロを組んだら、いろいろ使いまわせそう。 ●本書を読みながら気になった記述・コト ☆要求は変化する。次々に新しい要求が発生する ※これが、システム開発の本質である ・開発側は、新規で上がってくる要求を適切にトリアージする必要がある。一番危ないのは、「要求を受け入れるが、スケジュール・予算は変わらない」という姿勢だ。これでは、確実にプロジェクトは破綻してしまう ・新規要求を受け入れることは、必ず予算・開発期間の増加をもたらす。それらのリスクを顧客が受容するかどうかを確認しよう ・開発側は、要求のトリアージを行う際に、絶対的な言い方を避けよう。「○○の機能を実装するとすれば、~までに、納品できる確率が80%から30%に下がります」というように言うしかない *まとまな開発工数を算出するのは難しい。一番現実的なのは、過去の同規模の開発の結果を参考にすることだ *要件定義から開発導入にかけて、一番時間・予算をかけるべきは要求理解 ・要求理解に時間、予算をかけたプロジェクトの方が、予算超過が少なかったという研究がある *全ての要求に答えることは諦める。全ての要求のうち、60%にまず顧客と合意が得られたら、要求文書を書き始めてよい ・すべての要求を知ることは決してできない ・早く設計に着手すれば、それだけ、新たな要求を発見しやすくなる *要求のエラーには大きく分けて3つのエラーがある ・認識のエラー...顧客と開発者間で、実装必要な機能の認識が異なっていた ・トリアージエラー ・仕様エラー *顧客との開発プロジェクトにおいては、用語集を作るべし ・プロジェクト上の問題は、単語の認識に齟齬があるところから来ることも多い *シーケンス図は、シナリオを表現するための良いツールだ ・モデルツールは、顧客との認識を合わせるのが目的。様々なモデルを多用するのは混乱を招くので注意 *「ちょうど十分な要求マネジメント」とは、トリアージが行われていることである ・逆に、意識的にトリアージを行っていないなら、要求マネジメントができていない。予算と開発スケジュール、必須機能要件を満たしているかの検証が行えていない。つまり、そのようなプロジェクトは失敗するだろう *要求間の関係を見極めよう ・要求には関係性がある。必須依存、作業依存、サブセット依存などがある

Posted byブクログ

2019/07/24

邦題より"Just enough requirements management"という原題のほうがわかりやすい。

Posted byブクログ

2018/10/23

ソフトウエアに対する要求仕様についてのみをここまで掘り下げた文献はおそらくないだろう。ソフト開発は、仕様のみで、天国か地獄かが決定されるほど単純ではないが、この著者の言う通りかなりの割合を決定してしまうことは否めない。初めてソフト開発リーダーを引き受ける前にこの本を読んでおけばあ...

ソフトウエアに対する要求仕様についてのみをここまで掘り下げた文献はおそらくないだろう。ソフト開発は、仕様のみで、天国か地獄かが決定されるほど単純ではないが、この著者の言う通りかなりの割合を決定してしまうことは否めない。初めてソフト開発リーダーを引き受ける前にこの本を読んでおけばあんなひどいこと?にはならなかったのに。だが、残念ならが、この本はその時には出版されておらず、どうしようもなかったのだが。将来、開発リーダーをする可能性がある人には、私と同じミスをふせぐために、必読の書といえる。

Posted byブクログ

2016/12/18

原題は"Just Enough Requirements Management"。要求の導き出し/トリアージ/仕様化/変更管理 という四つのカテゴリでまとめられている。仕様化に関しては自然言語を中心に必要に応じて必要なモデルを描くという現実路線で、参考になる点...

原題は"Just Enough Requirements Management"。要求の導き出し/トリアージ/仕様化/変更管理 という四つのカテゴリでまとめられている。仕様化に関しては自然言語を中心に必要に応じて必要なモデルを描くという現実路線で、参考になる点が多い。

Posted byブクログ

2015/05/22

要求トリアージの要求分類は参考になった。顧客が理解できる自然言語を推奨しているが、個人的には、複数視点のモデルで要求の漏れや妥当性を確認は必須だと思った。顧客にモデルを説明するかは別にして。

Posted byブクログ

2010/07/29

要求が変化したり、新たに湧き上がってきたりすることそのものを恐れてはいけないということですね。 問題とは「現実」ではなく「認識」であるっていうのは胸に止めておきたい。 ワインバーグあたりを読んでおかないとちょっと理解に苦しみそうな箇所もちらほらで、一回読んでOKってわけにはい...

要求が変化したり、新たに湧き上がってきたりすることそのものを恐れてはいけないということですね。 問題とは「現実」ではなく「認識」であるっていうのは胸に止めておきたい。 ワインバーグあたりを読んでおかないとちょっと理解に苦しみそうな箇所もちらほらで、一回読んでOKってわけにはいかなそう。

Posted byブクログ

2009/10/04

ちょっと期待はずれ。 最後の最後に「結局は、賢明な選択をする、という一言に尽きるのである」はガッカリ。

Posted byブクログ