要件定義書の作成のコツ3（入力フォームの検討の仕方）
私は、WEBシステムの要件定義書を作成したり、他の人が作成した要件定義書をレビューすることがあり、その過程で指摘することも多く、自分で作成する際にもどのように記載すればよりわかりやすい仕様書となるのか？を日々試行錯誤しております。
「要件定義書の書き方をまとめたい！」という思いもあり、今回要件定義書の書き方をまとめてみることにしました！
まだ一部分ですが、要件定義書を作成する参考になれば嬉しいです。
要件定義書とは、サイトをどのような仕様にするかまとめたドキュメントのこと
要件定義書についてざっくり説明すると、WEBのシステム開発をする上で、サイトを作る（プログラミングする）前に、まずどのような仕様にするかをドキュメントにまとめます。このドキュメントのことを要件定義書と呼びます。
家電の取扱説明書には、ボタンを押すとどのような挙動となるかが記載されていますが、そのようなイメージに近いです。
今回のテーマは、「入力フォームの検討の仕方（入力内容にエラーがあった場合の挙動）」について
「入力フォームの仕様」とは、入力画面において、
入力内容にエラーがあった場合の挙動
入力フォーマット
入力内容のチェック処理
などを定義した仕様のことを言います。
今回は「入力内容にエラーがあった場合の挙動」について、解説していきます。
入力フォームの仕様書のイメージ
入力内容にエラーがある場合の挙動の整理
入力内容にエラーがある場合、
エラー画面を表示するか？
入力画面内にエラー文言を表示させるか？
でユーザビリティが変わってきます。
入力内容にエラーがある場合、入力内容は保持するか？
わりと仕様書作成時に見落としてしまう内容で、入力内容にエラーがある場合、送信ボタン押下前の入力内容は保持されるか？は、仕様書に明示的に記載していないと、どちらの意味でも捉えられるので、検討しておく必要があります。
ブラウザバックはブラウザによって挙動が変わるので、ブラウザバックを仕様に盛り込まないのがベター
上記入力内容を保持する仕様とする場合、入力画面内にエラー文言を表示させる仕様の場合は特に問題ないかと思いますが、エラー画面を表示する仕様の場合は注意が必要です。
ブラウザバックはブラウザやバージョンによって挙動が変わってしまうので、ブラウザバックを使用しない前提で仕様を検討する必要があり、エラー画面から元の入力画面に戻る場合は、専用の戻るボタンを設置するなどの対応が必要になってきます。
JavaScriptで、事前に入力内容をチェックするか？
またJavaScript（フロントエンド）で、事前に入力内容をチェックをすると、サーバーへのリクエストなしで入力チェックができるので、ユーザビリティが良くなります。
ただしJavaScriptは軽微なチェック処理しかできないのと、上手く動作しないブラウザも存在するので、サーバーサイドでの入力チェックも併せて必要となります。
JavaScriptの処理をリッチにしすぎると、ユーザビリティはよくなるが、工数は上がってしまう
その他としては、JavaScriptで入力文字をリアルタイムでカウントする機能などを用意すると、文字数超過エラーが発生しにくくなり、よりユーザビリティがよくなりますが、JavaScriptの処理をリッチにしすぎるとその分、工数も増えてしまうので、どの処理がMUSTで必要かを検討し仕様に盛り込んでいく必要があります。
おわりに
以上で終わりとなります。
要件定義書には、仕様を漏れなく記載し、わかりやすく、認識誤りがないようにまとめていく必要がありますので、なかなか大変な作業です。
ですが、気を付けるポイントを意識し、どのような目的のドキュメントなのかを考えながら、日々作成に取り組むと徐々に良いドキュメントになってくるかと思います。
最後まで読んで頂き、ありがとうございました！
前回までの記事
おまけ
デザインに関しては素人なのですが、最近canvaでサイトのデザインを実験的に作ってみてます！
もしよければ以下の記事も読んで頂けると嬉しいです！