個別の情報システムでの要件定義プロセスにおいて，利用部門として最も適切なものはどれか。
アは×。利用しにくいシステムになる
→参照：「要件定義でのトップダウンとボトムアップ」
イは×。全社的観点からの要求を
→参照：「全体最適化と部分最適化」
ウは○。
→参照：「過剰要求の危険」
エは×。大きな手戻りになる
→参照：「要求フェーズでの苦情」
要件定義での利用部門の取組みとして，最も適切なものはどれか。
ア 些細なことでも気づいたことはすべて要求事項とするのが適切である。
イ 経営戦略との整合性が重要なので，利用部門としての要求は最低限に絞るのがよい。
ウ 当初は必須項目だけ示し，開発の進捗をみながら逐次追加していくのが適切である。
エ 要求事項に利用部門としての優先順位をつけて示すのが適切である。
アは×。費用対効果を考えよ
→参照：「過剰要求の危険」
イは×。使いにくいシステムになる
→参照：「要件定義でのトップダウンとボトムアップ」
ウは×。大きな手戻りになる
→参照：「要求フェーズでの苦情」）
エは○。
→参照：「過剰要求の危険」
システム開発の費用や納期をできるだけ計画とおりに達成するために、最も適切な方策はどれか。
ア 姑息な方法だが、関係者には計画よりも少ない費用や短い納期を伝えておく。
イ 要求がまとまらない段階でも、できるだけ早期にプログラミングを開始する。
ウ 常に進捗状況を把握して対策を講じるための体制を整備しておく。
エ テスト工程を短縮して、ともかく実施にふみきり、その後トラブルがあったら対処する。
アは×。二度と通用しない
イは×。手戻りが発生する
ウは○。
エは×。このほうが費用がかかる
参照：「要求フェーズでの苦情」、
「２２２の法則」
システム開発の費用や納期をできるだけ計画とおりに達成するために、最も適切な方策はどれか。
ア リスクを考慮して、費用や納期に適切な余裕を持った計画にしておく。
イ 最先端のハードウェアやソフトウェア、システム開発方法論を採用する。
ウ 開発途中で遅れが発生したときには、多数の開発要員を増強する。
エ たとえ重要な要件であっても、いったん後工程に入ったら前工程には戻らない。
アは○。精神論だけでは困る
イは×。枯れていないのでリスクが大きい
ウは×。説明などが必要でかえって遅れる
エは×。それでは役立たないシステムになる
参照：「要求フェーズでの苦情」、
「２２２の法則」
ホモニム・シノニムに関する記述のうち、正しいものはどれか。
アは×。ホモニム→シノニム
イは○。
ウ・エは×。ホモニムもシノニムも誤解の原因
参照：「用語定義の重要性」
ユーザとベンダの間で、対象業務の用語に誤解があると、システム開発でトラブルが生じる原因になる。次のうち、最も適切なものはどれか。
アは×。利用者でないとわからない
イは×。同業他社どころか社内ですら解釈が異なる
ウは○。シノニム＝異名同義語、ホモニム＝同名異義語
エは×。どちらも相互理解を妨げる
参照：「用語定義の重要性」
誤ったデータが入力されないようにするために、システムにチェック機能を組み込むことが必要であるが、次のうち、最も適切なものはどれか。
アは○。
イは×。誤入力のケースは複雑。利用者でないと不明
ウは×。これではシステムの受け渡しにならない。大きな手戻りも発生
エは×。「人間は間違える」→システムでのチェックが重要
参照：「用語定義の重要性」（kj2-yogo-teigi）