要件定義と外部設計の進め方

要件定義は、システム化によって何を実現したいのかを業務の言葉で確定させる工程であり、外部設計は、確定した要件を利用者の視点から見える画面、帳票、入出力、機能の構成として具体化する工程である。両者は「何を実現するか」と「利用者にどう見えるか」を段階的に詰める関係にあるため、どの程度合意した段階で次の工程に進むかを事前に決めておくことが、進め方の要になる。ここでは、その原理、判断の基準、実務の場面、試験で問われやすい区別の順に整理する。

要件の確定と外部設計への引き渡し

要件定義では、業務上の課題と目標を出発点として、機能要件と非機能要件を利用者と開発側が共通に理解できる形にそろえる。外部設計では、その要件を受けて画面や帳票の仕様、業務処理の流れ、データの入出力を利用者から見た振る舞いとして定める。要件が曖昧なまま外部設計に進むと、後から要求が追加されて設計の作り直しが生じるため、要件の確定度を工程の出口で確認し、未確定の項目を明示しておくことが欠かせない。外部設計の内容は利用者との合意の材料であり、ここで認識がずれると、開発や受入れの段階で大きな手戻りを招く。そのため、利用者の代表者が業務の流れを自ら語れる体制を先に作ることが、要件定義の質を支える前提になる。

判断の基準と進め方の工夫

進め方を判断するときの中心的な問いは、利用者が実際に操作して初めて気づく要求があるかどうかである。標準画面や標準機能を用いたプロトタイピングは、利用者の理解を深め、業務理解のずれを早い段階で解消するために用いられる 。一方で、要件定義の時点で収集できなかった要求を受入テストの段階で追加的に集める運用は、要件定義の不足を補うための手段であり、前提として計画に組み込むものではない 。

進捗の把握にも判断の基準がある。プロジェクト全体がおおむね計画どおりに進んでいても、外部設計の各機能の作業状況を個別に把握する必要がある。全体の進捗は、個々の機能の遅れを覆い隠すことがあるためである 。仕様の確定に時間が掛かっている状況では、外部設計の内容を開発側が処理方法として容易に判断できるよう、補足資料を追加で作成して共有する 。資料は量よりも、読み手が判断に迷わないための具体性が重視される。

新技術を使うプロジェクトでは、要件が満たせるかどうかそのものが未確定である。未経験の技術やサービスを用いる場合は、開発フェーズに先立って実現性を検証する検証フェーズを設けることがある。検証する内容はステークホルダと合意しておき、検証で得た品質目標や工数、コストの情報をもとに、必要に応じて開発フェーズの計画を更新する 。