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

　・ 処理分類　オンライン／バッチ
　　該当業務を、オンライン処理するかバッチ処理するかを定義する。
　　- オンライン： 画面やイベントに対してリアルタイムに処理を行う
　　- バッチ　　 ： ｽｹｼﾞｭｰﾗや画面からの実行により、非同期で複数件の処理を行う

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

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

業務一覧と整合性を取ってフローを記載する。業務フローは無駄な分岐や処理がなく、前後の繋がりが把握出来るものにする。
　・業務Lv1の粒度（業務名、会社レベル）の業務の流れを記載する。
　・業務Lv2の粒度（部門レベル）の業務の流れを記載する。
　・業務Lv3の粒度（担当者単位）の作業の流れを記載する。

　　・ 1機能で処理する情報の件数を意識する
　　　・業務要件ごとにユーザへのヒアリングを実施し、該当機能での
　　　　対象件数を確認。
　　　　　（画面入力、バッチ処理 等）
　　　　（例）　画面入力件数　
　　　　　　　1件ごとに登録、複数件同時登録（ファイル取り込み）など
　　　　　　　業務効率化を意識して検討する。

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

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

　・インタフェースデータの連携方法を記載する。
　　・ タイミング　　　（相手先ｼｽﾃﾑとﾃﾞｰﾀ連携するﾀｲﾐﾝｸﾞを定義する）
　　　　・サイクル
　　　　・時刻
　　　　・時限
　　　　　・受信：業務の実施タイミングや作業制約（時間制約）に間に合っている。
　　　　　・送信：相手先システムの時間制約を満たしている。

　　・ 連携方式、文字コード 　　（ 相手先ｼｽﾃﾑとの連携方法を記載する）
　　　　・連携方法（通信方式）
　　　　・データ形式
　　　　・文字コード

　　　1システムに対して連携方法を纏めた方がメンテナンス負荷や
　　　　障害発生リスクの軽減に繋がる。
　　　　通信上のセキュリティ(データ暗号化)の方針は、通信方式の
　　　　確認時に一緒に確認する。
　　　　ファイルの暗号化をアプリケーションで担保　
　　　　　→　データ形式に反映(CSV形式／ZIP圧縮　など)
　  　　プロトコル（HTTPS、SSL）、S/W製品(付属ドライバ)で担保　
　　　　　→　通信方式に反映（HTTPSなど）

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

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

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

業務全体における当該システムの役割を図示する。
　・業務全体における当該システムの機能と範囲(境界）を明確にする。
　・関連システムや利用者を記載する。
　・関連システム、利用者のロケーション（社内、社外）を記載する。
　・要件定義の業務一覧・業務フロー、インタフェース一覧の内容を反映する。
　・関連システム（上流・下流）とのデータの流れを記載する。

　・構成要素を明確にする。
　・アプリケーションコンポーネント配置、サーバ構成について次のことを
　　考慮する。
　　・可用性（業務継続、冗長化）要求を反映する。
　　・処理量、性能要求が高い機能を集中させず、なるべく分散させる。
　　・要素を一つに統合する場合、運用（稼働時間、停止）に問題がないよう
　　　考慮する。
　・仮想化の検討
　　ｻｰﾊﾞ、ﾊｰﾄﾞｳｪｱﾘｿｰｽ、ﾈｯﾄﾜｰｸ、ｱﾌﾟﾘｹｰｼｮﾝ、ｸﾗｲｱﾝﾄの各箇所で仮想化を
　　検討する。

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

　・ 階層（レイヤー）の設定
　　・業務要件から機能を論理的な役割に分割する。
　　・分割することで実装範囲（設計対象）を整理する。
　　　　3層アーキテクチャの例を記す。

　・ レイヤーの実装方針、レイヤー間インタフェース
　　実装方針と受け渡しのインタフェースが決定することで
　　アプリケーションとしての処理フロー（抽象化版）が明らかにする。　
　　・レイヤーの分割を決めたら、各レイヤーの実装方針を検討する。
　　　　（適用する技術、ミドルウェア指定等）
　　　- レイヤー間の受け渡し方法（インタフェース）を取り決める。　
 　　　　レイヤー間インタフェースの検討ポイントを記す。　　   
　・実行形態の分類
　　オンライン処理、バッチ処理が担う範囲を定義する。
　　例） 実行形態の分類例
　　・ｵﾝﾗｲﾝ：ﾕｰｻﾞが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、レベル、メッセージ 等
　　　・ 管理方法
　　　　　例)　ﾃﾞｰﾀﾍﾞｰｽで管理。定義ﾌｧｲﾙで管理。ﾌﾟﾛｸﾞﾗﾑに埋め込み。等

・製品の選定
　・業務一覧で業務内容、非機能要件を踏まえているか確認する。
　・開発／運用面から有償・無償（オープンソース）製品の採用方針を検討する。
　・仮想環境の利用を検討する。
　・ﾈｯﾄﾜｰｸ／ｻｰﾊﾞ／ｽﾄﾚｰｼﾞ／ﾐﾄﾞﾙウェア
    各箇所の方式で不整合が発生していないか確認する
　・複数の製品を候補の比較検証を行う。
　・要件とコストを考慮して、採用製品・技術を決定する。
　
・HW/MW一覧
 決定したハードウェア・ﾐﾄﾞﾙウェアの情報を一覧化する。

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

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