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

2022年10月23日

本記事では、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.本書の構成

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

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

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

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の改善を図るなど
操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

8.アクセシビリティ

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

9.可用性

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

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

10.規模・拡張性

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