要求定義の方法論を知る【前編】：DOA型要件定義の実際
日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（データ中心型アプローチ）型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし，DOAはあらゆるプロジェクトに応用できる極めて基本的なアプローチである。基本をしっかりと押さえて欲しい。 「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。 本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範
読み手を混乱させる元凶は情報の不足，余計な内容，表現のミス
意図が伝わらない設計書には，情報の不足，余計な内容，表現のミスがある。こうした問題を解決するための現場の対策を紹介する。取り組みはそれぞれ異なる。だが，意図を伝えたいという思いは共通だ。 「情報の不足，余計な内容，表現のミス。意図が伝わらない設計書によくあるのはこの三つだ」。こう指摘するのは，日立製作所の石川貞裕氏（プロジェクトマネジメント統括推進本部 担当本部長）。石川氏は「現場ではこうした点を改善するための対策が必要だ」と強調する。では，設計書には具体的にどのような不備がよく見られるのか。最初にこの点を明らかにしておこう。 まず情報が不足している設計書。図1左の画面レイアウトがその例だ。画面の構造を視覚的に示し，操作したときの動きを個条書きで示している点はよい。だが，型やけた数といった画面項目に関する重要な情報がない。富士通の廣瀬守克氏（SI生産革新統括部 担当部長）は「特に画面を操作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
