要件定義

Salesforce要件定義の進め方(非機能要件)その1

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

※別途、非機能要件についてのテンプレートもご用意する予定です。

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

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

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

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

1.検討すべき非機能の範囲

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

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

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

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

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

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

No. 大分類 中分類 小分類 備考
1 可用性 継続性 運用スケジュール/業務継続性/目標復旧水準/稼働率 ※1
2 耐障害性 サーバ/端末/ネットワーク機器/ネットワーク/ストレージ/データ ※1
3 災害対策 システム/外部保管データ ※1
4 回復性 復旧作業/可用性確認 ※1
5 性能・拡張性 業務処理量 通常の業務処理量/業務量増大度/保管期間 顧客ごとに個別検討
6 性能目標値 オンラインレスポンス/バッチレスポンス(ターンアラウンドタイム)/オンラインスループット/バッチスループット/帳票印刷能力 性能目標値については、Salesforce標準機能とアドオン機能で分けて考える
7 リソース拡張性 CPU拡張性/メモリ拡張性/ディスク拡張性/ネットワーク/サーバ処理能力増強 ※1
8 性能品質保証 HWリソース専有の有無/性能テスト/スパイク負荷対応 マルチテナントの制限を説明、性能テストは実施方法含め検討(負荷テスト実施の際は、SFDC社サポートとの調整が必要)
9 運用・保守性 通常運用 運用時間/バックアップ/運用監視/時刻同期
10 保守運用 計画停止/運用負荷削減/パッチ適用ポリシー/活性保守/定期保守頻度/予防保守レベル SFDCの計画停止や年3回のバージョンアップや緊急対応などについて記述
11 障害時運用 復旧作業/障害復旧自動化の範囲/システム異常検知時の対応/交換用部材の確保 SFDCの障害対応と復旧に関する対応方針を記述
12 運用環境 開発用環境の設置/試験用環境の設置/マニュアル準備レベル/リモートオペレーション/外部システム接続 環境の運用方針については、プロジェクトごとの方針を定義、どの工程でどの環境を利用するなど
13 サポート体制 メンテナンス作業役割分担/一次対応役割分担/サポート要員/導入サポート/オペレーション訓練/定期報告会 稼働前のユーザトレーニングや運用保守フェーズのサポート内容についての検討結果を記述
14 その他の運用管理方針 サービスデスク/インシデント管理/問題管理/構成管理/変更管理/リリース管理 構成管理、変更管理、リリース管理などの管理全般に関しての方針を記述
15 移行性 移行時期 移行のスケジュール 移行関係作業のマスタスケジュールを提示する。詳細は後続フェーズで検討
16 移行方式 システム展開方式 展開方式(一括移行か段階移行)を定義
17 移行対象 業務、システム(機能)、移行データ量 移行は、新業務への移行、システム(機能)の移行、データの移行の3つの軸で検討
18 移行計画 作業分担、リハーサル、トラブル対応
19 セキュリティ 前提条件・制約条件 情報セキュリティに関するコンプライアンス ※1
20 セキュリティリスク分析 セキュリティリスク分析 ※1
21 セキュリティ診断 セキュリティ診断 標準部分はSFDCのセキュリティ対策で対応方針とし、個別開発した機能やサービスについて、別途第三者の専門機関による診断などを実施するかという観点で検討
22 システム環境・エコロジー システム特性 ユーザ数、クライアント数、拠点数、システム利用範囲、複数言語対応

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

非機能要件定義

これまでは、Salesforce導入プロジェクトで検討するべき非機能についての全体像を説明しました。

多くの非機能要件の事項にかんしては、セールスフォース社が提示している非機能要件に対する回答をベースに説明・検討を進めることができるということがご理解いただけたかと思います。

ただし、それ以外にもお客様やプロジェクトの特性に応じて、個別に検討するべき非機能も少なくはないため、それぞれ検討するべき内容の詳細は理解しておく必要があります。

ここからは、各非機能要件について具体的にどのように要件定義していくか説明していきたいと思います。

1.可用性(継続性・耐障害性・災害対策・回復性)

継続性・耐障害性

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

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

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

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

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

※以下、公式サイトより

参考

  • 緑 (利用可能): このインスタンスは利用可能であり、完全に機能しています。
  • 青 (情報メッセージあり): パフォーマンスの問題またはサービスの中断ではないインスタンスに関する情報。
  • 紫 (メンテナンス): このインスタンスは現在メンテナンス中です。メンテナンス中のインスタンスの利用可能状況についてのメッセージが表示されます
  • 黄 (パフォーマンスの低下): インスタンスは利用できますが、特定の機能が使用できない場合や、サービスが大幅に遅延して実行されている可能性があります。
  • 赤 (サービス中断): お客様がインスタンスを利用できない状態です。

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

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

災害対策、回復性

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

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

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

まとめ

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

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

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

にほんブログ村 IT技術ブログへ
にほんブログ村

-要件定義
-, , , , ,