ネットワーク 基本 設計 書 書き方
ぴん りゃ ん げた だり帳票編集定義 帳票の編集方法を述べた資料。 改ページ: ページ替えを行うための条件 ヘッダー・フッター: ヘッダー・フッターの出力条件 項目編集: 項目の編集ルール。テーブル項目を単純に表示する場合は前述の「帳票出力項目一覧」を見ればいいので、ここには項目一覧では書けない複雑なルールのある項目に限定して記載する。 2-4. バッチ設計 バッチ設計として整理するのは下記3つ。 バッチ処理一覧は要件定義で整理すべき資料だが、整理できていない場合は基本設計で一覧表にまとめたい。基本設計では「バッチ処理フロー」「バッチ処理定義」が主な作業となる。 2-4-1. バッチ処理一覧 2-4-2. バッチ処理フロー ★ 2-4-3. バッチ処理定義 ★ 2-4-1. 基本設計における成果物一覧と書き方（基本設計書サンプルあり） | 若手エンジニアの羅針盤. バッチ処理一覧 プロジェクトで開発するバッチ機能を一覧にまとめた資料。 2-4-2. バッチ処理フロー バッチ処理の流れにおける入力・処理機能・出力を整理した資料。 処理をどう分けるかを検討することになるが、下記のようにデータ抽出・加工・更新といったように機能を分けておくと、テストをする際にデータベースを都度戻さなくてよいので効率が良くなる。 ① Aテーブルから単純にデータを抽出(テーブル更新無し) ② ①のデータ加工(テーブル更新無し) ③ ②のデータをBテーブルに更新 2-4-3. バッチ処理定義 バッチ処理フローの1つ1つの処理について、入力・処理・出力を整理した資料。 基本設計ではなく、詳細設計で作成する場合もある。 2-5. テーブル・ファイル設計 基本設計のテーブル・ファイル関連で作成する資料は下記の通り。 2-5-1. テーブル関連図(ER図) 2-5-2. テーブル・ファイル一覧 2-5-3. テーブル・ファイル定義 ☆ UD図 ★ 要件定義で主要なテーブルを整理したER図や一覧資料については、設計を進めるにつれて処理に必要なテーブルを追記することもある。 基本設計工程ではテーブル定義やCRUD図の整理が主な作業となる。CRUD図は整理する組織と整理しない組織が大きく分かれる印象があるが、整理しておくと機能漏れやデッドロックの防止につながる。 2-5-1. テーブル関連図(ER図) システムで取り扱うテーブル関係が分かる資料。 要件定義では主要なテーブルのみを記載したが、基本設計では機能実現に必要なテーブルをきっちりと書き出していく。一方で、プログラミングをしていく中で必要となるテーブルも出てくるので、その場合は別途資料を修正することになる。 2-5-2.
基本設計における成果物一覧と書き方（基本設計書サンプルあり） | 若手エンジニアの羅針盤
業務要件(※1) 1-1. システム化の目的・背景・狙い 1-2. ビジネスプロセス関連図 1-3. 業務機能構成表 1-4. ビジネスプロセスフロー 1-5. システム化業務フロー 1-6. 業務処理定義書 2. 機能設計 2-1. システム方式 2-1-1. ハードウェア構成図 2-1-2. ソフトウェア構成図 2-1-3. ネットワーク構成図 2-1-4. アプリケーション機能構成図 2-2. 画面設計 2-2-1. 画面一覧 2-2-2. 画面遷移図 2-2-3. 画面レイアウト 2-2-4. 画面入出力項目一覧 2-2-5. 画面アクション定義 2-3. 帳票設計 2-3-1. 帳票一覧 2-3-2. 帳票概要 2-3-3. 帳票レイアウト 2-3-4. 帳票出力項目一覧 2-3-5. 帳票編集定義 2-4. バッチ設計 2-4-1. バッチ処理一覧 2-4-2. バッチ処理フロー 2-4-3. バッチ処理定義 2-5. テーブル・ファイル要件 2-5-1. テーブル関連図 2-5-2. テーブル・ファイル一覧 2-5-3. テーブル・ファイル定義 UD図 2-6. 外部インターフェース設計 2-6-1. 外部システム関連図 2-6-2. 外部インターフェース一覧 2-6-3. 外部インターフェース定義書 2-6-4. 外部インターフェース処理概要 3. 非機能要件(※1) 3-1. 可用性 3-2. 性能・拡張性 3-3. 運用・保守性 3-4. 移行性 3-5. セキュリティ 3-6. システム環境・エコロジー ※1業務要件と非機能要件は、要件定義書が無い場合に基本設計工程にて整理する。要件定義書に書かれている場合は作成不要。 1. 業務要件に関わる成果物 業務要件の認識に違いがあると、機能追加や修正の発生するリスクが高くなってしまうため、本来は要件定義工程で業務要件を整理することが望ましい。 設計を進めていく中で業務要件の修正加筆が発生することもあるが、そういう場合はユーザー企業とITベンダとの双方合意の元で、要件定義書を修正するのが正しい流れである。 一方で、業務要件が整理できていない場合は、基本設計工程で要件を確認しなければならないため見積りブレのリスクは高くなる。だが整理できていないものは仕方ないので基本設計工程からでも要件を整理したい。 業務要件は下記5つの資料でまとめられる。 1.
■基本設計書 別名外部設計書。要件定義書を基に、設計の基本方針の策定を示したもの。 視点として、主にユーザ(顧客)向けに書かれるもので、打合せを実施しながらまとめていきます。 基本設計書にはネットワーク構成や冗長構成の基本的な考え方を記載します。 ※作り上げるシステムのレベルとユーザのレベルによっては、要件定義書と詳細設計書だけでも良いかもしれない。 ■詳細設計書 別名内部設計書。基本設計書を基に、実作業レベルまで内容を落とし込んだもの。 視点として、主にエンジニア向けに書かれるもので、基本設計書から具体的な設定内容を検討し、まとめていきます。 工程表(導入計画書)や試験設計についても盛り込むケースがあります。 例えば、ネットワークシステムであれば以下のような項目が考えられます。 ・ネットワーク構成図(物理・論理) ・IPアドレス設計(IPアドレス管理表) ・機器命名規則 ・通信プロトコル設計 ・ルーティング設計 ・冗長構成設計 ・優先制御設計 ・セキュリティ設計 ・管理/管理設計 ・導入/移行設計(工程表) ・etc.