本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙4「非機能要件定義書」の資料の説明とエクセル版のテンプレートのダウンロード方法を説明いたします。
PPT（パワーポイント版）のテンプレートはこちらで提供しています。
-
-
参考Salesforce導入プロジェクト 要件定義書_別紙4「非機能要件定義書」テンプレート
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が提供する要件定義書_別紙4「非機能要件定義書」の資料の説明とダウンロード方法を説明いたします ...
続きを見る
1.はじめに（非機能要件の検討にあたって）
非機能要件の検討にあたっては、非機能要求事項の全体像を把握している必要があると思います。
非機能要件の検討が初めてという方は、以下IPAが提供する非機能要求グレードのエクセルから全体像とそれぞれの要求事項の中の定義を再確認しておくことをお勧めします。
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で要求されている非機能要件がある場合には、その内容を定義しておきます。
最低限こちらに記載の要件については要件定義の中で検討する必要があります。
参考
【可用性】
システム稼働率（SLA）：99.9% サービス提供時間：24時間365日
耐障害性：ネットワーク、ハードウェア含め冗長化構成を検討し、単一障害を回避できる仕組みとすること
復旧水準：
RPO（目標復旧時点）：障害発生時点
RTO（目標復旧時間）：3時間以内
RLO（目標復旧レベル）：B2Cに関する全ての業務
【規模】 ユーザ数（会員数）：ｘｘ / 月間登録者数：ｘｘ / 月間アクティブ利用者数： ｘｘ
【性能】 オンラインレスポンスタイム：3秒以内（順守率は通常時で90%、ピーク時70%程度の目標）
6.非機能要求の分類
続いては、本書で取り扱う非機能要求とその分類を定義しています。
上記のように種別１が1から10までの定義となっており、種別1の中でさらに種別2として詳細な要求種別として定義しています。
非機能要件の分類の分け方については、IPAの非機能要求グレードの整理をベースとするとよいでしょう。
纏め方や呼び方はプロジェクトや作成者によって多少異なると思いますが、それぞれのカテゴリの中で検討すべき事項が網羅されていて、わかりやすく定義されていれば問題ないです。
7.非機能要件詳細
ここからは各非機能の要求種別に応じて、具体的な要求仕様を定義します。
ユーザビリティに関する記載例
- 利用者（ユーザ）の定義：本システムを利用するユーザの所属、組織構成（階層）、担当業務、役割（申請の承認）、作業内容など（例）組織：本部 役割：全国各支部の活動状況の把握・分析 / 利用ユーザ：100名 ユーザ特性：Excelなどは使い慣れているがBIツールなどの利用経験なし
- クライアント端末：ユーザが利用するクライアント端末（PC/スマホ/タブレットなど）、利用者、利用場所など（例）PC端末（OS：Windows10、ブラウザ：Chrome最新バージョン）、社用携帯（iPhone/Android）、タブレット（iPad）
- 使いやすさを求められる業務処理：システムの使いやすさを求められる業務や処理（例）システムの使いやすさを求められる業務や処理について、Salesforceのプロトタイプを作成して、システムを利用する現場のユーザの方の意見を聞きながらアジャイル的に開発を行い、UI/UXの改善を図るなど
- 操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
- 入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
- システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など
補足
これまで説明してきたフォーマットを使って要件の詳細を定義するとともに、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（Excel版）のダウンロードはこちら
まとめ
そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。
-
-
参考ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧
サポーターお問合せ・ご要望いただいているコンテンツも頑張って作成しているので、もうしばらくお待ちください ダウンロード可能なコンテンツ一覧 提供しているテンプレートと公開範囲は以下の通りとなっています ...
続きを見る
