これまでの業務経験をもとに、バッチ処理の仕様で検討する必要がありそうな主な点をまとめてみました。あくまで参考程度なので、他にもいろいろあるとは思います。
◆バッチ実行時の入力パラメータ（あるのであれば...）
- 入力パラメータの数
- 入力パラメータの桁数
- 入力パラメータの型
- 入力パラメータの範囲
ジョブスケジューラ製品を使用する場合、その製品の特徴、制約を把握する必要があります。
◆実行契機、周期
いつ、何をトリガーにして実行を開始するのかの仕様を決めます。
◆入力ファイルの仕様
- 拡張子
- ファイルの内容項目
- 文字コード（テキストファイルの場合）
- ファイル名規則
- ファイルの生成契機
- ファイルの削除契機（貯めるとディスク容量を圧迫するので削除が必要な場合）
- 格納ディレクトリ（ディレクトリ構成）
- 入力ファイルなしの場合の挙動
- 入力ファイルが空の場合の挙動
- 入力ファイルが複数ある場合の読込順序
- 空行の扱い（テキストファイルの場合）
- 改行コード（テキストファイルの場合）
- 最大サイズ、最大行数
- ファイルのバックアップの有無、方法（NASへの保存とか）
◆出力ファイルの仕様
- 拡張子
- ファイルの内容項目
- 文字コード（テキストファイルの場合）
- ファイル名規則
- ファイルの削除契機（貯めるとディスク容量を圧迫するので削除が必要な場合）
- 出力先ディレクトリ（ディレクトリ構成）
- 出力ファイルが空の挙動の有無
- 出力ファイルがなしの場合の挙動の有無
- 改行コード（テキストファイルの場合）
- 最大サイズ、最大行数
- 出力先ディレクトリに既に同名ファイルがあった場合の挙動（上書きか異常終了か）
- ファイルのバックアップの有無、方法（NASへの保存とか）
◆中間ファイルの仕様（必要であれば...）
中間ファイルとは、ジョブとジョブの間などでデータを受け渡す目的で一時的に作成するファイルです。要求仕様を満たすために内部的に作成するものです。
◆業務量
- バッチ処理1回あたりの最大実行量
- 年間あたりの最大実行量
お客さん（発注者）しかわからないはずなのですが、お客さんもなかなか確定できないまま時間が経ちがちです。とりあえず概算で見積もって書いておく、くらいになりがちな気が。
◆データベース
- テーブル仕様（カラム、主キー、ユニークキー、AUTO INCREMENT、などなど）
- コミット単位の件数（100件ずつコミット？1000件ずつコミット？）
- コミット失敗時のリカバリ
- 「フラグ1」→「フラグ1」の更新を許容するか？（※１）
- 「フラグ1」→「フラグ0」への更新はありか？（※２）
- 削除は物理削除か論理削除か？（※３）
- 排他取得はwait?no wait?（※４）
- パーティショニング（※５）
（※１）仕様の問題として例えば「失効状態」→「失効状態」へのUPDATEは許容するか？という問題です。フラグは変わりありませんが、テーブルには大抵の場合、更新日カラムが存在するので、更新日をアップデートする必要があるか？という話です。
（※２）仕様の問題として例えば「失効状態」→「有効状態」へのUPDATEは許容するか？という問題です。不可逆的なテーブル更新がないかを確認する必要があります。
（※３）個人情報関係の場合、退会者のユーザ情報は保持しないことが原則なので物理削除になるかと思います。その他のデータに関してはディスク容量とも相談ということになるかと思います。
（※４）オンライン処理であればno waitが一般的でしょうけども、バッチ処理なら一定時間はwaitするのが一般的かと思われます。
（※５）テーブルデータが膨大になる時、性能向上のためパーティションに分けることが考えられます。まだ経験が浅いためなんとなくですが、100万レコード超えるテーブルなら検討を始めたい感じですかね。
◆ログメッセージ
- エラーメッセージ
- ワーニングメッセージ
- インフォメッセージ
- デバッグメッセージ
その他備考
◆異常発生時の扱い
異常があった時点で処理を異常終了？OR 異常があっても続けて流す？
これは決めの問題であり、プロジェクトや顧客の考え方によると思います。
ただ、製造業や流通系だと、どの商品でエラーが起きたのか特定することが大事なので、異常があっても全件ループさせる傾向にある、と聞いたことがあります。
◆フレームワークの特徴、制約
バッチ処理は、オンライン処理よりもフレームワークの特徴、制約の影響を受けやすいと思います。
（独自フレームワークを使っているプロジェクトで、入力ファイルとしてcsvしか読み込めない、1度の実行で入力ファイルは複数読み込めない、という事例を経験したことがあります。）
プロジェクトで使用されているフレームワークの仕組みを理解することが肝要です。
◆性能問題
- バッチ処理はオンライン処理に比べて性能観点が常につきまとう印象です。
- マルチスレッド、マルチプロセス化の検討が必要なシーンはよくあると思います。
- SELECT文の改修はよくありがちなので、SQLの学習が特に重要な印象です。DMLは基本的に、登録（INSERT）抽出（SELECT）、更新（UPDATE）、削除（DELETE)の4種類に分けられますが、この中でぶっちぎりに難しいのがSELECT文。テーブル結合が何重にもされていると、Javaなどのプログラミング言語よりもデバッグの難易度が高いので、厄介です。
- 何万、何億単位のテーブルレコードを操作する場合、プログラミング言語側で改善しようとするより、少量の重いSQLを実行した方が基本的に速いです。