システムの課題ページ最後部の業界事例に紹介のように、整備システム周りの現実課題は多く、整備システムが重要の証にもなっている。整備部門はシステム部門あるいはシステム会社の理解にフィットする細部要求機能を整理できないあるいは大きな時間を要する。業務担当により機能要求レベルがバラバラ(業務や組織が異なるためレベル統一性に欠ける)システム部門あるいはシステム会社は整備部門の実務機能ニーズの細部まで汲み取れないあるいは理解に大きな時間を要する。実務担当者とシステム担当者の相互知識がコンピュータおよびDB土俵上で噛み合わない。と1年以上にもおよぶ長い期間をかけてのシステム仕様とりまとめと、開発会社一体で要件定義を行っている状況がある。/機能要件のまとめまで手が回らない。大手航空会社のシステムレンタルはできれば避けたい海外パッケージ等を検討しても、導入判断がむずかしい。実業務へのフィット性に欠ける面は否めない年次のカスタマイズ機能強化等でコストが嵩む将来を含めて自社系によるプログラム改編を行えない整備情報システム�Wで全ての課題をクリア大手航空会社へ整備システム納入の大手SIヤーのプロジェクトマネージャと話す機会があったが、整備システム開発は整備業務とシステム/DBの両方に精通していることが重要であると述べていた。整備情報システムは、Phase�Vに至るまで度重なる機能強化を行っているが、この過程でも正にこのことが実感された。整備業務フィットのための、開発過程でテーブル設計の変更を伴う補正フィードバック量が想定外の状況を経験している。要件定義やテーブル設計の原則固定では細部改善は進まないし、フィードバック補正は業務を知らないと円滑に遂行できない。整備情報システム�Wは、開発当初から10年かけて今日の機能構成に至っている。総合テストマニュアル整備情報システム�Wは、システム開発並びにユーザー併用の総合テストマニュアルを特徴としている。テストマニュアルは実業務対応構成のため、ユーザーレベルの第2の要件定義書の目的を兼ねている。これにより、ユーザーは要求機能や要件定義書等の文書レベルでは見落とされがちの細部システム機能を、実業務レベルで総合確認できる。