要件定義プロセスとは？

「ユーザーの視点／ニーズ」に着目

システム開発において、「実装すべき機能」や「性能」を明確にし、ユーザのニーズを知ることが大事です。そのためには、現状のシステムを知り、「ユーザーが欲しいもの／困っているもの（ニーズ）」を洗い出すことが必要です。

※「経営者」のニーズは、企画プロセスとなるので、混同しないように注意。
※開発プロセスにでてくる「システム要件定義」とは、考える範囲が異なるので注意。

現状把握（問題）とあるべき姿

  1. 現状把握（背景）
    現状の業務を行っていくうえでの問題点、それが本当である具体例・数値・証拠（エビデンス）をもとに捉えていく。
    ※「何となくそういう感じ」「世の中そんなことを言っている」だけではなく、アンケート・ヒヤリングを実施など本当にそうなのかを調査する。
  2. 目的（あるべき姿）
    問題があることに対して、どうあればいいのか？どうあるべきか？
  3. 手段・機能
    どのような「システム機能・性能」を持つべきかを決める。
    ※ここでは、まだシステムの詳細な中身までは範囲としない。

＜注意＞
よく間違えるプロセスとして、「このシステムを入れないといけない」が背景・目的になってしまうことです。その場合、必要じゃない／使いづらいシステムを開発・導入してしまう可能性が高くなります。

業務要件定義（業務の洗い出し）

システムに関わり合いをもつ「利害関係者の種類（どんな人が関わるのか？）」の識別が必要。そのうえで、業務部門の業務プロセスを洗い出し、どのような問題・ニーズ・制約があるのかなどを考えていく。その際に、業務プロセスをまとめるのにBPMN（ビジネスプロセスモデリング）、データをまとめるのにDFD（データフロー図）などである。ちなみに、アルゴリズムを表現するのにつかわれる図を「フローチャート」。

＜表紙：１．業務要件定義書＞

目次

  • 1-1　業務の概要
    • 1-1-1　背景
    • 1-1-2　目的（方針）
    • 1-1-3　概要
      • 1-1-3-1　例）情報の登録と閲覧
    • 1-1-4　期待される効果（定量／定性）
    • 1-1-5　用語の定義
    • 1-1-6　組織体制
  • 1-2　規模
    • 1-2-1　ユーザー利用者数：〇〇万
  • 1-3　利用時間
    • 1-3-1　ユーザー利用時間：24時間
    • 1-3-2　管理者：業務時間内（9時－17時）
  • 1-4　利用場所
    • 1-4-1　ユーザー：自宅パソコン
    • 1-4-2　管理者：社内パソコン
  • 1-5　システム化範囲
  • 1-6　制約条件
  • 1-7　概略費用
  • 1-8　体制図
  • 1-9　スケジュール

システム要件定義（機能要件定義）

システムに必要な条件（システム要件）を決める工程。どのようなシステムを作るのかを、明確にするプロセスで、システムに必要な「機能」や「性能」をきめます。また、業務契約上、システム開発範囲を決める部分でもあるので、かなり重要な部分となります。後々の「言った、言わない」のトラブルを未然に防ぐためにもしっかりと「要件定義書」を作成しましょう。

システム要件には、機能要件と非機能要件があります。
  • 機能要件
    ユーザからのニーズで明らかになった、システムに必要な機能。
  • 非機能要件
    ユーザからのニーズからはでてこないが、システムに必要な性能。「応答時間」や「セキュリティ性」など。
    ※非機能要求グレード紹介ページはこちら

※データベース設計では『概念モデル』まで行います。
※SLCPの５つのステップ『要件定義プロセス』は「ユーザニーズ（業務要件）」を洗い出したが、システム要件定義は、『情報システム部門範囲で考える』システムの要件を決める。

 

 

＜表紙：２．機能要件定義書＞
  • 2-1　機能に関する事項
    ※本システムの機能一覧を示す
  • 2-2　画面に関する事項
  • 2-3　帳票に関する事項
  • 2-4　データに関する事項
  • 2-5　外部データ接続に関する事項

 

 

＜表紙：３．非機能要件定義書＞
  • 3-1　可用性に関する事項
    • 3-1-1　継続性要件：稼働している状態を定義、障害発生時の復旧目標を明記する。
    • 3-1-2　耐障害性要件：障害耐性を業務単位で明記する。
    • 3-1-3　災害要件：火災や大規模災害に対する対策を明記する。
    • 3-1-4　回復性要件：システム／データ復旧能力と労力を明記する。
  • 3-2　性能・拡張性に関する事項
    • 3-2-1　業務処理量：ユーザー数やデータ処理数、データ保管期間、通常時と繁忙期などでの業務増加量などを明記する。
    • 3-2-2　性能目標値：画面の応答速度やバッチ処理時間などの性能に関して明記する。
    • 3-2-3　リソース拡張性：CPUやメモリー、ディスクなど、拡張する予定などを明記する。
  • 3-3　運用・保守に関する事項
    • 3-3-1　通常運用：通常利用時間やスケジュール以外のバックアップ日、計画停止などを明記する。
    • 3-3-2　保守運用：OSアップデートやプラグイン更新などメンテナンス作業の方針や内容を明記する。
    • 3-3-3　障害時運用：障害発生時の対応を検討し、明記する。
    • 3-3-4　サポート体制：利用者からの問い合わせなどに対しての役割分担など保守契約内容を明記する。
    • 3-3-5　運用管理方針：上記を実現するための対応方針（サポートデスクの設置）や内部統制など具体的な実現方法を明記する。
  • 3-4　移行に関する事項
    • 3-4-1　移行時期：システム切り替え期間や時期、システム停止の可否を明記する。
    • 3-4-2　移行方式：拠点が複数あった場合、一斉か段階的かを明記する。
    • 3-4-3　移行対象：移行が必要な機器やデータを一斉か段階的を検討。また、移行ツールを利用するかも明記する。
    • 3-4-4　移行計画：作業分担やリハーサル環境、回数など検討し、移行中のトラブル発生時の対応プランを明記する。
  • 3-5　セキュリティに関する事項
    • 3-5-1　前提事項：業界基準や企業方針の時点で、順守すべき規定・法令・ガイドラインの有無を確認し、明記する。
    • 3-5-2　セキュリティ分析：脅威の洗い出し、影響分析を行い方針を明記する。
    • 3-5-3　セキュリティ診断：対象システムに対して、セキュリティに特化した試験の実施の有無を明記する。
    • 3-5-4　セキュリティリスク分析：発見された脅威の洗い出しやその影響分析の方針を明記する。
    • 3-5-5　アクセス制限：システムへのアクセスおよび利用制限について明記する。
    • 3-5-6　データの秘匿：機密性のあるデータの送受信する場合に暗号化を実施するかを明記する。
    • 3-5-7　不正追跡・監視：運用後の不正行為の追跡・監視などの記録方法および期間を明記する。
    • 3-5-8　ネットワーク対策：不正な通信を遮断するための制御やシステム内の不正行為や通信を検知する仕組みを明記する。
    • 3-5-9　マルウェア対策：マルウェア（ウィルス・ワーム・ボットなど）の完成を防止する方法などを明記する。
    • 3-5-10　Web対策：Webアプリケーション特有の脅威、脆弱性に関する対策を実施するかを明記する。
    • 3-5-11　セキュリティインシデント対応：問題が発生した時に、早期発見、被害の最小化、復旧支援などの体制について確認する。

 

品質特性とは、ソフトウェアの品質を評価する基準です。
  1. 機能性：ニーズに合った機能の実装度合い
  2. 信頼性：正常に動作し続ける度合い
  3. 使用性：使いやすさの度合い
  4. 効率性：資源の効率利用の度合い
  5. 保守性：保守のしやすさ度合い
  6. 移植性：別環境への移行動作する度合い

 

 

＜重要＞
「システム要件定義書」が完成したら、開発者と発注者で書類の内容を確認し、お互いの認識が一致しているかをチェックします。この作業を「共同レビュー」といいます。

次のページへ