ご回答。

問題の背景:

ITプロジェクトの規模と複雑さが増すにつれて、ビジネスオーダーからの要求が抽象的な希望の形で届き、開発チームに渡すとまったく異なるものになってしまう状況が何度も発生しました。この原因は、ビジネスとITの間の用語の断絶、期待、抽象度の違いです。

問題:

分解のステップを考慮しないと、要求が不完全になったり（重要な詳細が省かれる）、過度に曖昧になったり（評価や実現が難しくなる）、または語彙の罠、無視された用語、および誤解によって歪められてしまいます。

解決策:

システムアナリストは、各要求を順次分解します。ビジネステクニカル用語を形式化し、ビジネス目標を機能やタスクに変換し、ユーザーシナリオやシステム動作を説明し、受け入れ基準やテストケースに関連付けます。UMLやBPMNのモデル、グロッサリー、チェックリスト、チーム間の直接レビューを利用することが重要です。

重要な特徴:

• 注文者と共同で用語のグロッサリーを構築
• 図表と具体的な要求の定義を使用
• 要求を受け入れ基準やテストケースの言語に翻訳

騙しの質問。

ビジネスの希望を自由形式で残し、開発段階での追加作業を行うことは可能か？

いいえ、誤解や実装のエラーのリスクが高いです。

分析段階で実装の詳細（データの保存方法など）を考慮する必要があるか？

いいえ、分析は「何」と「なぜ」に関するものであり、「どのように」ではありません。技術的な詳細はアーキテクチャと開発の責任です。

常に一つの要求の記録 = 一つのモジュール/機能か？

いいえ、しばしば分解が必要であり、大きな要求はサブ機能やユーザーストーリーに分けられ、それぞれに受け入れ基準があります。

一般的な誤りとアンチパターン

• 用語集なしでビジネス用語とテクニカル用語を混在させる
• 要求を「曖昧な願望」として記述する
• 原子性の違反 — 一つの要求が異なる多くの実体を含む

事例

ネガティブケース: 注文者が「ユーザーは売上分析をすべて見る必要があります」という希望リストを渡し、それを仕様書にそのままコピーしました。

プラス:

• ドキュメント作成が迅速

マイナス:

• どの指標が必要か、どのように必要かが不明
• 常に追加作業が発生

ポジティブケース: アナリストが注文者に質問し、必要な指標のリストを作成し、ユーザーの役割を定義し、レポートのプロトタイプを作成し、用語のグロッサリーを確認しました。

プラス:

• 開発とテストのための明確な基準
• 追加作業の最小化

マイナス:

• より多くの時間がかかり、分析段階での注文者の関与が必要