支援対象地域:札幌、仙台、関東、愛知、関西、広島、福岡

  • TOP
  •   
  • コラム
  •   
  • 要件定義における機能要件と非機能要件

はじめに

ソフトウェアライフサイクル(SLCP)は主に以下のプロセスで構成されます。

[企画]→[要件定義]→[システム開発]→[ソフトウェア実装]→[保守]

本記事では、このライフサイクル中の要件定義における機能要件と非機能要件について説明します。

機能要件とは

機能要件は、クライアントがソフトウェアやシステムに求める機能のことです。言い換えると、実現する必要がある最低限の機能です。例えば、業務で扱うデータの種類や構造、処理内容、ユーザーインターフェース、帳票などが含まれます。クライアントが完成形のイメージを持っていない場合は、ヒアリング調査を重ねて、クライアントが必要とする機能を明確にしていきます。

一方で、機能要件を選定していく際には、制約条件についても把握しておく必要があります。主な条件として、開発コストが挙げられます。クライアントが提示する予算で、全ての機能を盛り込むことができない場合は代替案を検討する必要があります。

非機能要件とは

非機能要件とは、機能面以外の要件全般のことで、その内容は多岐にわたります。例えば、以下のものも非機能要件の範疇です。

  • 一覧表示やデータの集計といった機能を実行した時のレスポンスが速い
  • システムダウンから短時間で復旧する

つまり、非機能要件はクライアントの満足度を高めるために重要な要件です。情報処理機構(IPA)では、非機能要件を大きく分けて次の6つに分類しています。

  1. 可用性
  2. 性能・拡張性
  3. 運用・保守性
  4. 移行性
  5. セキュリティ
  6. システム環境・エコロジー

以下では、それぞれの項目について説明します。

1. 可用性

システムは、災害の発生や定期メンテナンスの際に停止することがあります。可用性は、システムが継続的に稼働できる能力を把握する指標となります。可用性の指標には、次の式で得られる稼働率が用いられます。

[稼働率] = [平均故障間隔]/([平均故障間隔]+[平均修理時間])

可用性が高いほど、システムの稼働時間が長くなり、継続的な利用ができるため、便利と言えますが、それを実現するためのコストも高くなります。

  • 平均故障間隔 - 平均故障間隔(MTBF)は、システムの平均稼働時間、もしくは一度システムが故障しから次に故障するまでの平均時間のことです。
  • 平均修復時間 - 平均修理時間(MTTR)は、システムが故障して復旧するまでの平均時間のことです。

2. 性能・拡張性

ライフサイクルを通して業務量は変化します。稼働開始からピーク時といったデータ量やユーザー数、同時アクセス数などの増加に対して、要求されるレスポンスタイムやスループットで対応できるように、リソースの拡張性やサーバーの処理能力などの検討を行います。

  • スループット - 単位時間あたりに処理できる仕事量のことで、システムのパフォーマンスを評価する指標として用いられます。

3. 運用・保守性

運用・保守性は、システム運用時の稼働率や、システム故障個所の早期発見および修復について定義している項目です。保守性の指標には、前述の平均修復時間が用いられ、平均修復時間が短いほど、システムの保守性は高くなります。しかし、保守性が高いほどコストも高くなります。

例えば、本番環境のシステムに障害が発生した場合などに連続して稼働させておくには、ホットスタンバイというシステムを用意する必要があります。しかし、このシステムは、障害発生時に現用系と待機系を用いて対応するシステム(ホットスタンバイ、ウォームスタンバイ、コールドスタンバイ)の中で最もコストが高いです。

  • ホットスタンバイ - 通常時に稼働している現用系に問題が発生した際に、処理やデータを現用系と同期している待機系に瞬時に切り替えて、処理を続行するシステムです。
  • ウォームスタンバイ - ホットスタンバイとコールドスタンバイの中間のシステムです。待機系は、現用系との処理やデータの同期は行わず、OSなどの起動までしておきます。そのため、障害発生時の切り替えには、いくつかの作業を要します。
  • コールドスタンバイ - 現用系と同じシステムなどの用意はしておきますが、待機系の起動はせず、停止しておきます。その後、現用系に障害が発生してから、現用系と切り替えるための設定などを行うシステムです。待機系には、普段では他の用途で使用しているものを待機系とする場合もあります。コールドスタンバイは、3つの中で最も安価な方法のため、復旧要件が厳しくない場合に利点があります。

4. 移行性

システムなどの移行に関して、移行スケジュールや移行方法、移行するデータ量や形式等に関して定義している項目です。この項目を実現する方法としては、移行スケジュールの立案や移行体制の確立、リハーサルの実施などがあります。

5. セキュリティ

利用者制限や不正アクセスの防止などのセキュリティを定義している項目です。この項目を実現する方法としては、認証機能や利用制限、データの暗号化、不正利用の監視などがあります。

6. システム環境・エコロジー

システムを設置する環境や消費エネルギー量などを定義している項目です。この項目を実現する方法としては、耐震/免震などの地震の揺れへの対策や重量/スペースを考慮した規定及び設備の選定、環境負荷の低減を考慮した構成などがあります。

まとめ

要件定義においては、機能要件はもちろん、非機能要件もユーザーの満足度を高めるという点で重要です。しかしながら、非機能要件はクライアントにとって意識しにくい部分、もしくは当然実現しているものとして認識されている場合もあります。したがって、クライアントに満足のいくものを提供するためには、機能要件だけでなく非機能要件の理解も必要です。