最初に要件をしっかりと定義できない場合が多い

投稿者

投稿内容

BRYAN: 会議室デビュー日: 2004/10/06; 投稿数: 4

投稿日時: 2004-10-08 00:35

「見切り発車はいけません」とは言いながらも、結局はいつも要件定義は曖昧なまま、PJはスタートし、ある程度プロトタイプが出来たところでユーザより仕様をヒヤリングして製品に組み込む繰り返しで開発がすすんでいます。
こういう場合は、「ある程度」の品質でプロトタイプは良いのだと思いますがその「按配」が上手く定義できなくて困っています。また「どうせ仕様も変わるだろ」との事から仕様書の記述が曖昧になり、悪循環になっています。
　最近はこのようなことの解決のためにRUP等の開発手法も導入しているベンダもあると聞いています。皆さんは、どのようにしてこのような悪循環を断ち切っていますか？

よっちゃん: 大ベテラン; 会議室デビュー日: 2004/02/15; 投稿数: 117; お住まい・勤務地: 千葉の片田舎

投稿日時: 2004-11-17 09:00

引用:
BRYANさんの書き込み (2004-10-08 00:35) より: 「見切り発車はいけません」とは言いながらも、結局はいつも要件定義は曖昧なまま、PJはスタートし、ある程度プロトタイプが出来たところでユーザより仕様をヒヤリングして製品に組み込む繰り返しで開発がすすんでいます。

悩ましいですね。
このプロトタイプ状態の曖昧さが何か、または
独断で設定内容を明確にしておかないと
後から大変ですね。

引用:

BRYANさんの書き込み (2004-10-08 00:35) より:
こういう場合は、「ある程度」の品質でプロトタイプは良いのだと思いますがその「按配」が上手く定義できなくて困っています。また「どうせ仕様も変わるだろ」との事から仕様書の記述が曖昧になり、悪循環になっています。
　最近はこのようなことの解決のためにRUP等の開発手法も導入しているベンダもあると聞いています。皆さんは、どのようにしてこのような悪循環を断ち切っていますか？

この曖昧状態は客先常駐であっても要求定義からですと
発生してると思います。
ただ、客先常駐だと、そこで疑問をすぐ聞けるため
傷が小さいうちに、手当が出来るから大して
問題にならないと思います。

この悪循環を断ち切るためには、ユーザの希望を含めた業務内容を
詳細に理解しており、更にその拡張方向も理解しており
且つその作り込みもバンバン出来ることが条件でしょう。

私は、相当難しいと思います。
ただ、ユーザの考え方との乖離を少なくする努力は必要であると
思ってます。

最初に要件をしっかりと定義できない場合が多い

スキルアップ／キャリアアップ（JOB@IT）