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

2022年10月23日

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