前置き

前回の記事からの続きになります。

本システムの機能要件と非機能要件を定義しました。
非機能要件に関しては、ipaの非機能要件グレードを参考に大項目を立てましたが、
非機能要件グレードはあまりにも広範過ぎ、網羅性が高すぎるのと
その一方でクラウドを主体に置いたものではそもそもないので、結局中身は自分で考えるしかないのかなと思いました。

クラウドインフラ等の非機能要件設計に役立つデファクトのツールとかプラクティスとかって、何かあるのでしょうか・・・？

(ちなみに自分は実務で要件定義を担当した事はありません。予めご了承ください)

機能要件

Infrastructure as Code

開発の際、処理を担うソースコードだけでなく、それが動く実行環境を含めて開発・管理できること。

ビルドの自動化

アプリケーションのコンパイルとリンク作業などのビルドプロセスを自動化できること

テストの自動化

単体テストの自動化ができること(単体テスト以外も自動化できれば望ましいがマストではない)

ワークフローの自動化

スクリプトレビューや、テストの各工程において、起案・承認などのプロセスが自動化されること

リリースの自動化

アプリケーションのリポジトリへのソース配置作業が自動化できること

デプロイの自動化

本番環境へのホスティング作業が自動化できること

非機能要件

可用性

クラウドのIaaS・PaaS・FaaS利用を想定しており、アプリケーションごとの要件に応じて都度変更可能であるため、規定しない

性能・拡張性

クラウドのIaaS・PaaS・FaaS利用を想定しており、アプリケーションごとの要件に応じて都度変更可能であるため、規定しない

移行性

実現性要件

既存アプリケーションをコンテナ化して当基盤上に移行できる実現性があること

移行運用

既存アプリケーションの移行に関して、ガイドラインがあること。

セキュリティ

権限管理

組織単位の設定の実施に関して、設定担当者のみに制限することができること

認証

設定担当者の認証プロセスにおいて、多要素認証または生体認証を強制できること

アクセス制限

外部公開しないクラウド上の社内リソースに対して、外部の人間からのアクセス拒否を実現できること

シークレット管理

インフラのコード化に際して、ID・パスワード・アクセスキー・キーペア等のシークレットの漏洩防止対策が徹底されていること（社内リポジトリにおいても平文でのアップロードは禁止する）

エンドポイント対策

クラウド上のソースコード保管領域（パイプライン含む）のセキュリティが多要素認証等で担保されていること

運用・保守性

管理方針の明確化

当基盤の運用管理方針が明確化されており、管理上の判断の指針になること

環境の統制

運用環境の統制が取れており、当基盤の方針から外れる独自の環境を勝手に増やすことを制限できること。（申請ベースで実現できれば良い）

運用ドキュメント整備

DevOps関連、コンテナ関連の技術的ドキュメントが整備されており、運用上の判断の指針になること

リソース監視

コンテナに対する監視を行うことができること

環境・エコロジー

物理的な設備導入を伴わない為、定義しない

あとがき

要件の取りまとめにかかった期間は2週間程度だった。
あくまでも自分一人で勝手に要件定義出来るので非常にイージーモードであることは間違いない。
これがお客さんを交えて諸々のちゃんとした資料等も準備して実施すると何ヶ月かは掛かるのだと思う。
SEって大変な仕事だなあと思う。