あらすじ
システム開発の要件定義をすばやく的確に作成するための方法をわかりやすく解説したノウハウ書です。要件定義を作ることになったが「要件定義の進め方がわからない」「何を定義していいかわからない」「議論ばかりで中身の検討ができない」などでお悩みではありませんか？ 本書は、前著『顧客の要求を確実に仕様にできる 要件定義マニュアル』の増補改訂新版であり、RDRA（リレーションシップ駆動要件分析）という手法をブラッシュアップし、要件定義書の作成手法をさらに具体的にわかりやすく解説しています。要件分析フレームワーク、外部システムとのやりとりだけでなくユーザーインターフェースを含めた入出力、顧客の要望を正確に把握するノウハウなどが満載です。
...続きを読む感情タグBEST3
Posted by ブクログ
モデル駆動開発と言う言葉を良く聞くが、実際のところ、UMLをこねくり回しているようにしか見えなかった。そういった中で、RDRAと称するこの手法は、実際の要件定義プロセスを良く考え抜いて作られていると感じた。やっぱり、図解が人間一番わかりやすいし、どういうプロセスを踏めば良いかも詳説されていて参考になる。まだマイナーな手法とは思うが、いずれ主流になれる素質を持っている手法と思う。
Posted by ブクログ
【要点の整理】
・ステークホルダー間の合意を得ながら、システムのあるべき姿や要件定義工程を主体的にリードしていく
・テキストだけでなくモデル（UML）ベースで可視化し、モデルを軸としたコミュニケーションで合意をとっていく
・システム価値、システム外部環境、システム境界、システム機能の四階層に分け、各々でモデル化する
・複合モデルに落とし込み、各階層の整合性を検証し、要件のヌケモレや矛盾などがないように要件を組み立てていく
・アジャイル的な進め方（タイムスケジュールの組み方）で、スプリントを繰り返して要件をブラッシュアップしていく
・実務者-管理者などの立場の違うステークホルダーごとに、共有する情報の抽象度/具体度を変え、「状態」「成果物」「タスク」と分けて計画を立てていく
【本質的な部分だと感じたところ】
・RDRA導入はコミュニケーションプロセスの改革であり、「要件をどう分かりやすく可視化するか」「クライアントとの認識のずれを是正するか」ということ
・抽象↔具体を反復する思考プロセスが大事、システム価値を具体化したものがシステム機能であり、また逆も然り。各階層ごとで抽象度が異なることを意識する
【感想】
・RDRAの考え方については非常にわかりやすかった
・要件定義プロセスの全体像を把握するのによかった。細かい部分は他の書籍などで深掘ることは必要だと思うが、全体の流れのヌケモレを認識できる点ではよい
・RDRAのプロセスをすべて当てはめられるケースはあまりないと思うが、要所要所で抜き出して自分のプロジェクトに活かせるとは感じたので高評価
・モデリングのシナリオ設定がイマイチで、具体例はわかりづらかった。「RDRAのモデルチェックシステム」を例にしていたが、この題材自体があまりピンとこなかったので、これをもとにした要件定義プロセスもわかりづらく、こじつけのように感じてしまった
・構成として、章をまたいでも説明の具体度があまり変わっていないところもあり、「なんかさっきとほとんど同じこと繰り返してない？」と感じるところもあった。また一般論的な話の部分もあり、紙面を埋めるための話なのかな、と思ってしまう部分もあった。もっとページ数減らした構成にできると思う
