ソフトウェア開発における「要件」の種類を整理 優れた要件の特徴とは？：ソフトウェア要件は3つに分類

どのようなソフトウェア開発プロジェクトにおいても、要件を包括的に明確化することは極めて重要だ。ソフトウェア開発における要件の種類や、優れた要件の特徴を整理する。

[Stephen J. Bigelow，TechTarget]

　どのようなソフトウェア開発プロジェクトにおいても、要件を包括的に明確化することは極めて重要だ。要件は、製品のビジネスニーズや目的を大まかに特定するものだ。要件により、関係者が期待する機能、動作、性能も明確になる。

　ソフトウェア要件は、ビジネスアプリケーションの開発理由、内容、仕組みを特定し、明確にする方法の一つになる。ソフトウェア要件を調べ、文書にすることで、開発チームはコストや手間がかかる手直しを最小限に抑えながら、適切なプロダクトを迅速に構築するためのロードマップを形成できる。

　特定のプロジェクトに対してIT部門が作成するソフトウェア要件と要件書の実際の種類は、要件の対象者とプロジェクトの成熟度に応じて異なる。実際、業務部門の責任者、プロジェクトマネジャー、アプリケーション開発者それぞれのニーズに合わせて、要件文書を複数起草することもある。

　以下では、ソフトウェアエンジニアリングにおける要件の種類を整理し、ソフトウェア要件の種類と、優れた要件の特徴を紹介する。

ソフトウェアエンジニアリングにおける要件の種類とは

　プロジェクトチームは、ビジネス関係者やユーザーのニーズだけでなく、ソフトウェアの技術機能を満たすための要件をまとめなければならない。ソフトウェアエンジニアリングにおける要件には、主にビジネス、ユーザー、ソフトウェアの3種類がある。

ビジネス要件

　多くのソフトウェアプロジェクトが動き出すきっかけとなるのが業務上のニーズ（ビジネス要件）だ。ビジネス要件定義書（BRD：Business Requirements Document）では、ビジネス、ユーザーなどの関係者にとっての具体的なプロジェクト目標を記述する。

　BRDは、プロジェクトの立ち上げ時に、ビジネスアナリスト、業務部門の責任者などのプロジェクトスポンサーが作成し、プロジェクト立ち上げの背景、理由を定義する。ソフトウェアの開発を請け負う担当者にとっては、BRDはクライアント向けに詳細な文書を記載する際の基礎となる。

　BRDで記述する章には普遍的に決められた書式はないが、目標をそろえることが1つのアプローチになる。プロジェクトの目標が、関係者の具体的なビジネス目標に沿うよう記述する。

　BRDは、基本的には「［プロジェクト名］のソフトウェアは、［ビジネス目標］を達成することで［ビジネスのメリット］を実現する」といった書式で記述する。完成したBRDの例は、「レーザーマーキングソフトウェアは、製造現場で適切なレーザー光線を使ってステンレス鋼の部品にテキストと画像をマーキングすることで、化学エッチングコストと廃棄コストの削減を実現する」といったものになる。

　この例では、ステンレス鋼製品の部品にマーキングを施す際、高価で環境に有害な化学物質を使う代わりに、工業用レーザーマーキングシステムを運用することを提案している。

　ビジネスの目標とメリットは多種多様で、中には目標とメリットを入れ替えても成り立つことがある。一般的なビジネスの目標とメリットには以下のようなものがある。

• 具体的な技術成果（新しいテクノロジーの実装など）を実現する
• 具体的な物流成果（市場にリリースするまでの時間を短縮するなど）を実現する
• 市場でのシェアや収益を増やし、事業拡大を目指す
• 顧客体験、顧客満足度、顧客関係を改善する
• 事業継続性、セキュリティ、コンプライアンス体制を強化する
• 事業の生産性や効率を高める（手動プロセスの自動化など）
• 企業ブランドを築く
• コストを抑制、削減する
• Webサイトのトラフィックを増やす
• ソーシャルメディアでのプレゼンスを高める

　BRDは、その後に作成する詳細要件書の基礎となるよう準備する。BRDが実用的で測定可能な目標を全て網羅し、顧客の期待に応えていることを確認する。

　最後に、BRDをいつでも変更可能な文書にする。プロジェクトへの将来の要件、更新、変更をBRDに反映し、常に目標を満たせるようにする必要がある。

ユーザー要件

　ユーザー要件とは、ソフトウェア利用者の特定のニーズや期待を表す。ユーザー要件をBRDに組み込むケースもあるが、ユーザーが利用する機能が幅広く、ユーザーインタフェース（UI）が複雑になる場合、対象ユーザーのニーズに特化する文書を別途作成する方が理にかなっている。ユーザー要件は、ユーザーストーリーとほぼ等しく、ユーザーがソフトウェアを操作する方法に重点を置く。

　ユーザー要件の記述にも普遍的に決められた書式はないが、一般的には「［ユーザーのタイプ］は［ビジネス目標を満たすため、または成果を実現するため］に［ソフトウェアを操作］する」のように記述する。

　前述の産業用レーザーマーキングソフトウェアにおけるユーザー要件を例にすると「［製造現場のマネジャー］は［製造に使用するレーザーマーキング画像の最新ライブラリを完備するため］に［新しいマーキングファイルを必要に応じてアップロードできる］必要がある」のようになる。

　どのソフトウェアプロジェクトにも、想定、目標、ユーザーストーリーをそれぞれ反映する多数のユーザー要件が存在する。ほとんどの場合、ユーザー要件は、ソフトウェアが実行する機能を表す大まかな目標になる。そこには、目標の実現方法に関する技術詳細を記述しないのが一般的だ。このユーザー要件が特定のソフトウェア要件の基礎になりやすい。

ソフトウェア要件

　BRDにプロジェクトのビジネス目標とメリットの概要を記述したら、ソフトウェアの特定の機能要件、機能以外の要件、必須のユースケースを定めるソフトウェア要件仕様書（SRS：Software Requirements Specification）を考える。

　SRSでは基本的にはソフトウェアについて細かく記述する。BRDとユーザー要件を、開発者が理解して開発できる機能や特徴へと広げ変換する。

　ソフトウェア要件は、機能要件、非機能要件、ドメイン要件に分かれるのが一般的だ。

機能要件

　システムの動作を定義する記述または目標を指す。機能要件では、ソフトウェアシステムが実行すべきこととすべきではないことを定義する。機能要件は、入力または条件に応じて生み出される応答（操作または出力）として表現される。一般的な機能要件には、データ入力、データアクセス、ユーザー認証、警告とレポート、オンライン決済、他のソフトウェアとの統合などがある。

　機能要件は、次の例のようにif/then関係で表現できる。「（If）センサーからアラームを受け取った場合、（then）システムはそのアラームを通報し、アラームが認識されクリアされるまで動作を一時停止する」

　機能要件には、氏名、住所、寸法、距離など、特定の種類のデータ入力を詳しく記述することもある。ソフトウェアが正しく動作するのに欠かせない一連の計算を含めることもある。

　機能要件はシステムの動作を定めるため、テストは比較的容易になる。システムが想定通り機能しなければテストは失敗する。

非機能要件

　非機能要件はソフトウェアのユーザビリティに関係する。非機能要件では、必須の運用効果やパフォーマンスを定める。機能要件を満たすソフトウェアであっても、非機能要件を満たさない場合がある。

　非機能要件では、ソフトウェアの特性と想定するユーザーエクスペリエンス（UX）を定める。非機能要件には、次のようなものがある。

• パフォーマンス：ソフトウェアの応答速度や、レンダリング速度が測定される
• ユーザビリティ：ユーザーがUIやソフトウェアシステムを理解または使用する難易度
• スケーラビリティ：ソフトウェアが多くの同時ユーザーや同時トランザクションを処理する能力
• セキュリティ：ソフトウェアが処理やデータを紛失や盗難から保護する方法
• 保守性：時間の経過とともにソフトウェアに修正プログラムの適用やアップグレードをできる能力
• 互換性：ハードウェア、OSなどのプラットフォーム要件とソフトウェアの互換性
• ポータビリティ：異なるシステムやプラットフォームでソフトウェアが動作する能力

　「このWebポータルのページは0.5秒以内に読み込まれなければならない」といったものが、パフォーマンスやUXに関する非機能要件の例になる。

ドメイン要件

　ドメイン要件とは、特定種類のソフトウェア、目的、業界分野に関連する想定事項を指す。ドメイン要件には機能要件も非機能要件もある。ドメイン要件に共通する要素は、ソフトウェアプロジェクトが該当するカテゴリーに対して確立されている標準や、広く受け入れられている機能セットを満たすことだ。

　ドメイン要件は多岐にわたるが、軍事、医療、金融業界で課せられるのが一般的だ。例えば、医療機器のソフトウェアのドメイン要件は「ソフトウェアは、医療用電気機器の基本的な安全性と性能に関する『IEC 60601』に従って開発しなければならない」のようになる。

　金融業界のドメイン要件なら、「ソフトウェアは、財務会計および報告に関するGenerally Accepted Accounting Principles（GAAP：一般に公正妥当と認められる会計原則）の現標準に準拠する必要がある」となる。

　ソフトウェアが機能要件を満たし、使用可能であっても、ドメイン要件を満たさなければ運用環境では受け入れられない。

要件仕様書の記述例

　SRSでは、ソフトウェアを一連の個別機能モジュールとして記述する。前述のレーザーマーキングソフトウェアの例では、SRSで次のようなモジュールを定義できる。

• マーキング画像ファイルをレーザービームの制御信号に変換するインタフェース
• オペレーターがログインし、ライブラリから製品を選択し、マーキングサイクルの開始や停止を行うUI
• システムを校正するためのテストモード

　SRSには、業界標準（「ISO/IEC/IEEE 29148:2018」など）も幾つかあるが、SRSの記述の推奨形式を別途使用することも可能だ。例えば、「［機能または関数］は［ユーザー入力に応じて処理を実行し、対応する出力を提供する］ものとする」といった文章にするのも一般的なアプローチの一つだ。

　前述のレーザーマーキングシステムの例に関連するソフトウェア要件としては、次のようなものが考えられる。

• 「［レーザーマーキング操作］は［Autodeskの『AutoCAD』形式のベクターグラフィックファイルをレーザーオン／オフ制御信号と、レーザーシステムの操作に使用するXおよびYミラー制御信号に変換する］ものとする」
• 「［本ソフトウェア］は［マーキングサイクルの現状をグラフィック製品画像に重ねて近くのモニターに表示することでオペレーターに視覚的なフィードバックを提供し、オペレーターがリアルタイムで追跡できるようにする］ものとする」

　SRSは、システムアナリストやプロダクトマネジャーが、開発スタッフや業務部門の責任者などの関係者と協力してまとめる。理想的には、SRSに記述する全ての要件は、BRDで概説されるビジネス目標に対応している必要がある。サードパーティーのソフトウェア開発請負業者にとっては、完成したSRSがコスト見積もりと契約順守の基礎となる。

　SRSには、機能要件と非機能要件を含めるのが一般的だが、SRSと機能要件仕様書（FRS：Functional Requirements Specification）を区別するチームもある。そのような場合、FRSを別の文書として用意し、ソフトウェア製品の仕組みを詳しく記載する。FRSでは、ソフトウェア製品全体にわたる全分野とユーザー操作を規定するのが一般的だ。

優れたソフトウェア要件の特徴

　どのようなソフトウェア要件であっても、製品開発プロセスの一環として、相当の準備作業が必要になる。チームはプロジェクトを実施する理由、ソフトウェア製品が提供すべき機能、目指す目標を実現する方法を検討せざるを得なくなる。要件をまとめた文書は、チームがソフトウェア開発プロジェクトを考案、提案、予算化、実装するための基盤となる。

　結果として、要件は、ソフトウェア開発とビジネス成果に数カ月から数年にわたる多大な影響を及ぼす可能性がある。そのため、事前に慎重に検討し、知的投資をすることで、成果が大幅に向上する可能性がある。

　チームは、ソフトウェア要件が次の8つの特徴を備えていることを確認する必要がある。

明確かつ理解しやすくする

　ソフトウェア要件は、最大限の明確さにする必要がある。ドメイン固有の用語や専門用語を使わず、平易な言葉で記述する。明確かつ簡潔な文章は要件文書を評価しやすくする。

正確かつ完全にする

　全ての要件を正確かつ詳細に記述する。BRDには全てのビジネス目標とメリットを詳しく記述し、SRSにはシステムに期待する全ての特性や機能を記述する必要がある。読みやすい書式を使い、未決定の項目を残さず完成させる。

　ソフトウェア要件を正確かつ完全にするため、作成を1人の担当者に委ねることはほとんどなく、業務部門の責任者、プロジェクトマネジャー、開発スタッフ、顧客、さらにはユーザーまで、全ての関係者を関与させ、慎重かつ継続的な共同作業で作成する。

一貫性を確保するが冗長にはしない

　ソフトウェア要件書は、それぞれ特定の要件を定める複数部分に分かれ、長くなることが多い。要件の一貫性を確保するため、時間、距離、用語の違いによる矛盾が生じないようにする。

　例えば、サーバとシステムの違いに混乱するチームメンバーがいる可能性がある。そのため、ソフトウェアを実行するデータセンター内の物理コンピュータを表現する場合は、サーバかシステムのいずれか一方だけを使用する。

　要件は1回だけ記述し、重複させない。要件を重複させると、チームが重複要件を変更または更新したのに、重複する要件の変更または更新を、マネジャーが忘れるといった間違いが起きがちだからだ。

曖昧さをなくす

　ソフトウェア要件には解釈の余地を残さない。明確に記述しても、複数の解釈が可能であれば、実装の見落としにつながる。例えば、温度測定に数学プロセスなどの関数を実行する必要があることは明らかだとしても、使用する温度測定単位（カ氏、セ氏、ケルビン）は明確にする必要がある。解釈が一つだけになるよう各文章を表現する。共同作業や同僚によるレビューを通じて、要件書から曖昧さを排除する。

設計にとらわれない

　ソフトウェア要件書では、結果を示す必要がある。例えば、アーキテクチャ図はさまざまな種類の要件をまとめて、開発チームが構築すべき内容とその理由を詳しく表現するとしても、構築方法を記述することはめったにない。

　要件書では、開発者がソフトウェアプロジェクトの実装フェーズでさまざまな設計オプションから選択できるようにする。ビジネス目標を満たすために必要な場合を除き、実装の具体的詳細は規定しない。

測定可能かつテスト可能とする

　要件書の目的は、実装のロードマップを提供することにある。最終的には、チームは完了後のプロジェクトを評価し、プロジェクトが成功したかどうかを判断しなければならない。そのためには、記述内容を客観的に測定できる必要がある。

　例えば、「すぐに起動しなければならない」といった要件は測定できない。そうではなく、「初期化を終え、ネットワークトラフィックを受け入れる準備を5秒以内に整えなければならない」といった数値化可能な要件にする。

　測定不能な記述により、コストがかかる実装が繰り返される可能性があるため、この特性はソフトウェア請負業者の作業には特に重要になる。ソフトウェア要件書は、テストを念頭に置いて準備する。完了後のビルドを検証するテスト計画やテストケースを作成できる記述内容にする必要がある。

追跡可能にする

　ソフトウェアプロジェクトがどの時点で完了したかを開発者が判断するのは難しい。要件書と完成したコードとの間には直接的なつながりがあるのが理想だ。プロジェクトマネジャーは、要件から設計要素、コードセグメント、さらにはテストケースやプロトコルに至るまで、プロジェクトの起源を追跡できる必要がある。

　完成したコードにまでさかのぼって要件を追跡できないとしたら、開発チームがその要件を実装していない可能性があり、プロジェクトは不完全になる可能性がある。対応する要件のないコードは、余分なコードか、悪意のあるコードである可能性がある。逆に、完成後のコードに全ての要件が反映され、コードがテストに合格した場合、プロジェクトマネジャーはプロジェクトは完了したと見なすことができる。

文書を管理下に置く

　ソフトウェア設計書の大半は動的に進化するため、共同作業やレビューを通じて、時間の経過とともに、時には頻繁に変更される可能性がある。そのため、開発中のソフトウェアのバージョン管理システムに似た注釈付きバージョン管理システムを使用して、設計書を管理するチームも多い。

　バージョン管理システムによって、話し合いや実装に全ての開発者とプロジェクト関係者が同じバージョンの文書を参照可能になる。文書の更新後は、プロジェクトチームに定期的に配布し、チーム共有ツールやコラボレーションツールから利用可能にするのが一般的だ。