ＡＷＳのＩＰＡの非機能要求グレード2018はつかえる？

運用などの非機能要件の実現をAWSに任せて運用負荷を減らしていくことが「AWSらしい設計」となる。ＩＰＡの非機能要求グレードが8年ぶりに更新されましたが活用できるのでしょうか。

非機能要件とは？

機能要件を実装するための設計がシステム設計であり、非機能要件を実装するための設計がシステムアーキテクチャとなる。

広義には、機能要件とはシステムが動作する内容について定義し、非機能要件とはシステムが動作する方法を定義すると言える。

機能要件は「要件に対するシステムのふるまい」の形で記述され、通常はシステム一部の個々の動作が明示されたり、数学関数として表されたり、あるいはブラックボックスとしての説明だったり、機能モデルとして説明される。

一方、非機能要件は、特定の状態のシステムとしてではなく、機能の全体的な特性を「システムが要件を満たさなければならない」の形で記述される。非機能要件は、システムの全体的な特性として、開発プロジェクトが成功したか失敗したかどうかの指標としても利用される。

非機能要求は、抽象的であること

非機能要求の難しさは、お客様とベンダ間で認識のギャップがある

具体化が進んでいない上流工程で決めることが困難、共通認識がもれない合意できない

ＡＷＳの非機能要件

AWSの導入・移行を実施する際、クラウド事業者はOS未満のインフラ面のみに責任を持ちます。

そのため、ユーザはOS以上の構築や維持管理について責任を持つ必要があり、業務機能はもとより非機能要件についてもユーザ企業で検討する必要があります。

例えば

• 災害対策やダウンタイム対策
• 性能・キャパシティー
• セキュリティ対策
• 運用機能の網羅性や自動化、監査など

事業継続性やシステムの安全性、IT統制、運用機能の網羅性や運用負荷の軽減、などに関わる重要な要件をユーザ企業側で抽出し、実装しなければなりません。

このような非機能要件をクラウドに合わせて検討する場合、業務要件とは異なり、高度なIT知識とクラウド基盤の専門知識が必要となります。

ＡＷＳでできることオンプレミスでできることを理解する

「AWSとオンプレでできることとできないことがある」ということです。ここはしっかりと把握して、できないことを「できますよ」と言わないように心がける必要があります。

「Amazonでは、Amazon EC2の可用性がどのくらいなのか」「Amazon S3のSLA・サービスレベルがどのくらいなのか」ということは、ホームページ上に個々に定義されていて、「万が一それ以上に停止した場合は、その時間のお金を返します」となっている。

IPAの非機能要求グレードの特徴

全体としては、いろいろと気になるところはあるけれども、全体として漏れがないかという確認には使えるし、粒度が粗いと判断した時点で、別途詳細な要件を決めればいいだけなので、道具としては便利という印象です。

• ハードウェアに対する要求は細かいが、ソフトウェアに対する要求は粗い。
• 自分たちで保守していくのならもっと詳細にルールを決めるべき。
• オンプレ前提なので、クラウドの場合は決めなくてよい場所がある。(というより勝手に決まって動かせない)
• それぞれの数値がコストにどれくらい影響するのかは記載がない。そのため、コスト感覚がない人がこれをベースに考えるとひどいことになる可能性がある。
• それぞれの項目間の影響度についての記載がない。そのため、レベルの選択具合によっては実現が非常に難しい場合がある。