サポーターさん

運用保守のサービス内容を検討する際にご利用ください。

1.テーラリングガイド

１．表紙（メッセージ定義書）

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．サービスカタログ（テンプレート）

サービスカタログの内容を定義するためのシートとなります。

【項目説明】

• サービス名称：サービス名称を定義（総称）
• サービス項目（詳細）：サービス名称について具体的なサービス項目（内容）を定義
• サービス提供内容：具体的な作業内容を定義
• 重要度：業務停止に係るような作業内容であればそのリスクを定義
• 提供時間：サービスの提供時間を定義
• サービス提供方法：メールやウェブサイトによる受付や、コールセンターを配置しての電話対応などを定義
• サービスレベル：MTBF、MTTR、MTTF、MTTA: インシデント指標を定義（※１）
• ※1.MTBF (平均故障間隔)、MTTR (復旧、修復、対応、解決までの平均時間)、MTTF (平均故障時間)、MTTA (平均確認時間) 
• 実施手順：具体的な作業実施手順や実施手順を記載したマニュアルの名称を定義
• 前提条件/制約事項：サービス提供のための前提条件や対応の制約事項など
• サービス提供担当：報告先、対応者（担当者）、責任者などを定義

4．サービスカタログ（サンプル）

サービスカタログのサンプル例を別シートに記載しています。

５．選択リスト

サービスカタログのシートで利用する選択リスト項目を定義します。

2.サービスカタログ（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

サービスカタログのダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか設計・開発に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

データベース設計や機能設計で利用するコード体系、コード値を定義する際にご利用ください。

1.テーラリングガイド

１．表紙（メッセージ定義書）

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

基本設計工程としていますが、プロジェクトの工程に合わせて適宜変更してご利用ください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．コード体系一覧

コード設計では、まずシステムで利用するコードの体系を整理します。コードは細かく分類すると複数の種類がありますが、ここではシンプルに2種類で分類しています。

主にプログラム等で自動採番する可変のコード値と、選択リストなどで定義する固定のコード値に分類しています。

コード定義する項目名とコード体系（コードを構成する要素の組み合わせ）を定義して、桁数や構成内容の細かい定義を説明しています。

【記載内容】

• 項目名：コード体系として定義する項目名（論理名）を定義します。
• コード体系：コードを構成する要素の組み合わせを定義します。
• 設定方式：自動採番か固定値かを定義します。
• 桁数：コードの最大桁数を定義します。
• 説明：コードの採番方式や構成要素に関する説明を記入します。
• 設定例：実際に定義されるコード値の設定例を記入します。
• 補足：コードに関する補足事項を記入します。

4．コード値定義

続いてのシートでは、具体的なコード値を定義していきます。コード値と説明（プログラムの制御やコードの意味を定義します。

【記載内容】

• • 項目名：コード名（論理名）を記入します。
  • 物理名（API参照名）：コードを選択リストなどで定義する場合のAPI参照名を記入します。
  • 設定場所：コード値を定義する場所を記入します。選択リストや選択リスト値セット（グローバル選択リスト）、プログラム内に固定など
  • コード値：コード体系で定義されているコード値を記入します。※ひとつのコード体系について複数の値がある場合は行を分けて記入します。
  • 説明（処理制御）：コード値のそれぞれの意味や処理制御で利用する場合の制御内容などを記入します。

４．コード利用状況一覧

コード体系とコード値の定義が完了したら最後にコード利用状況一覧を作成します

こちらでは、コードを利用する各機能/プログラムとの紐づけをマトリクス表に整理します。これを作成することにより、コード値を変更した場合にどの機能/プログラムに影響するか簡単に確認することができるようになります。（影響範囲の調査用）

• 機能ID：システム機能IDを記入します。
• 機能種別：機能の種類（画面、帳票、バッチ、APIなど）
• 機能名：システム機能名を記入します。
• プログラムID：プログラムIDを記入します。
• プログラム名：具体的なプログラム名（API参照名）を記入します。
• コード名：縦軸にはコード名を定義して、対象のコードが利用される機能に対して●をつけていきます。

2.コード設計書/コード定義書の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

設計_基本設計_コード設計書/コード定義書（EXCEL版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか設計・開発に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

設計工程で機能や処理で利用するオブジェクトやフィールドとの関連を定義する場合にご利用ください。

はじめに

1.CRUD図とは

CRUD図は、データベースやシステムの開発過程において使用されるモデリングツールです。CRUDとは、「Create（作成）」「Read（読み取り）」「Update（更新）」「Delete（削除）」の頭文字を取ったもので、データの基本的な操作を表しています。

CRUD図は、データベースやシステム内でどのようなデータ操作が行われるかを可視化するために使用されます。以下にCRUD図の要素とその役割について説明します。

1. エンティティ（Entity）: エンティティは、データベース内の特定のデータを表すものです。例えば、ユーザーや商品などがエンティティとして表されます。（※Salesforceではオブジェクトに該当します）

2. 属性（Attributes）: 属性は、エンティティが持つ特性やデータの要素を表します。例えば、ユーザーエンティティの属性には「名前」「メールアドレス」「パスワード」などが含まれます。※Salesforceでは、フィールドに該当します

3. 関連（Relationships）: 関連は、エンティティ間の接続や依存関係を示します。例えば、ユーザーエンティティと注文エンティティの間には「1対多の関係」があり、1つのユーザーが複数の注文を持つことができます。

4. 操作（Operations）: 操作は、CRUDの基本操作（作成、読み取り、更新、削除）を表します。それぞれの操作は、エンティティに対して行われるアクションを示します。例えば、ユーザーエンティティに対する操作として「新しいユーザーの作成」「ユーザー情報の読み取り」「ユーザー情報の更新」「ユーザーの削除」があります。

CRUD図の作成目的

1. データ操作の可視化: CRUD図は、データベースやシステム内で行われるデータ操作を視覚的に表現することで、開発者やステークホルダーにとって理解しやすくします。これにより、システムの要件やデータフローを明確にすることができます。
2. 設計の基盤: CRUD図は、データベースやシステムの設計の基盤となります。エンティティ、属性、関連などの要素を明確に定義することで、データベースのテーブル構造やシステムの機能を設計する際の指針となります。開発者やデータベース管理者は、CRUD図を参照してデータベースやシステムの設計や実装を行うことができます。
3. コミュニケーションとドキュメント化: CRUD図は、開発者やステークホルダーとのコミュニケーションツールとしても役立ちます。図によってデータ操作のフローを明確に示すことで、開発者間や関係者間での理解の共有が容易になります。また、CRUD図はプロジェクトのドキュメントとして使用され、後から開発やメンテナンスを行うためのリファレンスとなります。

データの整合性とセキュリティ: CRUD図は、データベースやシステム内のデータの整合性とセキュリティを確保するためにも役立ちます。

適切な関連性や操作の定義によって、データの整合性を保つことができます。また、CRUD図はアクセス権や機能制限の設計にも活用され、データのセキュリティを確保するための基礎となります。

1.テーラリングガイド

１．表紙（メッセージ定義書）

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

基本設計工程としていますが、プロジェクトの工程に合わせて適宜変更してご利用ください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．CRUDマトリクス表（機能ｘオブジェクト（エンティティ）レベル）

CRUDマトリクス表は、大きく2種類の粒度の設計書が存在します。1つ目は下記のようなエンティティ（オブジェクト）に対してのCRUDを定義するものとなります。

こちらは、各機能（またはプログラム）で、どのオブジェクトをどのような目的「Create（作成）」「Read（読み取り）」「Update（更新）」「Delete（削除）」で利用するかを定義した設計書となります。この資料を作成しておくことで、データベースに変更が入る場合に、どの機能/プログラムに影響があるのか簡単に確認することができます。

【記載内容】

• 機能ID：システム機能のIDを記入します。
• 機能種別：システム機能の種別（画面、バッチ、帳票、APIなど）を選択します。
• 機能名：システム機能の名称を記入します。
• プログラムID：プログラムのIDを記入します。
• プログラム名：具体的なプログラム名（物理名）を記入します。※1つの機能で複数のプログラムがある場合には全て羅列します。
• 業務領域：概念データモデルで定義したエンティティの纏めりを定義　（不要な場合は削除してもよい）
• エンティティ（オブジェクト）：システム全体のオブジェクトを列で定義します。（オブジェクト名は論理名と物理名（API参照名）の両方を定義しておきます）

4．CRUDマトリクス表（機能ｘ項目（フィールド）レベル）

２つ目のCRUCマトリクス表は下記のような項目（フィールド）に対しての機能/プログラムのCRUDを定義したものとなります。

こちらの場合は、項目数が多い場合には列がかなり長くなってくるため、可読性の観点から1つのエンティティ（オブジェクト）に対して、1シート単位で作成したほうが良いかもしれません。

また、処理単位で記載するようなサンプルとなっていますが、メンテナンスも大変なため、機能またはプログラム単位で作成してもよいでしょう。

【記載内容】

• • 機能ID：システム機能のIDを記入します。
  • 機能種別：システム機能の種別（画面、バッチ、帳票、APIなど）を選択します。
  • 機能名：システム機能の名称を記入します。
  • プログラムID：プログラムのIDを記入します。
  • プログラム名：具体的なプログラム名（物理名）を記入します。※1つの機能で複数のプログラムがある場合には全て羅列します。
  • 処理ＩＤ：プログラム内の処理ごとに採番されたＩＤを定義します。
  • 処理名称：プログラム内の処理名称を記入します。
  • 業務領域：概念データモデルで定義したエンティティの纏めりを定義　（不要な場合は削除してもよい）
  • エンティティ（オブジェクト）：システム全体のオブジェクトを列で定義します。（オブジェクト名は論理名と物理名（API参照名）の両方を定義しておきます）
  • 項目（フィールド）：オブジェクト内の項目を論理名と物理名（API参照名）で定義します。

４．メッセージ定義

最初にメッセージIDの設定ルールを定義しましたが、その定義内容に基づきメッセージ定義を作成していきます。

メッセージを利用するシステム、機能領域、種別（Sevirity）によってメッセージIDを定義します。

発生元：メッセージを出力するシステム/機能を定義します。

出力先：メッセージを利用する機能や出力先の画面などを定義します。

Sevirity（重要度）：メッセージの重要度を定義します。

メッセージ：出力するメッセージ内容を定義します。パラメータによってメッセージ内容を置換する場合には、パラメータで置き換える部分を{n}で定義してください。

2.CRUD的陸図表の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

設計_基本設計_CRUDマトリクス表（EXCEL版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

要件定義書（本編）が必要な方は、こちらの記事からダウンロードいただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.はじめに

申し送り事項一覧に関しては、前の工程で決まり切らなかった仕様や課題などについて、後工程で検討するために記録して残しておくものとなります。

要件定義工程では、要求事項を取り纏めますが、詳細な設計などについては、設計工程以降で検討する内容となりますので、申し送り対象として記録しておきます。

そのほかには、本来要件定義で決めるべきものが、決めきれなかったりした場合にも後続フェーズで引き続き検討が必要な場合がありますので、この場合にも申し送りとして記録しておきます。

1.申し送り事項一覧（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更（例では、「移行要件定義書」として設定）

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

2.改訂履歴

3.本書の構成

プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

もしくは、要件定義以外でも申し送り事項として利用する場合もあると思いますので、その場合本書の構成は不要であれば削除してご利用ください。

4.申し送り事項一覧

申し送り事項について、一覧形式で以下の内容を記録していきます。

• No.：シーケンスで番号を登録しておきます。
• カテゴリ：申し送りの種別（課題、仕様検討、タスクなど）を定義します。複数のカテゴリが必要であれば列を追加して大中小などで管理してください。
• 件名：申し送りの内容がすぐにわかるようにタイトルをつけておきます。
• 申し送り内容：申し送りの内容を記入しますが、後工程で担当者が変わる場合には内容がわかるように丁寧に記載しておく必要があります。
• 申し送りの経緯（理由）：申し送りとなった経緯や理由があれば記載しておきます。
• 起票者：申し送りを記入した担当者の名前を記入
• 起票日：申し送りを記入した日付を入力
• 承認者：申し送りの内容について承認した方の名前を記入します。（基本的にはお客様のプロジェクト責任者を記入）
• 承認日：申し送りの内容が承認された日付を入力
• 備考：備考があれば記入

以上となりますが、上記以外に必要な添付ファイルがあれば、別紙や補足資料としてページを追加しておきましょう。

2.テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料（PPT版）

要件定義_要件定義書_別紙9「申し送り事項一覧」（Excel版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

最近では、ファイルのやりとりに関しては、クラウドサービスを介しての受け渡しも増えているため、サービスによっては、ファイルの版数やアップロード日、担当者などの情報が可視化されていると思います。

まだ、そういった管理ができていない場合には、誰から、いつ、何を受領したのか整理して管理する必要があると思います。

その場合には、今回ご提供する受領資料管理簿のようなものを利用してドキュメントを管理しておくとよいでしょう。

Salesforce（セールスフォース）プロジェクト以外でもぜひご活用ください。

1.サンプル

1.受領資料管理簿

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

3.受領資料管理簿

受領資料管理簿では、以下の内容を記述して管理します。

No.：サンプルでは連番としていますが、これ以外にドキュメント管理番号を管理したい場合には、列を追加して管理項目を追加してください。

受領ドキュメント名：ドキュメントの名称

説明：ドキュメントの内容についての説明文

種別：ドキュメントの種類（Excel、PDF、PPT、Wordなど）

版数：ドキュメントのバージョン管理を行う場合は版数

受領元：ドキュメントの提供者

受領日：ドキュメントの受領日

受領者：ドキュメントの受領者

情報種別：社外秘や公開などの取り扱い区分を記載

保管場所：ドキュメントの保管場所を記載（格納サービスや具体的なフォルダのパス）

備考：その他備考

2.受領資料一覧のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

設計工程でシステムやアプリケーションのメッセージを定義する場合にご利用ください。

メッセージ設定書と合わせてコード定義書のテンプレートもご利用ください。

Excel版

要件定義_要件定義書_別紙1「業務フロー図」（Excel版）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.テーラリングガイド

１．表紙（メッセージ定義書）

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

基本設計工程としていますが、プロジェクトの工程に合わせて適宜変更してご利用ください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．メッセージID設定ルール

はじめにメッセージIDの設定ルールについて記載しています。

メッセージIDの構成について本サンプルでは以下のように定義しています。

本プロジェクトで利用するシステムメッセージは、システムID＋機能領域ID＋Sevirity（重要度）＋3桁連番の組み合わせで定義する

メッセージの利用方法については以下のように定義しています。

メッセージIDをプログラムで利用する場合には、事前にカスタム表示ラベルにメッセージIDや定義内容を設置してから利用すること

プロジェクトの開発方針によっては、Apexで利用する場合には、Apexクラス内で固定メッセージを定義して利用する場合もあると思いますが、その場合には、定義しているApexクラスの内容も本設計書に追加するとよいでしょう。

４．メッセージ定義

最初にメッセージIDの設定ルールを定義しましたが、その定義内容に基づきメッセージ定義を作成していきます。

メッセージを利用するシステム、機能領域、種別（Sevirity）によってメッセージIDを定義します。

発生元：メッセージを出力するシステム/機能を定義します。

出力先：メッセージを利用する機能や出力先の画面などを定義します。

Sevirity（重要度）：メッセージの重要度を定義します。

メッセージ：出力するメッセージ内容を定義します。パラメータによってメッセージ内容を置換する場合には、パラメータで置き換える部分を{n}で定義してください。

７．メッセージ利用状況一覧

最後に、メッセージを利用するプログラムとの紐づけを行います。メッセージを変更したり削除した場合にどのプログラムに影響するか把握するためのものとなります。

2.メッセージ設計書（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

※ダウンロードのリンクをクリックすると自動的にファイルのダウンロードが開始されます。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

PPT（パワーポイント版）のテンプレートはこちらで提供しています。

参考

Salesforce導入プロジェクト 要件定義書_別紙4「非機能要件定義書」テンプレート

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.はじめに（非機能要件の検討にあたって）

非機能要件の検討にあたっては、非機能要求事項の全体像を把握している必要があると思います。

非機能要件の検討が初めてという方は、以下IPAが提供する非機能要求グレードのエクセルから全体像とそれぞれの要求事項の中の定義を再確認しておくことをお勧めします。

図１「IPA（情報処理機構）非機能要求グレードの（06_活用シート.xls）「https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html」

上記のエクセルには、システム導入にあたって検討するべき非機能の全体像を確認することができます。

資料をダウンロードして全体をみていただくとわかると思いますが、非機能要件で検討するべき項目はかなりのボリュームがあります。

行政機関や金融機関など、かなりの大規模案件で、非常に高いセキュリティなどが求められるのシステム開発では、かなり詳細までこれらの全体像にたいして検討する必要が出てきますが、非機能の検討だけでかなりの期間や工数を要する作業となり、またインフラやセキュリティなど高度な専門性が求められる領域でもあるため、中規模以下の案件では、これらの中から最低限検討するべき非機能についてのみ検討・実施を行うというのが現状かと思います。

幸いなことにSalesforceはパブリッククラウドサービスのため、多くの非機能に関する要件はSalesforce側で自動的に制御、運用される部分が多いため、一般的なシステム開発と比べて検討すべき事項はかなり絞り込まれます。

※Salesforceのヘルプサイトなどを検索すると非機能要求に対するSalesforceとしての回答も記載されているものがあるので、非機能要件の検討の際にはその回答ベースに検討を行うこともできます。

上記の図でセールスフォースは、SaaS型サービスのため、ハードウェア、ネットワーク、負荷分散、障害対策など管理が難しい部分は、全てSalesforceのサービスとして管理・運用されます。

まず、基本はお客様のRFPで提示されている非機能の要求事項に対しては必ず検討対象とし、その他、権限やセキュリティなどリスクが高い項目については最低限検討すべきかと思います。

また、業務内容によっては、処理性能や高いユーザビリティなどが求められることもあるため、業務要件の整理の際に検討するとよいでしょう。

1.非機能要件定義書（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

2.改訂履歴

3.本書の構成

要件定義書の別紙４として非機能要件定義書を定義していますが、プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

5.RFPの要求仕様（非機能要求）

最初に、RFPで要求されている非機能要件がある場合には、その内容を定義しておきます。

最低限こちらに記載の要件については要件定義の中で検討する必要があります。

6.非機能要求の分類

続いては、本書で取り扱う非機能要求とその分類を定義しています。

上記のように種別１が1から10までの定義となっており、種別1の中でさらに種別2として詳細な要求種別として定義しています。

非機能要件の分類の分け方については、IPAの非機能要求グレードの整理をベースとするとよいでしょう。

纏め方や呼び方はプロジェクトや作成者によって多少異なると思いますが、それぞれのカテゴリの中で検討すべき事項が網羅されていて、わかりやすく定義されていれば問題ないです。

7.非機能要件詳細

ここからは各非機能の要求種別に応じて、具体的な要求仕様を定義します。

ユーザビリティに関する記載例

1. 利用者（ユーザ）の定義：本システムを利用するユーザの所属、組織構成（階層）、担当業務、役割（申請の承認）、作業内容など（例）組織：本部　役割：全国各支部の活動状況の把握・分析　/　利用ユーザ：100名　ユーザ特性：Excelなどは使い慣れているがBIツールなどの利用経験なし
2. クライアント端末：ユーザが利用するクライアント端末（PC/スマホ/タブレットなど）、利用者、利用場所など（例）PC端末（OS：Windows10、ブラウザ：Chrome最新バージョン）、社用携帯（iPhone/Android）、タブレット（iPad）
3. 使いやすさを求められる業務処理：システムの使いやすさを求められる業務や処理（例）システムの使いやすさを求められる業務や処理について、Salesforceのプロトタイプを作成して、システムを利用する現場のユーザの方の意見を聞きながらアジャイル的に開発を行い、UI/UXの改善を図るなど
4. 操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
5. 入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
6. システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

補足

これまで説明してきたフォーマットを使って要件の詳細を定義するとともに、Salesforceの非機能要件への対応方針やプロジェクト個別の対応方針など具体的な施策に関しては、上記とは別に詳細な資料を作成して説明するとよいでしょう。

例えば、可用性については以下の例のような資料を作成して説明するなど。

１．可用性（継続性・耐障害性・災害対策・回復性）

Salesforce（パブリッククラウドサービス）を利用するため、指定日時でのメンテナンスの制御はできません。

基本的にサービス提供ベンダーのサービス提供方針に従うことになります。

Salesforce社の可用性に関するサービス提供方針は、常に最新の状況を確認するようにしてください。

（１）Salesforce.comのサービス可用性

サービス提供時間：24時間365日（計画停止/定期保守を除く）

※セキュリティ対応やシステム稼働に重要な影響がある場合は、事前通知の上、緊急メンテナンスを実施する可能性有り

計画メンテナンスについては、現時点でSalesforce公式サイトを確認すると「暦月の第 1 週末と第 3 週末」と記載されています。

※リージョンやインスタンスによって実施日時が変わる可能性があります。

稼働率は過去の実績で99.9％を維持しています。現時点のインスタンスの稼働状況については、Trustサイトにて確認していただく運用となります。

https://trust.salesforce.com/ja/

継続性・耐障害性

可用性の各項目については、開発ベンダー側では制御できない内容となるため、基本的にSalesforce社の可用性に対する回答の内容を説明するだけとなります。

【重要】Salesforceは、実績として99.9% の稼働率となっていますが、セールスフォース社としては、SLAや個別契約などで可用性に関して担保するようなサービスは提供していません。（※2022年3月現在）

そのため、同社が提供するサービスとしての可用性はこのようになっていますという説明とともに、制約事項として承諾していただく必要があります。

リアルタイムのサービスの運用状況やインシデント、メンテンナンス状況については、Salesforceが提供する以下、「Salesforce Trustサイト」にて、運用担当者にて確認してもらう運用が基本となることを合わせて説明しておくほうがよいでしょう。

各サービス（機能）のステータスは色で判断することができます。

※以下、公式サイトより

Salesforeのハードウェアやネットワーク構成など基本的に非公開にされているため、基本的には以下のような記述をして説明します。

Salesforceサービスは拡張性と冗長性にすぐれているため、需要の変動やユーザの増加にも対応できるうえ、長時間のサービス停止リスクも大幅に軽減されます。設計面では、ネットワークの負荷分散、アプリケーションサーバのプール、およびデータベースのクラスタ化を特徴とします。

災害対策、回復性

事業（業務）継続性の要件として、災害対策の検討がありますが、Salesforceのサービスは単一拠点（一か所）での障害によって、サービスが中断してしまわないように地理的に離れた場所に複数のデータセンターが設けられています。

またSalesforceのトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

上記のように図やデータなどで示して説明するとよいと思います。

など。

サポーターさん

各非機能要件に対する具体的な定義例や補足資料のサンプルは別途記事を作成してご紹介したいと思います。

今回はここまでとなります。

2.テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料（PPT版）

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

サポーターさん

業務要件定義で業務フローを作成する際に合わせてご利用ください。

業務フロー図のエクセル版は以下の記事からダウンロードしてご利用いただけます。

Excel版

要件定義_要件定義書_別紙1「業務フロー図」（Excel版）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

PPT版

要件定義_要件定義書_別紙1「業務フロー図」（PPT版）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

要件定義書（本体）は以下の記事からダウンロードしてご利用いただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.テーラリングガイド

１．表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．本書の構成

要件定義書の構成に合わせて修正してください。

※今回は、要件定義書の別紙として定義しているため、上記の構成資料を用意していますが、単独で利用する場合には不要です。

４．目次

必要なビジネスルール（業務ルール）の数に合わせて、目次を定義してください。

５．はじめに（目的・概要）

はじめに本書の作成に関する目的や概要を記載します。※省略しても構いません。

６．ビジネスルール一覧

ビジネスルール定義書の中で、定義するルールを一覧化します。

業務領域、ビジネスルールID、ビジネスルール名、説明など、プロジェクトに合わせて必要な項目の定義を変更してください。

また、業務フロー図と合わせて用いる場合には、業務フロー内で利用している一意の番号を定義しておくとよいでしょう。

７．ビジネスルール（業務ルール）定義

ビジネスルール一覧で定義したビジネスルール（業務ルール）それぞれについて、一つずつ詳細なルール内容を定義します。

上記の例では、物販・飲食・宿泊・輸送などのサービスを対象とした割引制度の例を記載しています。

割引であれば、割引名用や対象とするサービスは何か、適用条件は何か、割引率の計算式は何かといった具合に業務上のルールを明確に定義します。

８．添付ファイル（Appendix）

業務ルールの説明資料の添付ファイルとして利用するものがあれば、添付ファイルの一覧に定義します。

2.要件定義_要件定義書_別紙2「ビジネスルール定義書」（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

※ダウンロードされるまで少し時間がかかる場合があります

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

要件定義書（本体）は以下の記事からダウンロードしてご利用いただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.利用方法

１．表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．業務フロー（凡例

業務フロー図として利用する図形についての説明を凡例として記載します。

４．業務プロセスのレイヤー定義

上記のように、一般的には業務プロセスは大きく3段階（大分類、中分類、小分類）にレイヤーを分けて、大分類の大きな流れから中小へとブレークダウンして整理していきます。

図で可視化するほうがわかりやすいですが、表形式でまとめても構いません。

５．業務フロー（プロセス詳細）一覧

業務フロー図として定義する範囲を業務プロセス一覧として一覧化します。

それぞれのプロセスでどこからどこまでの業務をカバーするのかわかるように定義してください。

参考）業務フローサンプル（販売管理）

サンプルとして業務フロー図を記載していますが、業務フロー図の書き方や粒度はプロジェクトの方針に沿って変更してください。

だれが、なにを、いつ、なんのために行うのか（時系列とアクター）をしっかり意識して抜け漏れがないように作成していきましょう。

2.要件定義_要件定義書_別紙1「業務フロー図」のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

※ダウンロードされるまで少し時間がかかる場合があります

以下は、スプレッドシートでの表示となります。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

1.ドキュメントサンプルイメージ

画面遷移図

１．利用方法に関する説明

【凡例】では、ログインやホーム画面などシステム共通の画面はオレンジ色とし、リストビューは黄色にするなど、画面の種別によって色分けをしています。

画面遷移図では、システム全体の画面遷移を確認するため細かい情報や矢印を増やしすぎると可読性が低くなってしまうため注意しましょう。

例えば、Salesforce標準画面では、リストビューからレコードを選択して参照画面へ遷移する、もしくはボタンクリックで新規レコードを作成することも可能ですが、画面間の遷移は同一としています。

また標準画面では、新規作成・参照・編集・削除の機能がありますが、これらも同一画面の処理と定義して、コメントを追加しています。

このようになるべくまとめて記載し、どうしても説明が必要なところはコメントなどで補足するくらいがよいでしょう。

画面遷移の方法や制御条件などは、画面定義書を作成する際に、主画面と関連する画面間の画面遷移図を定義するとよいでしょう。

まとめ

画面遷移図と合わせて、画面一覧や画面定義書などの設計書を作成すると思いますので、それらのテンプレートが必要な場合は、以下の記事からダウンロードしてご利用ください。

参考

画面一覧（Excelテンプレート）エクセル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。 また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

3.画面一覧（Excel版）テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

以下は、スプレッドシートでの表示となります。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村