汎用機システムでのシステムはCUIの世界で構築されます。(3270形式/5250形式とか言います)
(*)未経験の人もいらっしゃるので補足しますと,Unix系のCUI/Window.DOS BoxのCUIとも違う世界です。
1画面は 24行 * 80桁の固定で構成されます. (一部25行の分もあります)
帳票はラインプリンタで,1頁は 66行* 132桁で作表されます(一部136桁の版もあります)
設計は,キャラクタ単位で行います。ここで登場するのがスペーシングチャートと呼ばれる罫線入りの白紙です。
汎用機上流工程の設計はこのチャートに書き込んで,画面設計/帳票設計をしています。(過去形でないのは,今も手書きで設計している部隊もいるからです)
レコードレイアウトもこの手のチャートで項目長で線を引いてたんですよ...これは過去形。
Open系の開発には似合わないと思っているのですが,この手法でOpen系上流工程を仕切っているプロジェクトがあります。
さすがに,手書きではないですが, エクセルを小さなセルに区切って, 25行*80列の方眼紙を作り,そこにキャラクターで画面/帳票の設計をしています。
開発現場はOpen系の開発となりますので,摩擦が生じます。設計側と製造側間の摩擦は浪費でしかありません。
どうなっているんかな、と聞いてい見ると、上流工程は製造知識/経験は不要というスタンスです。
これは汎用機の世界では正論とされていて、Open系でもしばしば問題になるテーマです。
製造知識不要という背景には、汎用機の事務用言語(コボル・PL/I)は実装可能な範囲が小さいので,設計者は、あえて実装知識を習得しなくても、適切な設計が出来るからです。
Open系でこの手法を持ち込むときは,実装可能か不可能かの判定を,設計の段階で判定する機構が必要です。判定しないまま下流工程に流すとデスマーチの発生となります。
業務設計に実装経験不要というのは持論なのですが,実装の可否の判定を上流工程に適時にフィードバックする仕組みが必要だと考えてます。上流SEが知識を持つのがベストですが現実は難しいようですね。
汎用機方式では(一部ですが)製造工程を考慮しないで,設計を完了することがあるので,製造現場は混乱することがあるようです。升目のCUIベースの設計書でGUIを作ることになります。その結果,仕上がりは,設計書のイメージとはかけ離れたものになります。
エンドユーザーが抱いて姿と一致すればいいのですが、一致しないことが多いようです。
使用者であるエンドユーザーに快適に使っていただくのが技術者の目的であるので,不要な摩擦をなくすのは,プロジェクト運営の重要なテーマです。
ユーザーニーズの実現性の可否や,コスト対機能の調整は上流工程の目に見える仕事なので出来て当然でノウハウ本も結構出回ってます。上記で述べたような目に見えない調整ごとなどは,疎かすると大きなしっぺ返しとなって跳ね返ってきます。