プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

ITシステムで用いる要件とは？

ITエンジニアが遭遇する用語として「要件定義」があります。「要件定義」は顧客の行うことをまとめた要望書となります。それに基づき、ITシステムで実装できる設計書を作成します。顧客の要望を網羅するために、「機能要件」と「非機能要件」として見えない要望を可視化していきます。

機能要件は、顧客が実際にしたいことを指します。例えば、経理システムに経費精算情報を入力すると適切な費目に集計され結果が格納される機能をつけて欲しいと顧客側が要望した時、この機能を機能要件といいます。これは直接的な顧客の要望を要件化したもので、顧客とのヒアリングの中で比較的簡単に汲み取れるものです。しかしシステム設計には追加の検討、つまり非機能要件も必要となってきます。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

上記の機能要件の例において、経理システムでは経費精算が集計・格納できれば良いのですが、本当にそれだけでしょうか？例えば、月曜日の朝一の定時処理にアクセスが集中してシステム負荷が高まったり、結果が所定時間内に戻ってこなかったりした場合は、本来の顧客要望が満たされないことになります。そのために、本来必要とされる処理能力を定義したり、動作条件を定義したり、信頼性や保守の容易性についても要件にまとめたりする必要があります。この見えない要件を非機能要件と言います。

非機能要件で定義される項目は？

非機能要件は、機能要件を満たすシステム設計の動作環境や動作特性を保証するために必要な検討事項となります。したがって非機能要件は、システム単体の設計より広範囲の動作特性を考慮して、総合的に検討する必要があります。以降で具体的なガイドラインを見ていきましょう。

 IPA情報処理推進機構では、要求定義の品質を確保するために、非機能要求グレードを策定しました。

背景としては、システムが大規模化・複雑化したこと、および利用の広がりの観点から情報システムに安定的な提供基盤のニーズが高まったためです。利用用途としてはユーザと開発者の認識のずれを削減し、要求項目の漏れを削減することにあります。

非機能要求グレードの実際の項目に触れていきます。非機能要求グレードでは、非機能要件を以下の6種類238項目に分類しています。 ・可用性 　継続性(11項目)、耐障害性(15項目)、災害対策(4項目)、回復性(3項目) ・性能・拡張性 　業務処理量(14項目)、性能目標値(15項目)、リソース拡張性(9項目)、性能品質保証(5項目) ・運用・保守性 　通常運用(19項目)、保守運用(13項目)、障害時運用(8項目)、運用環境(8項目)、サポート体制(16項目)、その他の運用管理方針(7項目) ・移行性 　移行時期(3項目)、移行方式(2項目)、移行対象機器(1項目)、移行対象データ(6項目)、移行計画(6項目) ・セキュリティ 　前提条件・制約条件(1項目)、セキュリティリスク分析(1項目)、セキュリティ診断(3項目)、セキュリティリスク管理(7項目)、アクセス・利用制限(5項目)、データの秘匿(3項目)、不正追跡・監視(8項目)、ネットワーク対策(3項目)、マルウェア対策(項目3)、Web対策(2項目)、セキュリティインシデント対応/復旧(項目1) ・システム環境・エコロジー 　システム制約/前提条件(2項目)、システム特性(7項目)、適合規格(3項目)、機材設置環境条件(18項目)、環境マネージメント(6項目) 参考：IPA情報処理推進機構 非機能要求グレード

上記URLより、どなたでもドキュメント一式、並びに評価シートがダウンロード可能です。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

非機能要件の活用方法は？

非機能要件を定義することは、多くの経験を必要とする難しい工程です。IPA情報処理推進機構の非機能要求グレードを活用することで、これを比較的簡単に行うことができるようになります。というのも、汎用的に利用できる6種類の項目について漏れなく各項目がカバーされていることに加え、ユーザおよび開発者で共通利用が可能であるからです。

IPA情報処理推進機構の非機能要求グレードには利用ガイドと活用シートが同梱されています。利用ガイドは解説編・利用編・活用編の3種類のドキュメントからなり、手順が記載されています。これらを利用することで、要求項目をレベル化し潜在的な要求を可視化していくことができます。最初の段階では、要求を一意に決定できませんので、ユーザ側と開発者側で協議して収束させていきます。同様に参考モデルをグレード化してシステム間の差を段階的に定義しているため、必要な要求が確認できるようになっています。

RASISとは、コンピュータシステムのサービスサイクルをカバーする指標となります。各項目は英語の頭文字からなり、以下の項目に分類されます。 ・(R) Reliability　　： 信頼性、故障や障害への耐性 ・(A) Availability 　 ： 可用性、システムの継続性 ・(S) Serviceability ： 保守性、障害復旧の保守容易性 ・(I) Integrity　　　： 完全性、データの一貫性 ・(S) Security　　　： 機密性、情報アクセスの安全性の維持

すでに気づかれた方も多いと思いますが、RASISの項目は非機能要求グレードの各分類に含まれています。RASISを要件定義に盛り込むことで、大部分がカバーされることになります。

クラウド事業者との契約や、クラウドサービスを利用する際にSLAやSLOという用語が出てきます。SLAはService Level Agreementの略で、サービス提供時にどの程度のサービス品質を保証するか提示したものです。項目としては測定可能なもので、高負荷時の性能や速度を保証したり、稼働時間を保証するために提示する項目となります。同様にSLOはService Level Objectiveの略で、上記SLAで保証される実際の性能や速度、あるいは稼働時間等の目標水準や目標値となります。

これらの項目はサービスイン後の品質を保証するための評価基準となります。

クラウドエンジニアとは？従来型エンジニアとの違いや市場性・年収について解説します！

プロジェクトへの適用方法は？

実際の非機能要求グレードをプロジェクトに適用する流れについて簡単に説明します。非機能要求グレードでは複数のモデルシステムが定義されており、まずはその中から対象業務に近いモデルシステムを選定します。続いて、業務で必要とされる重要項目のレベルを決定し、重要項目以外のレベルを決定していきます。

一定の成果が確認されれば、関連システムの標準化を行い、プロジェクト適応範囲を順次拡大していきます。

非機能要件の要件定義は、見えない要件や暗黙の了解を可視化し、顧客と合意することです。そのために、顧客とのコミュニケーションが重要になってきます。コミュニケーションを円滑に進めるために、ヒアリングシートを作成し、統一化されたコミュニケーションを目指しましょう。

要件定義では、想定したグレードを仮置きでも設定し提示することで議論の基準を作成します。併せて、コスト面の提示も行うことで、実現の妥当性を判断していきます。その際、いくつかのアーキテクチャの選択肢を持つことで、レベルとグレードを決定していきます。同様に、保守対象システムと保守レベルを決めたり、将来の法令準拠への対応も必要に応じて検討していきます。

各要件に対して、重みづけを行い選択肢を決定していきます。また過度にグレードを上げても、システムが利用されないと検討の意味がありませんので、利用状況・需要予測を調査して検討していきます。グレードの選定には実装コスト等のトレードオフが発生することがありますので、これらも決定時に考慮します。また意思決定には時間がかかるため、PDCAを短いサイクルで回し、決定時間を短縮しましょう。初期コストが高いと決定判断がつきにくいので、段階的拡張(スモールスタート)の案を用意します。さらに、長期ビジョンの計画を別途検討することが、成功への近道です。

非機能要件を理解し高品質なシステムを設計しましょう

今後、ITシステムはさらに複雑化し、大規模化していきます。同様に、利用用途が爆発的に拡大します。当初想定していた範囲外の利用も増えていきますから、非機能要件の考え方をマスターして、システム設計に活かせるようになりましょう。その結果、自身の経験値も大幅に高まることでしょう。