非機能要件の学習メモ｜IPAの6分類と要件の書き方

「注文履歴を検索できる」は機能要件です。そこに「どのくらいの負荷で、何秒以内に検索結果が返るか」「障害で使えなくなったら何分で復旧するか」を加えると、設計やテストに必要な条件が見えてきます。こうした品質の目標や、運用・移行に関する制約が非機能要件です。

私はまだ要件定義を担当したことがありません。非機能要件を学ぶ手がかりとして、IPAの「非機能要求グレード2018」をもとに、どんな項目を確認するのか、どう書けば達成できたかを判定できるのかを整理しました。実際のプロジェクトで目標値をどう決めるかは、これから調べたいこととして最後に残しています。

IPAの非機能要求グレードの6分類

IPAの非機能要求グレードは、発注者と開発側が、求める水準をすり合わせるための資料です。大項目から確認し、設計や費用に影響する項目を具体化していきます。

大項目	確認することの例
可用性	いつ使える必要があるか。どの障害まで想定し、どれだけの時間で復旧するか。
性能・拡張性	どの負荷で、どれだけ速く処理するか。利用者数やデータ量の増加をどこまで見込むか。
運用・保守性	何を監視し、誰が対応するか。更新やバックアップ、復元をどう運用するか。
移行性	何を移行するか。切替時にどれだけ停止でき、失敗したらどう切り戻すか。
セキュリティ	誰にどの操作を許可するか。どのデータを保護し、どの操作の履歴を残すか。
システム環境・エコロジー	設置場所、電力、機器など、稼働環境にどんな制約があるか。

IPA「非機能要求グレード2018」の大項目をもとに整理

ISO/IEC 25010:2023は、ICT製品やソフトウェア製品を対象とする製品品質モデルで、9つの品質特性を定義しています。ここでは、運用や移行まで含めて要件を洗い出せるよう、IPAの6分類を使います。

「検索を高速にする」だけでは、対象の操作や測定時の負荷、合格ラインが決まりません。たとえば注文管理システムの性能要件なら、次のように書けます。

注文データ100万件、検索APIへの負荷が毎秒50リクエストの条件で、30分間の負荷試験を行う。成功した検索リクエストのp95応答時間を500ミリ秒以下、全検索リクエストのエラー率を0.1%以下とする。

この例では、p95は成功したリクエストの95%が収まる応答時間です。エラー率も併記することで、成功した処理の速さと、リクエストが成功した割合をそれぞれ確認できます。ここで使った数値は、測定条件と合格ラインの書き方を確認するための例です。

復旧についても、対象の障害を明示して、復旧までの目標時間（RTO）と、どの時点までデータを戻せればよいかの目標（RPO）を決めます。たとえばデータベース障害に対してRTOを1時間、RPOを15分とするなら、復旧訓練で所要時間と復元できたデータの時点を確認します。

検索APIの例では、負荷と合格ラインを仮に置きました。実際のプロジェクトで同じように書くには、数値を決める根拠と、決めた目標を誰がどう使うかも知っておきたいです。