Salesforce要件定義の進め方（非機能要件）その１

要件定義の中でも非機能要件に関する要件のヒアリングやまとめ方に悩んでいる方のお問い合わせも多いため、今回は特にSaleseforce（セールスフォース）の要件定義工程で行う、非機能要件に関するヒアリングや要件の取り纏め方について説明していきたいと思います。

※非機能要件書のテンプレートもご用意しています。

一般的なシステム開発の非機能要件については、IPAが提供している非機能要求グレードをベースにヒアリングすることが多いと思います。

これまで何度か改訂されており、2018年が現時点の最新版になるかと思います。AWSなどのクラウドサービスに対しての非機能の評価軸が追加されています。

Salesforceに関する非機能要件定義

基本的に非機能要件として検討するべき事項に関しては、SalesforceであってもベースはIPAが提供する非機能要求グレードにあるような事項についての検討が中心となります。

１．検討すべき非機能の範囲

以下、「IPA（情報処理機構）が提供している「非機能要求グレードの（06_活用シート.xls）」より

この非機能要求グレード表を開いてみるとわかると思いますが、非機能として検討すべき項目や指標はかなりのボリュームがあります。

また、機能要件と異なり非機能は、インフラや運用系の知識や経験がないと理解するのが難しい用語なども含まれます。またお客様の規模や業務に対して、各非機能の指標値として何が適切なのかを検討していくためにもある程度の知識は必要になってくるかと思います。

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

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

そのため、このあたりの非機能要件定義では、セールスフォース・ジャパン社が提供する非機能の内容を説明することで代用することができます。

※１.Salesforce社の非機能要件に対する対応方針を説明する。

非機能要件定義

これまでは、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のトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

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

まとめ

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

次回は「性能・拡張性」に関する非機能要件の要件定義について説明していきたいと思います。

チロ

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

にほんブログ村