empty
_
requirement_definition.f _ 03.01.要件定義
[要件定義]はシステム化の要です。  　 （※注01）

「ＩＴ戦略」と 「ＲＦＰ：要求仕様」 に則り、 利用部門ユーザ の方々及び、 ＩＴ化 責任部門 と、システム化の
　・　目的　　　　　（ ※注02）
　・　範囲・機能
　・　必要性-優先度を踏まえた スケジュール-実施順序（その為に 必要な事柄）
　について検討し、 システム化を実現させる為の要件 　（※注03） 　を決め、記述していきます。

要件定義                                                                      要件定義

※注01： システム化 　；　ＩＴ化を伴わないシステム化もある 為、
　　　　 ここでは要求仕様から 必要度、優先度を鑑み、ＩＴ化しない部分についても明記 します。
　　（ ＩＴベンダ の参画も不可欠ですが、 「 要件定義は発注者の責任 」という観点から定義しています）

※注02： 目的 　；　 ビジネス面の目的や目標をビジネス要件として明確化 し目的とします。（ ※ 注05）

※注03： 目的を システムの要件にブレーク・ダウン する。
　　　　 実現させる為の要件 ；まずは、システムで 実現させる業務要件 について「 機能要件 」 として定義します。
　　　　 続いて、システムを支える 基盤 （ ※注04） について「 非機能要件 」として定義します。

※注04： 基盤 ； 環境、品質、 セキュリティ、可用性、容量、処理速度 、 ユーザインターフェース、移行要件など

Jump      Jump要件定義      Jump※注05

※注05： 従来のシステム化は 、 人手の作業をシステム化する事により、生産性や品質が向上し、結果 、
　　　 ビジネス上の優位性やメリットが得られていた 。

　　　 単なる ＩＴ化 （システム導入）でもメリットが得られる為 、 システム要件を気にしているだけでも良かった。

　　　　 しかし、 一通りのシステム化が進んだ、現在に於いては 、 単なるシステム導入では 、
　　　 ビジネス上の優位性 や大きなメリットを得られにくくなって来ています 。

　　　 その為、まずは 、 ビジネス面の目的や目標をビジネス要件として明確化 し、
　　　 効果や必要性（必要度）、コストパフォーマンスを考慮し
　　　 システムの要件にブレーク・ダウンする事が重要 になって来ております。

　　　 （この為 、 要件定義 に於いて充分に検討し 、 ＩＴ化しない要件の判別・定義も大事になって来ています）
　 要件定義 フェーズに於いても、 IPA-SEC の   「 ＩＴ 化のバイブル 」をフレームワークとして使用します。

Jump      Jump要件定義      Jump※注05