非機能要件定義書の書き方について
こんにちは、株式会社SHIFT ITソリューション部インフラサービスグループの沖宗です。
今回は非機能要件定義書の書き方について、記載すべき項目や注意点等をご紹介させていただきます。
非機能要件とは、「機能以外の全ての要件」のことを指す。 機能要件が「システム構築にあたり、顧客が必要とする機能の要件」であるのに対し、非機能要件は「必要とする機能以外の要件」を指す。例えば、性能や可用性、セキュリティなどが上げられる。非機能要件定義書は機能以外の全ての要件を記載し、開発ベンダーに発注者が構築したいシステムの要件を伝え、発注者が望むシステムにより近づけるためのドキュメントである。
以下に非機能要件定義書に記載すべき項目、内容を記載する。
1.システムの利用者の特性及びユーザビリティ・アクセシビリティに関する要件
①システム利用者の特性
サブシステム毎の利用者について触れ、それぞれのシステムを利用する人について、役割を定義する。
システムを使いやすくするために画面の構成や操作のしやすさ、エラー表示、ヘルプ機能についての要件を規定する。
視認のしやすさ、使用言語等に関する要件を記載する。
2.方式に関する要件
①システム構成の全体方針
サブシステム毎にオンプレミスとするのか、可能であればクラウドにするのかを記載する。オンプレの場合はどのようなサーバを採用するのか、仮想化をするのか、物理サーバとするのかも記載する。仮想化等についても特に要件がない場合でも、次の更改時にはクラウドに移行するような計画がある場合には、クラウド移行へのステップとするため、できるだけ仮想化を望む等の要件を記載する。
アプリケーションの設計方針について、疎結合に関する要件、ブラウザに関する要件等を記載する。
ソフトウエア製品に関する要件について、製品の選定に関する要件を記載する。
文字コードに関する要件、和暦、西暦に関する要件、外字フォント等に関する要件を記載する。
ログの保管期間、保管場所、帳票の有無、ある場合には保管期間等について記載する。
②開発手法について
開発手法について、ウォーターフォール型とするのか、アジャイル開発とするのか等の要件を記載する。
他に画面の開発方式としてプロトタイピング等の方式を望むのか等の要件も記載する。
他の項目についても言えることだが、記載にないものをベンダー側が提案する場合には、当社の承認を得てから採用することとする、等の記載を入れておく。
③環境について
本番環境、開発環境、場合によってはテスト環境等に関する要件を記載する。
3.規模に関する要件
①機器等の種類、数、設置場所について
機器の種類、それぞれの用途、台数、設置場所に関する要件を記載する。
②データ量について
サブシステム毎のデータ量に関する要件を記載する。データ量の増加が見込まれる場合には過去数年の増加率から、新システムの使用終了年度のデータ量を予想して記載する。
③処理件数
サブシステム毎の処理件数（トランザクション数）に関する要件を記載する。データ量と同様に処理件数の増加が見込まれる場合には、将来の予想値を算出する必要がある。
④利用者数
サブシステム毎の利用者数に関する要件を記載する。増加が見込まれる場合には将来の予想値を記載する。
4.性能に関する要件
①システムからの応答時間
画面のレスポンスタイム（通常時、縮退時）に関する要件を記載する。
バッチの処理時間に関する要件を記載する。
5.信頼性に関する要件
①可用性に関する要件
システムの稼働率について、何%以上の稼働率とするのかを記載する。
サブシステム毎に稼働率の要件が異なるのであれば、それ毎に記載する。
②完全性に関する要件
データの消失や改変、毀損に関する要件を記載する。
6.拡張性に関する要件
①性能の拡張性に関する要件
処理能力の拡張性に関する要件を記述する
②機能の拡張性に関する要件
システムの機能やデータベース等の拡張性に関する要件を記述する
7.調達の中立性等関する要件
特定ベンダーに依存しない構成であったり、調達が困難な製品の使用等についての要件を記載する。またアプリケーションプログラムの使用言語に関する要件がある場合にはここに記載する。
8.継続性に関する要件
障害発生時の切替時間に関する要件を記載する。また障害発生時の復旧地点に関する要件も記載する。復旧時間については、単一障害なのか、大規模災害発生時なのか等も分けて記載する必要がある。
9.セキュリティに関する要件
①セキュリティ対策に関する要件
ログ取得に関する要件
システムの不正利用を防ぐためのアクセス権の管理や役割に応じた権限設定等に関する要件を記述する。
気密性、完全性に関する要件
通信の暗号化要否や情報漏洩を防ぐための対策に関する要件を記載する。
セキュリティ規則への準拠
準拠すべきセキュリティ規則やポリシーがある場合にはその旨を記載する。
認証に関する要件
SSO（シングルサインオン）を求める場合にはその方式等について記述する。
脆弱性対策に関する要件
開発終了時に脆弱性のチェックを必要とする場合にはその旨を記載する。
本番稼働後の脆弱性対策（パターンファイルの更新等）を実施する場合にはその要件を記載する。
不正プログラムに対する対策
ウイルスやワーム等の脅威に備えるための要件
ランサムウェアやDDoS攻撃を防ぐための要件
情報セキュリティが侵害された場合の対処に対する要件
10.情報システム環境に関する要件
①クラウド構成要件
クラウド事業者の選定に関する要件
リージョンやアベイラビリティゾーンに関する要件
②サーバ構成に関する要件
バックアップに関する要件
バックアップデータをどの位の頻度で取得して、どこに保存するのか等の要件を記載する。
ジョブ管理に関する要件
ジョブ管理を行うサーバはどこに配置するのか等の要件を記載する。
③端末構成に関する要件
PCの性能等について
CPU性能、メモリー、ディスク容量に関する要件を記載する。
LANボード、キーボードの配列、映像出力、音声出力、Webカメラの有無、スピーカーの有無、USBインターフェイスについて記述する。
タブレットの性能について
CPU性能、メモリー、ディスク容量に関する要件を記載する。
通信機能、映像出力、音声出力、Webカメラの有無、スピーカーの有無、重さや大きさの上限等について記述する。
④ソフトウエア構成要件
（サーバ環境）
OSの種類やバージョン、ウイルス対策ソフト、他の必要なソフトウエア関する要件を記載する。
（クライアント環境）
OSの種別やバージョン、Webブラウザーの種別、MS Officeの要否、PDFリーダーの要否、ウイルスソフトに関する要件を記述する。
⑤ネットワーク構成要件
ネットワークの冗長構成の要否等に関する要件
通信プロトコルに関する要件
システム毎にネットワークを分割するのか、しないのか等の要件
責任分界点
システム毎の責任分界点に関する要件
11.試験に関する要件
(開発工程）
①単体試験
開発ベンダーが行う単体試験に関する要件を記述する。
②結合試験１
開発ベンダーが個別システムを結合し、システム間の連携等を行う試験に関する要件を記述する
③結合試験２
試験ケースに基づいたシナリオテスト等に関する要件を記述する。
（全体接続試験）
・個別システムを全て結合し、全体を通した接続試験に関する要件を記述する。
・本試験の主体者に関する要件も記述する。
（受入試験）
・システムの発注者が主体となって行う試験であるが、開発ベンダーに対する支援の要望、サポート体制の要望等があれば、ここに記述する。
（運用試験）
・システムの運用の視点に立って行う試験だが、開発ベンダーに対する支援体制等の要件があればここに記載する。
（全体）
・試験における役割分担
それぞれの試験における登場人物（団体、会社）と主担当、支援等の役割に関する要件を記載する。
12.移行に関する要件
移行に関して、移行するデータの範囲、タイミング、体制等の要件を記載する。
移行フェーズ 移行準備、移行リハ、事前作業、本番移行、稼働後の確認等に関する要件を記載する。また本社や支店、拠点がある場合には、それぞれの場所における移行方針に関する要件を記載する。
13.引継ぎに関する要件
①引継ぎ方針
開発ベンダーから発注者の運用部門等への引継ぎに関する要件を記載する。
②引継ぎ内容
各種手順について、どの部門にどのサブシステムの内容を引き継ぐのか等の要件を記載する。
14.教育に関する要件
システムの利用者に対する教育についての要件を記載する。どのような教材で、どのようなレクチャーを、どの部門に求めるのか等を記載する。
15.運用に関する要件
運用に関する要件を以下の項目に沿って記載する。
①通常運用に関する要件
②運用環境に関する要件
③セキュリティに関する要件
④資産管理に関する要件
⑤構成管理に関する要件
⑥稼働管理に関する要件
⑦障害時運用に関する要件
⑧業務運用に関する要件
16.保守に関する要件
保守に関する基本方針、要件について記載する。
①保守の頻度、所要時間に関する要件
②アプリケーションプログラム保守に関する要件
③クラウドサービスの保守要件
④ソフトウエア製品の保守
⑤障害時保守作業に関する要件
⑥大規模災害発災時の対応
保守サポート（サポート期間、ライフサイクル、サポート要員のスキル等）に関する要件を記載する。
全体を通して
要件定義書を約20年ぶりに作成したが、昔に比べ記載内容がより詳細になっている印象を受けた。また当時は意識が低かったセキュリティや新しい技術であるクラウド構築等の要件が増え、記載すべき項目がかなり増えているように思う。
要件定義書はシステム構築の基礎となる部分であるので、漏れのないように記載し、受け手に分かり易くすることが、品質の高いシステムを構築するために非常に重要であると感じた。
執筆者プロフィール：沖宗 直哉
コンサル系SIer、メーカー系SIerで大規模システム開発に従事。2024年2月にSHIFTに入社。AWSを使ったシステム構築のスキルUPに向けて日々奮闘中。
SHIFTへのお問合せはお気軽に
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO：UnsplashのNeeqolah Creative Works