2024.02.07
ユーザー目線で分かりやすい機能要件に対して、非機能要件はわかりにくいものです。
しかし、非機能要件をないがしろにしてしまうと、開発中の大幅な手戻り、リリース後のトラブルなどが発生しかねません。本記事では、非機能要件を定義するための「非機能要求グレード」と、非機能要件を定義するポイントについて解説します。
- もくじ
1．非機能要求グレードとは？
非機能要求グレードとは、非機能要件を定義付けるために重要な項目です。
この章では、非機能要求グレードとは何かと、非機能要求グレードの６つのカテゴリについて解説していきます。
非機能要求と非機能要件の違い
そもそも、非機能要求とは、クライアントがソフトウェアを利用して達成したいこと・実現したいことを具体化したものです。
一方、非機能要件とはソフトウェアをどのように設計すべきか、という開発者の視点に基づいた概念です。
非機能要件は非機能要求をもとに整理していくことが必要になります。
非機能要求には、様々な団体や研究者によって定義が存在します。
日本においては、IPA(独立行政法人情報処理推進機構)が2018年に公開している「非機能要求グレード」というものがあり、本記事ではこの非機能要求について解説していきます。
非機能要求グレード6つのカテゴリ
IPAが公開した、非機能要求グレードの６つの項目をご紹介します。
クライアント視点から要求の実現レベルを見える化するため、段階的に各項目を詳細化しながら「早期に」「誤解なく」「漏らさずに」確認できるようにします。
非機能要求グレードの項目を整理しながら、非機能要件の定義づけを行い、非機能要件テストの実行に移っていきましょう。
可用性
システムサービスを継続的に利用可能とするための要求
(例)長時間利用できるか・メンテナンスがクライアントの利用に支障を及ぼさないか・障害発生時の復旧手順・スケジュールが事前に用意されているか、など
性能・拡張性
システムの性能と将来のシステム拡張に関する要求
(例)今後の機能追加の可能性を考慮した設計になっているか、同時に利用するクライアント数やデータ負荷に耐えられるか、など
運用・保守性
システムの運用と保守のサービスに関する要求
(例)ソフトウェアの利用目的に合わせて稼働時間を確保できているか、データのバックアップを適切な形式・頻度で取れているか、運用時の役割分担や手順のマニュアル化など
移行性
現行システム資産の移行に関する要
(例)旧システムの資産であるマスターデータやトランザクションデータを新システムへ安全に移行できるか、移行する場合の負担はどの程度か、など
セキュリティ
情報システムの安全性の確保に関する要求
(例)機密性の高い情報へのアクセスには利用制限がかけられているか、不正なアクセスをブロックできているか、など
システム環境・エコロジー
システムの設置環境やエコロジーに関する要求
(例)サーバーの設置環境が免震・耐震されているか、機材を故障させないための温度・湿度の管理ができているか、エネルギー面で環境に配慮できているか、など
2．非機能要件に抜け漏れがあると起こるリスク
非機能要件に不備があると具体的にどのようなことが起こるでしょうか。
非機能要求グレードの6項目ごとにそれぞれ解説します。
| 非機能要求 | 抜け漏れがあったときに起こるリスク |
|---|---|
| 可用性 | 頻繁に停止したり、長時間停止したりして使いたいときに使えなくなってしまう |
| 性能・拡張性 | レスポンスが遅かったり、返ってこなかったりする。リソースの増強も困難となってしまう |
| 運用・保守性 | システム運用に多くの時間がかかってしまう |
| 移行性 | 移行に失敗し、切り戻しにも多くの時間がかかってしまう |
| セキュリティ | システムがウイルスなどに感染して顧客情報が漏洩してしまう |
| システム環境・エコロジー | 法令違反となり課徴金の支払いとシステム改修が必要となってしまう |
いずれも要件定義をきちんと行い、コストをかければ避けられるものです。ただし、過剰な要件としてしまうとコストが多くかかるうえに、弊害が起こることもあります。
例えば、セキュリティのレベルだけを過剰に高めてしまうと、コストだけでなく使いやすさ、ユーザビリティの低下につながる場合があるので注意が必要です。
3．非機能要件を定義する流れとポイント
非機能要求グレードの適用の流れは大きく、「1.モデルシステムの選定」、「2.重要項目のレベル決定」、「3.重要項目以外のレベル決定」の３段階からなります。
あいまいになりがちな非機能要件を、順を追って詳細化していくことができます。
① モデルシステムの選定
まずは、各詳細項目のレベル決定の基となるモデルシステムを選定します。ここで決めたモデルシステムを参考に、各項目の仮のレベルが決められ調整していきます。
稼働率や、性能目標、運用時間などの目安も記載されているので、最も近いものを選びましょう。
例えば「社会的影響が限定されるシステム」の場合、稼働率は99.99%（年間停止許容時間1時間未満）、被災時は1週間以内で復旧、というレベルが設定されています。
② 重要項目のレベル決定
つづいて、約100個の重要項目のレベルを決定します。1.で決定したモデルシステムによって参考レベルが設定されているので、相違がある場合は変更を検討します。
モデルシステム通りだと稼動率が99.99%と設定されているところに対して、そこまでのレベルが必要なければ変更したりします。
どの項目もレベルが上がるほどコストがかかってしまいますので、ユーザーの予算感も把握したうえでレベル調整を行います。
③ 重要項目以外のレベル決定
最後に重要項目以外、200個以上の詳細な項目を2.と同様に決定していきます。項目数が多いので、図示するなどしてクライアントにイメージしてもらいながら進めるとスムーズに進められます。
このような流れで各項目のレベルをクライアントと一緒に決めていくことで、非機能要件の定義を完了させられます。繰り返しになりますが、非機能要件は重要な項目です。
事業責任者などクライアントのキーマンの承認を得ながら定義を固めていきましょう。
まとめ
非機能要件の定義は実体が見えず難しいと思われがちですが、非機能要求グレードを活用すれば恐れることはありません。
非機能要件についてイメージできないエンジニアの方も、まずは非機能要求グレードを見て全体像を掴んでみてはいかがでしょうか。
