非機能要件

同じ機能でも「何秒で応答するか」「年間どれだけ止まってよいか」を決めないと、調達後に性能不足や運用負荷の問題が表面化する。非機能要件は機能要件と対をなし、システムが「どの品質水準で」動くべきかを定める。情報処理推進機構（IPA）の非機能要求グレードでは、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の6項目に整理される。自治体システムでは、住民の窓口対応に直結する応答時間、災害時の業務継続に関わる可用性、三層の対策に沿ったセキュリティ要件が特に重い。非機能要件を曖昧にすると、見積条件が揃わずベンダ間の比較ができなくなり、稼働後のサービス水準（SLA）の根拠も失われる。

非機能要求グレードによる整理

非機能要件は機能要件に比べて言語化が難しく、発注側が暗黙の期待として抱えたまま明文化されないことが多い。情報処理推進機構（IPA）が公開する「非機能要求グレード」は、この曖昧さを埋めるため非機能要件を可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境/エコロジーの6大項目に分類し、各項目をレベル値で合意できる枠組みを提供する。自治体の調達では、これを下敷きに稼働時間・目標復旧時間（RTO）・同時接続数・データ保存年限などを数値で示すことで、ベンダ提案の前提を揃え、稼働後のサービス水準合意（SLA）や運用保守契約の基準とする。標準化対象システムでも、国の標準仕様書が機能要件を統一する一方、非機能要件の一部は団体の環境に応じて設定する余地が残る。