システム要件定義・ソフトウェア要件定義

要点と定義

システム要件定義では、システムの機能・能力と性能、利用者や業務の要求、システム構成や品質などの要件を明確にする。機能要件はシステムが提供する機能を定め、非機能要件は可用性、性能、拡張性、運用性、保守性、移行性、セキュリティなど、品質や運用に関する条件を定める 。要件は取得ニーズとの一貫性、追跡可能性、テスト可能性などを基準に評価する 。

ソフトウェア要件定義では、業務モデルや論理データモデルを作成し、ソフトウェアの境界、機能、能力、インタフェースなどを定める。業務分析にはDFD、E-R図、UMLなどを用いる。システム要件とソフトウェア要件の評価後には、取得者と供給者が共同レビューを行う。要件の根拠と成果物との対応を追跡できることは、変更の影響を確かめるうえでも重要である 。

適用条件と例

要件を分類するときは、機能そのものか、機能の品質・運用条件かを見分ける。例えば、ピーク時の処理時間は性能要件、現行システムからの移行所要時間は移行要件、利用者が操作を習得するまでの時間は使用性に関する要件として扱う 。製品やシステムが明示的・暗黙のニーズを満たす機能を提供できる度合いは、機能適合性に関する品質の観点である 。

業務フローの順序、分岐、並行処理、同期を表現する場合は、UMLのアクティビティ図を用いる 。成果物の文書に記載された内容を要件と照合して確認する場面では、インスペクションが検証手法の一例となる 。

誤りやすい点

可用性や性能など、システムの品質・運用に関する条件を、システムが提供する機能そのものと混同しない。要件評価では、取得ニーズとの一貫性や、取得ニーズから要件への追跡可能性などを確認する。単にテストの網羅性を確認することと、要件自体がテスト可能かを評価することは異なる 。

追跡可能性は、要求の根拠と成果物の対応をたどれる状態を指す。仕様変更時には関連する成果物を追い、求められる品質への影響を確認する 。また、アクティビティ図は業務や処理の流れを表す図であり、状態とその遷移を表す図や、利用者とシステム機能との関係を表す図とは用途が異なる 。