回答

システム分析の歴史の中で、最も困難な課題の1つは、明白でない、曖昧な、または隠れた要件を特定し形式化することです。発注者自身が何が必要かを明確に説明できないことが多く、真の期待を明らかにせずに用語を使用します。

主要な特長:

• 暗黙の要件は分析、積極的な傾聴、確認質問、インタビュー、および観察を通じて特定されます。
• 形式化は、発注者と開発者の両方に理解可能な言語で行われます（例えば、ユーザーストーリーやBPMNシナリオを使用）。
• 必ず修正された表現を発注者と確認し、合意することが重要です。これにより、あいまいさを避けることができます。

問題の歴史

形式化されていない要件の問題は、最初の導入プロジェクトから知られています。当初は簡単なインタビューが用いられましたが、現在ではユーザーストーリーマッピング、プロトタイピング、ファシリテーションが使用されています。

問題

暗黙の要件は、誤ったタスク設定、無駄な労力、および当事者間の対立を引き起こします。

解決策

インタビュー技術、視覚化（プロセスマップ、プロトタイプ）、ファシリテーション、結果の明確な文書化を使用します。要件の各段階の後でフィードバックを確認します。

ひねりのある質問。

プロジェクト開始前にすべての要件を形式化できますか？

いいえ、多くの要件はプロトタイピングとプロジェクトの明確化の過程で明確にされ、特定されます。

発注者の明示された希望だけを記録すべきですか？

いいえ、アナリストは暗黙の期待にも取り組み、ビジネスの目標を分析し、隠れたニーズを特定する必要があります。

システムアナリストの仕事は要件を技術的な仕様に翻訳するだけですか？

いいえ、アナリストは要件の形式化、合意、明確化、矛盾の特定にも責任を負います。

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

• 中間合意を記録しないこと。
• すべての要件を同じ重要性だと考えること。
• 明示されたことだけを文書化し、実際のプロセスを分析しないこと。

生活からの例

ネガティブケース:
アナリストは、発注者が言ったすべてのことをプロジェクトに記録し、詳細を明確にしませんでした。 利点: 開発が迅速に始まり、分析にかかる時間を節約。
欠点: 要件の誤解から多くの手戻りや発注者との対立が発生しました。

ポジティブケース:
アナリストはプロトタイプを作成し、確認セッションを行い、発注者と共に暗黙の要件を記録しました。
利点: 要件の高い正確性、満足した発注者、少ない対立。
欠点: ファシリテーションとフィードバック収集にかかるコスト。