PD-Mビジネスモデル・ビジネスプロセス · プロダクトのマネジメント

MoSCoW分析

MoSCoW Analysis

もすこうぶんせき

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

共有:

他の資格での定義

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

Past Exams

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

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

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

システム化の対象となる業務の内容、業務フロー、ルールなどを明確に定義するプロセス。現状の業務分析に基づき、システムに求められる業務上の要件を整理・文書化する。

システムが実現すべき機能に関する要件。業務処理や画面・帳票の仕様、データ処理など、システムが「何をするか」を明確にする。非機能要件と対比される概念で、ユーザーの業務ニーズを直接反映する。

性能、信頼性、セキュリティ、可用性、拡張性、運用性など、システムの機能以外の品質や制約に関する要件。レスポンスタイムやスループットなどの具体的な数値目標として定義されることが多い。システムが「どのように動くか」の基準を定義する。

システム開発の最初の工程で、システムに求められる機能、性能、操作性、セキュリティなどの要件を明確にして文書にまとめること。業務の要件をもとに、システムとして何を実現するかを定め、利用者の確認を得てから設計に進む。

システム要件定義で決めた要件のうち、ソフトウェアで実現する部分について、必要な機能、性能、画面や帳票などのインタフェースを明確にする工程。決めた内容を利用者などと確認してから、ソフトウェアの設計に進む。