要件定義
■開始条件
ユーザ側で要求事項が整理されている事。
システム開発案件を受注し、契約が締結されている事。
■要件定義の目的
業務をシステム化するときにユーザの要求をまとめる作業を要求定義という。その成果物を要求定義書という。
要求を実現するために、システム化の要件をまとめる作業を要件定義という。その成果物を要件定義書という。
要件定義は、システム化の範囲を明確にし、システム開発にかかる工数や費用を見積もる為にも行う。
■要件定義の担当
要求定義、および要件定義はユーザ中心で行うべきである。
ユーザ側で関係部門の担当者を集めて、システム化の委員会を発足させ、要求事項の導出やとりまとめ、要件定義を行う。
開発者は情報システムに関する専門知識を提供し、ユーザの要件定義作業を支援する。
■要件定義の方法
ユーザはシステム化したい事を明確に定義し、開発者に漏れなく伝えなければならない。
ユーザは自らの業務を定義しなければならない。いつ、誰が、どこで何を、どのようにしているのか、何の為にそれをしているのかをひとつずつ記述しなければならない。
業務上何が問題になっているのかを挙げていく。それぞれの問題に対してどのように解決するのかを記述する。
解決方法には、「その業務を止める」、「アウトソーシングする」、「運用を変える」、「システム化する」等があり、コスト面や体制面、関係者への影響等、いろいろな側面から検討して、決定する。
問題解決の方法の中からシステム化するものについて、開発者は情報システムの専門家の立場で助言していく。
■要件定義の基になる資料
中長期事業計画書。
業務内部資料(業務マニュアル/業務定義書/業務フロー等)。
業務課題一覧。
現行システムがあれば、現行システムの各種資料(出力帳票/操作マニュアル/設計書/仕様書等)。
ヒアリングシート。
アンケート用紙。
打ち合わせ議事録。
■要件の種類
業務面
業務スケジュール・部署・拠点・効率
システム面
機能・操作性・品質・性能・セキュリティ
運用面
リソース・保守性・拡張性・安全性・運用コスト・運用体制・リスク・ヘルプデスク
■要件定義の確認
課題は何か。
その課題は何時まで続くのか。
その課題は何時までに解決しなければならないのか。
その課題を解決するとどのような効果が見込めるか。
その課題は主にどこの部署の誰が担当しているのか。
その課題はどのように解決しようとしているのか。
何故、そのような解決方法を取るのか。
その課題は何が原因で起こったのか。
その課題を放置するとどのような影響があるのか。
その課題を解決する方法として、システム化を選ばなかったらどうなるか。
■要件定義書の項目
項番
部門
部門担当者
業務名
課題
課題分類コード(経営戦略、情報戦略、業務上の問題等)
対応方法
対応方法分類コード(業務プロセス変更、業務廃止、システム変更、新規システム化等)
実現可能性
優先度
実施期限
備考
■要件定義書作成時の注意点
一つの項目に一つの要件を書く。複数の要件を書かない。
「〜を〜する」のような表現で統一する。
続く
位置:
トップ
>
システム開発の方法
通読:
前頁
|
次頁
Page Views
トップ
ブログ
Tips集
用語集
フォーム集
リンク集
参考文献
道具集
システム企画
プロジェクト管理
システム開発
システム管理
プロフィール
当サイトについて
サイトマップ
更新履歴
今後の予定
掲示板
QRコード
このページの先頭へ