システム開発における要件定義で定義する業務要件、機能要件、非機能要件について詳しく解説します
目次
はじめに
システム開発における要件定義の中で必ず行なう作業として、機能要件と非機能要件を列挙するという内容があります。
この記事では、業務要件とは何か？機能要件とは何か？非機能要件とは何か？の定義づけを説明した上で、具体的にどういう内容を列挙すれば良いのかについて詳しく解説します。
ポッドキャストでも話しています
以下の画像をクリックしてお聞き下さい
↓
業務要件とは？
業務要件とは、システム開発における要件定義の段階で、システム開発での対象となる業務の流れを明確化したものです。
業務要件の項目は以下のような内容になります。
2）ビジネスプロセス関連図
3）業務機能構成表
4)ビジネスプロセスフロー
5）システム化業務フロー
6）業務処理定義書
この中で1）のシステム化の目的・背景・狙いについて詳しく解説します。
業務要件1） システム化の目的・背景・狙い について
システム化ということは今回対象のものが今までは“システム”ではないと捉えられます。
システムでは無いという意味は、対象のものがクラウドに接続されていなかったりサーバーに接続されていなかったりすると言うイメージでしょう。
たとえ対象のもので今までパソコンなどを使ってとしてもそのパソコンで行なっていることが既存の業務系の一般ソフトウエアであり、専用のアプリケーションなどが無い場合に、今回新たに業務用のアプリケーションを作る というのもシステム化に捉えられるかと思います。
いずれにせよ、何らかのシステム開発行為を行なう事によって、業務系であれ、IoT関係であれ、業務が便利になったり、更なるお客様に対して便利な商品やサービスを提供することが大きく捉えた場合のシステム化の目的だと思います。
これからは、もう少しブレークダウンして、
システムの目的＝何のためのシステム開発であるか？
背景＝いま使用しているモノ、業務はどんなものであるか？
狙い＝今回のシステム開発によって出来上がるシステムでどんなメリットが生まれるか？
などを書いていきましょう。
業務要件の中でこの“システム化の目的・背景・狙い”というのが一番重要な項目であり、どんなシステムであっても必ず記述できる項目になります。
それ以外のの項目は業務系システム、いわゆるIT系システムでは必須になりますが、一方組み込み系システム、IoTでもセンサー端末など人が介在しない端末においては記述しなくても良い項目になります。
機能要件
機能要件は、システムを使用するお客様の立場から観ると一番分かりやすい要件になります。
システムの中の機能二層等する内容を列挙することになります。
機能要件の項目について
機能要件の項目の詳細については、業務系と組み込み系などシステムの内容によって大きく異なります。
ここではどのようなシステムでも共通で書く必要がある機能要件項目を挙げてみましょう。
・背景／目的
・入力処理
・制御
・出力処理
・通信
・設計方針
・信頼性
・ソフトウエア構成
等です。以下それぞれの項目について解説します。
背景／目的
業務要件でも記している場合が多いですが、ここでは実際にシステムを使う方を想定してどういうシステムでどういう機能を有しているかを、これまでの背景を含めて説明するようにしましょう。
入力処理、制御、出力処理
情報処理装置の3大要素ですから分かりやすいと思います。
人が介在する場合にはどのような入力手段があるかを記します。例えばタッチパネルがあるとか、操作ボタン、スイッチがあるか等です。
制御というところでシステムとしてどういう処理がされるかを、これもシステムを使う人を想定して分かりやすく記述しましょう。
出力はディスプレイ表示とか、音が鳴るとか、温度が上昇するとか風を送るとか、このシステムでの機能に相当することを、これもシステムを使う人を想定して分かりやすく記述しましょう。
通信
システムにおいて、インターネットに接続したり、スマートフォンに接続するものは必ず通信機能を有していますので、どういう通信方式を有しているのかなどを記述しましょう。
この要件定義の中の機能要件においては無線通信方式、機能の詳しい記述までする必要は原則としてありません。
設計方針
何故機能要件かというと意見が分かれるところですが、システムの要件定義で機能要件を定義している中で、その機能は、設計によって実現出来るという観点で、設計方針をこの要件定義で示すことは意義があると思います。
次のステップは基本設計、システム設計になりますので、その基本設計の方針を示すのはその前の工程である要件定義で行なうという意味では正しいかと思います。
信頼性
この言葉も設計方針同様に機能要件というと少し違和感はあります。
広い意味では設計方針に入るかも知れませんが、システムを開発設計する場合の信頼性というのは非常に重要ですので、設計方針とは別にして特出して、信頼性に関する方針を説明することは意義が有ると思います。
ソフトウエア構成
ソフトウエア構成については意見が分かれれるところですが、機能を実現するための大きなレベルでのソフトウエア構成を示すのは意義があるかと思います。
例えば使用しているOSとか大まかなソフトウエア構成などを記述するようにしましょう。
非機能要件とは？
要件定義の中で、例えばシステムの“性能”など、“実装する機能以外”に関する要件を非機能要件といいます。
非機能要件の項目について
・性能
・拡張性
・運用性
・保守性
・可用性
・移行性
・セキュリティ
・システム環境
などがあります。それぞれについてもう少し詳しく解説します。
性能
私も過去に電話機などの商品開発設計をする場合に、機能と性能という2つの言葉は常に商品開発についてまわったものです。
機能は機能要件でも記したように商品、サービスをお届けして使って頂くお客様からみて実際に便利さ、心地よさなどを提供するのに直結していますが、性能は必ずしもそうでない場合があります。
電話機で言えば音質が良いなどは、機能で無く性能に当てはまるのですが、例えば外で使用する携帯電話、スマートフォンが気温50度のところでも-30度のところでも使用出来るという内容などは性能に相当します。
性能は場合によってはお客様には直接伝わらないものかもしれませんが、機能含めて商品、製品の価値を高める土台となるものであり、性能は殆ど数値で表すことが出来るのが特長です。
拡張性
この言葉は主に大きなシステム物の場合に使われます。例えばコンピュータシステムにおいて、メモリが拡張できるとか、CPUが拡張できるとかが拡張性に相当します。
そういったシステムとしての拡張性を記述していきましょう。
運用性
この言葉もシステム製品、サービスを行なうシステムに使われます。実際にシステムを動かすときの動かしやすさ、操作のしやすさなども運用性に入ります。
保守性
同じくこの言葉も大きなシステム製品で用いられる場合が多いです。必ずシステム物は例えば3陰tに1回とかシステム全体で問題が無いかを点検したり、もし劣化している部品などがあったら交換したりすることが必要です。
そういったアクションを総称して保守と定義しています。
保守が行ないやすいシステムになっているか、保守のためにどういった仕組みを取り入れているかなどを記述する必要があります。
・可用性
この言葉もシステムで使われます。というかこの言葉こそシステムで無いと使わない言葉と言えます。 定義としては、システムが継続して稼働できる能力のことで有り、分かりやすい言葉に置き換えるとしたら継続性になると思います。
・セキュリティ
システムでは必ずこのセキュリティもかかせません。システムだけで無いですね。
セキュリティに関しては組み込みシステムなども当然考慮する必要があります。特に通信機能を有するものはセキュリティに関する配慮が必ず必要になります。
これら非機能要件は、機能要件に比べると一般的には軽視されがちですが、システムもの、それもサービス事業で毎月のように定期的にお客様から費用を頂戴するようなシステムの場合は、非常に重要な要件になります。
サービス事業では、サービスマネジメントという考え方があり、ここに挙げたような非機能要件は殆どサービスマネジメントで取り上げられている要件に入っています。
サービスマネジメントの詳細はITILとかISO20000というものを参照してみてください。
まとめ
今回はシステム開発における要件定義における業務要件、機能要件、非機能要件について詳しく解説しました。
特に今後モノからコトへということで単なる物販ではなくサービス事業、サブスクリプション事業などが増えるにつれて、非機能要件が重視されると言うことは覚えておいて頂くと良いかと思います。
ハートテクノロジーズ株式会社では、システム開発・要求仕様・要件定義・設計などについてのお困りごとをお聞きする30分～60分くらいのオンライン無料相談会を実施しております。
もしご希望の方は、以下の問い合わせフォームの”問い合わせ”欄に【無料相談会希望】と書いていただき、かつ可能であれば現在のお困りごとを書いていただければ幸いです。折り返しご連絡させていただきます。以下をクリックしてお申し込みくださいませ。
関連記事
⇓
ハートテクノロジーズ株式会社では、この記事にあるような要件定義の仕方、さらには要件定義含めてシステム開発を行なうためにはどのようなステップを踏んだら良いかなどについて御社の課題に即してご説明したり、具体的なプロジェクトを回すご支援もしております。ご興味・ご関心ある方はお問い合わせいただければ幸いです。
前の記事へ
次の記事へ