要件定義工程について
要件定義は、「何を作るか（What）」を明確にする工程です。以下に、要件定義フェーズで実施すべき内容を説明します。
💻要件定義主な内容
| 区分 | 内容 |
|---|---|
| 1. 現状分析（As-Is） | 現行業務や既存システムの調査・課題整理（業務フローの可視化など） |
| 2. 要求ヒアリング | 利用部門・関係者からの「やりたいこと」「困っていること」などの要望収集 |
| 3. 業務要件の整理 | ユーザーが実現したい業務（例：顧客情報を検索したい、レポートを出したい）を文書化 |
| 4. 機能要件定義 | システムに必要な機能の明確化（画面・帳票・処理など） |
| 5. 非機能要件定義 | 性能・セキュリティ・可用性・拡張性・バックアップなどの技術的な要件 |
| 6. ユーザー・権限要件 | ユーザーの種類と、それぞれに必要な操作／アクセス制限など |
| 7. データ分析 | 管理対象となるデータの項目・構造・件数などの定義 |
| 8. 入出力要件 | 入力画面、出力帳票（CSV、PDFなど）に必要な項目・仕様の明確化 |
| 9. システム外部連携要件 | 他システムや外部APIとの連携の有無と方式（REST, ファイル連携など） |
| 10. 業務フロー定義 | システム導入後のTo-Be業務フロー（手順、関係部署）を整理（※特に重要） |
| 11. 画面一覧・帳票一覧作成 | 開発対象となる画面／帳票の洗い出しと概要定義 |
| 12. その他条件の明示 | 対応プラットフォーム、運用時間、開発予算、納期など |
💻要件定義で作成される代表的な成果物
| 成果物名 | 概要 |
|---|---|
| 要件定義書 | 上記の内容を全て文書化したドキュメント（業務・機能・非機能） |
| 業務フロー図 | 業務処理の流れを図式化（As-Is / To-Be） |
| ユースケース図 | システムとユーザーの関係を定義（機能単位での利用シナリオ） |
| 画面一覧／帳票一覧 | 想定される画面・帳票の一覧とその概要 |
| 入出力仕様書 | データの項目、フォーマット、データ分析など |
| データ項目一覧 | DBに格納する各データの名称・型・用途の定義 |
要件定義は、業務側の要望を取りまとめシステム側としては、実現可能かを相互に確認していく重要な工程です。
日程や費用の関連から仮承認等にて明確化しないで次工程（基本設計）に進んで後続で吸収したい等のシステムをよく見ます。色々と失敗しているシステムを見ますが、最初の時点のずれは、後続工程で色々な問題を発生することが多いですので、諸事情はあるかとは思いますが、業務側、システム側が納得いくもので、作業は終わらせてください。
次は、基本設計工程です。確認ください。
Share this content:
コメントを送信