ホーム > システムアーキテクト試験 > 2018年
システムアーキテクト試験 2018年 午前2 問05
ソフトウェア要件定義プロセスで定義する内容の具体例として、適切なものはどれか。
イ：データエントリ画面における応答時間は、3秒以内とする。
ア：基幹システムから利用者の所属情報を取得するために、全てのサブシステムで共通の通信プロトコルを使用する。（正解）
ウ：窓口業務は、ソフトウェアで実現することと人手で実施する作業を組み合わせて運用する。
エ：利用者の利便性を考えて、受付端末は店舗の入り口から5メートル以内に設置する
解説
ソフトウェア要件定義プロセスで定義する内容の具体例【午前2 解説】
要点まとめ
- 結論：要件定義ではシステム間の連携や通信方式など、システムの機能的な枠組みを明確にすることが重要です。
- 根拠：要件定義は「何を実現するか」を決める段階であり、通信プロトコルの共通化はシステム間連携の基本要件に該当します。
- 差がつくポイント：応答時間や設置場所などの非機能要件や運用方針は要件定義の後の設計や運用計画で扱うため、要件定義の範囲を正確に理解することが差別化につながります。
正解の理由
ア: 基幹システムから利用者の所属情報を取得するために、全てのサブシステムで共通の通信プロトコルを使用する。は、システム間の連携方法を具体的に定義しており、要件定義プロセスで扱うべき内容です。
これはシステムの機能的要件の一部であり、どのように情報をやり取りするかを明確にすることで、後続の設計や開発の基盤となります。
これはシステムの機能的要件の一部であり、どのように情報をやり取りするかを明確にすることで、後続の設計や開発の基盤となります。
よくある誤解
要件定義は単に「やりたいこと」を書くだけでなく、システムの機能や連携の枠組みを具体的に決める段階です。
応答時間や設置場所などは非機能要件や運用設計で扱うため、混同しやすい点に注意が必要です。
応答時間や設置場所などは非機能要件や運用設計で扱うため、混同しやすい点に注意が必要です。
解法ステップ
- 問題文の「ソフトウェア要件定義プロセスで定義する内容」に注目する。
- 要件定義の役割を「システムが何をするか（機能要件）」と理解する。
- 選択肢を機能要件か非機能要件、運用方針かで分類する。
- 機能要件に該当する「通信プロトコルの共通化」を選ぶ。
- 他の選択肢が非機能要件や運用に関する内容であることを確認し除外する。
選択肢別の誤答解説
- ア: 正解。システム間の通信方式を定義し、機能要件の具体例として適切。
- イ: 応答時間は性能などの非機能要件であり、要件定義の後の詳細設計で扱う。
- ウ: 業務の人手とシステムの組み合わせは運用設計の範囲で、要件定義の直接的な内容ではない。
- エ: 端末の設置場所は物理的な環境設計や運用に関わる事項であり、要件定義の範囲外。
補足コラム
要件定義はシステム開発の初期段階であり、機能要件と非機能要件を明確に区別することが重要です。
機能要件は「何をするか」、非機能要件は「どのように動作するか」を示します。
また、運用設計や物理設計は要件定義の後に詳細化されるため、問題文の段階で混同しないようにしましょう。
機能要件は「何をするか」、非機能要件は「どのように動作するか」を示します。
また、運用設計や物理設計は要件定義の後に詳細化されるため、問題文の段階で混同しないようにしましょう。
FAQ
Q: 要件定義と設計の違いは何ですか？
A: 要件定義は「何を実現するか」を決める段階で、設計は「どう実現するか」を具体化する段階です。
A: 要件定義は「何を実現するか」を決める段階で、設計は「どう実現するか」を具体化する段階です。
Q: 非機能要件は要件定義で扱わないのですか？
A: 非機能要件も要件定義で扱いますが、応答時間のような詳細な性能要件は後の設計段階で具体化されることが多いです。
A: 非機能要件も要件定義で扱いますが、応答時間のような詳細な性能要件は後の設計段階で具体化されることが多いです。
Q: 運用設計は要件定義に含まれますか？
A: 運用設計は要件定義の後の段階で、システムの運用方法や環境を決める工程です。
A: 運用設計は要件定義の後の段階で、システムの運用方法や環境を決める工程です。
関連キーワード: 要件定義, 機能要件, 非機能要件, システム連携, 通信プロトコル, ソフトウェア開発プロセス