SAシステムの要件定義 · 要件定義の技法

MoSCoW分析

MoSCoW Analysis

もすこうぶんせき

要件の優先順位を4段階に分類する技法。Must（必須）、Should（重要）、Could（あれば望ましい）、Won't（今回は対象外）の4つに分類し、限られたリソースの中で実装すべき要件を明確にする。アジャイル開発でも活用される。

共有:

他の資格での定義

要求事項の優先順位をMust（必須）、Should（重要）、Could（あれば良い）、Won't（今回は対象外）の4段階で分類する手法。限られたリソースで最も重要な要求を確実に実現するための優先順位付けに使用される。

Past Exams

過去問で 2 回出題（システムアーキテクト試験 1・プロジェクトマネージャ試験 1）

出典: 独立行政法人情報処理推進機構（IPA）の過去問題。問題文は IPA のサイトの PDF で確認できます。「選択肢」は、問題文ではなく選択肢に出たものです。用語名で照合しているため、関係の薄い問題が含まれることがあります。

情報システムが支援すべき業務上のニーズや目標を明確にしたもの。業務プロセス、業務ルール、組織要件などを含み、システム要件の上位に位置づけられる。利害関係者へのヒアリングや業務分析を通じて抽出する。

プロジェクトやシステム開発に関わる利害関係者を特定し、その関心事、影響力、要求事項を分析する手法。要件定義の初期段階で実施し、適切なコミュニケーション計画や合意形成の戦略を立てるために用いる。

システムが提供すべき機能や振る舞いに関する要件。入力に対する処理内容と出力、データの管理方法、業務ルールの実装などを具体的に定義する。非機能要件と対比して用いられる。

業務要件を基に、システムとして実現すべき機能・性能・制約を明確に文書化するプロセス。システム化の範囲、機能一覧、データ項目、外部インタフェース仕様などを定義し、設計工程への入力とする。

システムの機能要件、非機能要件、制約条件、前提条件などを体系的にまとめた文書。開発の基準となり、設計・テスト・受入の各工程で参照される。利害関係者の合意を得た上で承認する。

複数の要件や品質特性の間で、あるものを優先するとほかが犠牲になる関係を分析・評価すること。性能と保守性、コストと品質など、相反する要件間の最適なバランスを見つけるためにシステム設計で広く用いる。