インフラチームの担当者として要件定義から参画することがありますが、その中で非機能要件を検討する機会がありましたので、改めて非機能要件とは何かというのを自分なりに振り返りを実施していきたいと思います。
非機能とは何か？
要件定義工程の中で業務やアプリチーム側で検討する内容は、業務要件や機能要件と呼ばれますが、業務の機能以外の範囲が「非機能」という理解になります。また、非機能は以下の2点に分けられると理解しています。
- インフラ部分の非機能（可用性、運用・保守性、セキュリティなど）
- アプリケーションの非機能（サービスの使い勝手など。UI/UXに関わる部分ですね。）
私はインフラを担当しているので、インフラの非機能要件をスコープとしているので、そのあたりの概要を説明したいと思います。
インフラの非機能の項目
インフラの非機能として検討する項目は、IPA（情報処理推進機構）が提供している「非機能要求グレード」で定義されている以下項目が一般的には対象となります。
※非機能要求グレード：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
- 可用性：システムをどこまで利用可能とするか
- 性能・拡張性：負荷や処理内容からシステムにどの程度の性能や拡張が可能な構成とするか
- 運用・保守性：運用や保守をどこまで実施するか
- 移行性：現行システムからの移行範囲の取り決めなので、新規システムは検討対象外
- セキュリティ：セキュリティの対策範囲などをどこまでやるか
- システム環境・エコロジー：システムの設置環境にかかわるもので、AWSの場合それほど検討項目はない
インフラの非機能要件の検討方法
私が実施しているやり方としては、上記でも記載したIPA（情報処理推進機構）の「非機能要求グレード」に定義されている項目（非機能要求グレードではメトリクスと定義）とレベルを構築対象のシステムに対し検討し設定していきます。
検討内容は、以下のようなことを各メトリクスに対して検討していきます。
- メトリクスに対しどういった方針や要求とするか
- 上記の方針や要求がどのレベルに該当するか
- 方針や要求に対する実装（概要レベル）はどのようにするか
例えば、非機能要求グレードの項番「A.1.1.1」のメトリクスは「運用時間（通常）」となっていますがそれに対しては以下のように検討するイメージです。
- メトリクスに対しどういった方針や要求とするか ⇒BtoC向けのシステムであるため、24時間無停止での稼働が必要。
- 上記の方針や要求がどのレベルに該当するか ⇒24時間無停止なので、レベル”5″に該当。
- 方針や要求に対する実装（概要レベル）はどのようにするか ⇒どこまで具体的に書くかのさじ加減は難しいですが、24時間無停止を前提としてAWSサービスを組み合わせて実装する…など色々書き方はあるかと思います。
最終的にはまとめた非機能要求グレードの内容は、顧客と合意する必要があります。
ITに関して知見のない顧客もいますので、技術よりの内容である非機能要求グレードをどう理解してもらうかは工夫の必要があります。（単純に非機能要求グレードの項目を1つ1つ説明しても理解いただけないですし、時間も無駄にかかってしまいます）
工夫の仕方としては、重要度の高い項目を丁寧に説明しながら決めていき、それ以外は適当？にやるなど、やり方はあるかと思います。
まとめ
- 非機能要件の検討にあたりIPAの非機能要求グレードが利用できると紹介させていただきました。
- 非機能要件を顧客と合意する際は、顧客の理解度に合わせて進め方の作戦を立てる必要があります。
- 非機能要求グレードの項目一つ一つの検討例については、今後出来たらブログに書きたいと思います！
コメント