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]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

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

にほんブログ村

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

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.本書の構成

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

4.はじめに（本書の目的）

非機能要件定義書の目的や位置づけなどについて記載します。※不要なら削除して構いません。

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. システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

8.アクセシビリティ

1. ウェブアクセシビリティ：ターゲットユーザのみではなく、本システムを利用する可能性のあるすべてのユーザ（高齢者や障碍者を含む）を考慮したデザインや操作性

9.可用性

可用性：（機器の故障・災害・アクシデントなどによる障害でシステムを停止させることなく稼働し続けること）について、（システム）継続性、業務継続性、目標復旧水準、稼働率、耐障害性、データの保護、災害対策について、それぞれの要件を確認して定義します。

1. 継続性：システム稼働時間や停止に関して（通常運用時間、計画停止（メンテナンス）スケジュールなど）
2. 業務継続性：可用性を保証するにあたり要求される業務範囲と条件（障害発生時のサービス切替時間など）、業務継続性の要求度合い
3. 目標復旧水準：業務停止を伴う障害発生時、何をどこまで、どの程度復旧させるかの目標 RPO(目標復旧地点）、PRT（目標復旧時間）、RLO（目標復旧レベル）など
4. 稼働率：明示された利用条件の下で、システムが要求されたサービスを提供できる割合（例）稼働率：99.99%
5. 耐障害性：サーバで発生する障害に対して、要求されたサービスを維持するための要求。機器、ストレージの冗長化、ネットワーク回線、経路の冗長化など
6. データの保護：データの保護方式（バックアップ方式）、データ復旧範囲、データインテグリティ：改ざんや偽装を防ぎ、データの完全性と正確性が客観的に担保されていること）
7. 災害対策：地震、水害、テロ、火災などの大規模災害時の業務継続性を満たすための要求※Salesforceがサービスとして提供している対策をベースに検討

10.規模・拡張性

1. 利用者：本システムの稼働時点の想定利用者、利用者数、利用時間帯、アクセス方式など　※将来の見込み数も算出
2. 業務処理量：日別・月間のオンラインリクエスト件数、バッチ処理件数、PV、アクティブ接続数、時間平均接続数、ピーク時の接続ユーザ数、同時接続数、帳票出力枚数（日別、月別）など
3. データ量：データ名称、データの種類、データ量（件数、サイズ）、発生頻度
4. データ保有期間：データの保有期間（社内規定や法令法規などによって定められている場合はその期間）
5. 拡張性：利用者、アクセス数、業務処理量、データの増減に応じたシステム（メモリ、CPU、ディスクなど）の拡張対応

11.性能要件

1. オンライン処理性能：画面のオンラインレスポンスタイム、スループットなどの指標と対象機能など
2. バッチ処理性能：バッチ処理の最大処理件数、ターンアラウンドタイム、時間当たり処理件数の指標（通常時、ピーク時）と対象機能など

12.上位互換性

1. バージョンアップ：（メジャー、マイナー）バージョンアップ時の上位互換の保証に関して（保証対象の機能、互換性が保証されない機能に対する対応、検証方法など）

13.中立性

1. 技術・製品（サービス）の利用に関して：ベンダーロックイン（特定の事業者（ベンダー）を利用し続けなくてはならなくて、他社の参入が困難な状態）を回避し、システムの中立性を担保するため、本システムで利用する技術や製品（サービス）に関しての要件※オープンで標準的なものを利用するなど

14.移行性

1. 移行スケジュール：移行スケジュール（移行計画から本番稼働までの移行全体のスケジュールを定義）、システム停止可能期間、平行稼働有無など
2. 展開方式：・複数拠点展開の場合の展開方式（単一拠点の場合は定義不要）、業務の展開方式（全業務一斉展開、または部分展開）
3. 移行対象、ボリューム：移行対象（業務、システム/機器、データ）　※データに関しては、移行対象のデータ名称、データ形式、データ量（件数、サイズ）
4. 移行リハーサル：移行リハーサルの範囲、環境、回数
5. 移行計画（書）：移行対象に関する移行計画書の作成について（計画書に記載する内容）、コンティンジェンシープラン

15.運用保守性

1. 運用監視：異常検知の実施有無、監視対象（システム、プロセス、DB、ストレージ、ネットワーク）、監視方式、間隔など
2. 運用時間、時刻同期：システム運用を行う時間、（利用者や管理者に開放する時間）、時刻同期設定の範囲、システム全体を外部標準時間と同期など
3. 運用負荷軽減：保守運用に関する作業を軽減するための要件、作業の自動化、ソフトウェア更新の自動化など
4. 障害時運用：障害時の運用（検知方法、報告ルート、対応窓口、復旧作業の整理）、対応可能時間、代替業務運用など
5. 運用環境：開発や試験（検証）目的の環境の用意、リモート監視の有無、対象、範囲など
6. サポート体制：保守対象（H/W,S/W）、ライフサイクル期間、メンテナンス役割、体制、サポート要員、操作訓練、運用報告内容に関して
7. その他運用方針：内部統制対応、サービスデスク設定、インシデント管理、問題管理、構成管理、への宇管理、リリース管理

16.セキュリティ

1. 前提条件：順守すべき情報セキュリティに関する規定やルール、法規法令、ガイドラインなど
2. セキュリティリスク分析・診断・管理：リスク分析範囲、セキュリティ診断、リスクの管理について
3. アクセス利用制限：アクセス認証方式、利用者/時間制限、ネットワーク制限、権限など
4. データの秘匿：機密性のあるデータについて、送信時や蓄積時の秘匿（暗号化）について
5. 不正追跡・監視：ログ取得対象、保持期間、IDS（不正侵入検知）・IPS（不正侵入防止）の検知、データ検証（デジタル署名）など
6. ネットワーク対策：ネットワーク制御、不正検知、サービス停止攻撃への対処
7. マルウェア、WEB対策：マルウェア（ウイルス、ワーム、ボット等）の感染防止、Webアプリケーション特有の脅威、脆弱性についての対策
8. セキュリティインシデント対応：セキュリティインシデントの早期発見、被害の最小化、復旧支援に関して

補足

これまで説明してきたフォーマットを使って要件の詳細を定義するとともに、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版）

要件定義_要件定義書_別紙4「非機能要件定義書」_20221016_v1.0（PPT版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

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

参考

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

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

続きを読む

サポーターさん

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

にほんブログ村