画面ごとの目的と役割を明確にする
その画面が「何のためにあるのか（目的）」を簡潔に明記することがまず必要です。その画面仕様書を開いた際に何の画面仕様書なのかが一目でわかるものをになっているといいと思います。
また、前後の画面遷移の流れ（UX面）も書いてあると実装の際により理解が深まり、処理やユーザー操作の流れをイメージしやすいと思います。
UIについて
UIの要素ごとの名称や種類などを表として作成する必要があります。
現場やチームによってどこまで詳細なものを求められているかによりますが、既にフォーマットがあったり、前回の実装などで作成されているものがあればそれを元に相談しながら進めるのがいいと思います。
例:
| 項目 | 内容 |
|---|---|
| 画面名 | ログイン画面, 入力画面 |
| ID | login_button, tv_name |
| 種類 | TextView, EditText, Button |
| 表示テキスト | 「ログイン」「利用する」 |
| 初期状態 | 活性非活性の状態,Visibilityの状態など 特に変化がない場合は「-」にする時もある |
| イベント処理 | クリック時の挙動、文言表示など、 状況によって変化する際はその詳細なども含めて書く |
| 遷移先 | API成功時→「ホーム画面」失敗時→「エラー画面」など。（イベント処理の中に書いてもいいと思います。） |
| 多言語対応の有無 | 「⚪︎」「-」 |
その画面で使用するAPIを記す
その画面への遷移時や画面内のボタンを押した時の処理に使用するAPIはそれぞれの処理とは別に明記されていると親切だと思います。
また、そのAPIからのレスポンスをどのように使用するのか、返却されたレスポンスを直接使用するのか、DBに保存されるのか、Preferenceに保存するのかなども気をつけて書いていきたいですね。
送信時・取得時に関わらず、必要なデータ項目やどこでそのデータを使用するのかなども細かく書いてあるとよりわかりやすくなります。
エラー時の処理も忘れずに！
API処理がある場合などは成功時の処理と失敗時の処理で挙動が異なるためどちらも記載する必要があることを忘れないでおきましょう