B)要件定義 成果物作成要領

Home » エンタープライズアプリケーション開発 » B)要件定義 成果物作成要領

業務要件を定義するにあたって、検討漏れを防ぎ(網羅性の確保)、情報を整理するために、要件レベルを3階層に分ける。

Lv1:会社レベル
   =会社(組織や部門)、関連機関などを単位にした業務の記載する。
Lv2:部署レベル
   =部署(部門・部署)を単位にした業務の記載する。
Lv3:人レベル
   =部署内の人を単位にした作業内容を記載する。

上記の要件レベルの3階層を前提として、成果物の作成要領を記す。

成果物名  作成要領  サンプル
 1  業務要件一覧 業務 Lv1の粒度で対象業務を洗い出す。システム化に関係なく業務を洗い出す。1つの業務に対して以下の各項目を記載する。
 - 業務名
 - 業務内容
 - 会社・部署・担当者 (会社、外部機関 を記載)
 - 発生タイミング    
 - 前提条件
 - 作業制約 (外部機関とやりとりする場合のインタフェースの時間制約等)
業務要件一覧  
 2  業務要件詳細記述書

業務Lv1→業務 Lv2→業務Lv3への分割・詳細化を行う。
 ・担当者の役割と作業内容を明確にする。
 ・役割は現存する役職ではなく、業務やシステム利用上の役割で検討する。
 ・権限移譲・代理が発生するケースを考慮する。

 3  ディスカッションペーパー 各要件を文書に落とし込む過程で、ディスカッションポイントを明示した検討用資料を作成する。
 ・検討課題を明示する。
 ・解決案を複数用意する。
 ・解決案の意図や背景を記載する。
 ・最終的にディスカッション結果を追記する。判断理由も記載する。
ディスカッションペーパー
 4  システム化要件
(スコープ)
業務Lv3に設定された業務に対してシステム化の要素を洗い出す。
(「業務一覧」右側の“機能”欄に記載)

 ・ 処理分類 オンライン/バッチ
  該当業務を、オンライン処理するかバッチ処理するかを定義する。
  - オンライン: 画面やイベントに対してリアルタイムに処理を行う
  - バッチ   : スケジューラや画面からの実行により、非同期で複数件の処理を行う

  主な入力情報/出力情報
  ・該当業務を行うために必要な主な入力データと出力データを定義する。
  ・インタフェース一覧/エンティティ一覧と整合性を取る。

  システムの状態
  該当業務を実施した後のシステム状態(処理の状態、ステータス 等)を定義する。
  ・承認フローにおける状態を記載する。
  ・該当業務と関連する業務がある場合、業務の前提条件と本項目で矛盾がないこと
   (例)申請フローにおけるシステムの状態
      申請済みの情報のデータ修正可否について

機能一覧#6と同じ 
 5  業務フロー(概念)

業務一覧と整合性を取ってフローを記載する。業務フローは無駄な分岐や処理がなく、前後の繋がりが把握出来るものにする。
 ・業務Lv1の粒度(業務名、会社レベル)の業務の流れを記載する。

 ・業務Lv2の粒度(部門レベル)の業務の流れを記載する。
 ・業務Lv3の粒度(担当者単位)の作業の流れを記載する。

業務フロー 
 6  機能一覧  業務一覧を元に、システムが実装する機能のフローを明確にする。
 ・システム化対象業務に関するシステムの振る舞いを定義する。
  業務要件の内容を反映させる。
  システムと利用者とのやりとりを記載する。(ユースケース等)
  システムが担当する処理を記載する。
   (画面表示、データ編集、データ出力 等)

  処理の流れが把握できるように順序立てて記載する。
   → 基本設計工程で行う”機能の分割”や”ロジック設計”に繋がる。

 

  ・ 1機能で処理する情報の件数を意識する
   業務要件ごとにユーザへのヒアリングを実施し、該当機能での
    対象件数を確認。

     (画面入力、バッチ処理 等)
    (例) 画面入力件数 
       1件ごとに登録、複数件同時登録(ファイル取り込み)など
       業務効率化を意識して検討する。

機能一覧#4と同じ 
 7  インタフェース一覧
(概要)

インタフェースデータを列挙する。業務一覧 Lv1、Lv2の単位で発生するインタフェースデータを記載する。
 Lv1:外部機関、会社外とやりとりするデータ
 Lv2:他部署、他システムとやりとりするデータ

 ・インタフェースの基本要素を記載する。
  ・ 連携システム名  (外部機関との連携では外部機関名でも良い)
  ・ データ名称   (エンティティ一覧の名称と整合性を取る)
  ・ データ内容    
  ・ 業務(Lv2)   (データを使用する業務Lv2の業務名と結び付ける)
  ・ 連携方向    (自システムから見た送信/受信を明確にする)

 ・インタフェースデータの連携方法を記載する。
  ・ タイミング   (相手先システムとデータ連携するタイミングを定義する)
    ・サイクル
    ・時刻
    ・時限
     ・受信:業務の実施タイミングや作業制約(時間制約)に間に合っている。
     ・送信:相手先システムの時間制約を満たしている。

  ・ 連携方式、文字コード   ( 相手先システムとの連携方法を記載する)
    ・連携方法(通信方式)
    ・データ形式
    ・文字コード

   1システムに対して連携方法を纏めた方がメンテナンス負荷や
    障害発生リスクの軽減に繋がる。
    通信上のセキュリティ(データ暗号化)の方針は、通信方式の
    確認時に一緒に確認する。

    ファイルの暗号化をアプリケーションで担保 
     → データ形式に反映(CSV形式/ZIP圧縮 など)
     プロトコル(HTTPS、SSL)、S/W製品(付属ドライバ)で担保 
     → 通信方式に反映(HTTPSなど)

  ・想定データ量
   ・1回でやりとりするデータ件数(の目安)を把握する。
     通信量や処理負荷への目安になる情報になる。
     システム方式設計にも影響する。

  ・異常時の対処方法
    ・相手先システムとのデータ連携に失敗した際の動作や再受信/送信の方法
    ・データの漏れや順序の追い抜きが発生しないように考慮する。
    ・リカバリ手順が簡易でかつ安全な方法になるように考慮する。

インタフェース一覧 
8  概念レベルのER図  ER図でデータ設計を表現し、データとその関係性から業務が成り立つか確認する。
 ・必要なデータを登場させて、粒度を同じにする。
 ・エンティティ間の関係(線)を定義する。
 ・線が定義されないものでも存在意義が分かるように情報を付記する。
 ・他のエンティティに依存している/しないを表現し、矛盾や漏れが無いようにする。

エンティティ一覧・ER図  
9  エンティティ一覧  業務で取り扱うデータ(データのまとまり)を洗い出す。
 ・エンティティの列挙
  業務一覧 Lv1、Lv2作業で発生したデータ(エンティティ)を記載する。
  インタフェースのデータも反映する。
   - エンティティ名   論理的なデータの名称
   - 業務Lv1、Lv2  エンティティが属する主な業務(業務一覧のLv1、Lv2)

 ・エンティティの属性
  列挙したエンティティの種類(トランザクション、マスタ)を定義する。
  - エンティティの種別(トランザクション/マスタ)

10  非機能要件 業務要件とシステム化要件を踏まえて、非機能要件を定義する。
 ・可用性
 ・性能・拡張性
 ・運用・保守性
 ・移行性
 ・セキュリティ
 ・システム環境・エコロジー
非機能要件 
11  主管部署・関連ユーザ一覧 ・会社・部署・担当者の役割について、実際の部署・役職で確認する。
  各機能(システムフロー)に当てはめて検証する。権限移譲・代理実行
  の要否や可否について確認する。
 ・業務一覧で登場する会社、部署 と本案件の担当窓口
 ・システム運用を担当する部署と担当者
 ・他システムの担当者と製品ベンダー
主管部署・関連ユーザ一覧 
12  システム概要図

業務全体における当該システムの役割を図示する。
 ・業務全体における当該システムの機能と範囲(境界)を明確にする。
 ・関連システムや利用者を記載する。
 ・関連システム、利用者のロケーション(社内、社外)を記載する。

 ・要件定義の業務一覧・業務フロー、インタフェース一覧の内容を反映する。
 ・関連システム(上流・下流)とのデータの流れを記載する。

システム概要図 
13  システム構成図  システムを構成する要素(コンポーネント、サーバ)を記載する。アプリケーション構成を意識した視点”と“インフラ構成を意識した視点”で、それぞれ構成図を作成する。

 ・構成要素を明確にする。
 ・アプリケーションコンポーネント配置、サーバ構成について次のことを
  考慮する。

  ・可用性(業務継続、冗長化)要求を反映する。
  ・処理量、性能要求が高い機能を集中させず、なるべく分散させる。
  ・要素を一つに統合する場合、運用(稼働時間、停止)に問題がないよう
   考慮する。

 ・仮想化の検討
  サーバ、ハードウェアリソース、ネットワーク、アプリケーション、クライアントの各箇所で仮想化を
  検討する。

システム構成図
14  データフロー(全体)  システム内のデータと機能の流れを視覚的にわかりやす記載する。『業務一覧』の”業務Lv2 or Lv3″/”主な入力情報”/”主な出力情報”、『エンティティ一覧』、『ER図』などを参照して作成する。

 ・要件定義の内容をデータと機能の観点で結びつけて図示する。
 ・システムで実現する範囲の機能とデータを全て表現する。
 
業務要件があいまいでデータフローを作成できない場合は、業務一覧に立ち戻って業務ユーザーとコミュニケーションを取り、不明点を解消させてからデータフローに追記または更新する。

データフロー 
15  アプリケーション方式設計 ・アプリケーション構成
 アプリケーションで必要な機能を論理的な役割(階層)に分割する。
 開発する単位を明確化する。

  階層(レイヤー)の設定
  業務要件から機能を論理的な役割に分割する。
  分割することで実装範囲(設計対象)を整理する。
    3層アーキテクチャの例を記す。
B_要件定義_3層アーキテクチャ
  レイヤーの実装方針、レイヤー間インタフェース
  実装方針と受け渡しのインタフェースが決定することで
  アプリケーションとしての処理フロー(抽象化版)が明らかにする。 

  レイヤーの分割を決めたら、各レイヤーの実装方針を検討する。
    (適用する技術、ミドルウェア指定等)
   - レイヤー間の受け渡し方法(インタフェース)を取り決める。 
     レイヤー間インタフェースの検討ポイントを記す。     B_要件定義_レイヤー間インタフェース
 実行形態の分類
  オンライン処理、バッチ処理が担う範囲を定義する。
  例) 実行形態の分類例
  ・オンライン:ユーザがWEBアプリケーションの画面を介して対話する形式
  ・バッチ:スケジューラによりバックグラウンド(利用者と対話しない)で実行する形式
  ・オンラインバッチ:ユーザがWEBアプリケーションの画面で非同期バッチ処理の実行を指示

・ トランザクション(データ更新)管理
 システムで取り扱うデータの整合性が保てるように、
 トランザクションデータ更新のルールを決める。

 トランザクション管理、リランの考え方
  処理においてデータ不整合が起きないようにトランザクションのスコープを決定する。
  障害発生、異常終了時においてもデータ不整合を保つ仕組みを検討する。
  業務におけるデータ状態遷移からUMLシーケンス図を用いるなどをして設計する。
  トランザクションのスコープの例を記す。
   ・オンラインアプリケーション : 
    ロジック層の入口~出口まで。失敗時は元に戻すことで整合性を保つ。
   ・バッチアプリケーション : 
    ケース1: 1バッチ1トランザクションとする。単純リランを可能にするため。
    ケース2: 一定の処理件数で分割する。再実行時間を短縮するため。 

 データ更新時のロック制御
 同一データソースに対して同時更新が発生する場合に
 データ整合性を保つための仕組みを設計する。
  データベースで提供するロック機能採用による業務機能への弊害の有無
     - 参照から更新までに時間がかかる処理があり、他の処理が更新待ちにならないか?
     - システム的な更新制御では、タイミングにより上書きが発生されないか?

  
更新制御の仕組み・ルールの導入

    例)”楽観的ロック”の採用
    - 制御用項目(シリアル番号や更新日時)により、更新前後の状態をチェック
     →同時に他の更新がないことを確認する
    - ロックの単位を決定する。行単位・テーブル単位等。

・性能確保の方針
 性能要件に対して、当該アプリケーションアーキテクチャでの実現方法を設計する。

 性能劣化を起こす場所と要の因洗い出し
  性能劣化を起こす可能性がある箇所とその要因を洗い出す。
  システム化要件と前述で考えたレイヤーに対して次の視点で洗い出す。
   ・オンラインアプリケーション:レスポンスタイム、スループット
   ・バッチアプリケーション     :ターンアラウンドタイム
   ・サーバ/ストレージ/ネットワーク: リソース利用

 実現方法(対応策、また性能劣化時の処置方法を設計する)
  対応策を例示する。
   分散処理
    - 水平分散:同じ処理を行うサーバを複数用意する。
    - 垂直分散:処理内容により処理するサーバを振り分ける。
   ・キャッシュの利用
    - メモリ上にデータや定義情報を保持することで物理I/Oを減らす。
   ・非同期処理
    メッセージキュー等を利用して非同期で処理を行う。
     (処理を完結する前に見せかけ上のレスポンスを返す)
   ・リソース拡張(スケーラビリティ)
     - システム運用中にリソース追加が出来る仕組みにする。

・可用性の方針
 可溶性に対して当該アプリケーションアーキテクチャでの実現方法を設計する。

 可用性を高める必要がある箇所の洗い出し
  システム化要件と前述で考えたレイヤーから、可用性が必要な業務を特定する。
  それに関連する機能を洗い出す。

 実現方法(対応策と、復旧方法(発生前状態への戻し)を設計する。)
  ・冗長化 (Active-Active構成、Active-Standby構成)
   どのレイヤー(ハードウェア/ミドルウェアも含む)で冗長化を実現させるか。
    ・状態引継ぎ:
     縮退発生時にどこまで事前状態を引き継ぐ必要があるか。(システム、データ)
    ・正常状態への戻し
     どのように戻すか(システム停止(運用への影響)の可否・要否確認 など)

・例外の取り扱い
 システム不具合や業務エラーが発生した際の処理を設計する。

 例外の分類と取り扱い
  不具合が発生するケースを洗い出し、その際に実施中の処理の扱いを検討する。
  エラーケース
    ・ 業務エラー:業務シナリオ上のエラーケースなどの業務上のエラー
    ・ システムエラー:ハードウェア障害、製品バグなどのシステム面でのエラー
  -例外発生後の処理(トランザクション)の扱い
    ・ロールバックして例外扱い
    ・ロールバックせずに例外扱い
    ・例外扱いにしない

 例外処理の方法
  例外発生の検知から処理終了までを設計する。
   ・ロールバック機能を実装する箇所
   ・エラーの表示方法(画面の要否、画面遷移等)
   ・ログ(エラーメッセージ)出力イメージ

・セキュリティの確保
 アプリケーションのセキュリティとして実装すべきことを設計する。

 認可・認証
  利用者のアクセス権の制御(認可)、利用者本人の特定(認証)について設計する。
  認証の仕組み:  認証に必要な情報と特定(判断)の仕方
  認可の仕組み: 認証された情報を元にアクセス権の制御の仕方

 ロール管理
  システムユーザーに割り当てる機能・アクセスできる情報の利用範囲を定義する。
  その情報の管理方法を設計する。
  ・役割(ロール)の定義 … システムを利用するユーザに必要な役割は何か?
   ・各ロールの範囲
   ・ロールの管理方法(ユーザ画面でメンテナンスする等)

 セッション管理
  ステートレスなサーバ通信の処理の中で共有する情報(セッション)の管理方法を設計する。
  セッションIDの入手による乗っ取りや成りすましを排除する。
   ・セッションIDの発行方法
   ・セッションIDの受渡方法
   ・共通情報(ログイン、ユーザ情報、買物カート 等)の格納方法
   ・共通情報のスコープ( = 作成~破棄のタイミング)
     アプリケーション/セッション/リクエスト

 暗号化
  データ項目から通信、媒体に対して暗号化すべき対象を洗い出す。
  暗号化・複合化の仕組みを設計する。

 ・対象
   ・データ項目:
    データベースやファイルの情報で、第3者に漏れると社会的な影響があるもの
    個人を特定できる情報、クレジットカード番号、ログインパスワード 等
   ・通信データ:
    プロトコルレベルまたはアプリケーションでの通信データの暗号化
   ・媒体 :
    ディスクやその他の媒体で保存するファイルなどに対する暗号化

 ・仕組み
    採用する暗号化方式、強度を設計する。

・ ログの出力
 ログ出力対象とログの用途の洗い出し
  アプリケーションが出力するログの用途を明確にする。
  あわせて、出力するアプリケーションレイヤーを検討する。
   ・アクセスログ: ユーザインタフェースからリクエストとレスポンス情報。
    ・障害時:エラー影響(リクエスト、ユーザ)の特定
    ・通常時:性能評価、アクセス分析
    ・サービスレイヤーが出力する。 

   ・ロジックログ:業務ロジックの実行ログ、ターンアラウンドタイム
    ・障害時:エラー箇所と原因の特定
    ・通常時:性能評価
    ・開発時:実行の証跡

    ・サービスレイヤー+ロジックレイヤーが出力する。 

   ・データアクセスログ:データソースへのSQL実行ログ
    ・障害時:エラー原因(SQLと条件)の解析
    ・通常時:監査用

    ・データアクセスレイヤーが出力する。

   ・エラーログ: 各レイヤーで起こったエラーを集約したもの。
    ・通常時:監視向け
    ・障害時:障害箇所の切り分け

     ・サービスレイヤーが出力する。

 ログレベル、フォーマット
  出力するログレベルとフォーマットを決定する。
  ・ログレベル
    ログの重要度で分類する。レベルで出力要否を設定出来るようにする。
    ・FATAL(致命的エラー)
    ERROR(エラー)
    WARN(警告)
    INFO(情報)
    DEBUG(デバッグ情報)
    TRACE(トレース情報)
   ・フォーマット
    解析に必要な情報を特定する。
    どのようなフォーマットで出力するか決定する。

 出力先、出力タイミングの決定
  ログの出力先と出力するアプリケーションレイヤー、出力方法を決定する。
  ・出力先(例)
   ・ アプリケーションのファイルに出力する。
   ・ OSやミドルウェアのログに一緒に出力する。
   ・ 監視ツールへ送信する。 SNMP、メッセージキューを利用する。

  ・出力方法とタイミング
   ・ ログを出力するアプリケーションレイヤーと出力するタイミングを決定する。
   ・ APIやライブラリの使用方法を決定する。
   ・ 業務処理と非同期で出力する仕組みを検討・決定する。
   ・ ログの新規作成やローテーションの仕組みなどのログ運用方法を決定する。

・メッセージの管理
 メッセージの利用方法(ログ出力や画面出力)と管理方法を決定する。 

 ログ・画面への出力方法
  ログや画面へ出力する際の実現方法(インタフェース)を決定する。

 メッセージの管理方針
  メッセージとして管理する項目やメンテナンス方法を決定する。
   ・ 管理項目
     例)メッセージID、レベル、メッセージ 等
   ・ 管理方法
     例) データベースで管理。定義ファイルで管理。プログラムに埋め込み。等

- 
16   H/W、M/W一覧 ・システム仮構成の決定
 業務要件、比企能要件を踏まえてシステムの仮の構成を策定する。
 <システム構成に関わる要素>
 ・業務機能の要素
  ・オンライン/バッチ、画面・帳票の複雑度
  ・データ量・処理量、実施頻度(同時処理度合い) 等
  
 ・非機能の要素
  ・運用・保守性
  ・性能・拡張性、
  ・耐障害性・可用性
  ・移行性、エコロジー 等
 
・サーバサイジング
 システム構成案の作成と合わせてサーバサイジングを実施する。
 仮想化採用の場合は、論理構成と物理構成の整合性を確認する。
 <サーバサイジングの要素>
 ・処理性能
  ・CPU   :モデル、数の決定
  ・ディスク:ディスク処理能力(IPOS)、
        ディスク(HDD[SAS/SATA]、SSD)
        RAID構成の決定
        データ量(バックアップも含む)
  ・メモリ :キャッシュ利用量
 
 ・拡張性
  ・ CPU/メモリ/ディスクの拡張(拡張後の処理能力・容量)
  
 ・可用性
  可用性方針から冗長化(クラスタ構成、ロードバランシング)構成を決定する。

 

・製品の選定
 ・業務一覧で業務内容、非機能要件を踏まえているか確認する。
 ・開発/運用面から有償・無償(オープンソース)製品の採用方針を検討する。
 ・仮想環境の利用を検討する。
 ・ネットワーク/サーバ/ストレージ/ミドルウェア
    各箇所の方式で不整合が発生していないか確認する

 ・複数の製品を候補の比較検証を行う。
 ・要件とコストを考慮して、採用製品・技術を決定する。
 
・HW/MW一覧
 決定したハードウェア・ミドルウェアの情報を一覧化する。

 -
17   システム化計画書

 システム化に向けたプロジェクトの計画を作成する。以下に、計画の主要な要素を記載する。
 ・プロジェクトの概要
  ・プロジェクトの目的/目標
  ・プロジェクトの範囲
  ・プロジェクトの前提条件
  ・プロジェクトの成果物
  ・スケジュールと予算
 
 ・体制
  ・業務部門の体制
  ・IT部門の体制
 
 ・リソース計画
  ・開発規模と工数の計画
  ・人員計画
  ・設備/機器等の調達計画
  ・プロジェクトの人員研修計画
  ・予算計画
 
 ・作業計画
  ・開発関連作業の洗い出し
  ・開発関連作業の順序・依存関係
  ・開発作業担当者の割り当て・充足性
  ・作業計画(WBS)作成
 
 ・品質管理計画
  ・品質目標
  ・品質管理体制と仕組み
  ・品質管理に関する主要なイベント

 ・リスク管理
  ・リスク管理方針
  ・リスク管理体制と仕組み
  ・リスク一覧

 -