「要求定義と要件定義の違い」
はじまり
はぁ…
・なんでシステム開発が失敗するんだろう…
・仕様の変更が多くて…
・言った言ってないのトラブルから避けたい…
・システム動かしてみても全然使えない…
原因
事業運用をオペレーションレベルに展開しないままに、システム開発をしてしまうところに原因があります。
入力画面や出力画面を決めても…
それを使って、いかに日々の仕事をこなすのか？
オペレーションレベルまで突き詰めた創りこみをしないで、専門家だから、プロだからと．．．
コンピュータの専門家に、業務運用の仕組みまで丸投げにしてしまうことが問題になります。
要求定義と要件定義の違いについて
・ビジネス
要求定義
・「〜したい」と利用者側の希望、ビジネスで何が必要なのかなどを記載したもの
・システム
要件定義
・「〜が必要」システムの仕様書、システムが何をしなければならないかなどを記載したもの
要求定義と要件定義の違いを考える
どの会社でも、コンピュータのシステムを導入しています。
実績のあるパッケージソフトの導入なら問題ありませんが、自社のシステムを開発するとなると失敗などがあります。
特に、経験の少ないＳＥが担当した場合や無理な要求をした場合に失敗する可能性が高まります。
その原因は何なのでしょうか？
そこで重要となるのが、システム化の「要求」を正しくＳＥに伝えるということです。
ＳＥは、エンドユーザーの要求を正しく掴まないと．．．
要求を出発点とするシステム開発を成功させることができません。
システム開発には、ユーザーの要求を正しくつかみ、技術者が開発のために必要な要件定義を作成することが大切です。
開発には、要求を「どんな資料で、どうまとめる」のでしょうか？
要求定義と要件定義の関連は、どこにあるのでしょうか？
●要求定義
「～がしたい」 利用者の希望
ビジネスで何が必要かを記述したもの
事業運用をオペレーションレベル考えそれを実現する
コンピュータシステムへの要求
●要件定義
「～が必要」システムの仕様書
システムが何をしなければならないかを記述したもの
システムの機能やＤＢ・通信などの利用方法
要求定義が変更されると要件定義の変更が必要となります。
事業の方針が変わると、オペレーションが変わります。
オペレーションが変わるということは、画面や帳票などの
インターフェースの変更が必要となります。
ですから、システム開発をする時は．．．
具体的なオペレーションレベルで、作業の「仕組み」を捕えていないと、
「要求定義」が抽象的なものになります。
業務の運用の仕組みが抽象的なままだと．．
担当ＳＥの、その業務経験や能力、得意・不得意で、作成する「要件定義」が違ってきます。
ここが問題なのですね。
システム成功の要件は、担当ＳＥの経験と能力任せ．．
これでいいのでしょうか？
システム開発を３つの区分に分けると考えやすくなります。
・ビジネス
・システム
・ＩＴ技術
システム開発の現場では、この３つのレベルを一緒に論じがちです。
これは、全く別の能力です。全てに精通する人はいません。
「要求・要件」を追跡できる仕組みが必要
ビジネスの運用方針が変わった変わった．．
・システムのどこを修正すべきか？
システムに問題が出た．．
・その問題は、ビジネスのどこに影響があるか？
ビジネス環境は変化しています。
システムの開発環境も変化しています。
今、最良と思えるシステム開発ができたとしても、そのまま使い続けることはできません。
常に改良を加えていく必要があります。
その時に．．．
要求と要件を追跡する仕組が無いと．．プログラムのソースリストを追いかけることになります。
途方もない労力がかかります。
そして、成功率はかなり低くなります。
開発ドキュメントには２つ必要です。
・ビジネスの構造をオペレーションレベルで示すもの
・システム開発を行うＳＥが利用するもの
両方をそろえることがこれからの開発には必要です。
要求定義
（利用者が求めるシステムの機能）
ビジネスの「要求」
ビジネスの基本設計
ビジネスの詳細設計
（ビジネスのオペレーション）
要件定義
（開発されるシステムの機能・仕様）
システム開発の設計仕様
システムの基本設計書
システムの詳細設計書
ソフトウェア
ビジネスの要求によって変化しやすいソフトウェアの要件を追跡管理していく環境を築く
文章から双方向で追跡できる環境を築く
方針決定
開発の範囲や手順
導入例・開発例の意見の一致
システムの品質 をよくしていくことにもつながります。
関連情報
掲載元：制作チーム：サンストライプ
0コメント