YAZエンジニアが運営するメディア

一般的なシステム開発では最初に要件定義が行われます。システムが満たすべき性能や機能を明確にするのが目的です。

要件定義は機能要件と非機能要件に分けられます。機能要件はシステムに必須となる機能について、非機能要件はユーザビリティに関する性能について定義します。

こちらでは、システム開発において重要な工程である機能要件・非機能要件について解説します。システム開発の発注を検討されている場合はぜひお読みください。

機能要件の基礎知識

機能要件・非機能要件はどちらも要件定義における重要な要素です。機能要件の概要と、非機能要件との違いについて解説します。

機能要件とは？

機能要件（functional requirement）とは、システムに実装する機能・挙動についての要件のことです。発注側がシステムに必ず盛り込みたい機能・挙動を指します。システム開発における最初の工程である「要件定義」の段階で文章化します。

非機能要件との違い

非機能要件とは、「発注側が実装したい機能」以外についての要件のことです。システムを運用する際に決めておくべき副次的な内容であることが一般的です。例として、検索結果表示を何秒以内に完了するか、システム内での日時の切り替えの基準を何時にするか、といった内容が挙げられます。

非機能要件の精度が高い開発会社を選ぶと、満足度が高くなりやすい傾向があります。これは、非機能要件が開発するシステムの使いやすさや質に関わるためです。

機能要件は発注側の希望が明確なため定義しやすい一方で、非機能要件は開発側にとって定義の作業が難しくなることがあります。発注側が事前に想定していない要件の作成となるため、開発側がヒアリングで聞き出しにくい点が主な理由です。

機能要件・非機能要件を定義する流れ

機能要件・非機能要件を定義する一般的な流れをご紹介します。

機能要件を定義する流れ

STEP1：要求の背景や目的の確認

まず、クライアントからの要求にある背景や目的の確認を行う必要があります。これらを把握していない場合、実装する機能の要件にずれが生じ、開発側が違う機能を作成する可能性があるためです。単に必要な機能をヒアリングするだけではなく、背景や目的まで共有しておくことで、開発側が要件を絞り込む際の判断材料にもなります。

STEP2：必要な機能の洗い出し

続いて、開発側が発注側から必要な機能をヒアリングで聞き出し、一覧にしてまとめます。業務改善のシステム開発の場合は、業務フローから確認して必要な機能を洗い出します。

STEP3：機能要件の選定

続いて、本格的に機能要件を選定していきます。すべての機能を実現できない場合は、割り当てられた予算やスケジュールの中で、実現可能な機能要件を発注側と開発側で絞り込みます。各機能の優先順位を考慮するほか、盛り込めない機能の代替案がある場合は開発側に提示してもらいましょう。

非機能要件を定義する流れ

STEP1：開発側が仮作成

開発側が非機能要件を考案し要件定義書を仮作成します。非機能要件は発注側の直接的な要求ではないため、発注側からの提示が困難です。

非機能要件は、一般的に独立行政法人情報処理推進機構（IPA）が定める「非機能要求グレード」に沿って作成されます。非機能要求グレードは以下6つのカテゴリーに分けられています。

• 可用性

システムを使用できる時間帯や安定性などに関する要件が分類されます。運用スケジュールの策定、バックアップの方法、障害発生時の復旧方法などが代表例です。

• 性能/拡張性

システムの性能・拡張に関する要件です。機能追加が可能かどうか、利用できるクライアント数や許容できるデータ負荷などが定義されます。

• 運用/保守性

運用と保守に関する要件です。バックアップの形式・頻度、運用時の役割分担やマニュアル作成などがこのカテゴリーに分類されます。

• 移行性

新システムへの移行に関する要件です。移行によるシステムの停止期間や移行計画、トラブル時の対応について定義します。

• セキュリティ

システムの安全性確保に関する要件です。セキュリティリスク分析やアクセス・利用制限、データの秘匿などについて定義します。

• システム環境/エコロジー

システムを設置する環境や環境規格への適合性についての項目です。運用する上でのシステム成約や前提条件について定義します。

STEP2：要件のすり合わせ

開発側が仮作成した非機能要件を基に、細かな条件をすり合わせていきます。システム稼働時間の終了時刻を21時から24時に変更するなど、実際の運用を想定して細かな変更を加えましょう。

要件を変更する場合は理由を必ず説明することが重要です。変更の背景を教えておくと、開発側が代替案を提示できるようになります。

STEP3：非機能要件の選定

開発側とのすり合わせにより、機能として実装する非機能要件の最終的な選定を行います。コストを聞き、予算内で優先度の高い機能から選んでいくのが基本です。

機能要件・非機能要件のチェックポイント

問題のない機能要件・非機能要件を定義するためには、意識していただきたいポイントがあります。以下では、代表的なポイントをご紹介します。

曖昧な表現はないか

曖昧な表現があると、システムを構築する際に問題が起こりやすくなります。機械的に「はい」か「いいえ」で分岐可能な状態まで明確にしておくことが重要です。また、目標を設定する場合は、努力目標ではなく必達目標の数値にします。

実現可能なものになっているか

実現できない定義は要件として機能しません。実現性の可否について技術的裏付けを確認する必要があります。与えられた予算・スケジュール・ネットワーク環境などでシミュレーションし、実現可能なラインで定義してもらいましょう。要件定義の際には開発側のSEに参加してもらうよう依頼することも重要です。実現可能性を直接確認できます。

機能要件・非機能要件を慎重に定義して満足度の高いシステムを実現

要件定義において機能要件・非機能要件は重要な要素です。機能要件は開発開始後にトラブルにならないように、もれなく伝えるようにしましょう。

非機能要件もシステムの使いやすさに大きく関わるため、開発側としっかりとコミュニケーションをとって決めていきましょう。

YAZでは経験豊富なエンジニアが機能要件および非機能要件についてしっかり要件定義を行いますので、初めてのシステム・アプリ開発の際にもぜひご相談ください。