システム開発の要件定義を進めていると、
「非機能要件には何を書けばよいのか」
「性能やセキュリティ以外に何を確認すればよいのか」
「非機能要件のチェックリストが欲しい」
と悩むことがあります。
機能要件であれば、
ログインできる
顧客を登録できる
商品を検索できる
CSVを出力できる
など、比較的イメージしやすいでしょう。
一方、非機能要件には、
何人まで利用できるのか
画面を何秒以内に表示するのか
システムが止まったときどうするのか
バックアップを何日保存するのか
誰がどのデータを閲覧できるのか
障害をどのように検知するのか
など、システムの品質・運用に関する条件が含まれます。
非機能要件を決めずに開発すると、
必要な機能は完成した
↓
しかし動作が遅い
障害時に復旧できない
個人情報へのアクセス制限が足りない
運用方法が決まっていない
バックアップがない
といった問題につながる可能性があります。
IPAの「非機能要求グレード」でも、非機能要求について発注者と開発者の認識の行き違いを防ぐため、項目を網羅的に整理し、重要な項目から要求レベルを決めていく方法が示されています。
IPAでは非機能要求を大きく、
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
の6項目に分類しています。
この記事では、この分類を参考にしながら、中小企業のWebシステム・業務システム開発で実際に確認したい非機能要件を一覧形式で解説します。
非機能要件とは
非機能要件とは、
「システムで何ができるか」以外に求める性能・品質・運用などの条件
です。
例えば在庫管理システムで、
在庫を検索できる
というのは機能要件です。
一方、
検索結果を通常3秒以内に表示する
というのは非機能要件です。
もう一つ例を挙げます。
管理者がユーザーを削除できる
は機能要件です。
それに対して、
一般ユーザーは
他ユーザーの個人情報を閲覧できない
などはセキュリティ・権限に関する非機能要件として整理できます。
簡単に言えば、
機能要件
=
何ができるか
非機能要件
=
どの程度の品質・条件で
それを実現するか
という違いです。
非機能要件が重要な理由
例えば、
顧客登録
顧客検索
案件管理
CSV出力
という機能がすべて完成していたとします。
しかし、
検索に30秒かかる
夜間は頻繁に停止する
誰でも顧客データを削除できる
バックアップがない
障害が起きても誰にも通知されない
のであれば、業務システムとして安心して利用するのは難しいでしょう。
つまり、システム開発では、
機能がある
だけではなく、
業務で問題なく使い続けられる
ことまで考える必要があります。
そのために非機能要件を定義します。
非機能要件の一覧
まず全体像を整理します。
| 大項目 | 主な内容 |
|---|---|
| 可用性 | 稼働時間、障害、復旧、バックアップ |
| 性能・拡張性 | レスポンス、利用人数、データ量、拡張 |
| 運用・保守性 | 監視、ログ、問い合わせ、保守 |
| 移行性 | データ移行、切替、移行期間 |
| セキュリティ | 認証、権限、暗号化、監査 |
| システム環境 | クラウド、端末、ブラウザ、設置環境 |
これはIPAの非機能要求グレードの6大項目をベースにした分類です。IPAではさらに各項目を細分化し、可用性では継続性・耐障害性・災害対策・回復性、性能では業務処理量・性能目標値・リソース拡張性などを整理しています。
ここから、それぞれ具体的に見ていきます。
1．可用性
可用性とは、
システムを
どの程度止めずに利用できる必要があるか
に関する要件です。
例えば、
利用時間
停止可能時間
障害時の復旧
バックアップ
災害対策
などがあります。
利用時間
まず、
いつシステムを使うのか
を確認します。
例えば社内システムなら、
平日
8:00〜20:00
で十分かもしれません。
一方、ECサイトなら、
24時間365日
の利用が想定されます。
確認事項
利用曜日は？
利用時間帯は？
夜間利用はある？
休日利用はある？
メンテナンス可能な時間帯は？
稼働率
必要に応じて、
月間稼働率99.9％
などの目標を決めます。
ただし、中小企業の小規模な社内システムで、理由なく非常に高い稼働率を設定するとコストが増える可能性があります。
重要なのは、
システムが1時間止まった場合
どの程度業務に影響するのか
から必要水準を考えることです。
障害時の復旧
例えば、
システム停止後
4時間以内に復旧する
などです。
確認したいのは、
何時間停止しても業務を継続できるか
停止中の代替手段はあるか
どの時点までデータを戻せればよいか
です。
RTOとRPO
可用性では、
RTO
Recovery Time Objective
RPO
Recovery Point Objective
という言葉も使われます。
簡単に言えば、
RTO
=
何時間以内に復旧したいか
RPO
=
何時間前までのデータなら
失っても許容できるか
です。
例えば、
RTO：
4時間
RPO：
24時間
なら、
障害発生から4時間以内に復旧
最大で前日バックアップ時点まで戻る可能性あり
という考え方になります。
バックアップ
確認事項として、
バックアップ頻度
保存期間
保存場所
復元方法
があります。
例えば、
DBバックアップ：
1日1回
保存期間：
30日
別リージョン：
不要
復元手順：
運用手順書に記載
などです。
2．性能・拡張性
性能・拡張性は、
どの程度の負荷まで
快適に動作する必要があるか
という要件です。
例えば、
画面表示速度
同時利用者数
データ量
API応答時間
バッチ処理時間
将来の利用増加
などがあります。
レスポンスタイム
例えば、
主要画面：
通常3秒以内
などです。
「高速に動作する」と書くだけでは曖昧なので、
何秒以内
とできるだけ具体化します。
確認事項
画面表示は何秒まで許容できる？
検索は何秒まで？
CSV生成には何秒まで待てる？
時間のかかる処理は非同期でもよい？
同時利用者数
例えば、
登録ユーザー：
300人
通常同時利用：
30人
最大同時利用：
100人
などです。
登録ユーザー数と同時利用者数は別に考えます。
社員500人の会社でも、実際に同時利用するのが50人なら、それに合わせて設計を検討します。
データ量
例えば、
顧客：
50,000件
商品：
100,000件
注文：
年間500,000件
などです。
さらに、
現在件数
年間増加量
保存年数
を確認します。
例えば現在1万件でも、
年間100万件増える
のであれば設計は変わります。
大量データ出力
業務システムでは、
CSV10万件
PDF1万件
月次集計
など、大量処理が発生する場合があります。
例えば、
CSV100,000件を
60秒以内に生成
など、必要に応じて基準を決めます。
拡張性
将来、
利用部署が増える
店舗が増える
ユーザーが増える
データ量が増える
可能性も確認します。
例えば、
現在：
3拠点
3年後：
最大20拠点想定
であれば、その前提を共有します。
3．運用・保守性
運用・保守性とは、
システム完成後に
どう運用・保守するか
に関する要件です。
IPAの分類でも、通常運用、運用保守、障害時運用、運用環境、サポート体制などが運用・保守性の中項目として整理されています。
運用時間
例えば、
平日9:00〜18:00
夜間バッチ：
毎日2:00
などです。
システム監視
確認したいのは、
サーバー停止を監視するか
エラー率を監視するか
CPU・メモリを監視するか
外部APIエラーを監視するか
などです。
例えば、
重大エラー
↓
監視サービス
↓
Slack通知
とします。
ログ
最低限、
アプリケーションログ
エラーログ
アクセスログ
などを検討します。
重要な業務では、
誰が
いつ
何を変更したか
を記録する監査ログが必要になる場合があります。
例えば在庫管理なら、
商品A
100個
↓
80個
変更者：
user001
変更日時：
2026-07-30 10:00
のような履歴です。
ログ保存期間
例えば、
アクセスログ：
90日
監査ログ：
1年
エラーログ：
90日
などです。
無期限に保存するとストレージ費用・個人情報管理などの問題も出るため、目的に合わせて決めます。
障害通知
例えば、
重大障害
↓
Slack
夜間重大障害
↓
メール
などです。
確認事項は、
誰へ通知するか
何を重大障害とするか
何時まで対応するか
です。
問い合わせ対応
例えば、
一般利用者
↓
社内管理者
社内管理者
↓
開発会社
とします。
利用者全員が直接開発会社へ問い合わせるのか、社内窓口へ集約するのかも決めます。
保守時間
例えば、
平日10:00〜18:00
緊急障害のみ時間外対応
などです。
保守契約の費用にも影響するため、要件定義段階で必要水準を確認します。
4．移行性
既存システム・Excelなどから新しいシステムへ移行する場合に必要です。
IPAの非機能要求グレードでも、
移行時期
移行方式
移行対象
移行計画
などが移行性として整理されています。
データ移行
例えば、
顧客：
30,000件
商品：
5,000件
注文履歴：
過去3年分
を移行するとします。
確認する内容は、
移行対象
データ件数
移行元形式
移行対象期間
文字コード
重複
欠損データ
などです。
移行元
例えば、
Excel
CSV
Access
旧Webシステム
基幹システム
などがあります。
Excelの場合でも、
1ファイル
なのか、
部署ごとに100ファイル
なのかで工数が変わります。
データクレンジング
例えば顧客名が、
株式会社ABC
（株）ABC
ABC株式会社
のようにバラバラかもしれません。
そのまま移行すると重複データになります。
そのため、
誰がデータを整理するか
も決めます。
システム切替
例えば、
金曜18時
旧システム停止
↓
土曜
データ移行
↓
日曜
確認
↓
月曜8時
新システム開始
などです。
24時間稼働するシステムでは、停止を伴う移行が難しい場合もあります。
移行後の検証
例えば、
顧客件数が一致
合計金額が一致
在庫数が一致
ランダム100件を目視確認
など、移行成功をどう判断するか決めます。
5．セキュリティ
非機能要件の中でも特に重要な項目です。
IPAの非機能要求グレードでは、アクセス・利用制限、データ秘匿、不正追跡・監視、ネットワーク対策、Web対策、セキュリティインシデント対応・復旧などがセキュリティの中項目として整理されています。
認証
例えば、
メールアドレス
+
パスワード
でログインするのか、
Googleアカウント
Microsoftアカウント
SSO
を利用するのか決めます。
多要素認証
個人情報・重要情報を扱う場合、
パスワード
+
ワンタイムコード
などの多要素認証を検討します。
ただしシステムのリスク・利用者・コストに応じて決めます。
権限管理
例えば、
一般ユーザー
拠点管理者
本社管理者
システム管理者
などのロールを設定します。
例：
| 操作 | 一般 | 拠点管理 | 本社管理 |
|---|---|---|---|
| データ閲覧 | ○ | ○ | ○ |
| 登録 | ○ | ○ | ○ |
| 修正 | △ | ○ | ○ |
| 削除 | × | × | ○ |
| ユーザー管理 | × | × | ○ |
データアクセス制御
例えば営業担当者が、
自分の顧客だけ閲覧可能
なのか、
営業部全体の顧客を閲覧可能
なのかを決めます。
機能として画面を隠すだけではなく、バックエンド・DB側でも適切にアクセス制御することが重要です。
通信の暗号化
Webシステムでは通常、
HTTPS
を利用します。
社内システムだから暗号化不要、と単純には考えないようにします。
保存データ
例えば、
個人情報
パスワード
APIキー
決済情報
など、データの種類によって適切な保存方法を検討します。
特にパスワードは平文保存せず、安全な方法でハッシュ化する必要があります。
操作ログ
例えば、
顧客情報を削除
金額を変更
権限を変更
といった重要操作について、
誰が
いつ
何をしたか
を記録します。
アカウント管理
確認事項として、
退職者アカウントは誰が停止する？
一定期間未利用なら無効化する？
パスワードポリシーは？
管理者権限は誰が付与する？
などがあります。
セキュリティインシデント
例えば、
情報漏えい
アカウント乗っ取り
不正アクセス
が疑われた場合に、
誰へ連絡するか
アカウント停止するか
ログをどこまで確認できるか
なども検討します。
6．システム環境・エコロジー
IPAでは6つ目の大項目として「システム環境・エコロジー」を定義しており、システムの前提・制約、適合規格、設置環境などを整理しています。
一般的なWebシステムでは、
クラウド
OS
ブラウザ
端末
ネットワーク
利用環境
などを確認します。
対応端末
例えば、
Windows PC
Mac
iPhone
Android
iPad
です。
全部対応する必要はありません。
例えば社内システムなら、
会社支給Windows PCのみ
という場合もあります。
対応ブラウザ
例えば、
Google Chrome最新版
Microsoft Edge最新版
などです。
古いブラウザまで対応すると開発・テスト工数が増える可能性があります。
スマートフォン対応
例えば、
PCのみ
スマホ閲覧のみ
スマホから登録も必要
ではUI設計が変わります。
要件定義で明確にします。
インフラ
例えば、
AWS
Azure
Google Cloud
Vercel
VPS
などです。
会社の指定がある場合は制約条件として記載します。
ネットワーク
例えば、
インターネットからアクセス可能
社内ネットワーク限定
VPN経由のみ
特定IPのみ
などです。
【コピペ用】非機能要件チェックリスト
実際の要件定義では、以下を確認すると整理しやすくなります。
【可用性】
□ システムを利用する曜日は？
□ 利用時間帯は？
□ 24時間365日稼働が必要か？
□ メンテナンス可能な時間は？
□ システム停止時に何時間まで許容できるか？
□ 何時間前までのデータ損失なら許容できるか？
□ バックアップ頻度は？
□ バックアップ保存期間は？
□ 災害時の復旧まで考える必要があるか？
【性能・拡張性】
□ 登録ユーザー数は？
□ 最大同時利用者数は？
□ 現在のデータ件数は？
□ 年間どの程度増えるか？
□ 主要画面は何秒以内に表示したいか？
□ 大量CSV・PDFを出力するか？
□ バッチ処理はあるか？
□ 将来、利用者・拠点は増えるか？
【運用・保守性】
□ 誰がシステムを管理するか？
□ 誰がユーザーを追加するか？
□ 誰がマスタを管理するか？
□ エラーを監視する必要があるか？
□ 障害時は誰へ通知するか？
□ Slack・メール等で通知するか？
□ アプリケーションログを保存するか？
□ 操作ログを保存するか？
□ ログ保存期間は？
□ 問い合わせ窓口は？
□ 保守対応時間は？
【移行性】
□ 既存システムはあるか？
□ Excel・CSVデータはあるか？
□ 何件移行するか？
□ 何年分移行するか？
□ 移行しないデータはあるか？
□ データの重複・欠損はあるか？
□ 誰がデータを整理するか？
□ 旧システム停止期間は確保できるか？
□ 移行後の確認方法は？
【セキュリティ】
□ 個人情報を扱うか？
□ 機密情報を扱うか？
□ 認証方法は？
□ 多要素認証は必要か？
□ ユーザー種別は？
□ 権限管理は必要か？
□ 部署・拠点単位の閲覧制限はあるか？
□ HTTPS通信を利用するか？
□ 重要操作のログを残すか？
□ 退職者アカウントの停止方法は？
□ APIキー等の秘密情報を扱うか？
□ インシデント発生時の対応方法は？
【システム環境】
□ Windows・Macどちらで利用するか？
□ スマートフォン対応は必要か？
□ タブレット対応は必要か？
□ 対応ブラウザは？
□ クラウド指定はあるか？
□ 社内ネットワーク限定か？
□ VPNは必要か？
□ IP制限は必要か？
非機能要件の書き方
非機能要件では、
できるだけ安全に
できるだけ高速に
安定して稼働する
といった曖昧な表現を避けます。
悪い例
画面を高速に表示する
良い例
通常利用時、
主要画面を3秒以内に表示する
別の例です。
悪い例
定期的にバックアップする
良い例
DBを1日1回バックアップし、
30日間保存する
さらに、
悪い例
十分なセキュリティを確保する
良い例
一般ユーザーは
他部署の顧客情報を閲覧できない。
管理者によるユーザー削除操作は
操作ログへ記録する。
このように、
テスト・確認できる条件
へ近づけます。
非機能要件のテンプレート
一覧表で管理するなら、次の形式が使いやすいでしょう。
| ID | 分類 | 要件 | 目標値・条件 | 優先度 |
|---|---|---|---|---|
| NF-001 | 可用性 | 利用時間 | 平日8:00〜20:00 | Must |
| NF-002 | 性能 | 画面表示 | 通常3秒以内 | Must |
| NF-003 | 性能 | 同時利用 | 最大50人 | Must |
| NF-004 | 運用 | バックアップ | 1日1回 | Must |
| NF-005 | 運用 | ログ保存 | 90日 | Should |
| NF-006 | セキュリティ | 通信 | HTTPS | Must |
| NF-007 | セキュリティ | 権限 | ロール別制御 | Must |
| NF-008 | 環境 | ブラウザ | Chrome・Edge最新版 | Must |
IDを、
NF-001
NF-002
のように付けると、打ち合わせ・テストでも参照しやすくなります。
中小企業の業務システムで最低限確認したい非機能要件
IPAの非機能要求グレードには多数の確認項目があります。
しかし、小規模な業務システムですべてを細かく定義しようとすると、要件定義だけで大きな工数がかかります。
IPA自身も、すべての非機能要求項目を一度に均一的に確認するのは現実的ではないとして、重要項目から段階的に要求レベルを確認する方法を示しています。
中小企業の一般的なWeb業務システムであれば、まず次を確認するとよいでしょう。
| 分類 | 最低限確認したいこと |
|---|---|
| 利用 | 利用人数・利用時間 |
| 性能 | 画面表示時間 |
| データ | 件数・増加量 |
| 障害 | 停止時の業務影響 |
| Backup | 頻度・保存期間 |
| 認証 | ログイン方法 |
| 権限 | 誰が何を見られるか |
| ログ | 操作履歴が必要か |
| 環境 | PC・スマホ・ブラウザ |
| 移行 | Excel等を移すか |
| 運用 | 誰が管理するか |
| 保守 | 障害時の連絡先 |
例えば社員20人向けの在庫管理システムなら、
利用時間：
平日8:00〜20:00
利用者：
20人
同時利用：
最大10人
主要画面：
通常3秒以内
バックアップ：
1日1回
認証：
メール＋パスワード
権限：
一般・管理者
操作ログ：
在庫変更のみ記録
端末：
PC・スマートフォン
ブラウザ：
Chrome最新版
保守：
平日日中対応
などから始められます。
非機能要件は高ければ高いほどよいわけではない
例えば、
24時間365日
稼働率99.999％
全国複数リージョン
即時フェイルオーバー
大量アクセス対応
というシステムは高い可用性を実現できます。
しかし、その分、
インフラ費
設計費
開発費
テスト費
保守費
も増える可能性があります。
社員10人だけが平日日中に利用するシステムへ同じ要件を適用する必要があるとは限りません。
つまり、
高品質
=
すべて最高レベル
ではありません。
重要なのは、
業務上必要な水準を適切なコストで実現すること
です。
非機能要件の優先順位を決める
例えば、
Must
絶対必要
Should
できれば必要
Could
余裕があれば
と分類します。
Must
個人情報へのアクセス制御
日次バックアップ
主要画面3秒以内
Should
管理画面でログ検索
Slack障害通知
Could
マルチリージョン構成
などです。
システムによって優先順位は当然変わります。
非機能要件は業務影響から逆算する
例えば、
システムを
24時間稼働させたい
と言われた場合、
なぜ24時間必要ですか？
と確認します。
すると、
社員は平日9〜18時しか使わない
かもしれません。
その場合、本当に24時間の高い可用性が必要なのか再検討できます。
性能も同じです。
1秒以内に表示したい
のであれば、
3秒だと
どのような業務上の問題がありますか？
と確認します。
非機能要件では、
数字を決める
だけではなく、
なぜその水準が必要なのか
まで確認することが重要です。
非機能要件を決めるタイミング
基本的には要件定義で主要項目を決めます。
流れとしては、
開発目的
↓
業務要件
↓
機能要件
↓
主要な非機能要件
↓
基本設計
↓
詳細設計
↓
開発
となります。
ただし、要件定義ですべての技術的詳細を決める必要はありません。
例えば、
バックアップを1日1回取得する
までは要件定義で決め、
AWSのどのバックアップ機能を使うか
は設計工程で決める方法があります。
つまり、
要件定義
=
必要な条件
設計
=
その条件の実現方法
です。
非機能要件のヒアリングでは専門用語をそのまま聞かない
顧客へ、
RTOは何時間ですか？
RPOは？
可用性レベルは？
冗長化要件は？
と聞いても伝わらない場合があります。
代わりに、
システムが停止した場合、
何時間までなら業務を継続できますか？
障害でデータが消えた場合、
どの時点まで戻れば許容できますか？
夜中にシステムが止まった場合、
すぐ対応する必要がありますか？
と業務の言葉へ変換します。
そこから、
RTO
RPO
監視
冗長化
などの技術要件へ落としていきます。
非機能要件でよくある失敗
失敗1｜最後に決める
開発終盤になって、
実は24時間稼働が必要です
と分かると、アーキテクチャから変更する可能性があります。
主要項目は要件定義段階で確認します。
失敗2｜「普通でお願いします」で終わる
例えば、
セキュリティは普通で
速度も普通で
では判断できません。
業務上必要な条件へ具体化します。
失敗3｜すべて最高レベルにする
高い非機能要件にはコストが伴います。
必要性と費用を比較します。
失敗4｜数字の根拠がない
例えば、
必ず1秒以内
と設定しても、その必要性がなければ過剰設計になる可能性があります。
失敗5｜現在だけを見る
利用者・データ量が将来増える予定なら、その前提も共有します。
失敗6｜バックアップはあるが復元できない
バックアップを取得していても、
どう復元するか
復元できることを確認しているか
まで考える必要があります。
失敗7｜監視対象が決まっていない
サーバーが動いていても、アプリケーションが正常とは限りません。
サーバー
アプリ
DB
外部API
など、どこまで監視するか整理します。
失敗8｜セキュリティをログイン機能だけで終わらせる
認証だけでなく、
権限
データアクセス
操作ログ
秘密情報
アカウント管理
なども確認します。
非機能要件に関するよくある質問
非機能要件には何がありますか？
代表的なものとして、
可用性
性能・拡張性
運用・保守性
移行性
セキュリティ
システム環境
があります。
IPAの非機能要求グレードでも、この6つを大項目として整理しています。
機能要件と非機能要件の違いは？
機能要件は、
システムで何ができるか
です。
非機能要件は、
どの程度の性能・品質・条件で
その機能を提供するか
です。
例えば、
顧客を検索できる
は機能要件、
検索結果を通常3秒以内に表示する
は非機能要件です。
非機能要件は誰が決めますか？
発注者と開発会社が一緒に整理します。
発注者側は、
業務への影響
必要なセキュリティ
利用人数
利用時間
などを伝えます。
開発会社は、
実現方法
コスト
技術的な選択肢
を提示します。
小規模システムでも非機能要件は必要ですか？
必要です。
ただし、IPAの全項目を詳細に定義する必要があるとは限りません。
利用時間、利用人数、性能、バックアップ、権限、セキュリティ、対応端末、運用方法など、重要項目から整理します。
IPAも非機能要求の全項目を均一に決めるのではなく、重要項目から段階的に確認する方法を示しています。
非機能要件は要件定義書のどこへ書きますか？
要件定義書に「非機能要件」という章を設け、
可用性
性能
運用
移行
セキュリティ
システム環境
などに分けて記載する方法があります。
大量の項目がある場合は、Excel・Google Sheetsへ一覧化し、要件定義書本文から参照する方法もあります。
IPAの非機能要求グレードとは何ですか？
非機能要求について発注者と開発者の認識の行き違いを防ぐため、IPAが非機能要求項目を網羅的に整理し、要求レベルを段階的に確認できるようにしたツール群です。
「グレード表」「項目一覧」「樹系図」「活用シート」などが用意されており、プロジェクトに応じて利用できます。
hiro-dev-labの要件定義・業務システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく要件整理から対応しています。
例えば、
- 現状業務のヒアリング
- 業務フロー整理
- 業務要件・機能要件整理
- 非機能要件整理
- 利用人数・性能要件整理
- 権限・セキュリティ設計
- データ移行方針整理
- バックアップ・ログ設計
- 運用・保守方法の整理
- 外部システム・API連携
- Java・Python・TypeScriptによるWebシステム開発
などを検討できます。
例えば、
顧客管理システムを作りたい
という段階でも、いきなり開発を始めるのではなく、
現在の業務
↓
業務課題
↓
業務要件
↓
機能要件
↓
非機能要件
↓
設計
↓
開発
という順番で整理できます。
非機能要件で重要なのは「全部決めること」ではなく「重要な条件を決め忘れないこと」
非機能要件には非常に多くの項目があります。
IPAの非機能要求グレードも、要求項目を網羅的に整理しつつ、すべてを一度に同じ粒度で評価するのではなく、重要項目から要求レベルを確認する方法を採用しています。
中小企業のWebシステムであれば、まず、
1．いつ利用するか
2．何人利用するか
3．どの程度のデータ量か
4．何秒程度の性能が必要か
5．停止するとどの程度困るか
6．バックアップをどうするか
7．誰が何を閲覧・操作できるか
8．個人情報・機密情報を扱うか
9．どの端末・ブラウザで利用するか
10．既存データを移行するか
11．誰が運用・管理するか
12．障害時に誰が対応するか
を確認するだけでも、重要な抜け漏れをかなり減らせます。
非機能要件は、
高速にする
安全にする
安定させる
という抽象的な要求ではなく、
業務で必要な水準を
具体的な条件として定義する
ことがポイントです。
「機能一覧はできたが、非機能要件が整理できていない」
「性能・セキュリティ・バックアップをどこまで決めればよいか分からない」
「要件定義からシステム開発までまとめて相談したい」
「既存業務を整理して適切なシステム構成を検討したい」
といった段階からでも、要件整理を進めることができます。
要件定義・業務システム開発について相談する