要件定義に関するケース問題

「最新の検索エンジンを導入し、業界最高水準の検索速度を実現する」と記載する。 「検索実行ボタンの押下から結果表示まで、平均1秒以内（最大3秒以内）」と具体的な数値を定義する。 「ユーザーがストレスを感じない程度の速度」と、人間の感覚に基づいた記述にする。 「現状のシステムよりも速くすること」と、比較対象を明示する。

画面の遷移が正しく行われるかという「機能要件」の網羅的なチェック。 開発メンバーのプログラミングスキルが十分であったかの確認。 予算を増額し、より高価なサーバーを導入することの検討。 システムの「可用性」や「ピーク時の同時接続数」などの非機能要件の定義。

顧客の熱意を優先し、技術的な調査よりも「まず作ってみる」という姿勢。 顧客が提示した仕様書を、一言一句変えずにそのまま要件定義書に転記すること。 プログラミング言語の選定ミスとして、言語を切り替えること。 不確実性の高い技術について、要件定義の段階で「十分に調査・分析（フィジビリティスタディ）」を実施すること。

口頭での依頼は受け付けず、所定の「変更要求書」の提出を求め、影響分析（工数・コスト）の結果をもとに審議する。 顧客満足度を第一に考え、その場ですぐに追加を承諾し、作業を開始する。 開発チーム内の人間関係を考慮し、追加要件はこっそり実装して事後報告する。 納期遅延のリスクがあるため、一切の変更要求を拒否し、当初の予定を貫く。

ユーザーに操作マニュアルを読み込んでもらい、機能名称をすべて覚えてもらう。 ワイヤーフレームやプロトタイプを作成し、具体的な画面イメージと操作フローを共有して合意を得る。 会議の回数を増やし、議事録を1文字も漏らさず正確に記録する。 専門用語を多用した詳細な内部構造図（クラス図など）を提示し、納得させる。