ＳＥノウハウ要件定義編: Ver2.0

システム化構想・システム化方針・計画は本書の対象外とし、個別システムの要件定義を対象としています。
特に、エンタープライズレベルの企業の要件定義において、本書が参考になるかと思います。

＜特徴＞
・システム構築の実際のノウハウであること
・実際の業務で使えることを目的としており、工程・業務・タスク単位の章立てであること
・具体的な要件例を記していること

＜目次＞
1 要件定義
1.1. 準備
1.1.1. 用語等
1.1.2. 本書の前提（全般）
1.1.3. 本書の前提（現行システム調査・分析）
1.1.4. 本書の前提（システム化方針・計画）
1.1.5. 本書の前提（プロジェクト管理）
1.1.6. 本書の前提（システム重要度評価）
1.1.7. INPUT資料の確認
1.2. 実施計画の策定
1.2.1. 目的の確認・設定
1.2.2. ヒアリング方法の検討・確定
1.2.3. ステークホルダー分析
1.2.4. リスクの識別
1.2.5. 【補足】工数見積りの留意点
1.3. 機能要件の定義
1.4. データ要件の定義
1.4.1. データ一覧の作成
1.4.2. データ項目一覧の作成
1.4.3. ER図の作成
1.5. 画面要件の定義
1.5.1. 画面一覧の作成
1.5.2. 画面レイアウトの作成
1.5.3. 画面プロトタイプの作成
1.5.4. 開発有無の検討
1.5.5. 画面機能要件 例
1.6. 帳票要件の定義
1.6.1. 帳票一覧の作成
1.6.2. 帳票レイアウトの作成
1.6.3. 開発有無の検討
1.6.4. 帳票機能要件 例
1.7. バッチ要件の定義
1.7.1. バッチ一覧の作成
1.7.2. DFDの作成
1.7.3. リアルタイム／バッチの識別
1.7.4. バッチ機能要件 例
1.8. 外部I/F 要件の定義
1.9. 例外処理要件の定義
1.9.1. 例外処理機能要件 例
1.10. セキュリティ要件の定義
1.10.1. ゴールの設定
1.10.2. 認証にかかわる機能要件
1.10.3. 権限にかかわる機能要件
1.10.4. OS・BIOSのセキュリティ要件
1.10.5. DBのセキュリティ要件
1.10.6. ネットワークのセキュリティ要件
1.10.7. Webアプリケーションのセキュリティ要件
1.10.8. その他セキュリティ要件
1.11. 完全性要件の定義
1.11.1. ゴールの設定
1.11.2. 完全性要件 例
1.12. 耐障害性要件（可用性要件）の定義
1.12.1. ゴールの設定
1.12.2. 指標の設定
1.12.3. ハードウェアの冗長化
1.12.4. 予防的対策 要件
1.12.5. 障害の拡大防止 要件
1.13. 性能要件の定義
1.13.1. オンラインの性能要件
1.13.2. バッチの性能要件
1.14. 拡張性要件の定義
1.15. ハードウェア要件の定義
1.16. ソフトウェア要件の定義
1.17. 運用要件の定義
1.17.1. 運用時間の決定
1.17.2. 監視要件
1.17.3. サーバー（OS）運用 要件
1.17.4. バックアップ 要件
1.17.5. パッチ適用要件
1.17.6. 障害通知プロセス 要件
1.18. 保守性要件の定義
1.18.1. アプリケーション保守 要件
1.18.2. ハードウェア保守 要件
1.19. 【共通】ログ要件の定義
1.20. その他 要件等
1.20.1. 環境にかかわる要件
1.20.2. 実現性確認
1.21. 要件定義書のレビュー・承認
1.21.1. 要件定義書のレビュー
1.21.2. 費用調整
1.21.3. 要件定義書の承認

＜冒頭＞

1.要件定義
要件定義とは、システムを利用して業務を行う時に、どのようなシステム化対象・機能、性能等が必要か決める業務である。
ユーザー企業の経営戦略・業務戦略、情報戦略や既存のシステムの基盤・各種管理体を踏まえ、ステークホルダーの様々な要求や意見を纏め、調査、分析、知識や経験等により「相対効果の大きい対策」を導き出し、各種要件（機能要件、セキュリティ要件、性能要件等）として纏めることを目的としている。
「相対効果の大きい対策」には特に留意が必要で、ステークホルダーの要望を単に全て取り入れることなく、目的を実現できるよう代替え案の提示を行うことやシステムに求める要件が過度に増加することの無いように制御し、費用対効果等の観点（※１）から合理的な内容とし、ステークホルダーの合意形成を図る必要があることに要件定義の難しさがある。
システム開発というビジネスは、他のビジネスと比べ曖昧なビジネスである。例えば、他のビジネスでは、展示品があったり、試供品があったり、模型があったりと成果物が明確であるが、システム開発は発注者と受注者のイメージでのやり取りが行われ、イメージに大きな隔たりがあることもしばしばある。このシステム開発における要件定義の曖昧性を認識しつつ、イメージの提示・提案等により、隔たりのギャップを埋めるとともに、曖昧性をいかに減らせるかが、要件定義の重要なポイントである。

※１ 考慮すべき観点
・費用対効果
・全体最適化
・システム化に伴う影響
・システムの資産価値

＜成果物＞要件定義書／要求定義書（RFP）

＜成果物の構成　例＞
ドキュメントは、各要求における決定事項を整理し、構造化した形でドキュメントに纏める。作成方法は決定事項を最後に書くのではなく、ヒアリングや議論の叩き台として作成し、関係者の意見を反映し（何度も書き直しながら）、品質・精度を高めてゆくものである。
要件定義書の構成例は、以下のとおりである。

●要件定義書サマリー
忙しく見る時間のない者もいるため、以降のページをサマリーした1枚程度で作成する。
例えば、機能数や画面数でサマリーすることで規模感を表現することが出来る。ユーザー企業の上層部は（1つ1つの機能に興味はなく、）知りたいのは規模感（開発規模、スケジュール）である。

●制約と前提条件
当該システム開発において、制約、前提条件があれば記す。

●システムフロー図
新規システム・改修システムを中心とした関連システムをプロットし、主要なトランザクションを記す。

●システム別の対応概要
新規システム／改修システム／テスト参加システム毎の対応概要を記す。これにより、対応の全体感を表現することが出来る。
‐新規システム：
開発対象のシステムについては、主要機能（サマリー）を記す。
‐改修システム：
開発に伴い影響を受けるシステム（改修システム）においては、改修概要を記す
‐テスト参加システム
作成時点で改修するとは言い切れないが、念のためテストを実施するシステム（テスト参加システム）を列挙する。これによりシステム改修の最大範囲、ならびに、テストの規模感を表現することが出来る。

●システム構成図（新規システム）
新規システムについては、システム構成図を記す。
システム構成図は、1.15ハードウェア要件の定義、1.16ソフトウェア要件の定義をサマリーし作成する。
例：Webサーバー、APサーバー、DBサーバーの構成

●課題と解決策
ユーザー企業が解決を求めている課題に対する解決策を記す。
ユーザー企業にとって最も関心があることは、現状の業務の課題がどのように解決されるかである。もし、未解決のものがあれば、未解決の理由と対応方針を記載するが、以降の工程に持ち越しても問題ないか判断する必要がある。

●機能要件
⇒1.3機能要件の定義 参照

●データ要件
⇒1.4データ要件の定義 参照

●画面要件
⇒1.5画面要件の定義 参照

●帳票要件
⇒1.6帳票要件の定義 参照

●バッチ要件
⇒1.7バッチ要件の定義 参照

●外部I/F要件
⇒1.8外部I/F 要件の定義 参照

●例外処理要件
⇒1.9例外処理要件の定義 参照

●セキュリティ要件
⇒1.10セキュリティ要件の定義

●完全性要件
⇒1.11完全性要件の定義

●耐障害性要件
⇒1.12耐障害性要件（可用性要件）の定義 参照

●性能要件
⇒1.13性能要件の定義 参照

●拡張性要件
⇒1.14拡張性要件の定義 参照

●ハードウェア要件
⇒1.15ハードウェア要件の定義

●ソフトウェア要件
⇒1.16ソフトウェア要件の定義

●運用要件
⇒1.17運用要件の定義 参照

●保守性要件
⇒1.18保守性要件の定義 参照

●共通
⇒1.19【共通】ログ要件の定義 参照

●特記事項
特記事項があれば記す。
例：費用（予算）にかかわる要求事項