ITベンダーやユーザー企業の中には、社内標準の要件定義方法論を持っているケースがある。ただし、それらは大抵の場合、新規システム開発を前提としたもの。既存システム改善（保守開発）に特化した要件定義方法論は、寡聞にして聞いたことがない。
新規開発の方法論を既存システム改善に流用できればよい。しかし、要件定義のエキスパートが集まった有志のコミュニティー「要件定義チームジャパン」のメンバーによると、新規開発と既存システム改善の要件定義は似て非なるものであり、アプローチの仕方を変える必要があるという。要件定義チームジャパンは2014年に既存システム改善での要件定義方法論を独自に策定しており、その議論の過程で違いが明らかになった。
既存システム改善での要件定義は、近年重要性を増している。ここでは、既存システム改善での要件定義の特徴、方法論の要点、必要とされるスキルを紹介する。
既存システム改善の「起点」はシステムレベルの要望
新規開発と既存システム改善とでは、本質的に何が違うのか。要件定義チームジャパンのメンバーの一人、日立コンサルティング マネージングディレクターの水田哲郎氏によると、要件を考える「起点」が違うという。
新規開発では、開発者側が経営層や上級管理職と「在庫回転率を2割高める」「見込み客の成約率を1割高める」といった経営レベルの目標を定め、それを起点とする。その上で、経営レベルの目標を実現するための業務とシステムの要件を考える。実際には、利用部門の現場担当者にもヒアリングし、「こんな機能が欲しい」「こういうデータを扱えるようにしたい」といった具体的なシステム要望が上がってくることもあるが、そうした要望は経営レベルの目標に合致するかどうかで取捨選択する。あくまで、起点は経営レベルの目標。トップダウンのアプローチである。
一方、既存システム改善では、システム要望が起点になる。既に使っているシステムを対象に改善要望を募るので、利用部門はそれを基に「こんな機能が欲しい」「こういうデータも扱えるようにしたい」といった具体的なシステム要望を上げてくる。別の見方をすれば、開発者側は利用部門に対して、既存システムをベースにした具体的なシステム要望を求めることができる。あとは、システム要望の妥当性を検証して、実現する要件を決めればよい。これは、ボトムアップのアプローチといえる。
