要件定義(RDRA)入門セミナー in 東京 |
| アンケート回収数:9 公開可能コメント数:9
|
| ●もうウォーターフォールには戻れません・・・ 大変有意義なセミナーでした。ありがとうございました。 |
| ●実習の部分がたくさんあったため、あまり理解できずにただ転記しているだけという状態になってしまった。
|
| ●実習でダイアグラムに記述していくことでより具体的に実務に導入するイメージが出来ました。 普段アクターと関わる部分しか扱っていないため、プロトコル部分は少し現実感が持ちにくかったです。 全体の粒度をそろえることに留意する、という考え方が新鮮でした。 実務でつい陥りがちな「進行に比例して詳細になっていってまとまらない」理由がわかりました。 |
| ●各モデルを作成する意図やそのモデルの関係性を理解することが出来ました。 また、各モデルはひとつ前のモデルに依存し、最終的には“システムの価値”が大事であることが理解でき、要件定義をする上で、軌道修正の方法が解りました。本日はありがとうございました。 |
| ●管理が難しそうだと感じました。要件定義で定義する範囲が明確になって参考になりました。
各図をつなげる時に上手くつながるかなと思いました。 チーム内での共通語としてのモデル図はメンバーが読み方、書き方を理解すれば有用なものになると思いました。 |
| ●レビュー時にダイアグラムに配置しながら確認するというのは感心した。
あと、計画についてはタイムボックス方式を理解していない人が多い。(ガンチャート、WBSで線を引かないと気に入らない人) でもやってますが。 進捗の報告が難しい(神崎さんの言う、濃度・粒度・洗練度をどう伝えるか) |
| ●複数のダイアグラムの関係により、要件がシステマティックに整理されていくのはよい手法だと思った。 →従来だと「えいや」で途中が飛躍してしまうことが多いので。 どのようなダイアグラムが必要(使える)か?は理解できたが、どうやって図を作っていくかはまだ理解しきれていない。これはケースをこなしていくことが必要だと思う。(実践セミナー?) 成果物をだんだん洗練させていくイメージは昔からあったが、それぞれのマイルストーンでの具体的な達成基準を例示して頂いたのは解り易く、参考になった。 |
| ●とても現実的な方法だと思いました。曖昧でターゲットが定まっていない状態でstartする要件定義という工程を歪みなく自然に進められるのではないでしょうか?
タイムボックスが良かったです。上流工程でスケジュール法に切り込んでいる方法は他に無いのでは? |
| ●「要件定義マニュアル」の本を使用し、実際にRDRAで要件定義を行っているのですが、曖昧な部分(理解できていない)に関して知識が深まりました。実践セミナーにも参加したいのですが、予算的なところと相談になりそうです。 本日はありがとうございました。 |