プロジェクトにおいて、要件定義は欠かせない一環と認識されています。
そこで、機能要件と非機能要件を定義し、システムにブレイクダウンすることは一般的な考え方になります。
今回は、システム開発ではなく、Microsoftのテクノロジーを活用した上で、dynamics 365のプロジェクトにおける機能要件と非機能要件の考え方をシェアします。
機能要件と非機能要件とは（おさらい）
機能要件とは：システムまたはそのコンポーネントに必要な機能や性能の定義のこと。例えば、電子マネーにチャージするシステムを作りたい場合、「チャージできる」というものは機能要件と言ってもいいでしょう。
非機能要件とは：機能要件以外のもの。可用性、互換性、拡張性、セキュリティなどを示す。
| 機能要件 | 非機能要件 | |
| 定義 | 該当機能を実現するため、必要な機能や性能の定義する Functional requirement | 機能要件以外のものを示す Non-functional requirement |
| 必須項目か | 考慮必須 | 考慮必須 |
| 定義までかかる時間 | 多い | 相対的に少ない |
dynamics 365における機能要件と非機能要件
前提：dynamics 365は、MicrosoftのSaasであり、MSエコシステムの一環として存在します。
結論：dynamics 365の導入にあたって、一般的なシステム開発との大きな違いは、非機能要件への考慮にかかる時間が圧倒的少ないこと。
理由は主に以下の2点です。
1．dynamics 365を支えるプラットフォームはMicrosoft Azureであり、パフォーマンス、可用性、互換性、コンプライアンスといった非機能要件は、Microsoft Azureがすべでカバーしてもうようになってきた。
つまり、クラウドを利用することにより、オンプレミス環境でよく考えられる非機能要件がクラウドに移行してきた。
しかも、オンプレミスで自社開発・保守したシステムのパフォーマンス、互換性、可用性は、Azureより劣るのも一目瞭然であり、コストに関しても、膨大な人件費を払うより、ライセンス費用の方が圧倒的に安価でした。
2．そもそもセキュリティは非機能要件ではなく、機能要件だと考えられる。
昔は、セキュリティ維持と保守はコストだと認識される方が多かったが。近年、情報漏洩といったセキュリティ・コンプライアンス事件が発生したにより、企業に対する影響が大きく、イメージダウンに当たる膨大な損失が出てきた。
万全なセキュリティ対策が取らないと、パッケージ導入PJは成功だとは言えないようになった。
dynamics 365のセキュリティ設計は機能要件に当たります。ステークホルダーと折衝し、該当するセキュリティ要件を洗い出して、セキュリティロールのデザインに落とし込むという流れは、非常に重要であり、それなりの工数もかかります。
ただ、パフォーマンスや互換性などの非機能要件の定義、開発に時間がかかりません。何故かというと、dynamics 365を支えるAzureはカバーして頂いているのですから。
まとめ
今回は、dynamics 365 PJにおける機能要件と非機能要件の考え方を説明しました。
結論としては、下記の3つである。
・機能要件にかかる工数が大きく、非機能要件への考慮は少なかった。
・セキュリティは機能要件である。
・一般的な「パフォーマンス、可用性、互換性、コンプライアンス」という非機能要件は、わざわざ考慮する必要がありません。理由はAzureがカバーしてもらうのですから。
コメント