要件定義書の作成のコツ7（裏で状態が変わった時の考慮）
私は、WEBシステムの要件定義書を作成したり、他の人が作成した要件定義書をレビューすることがあり、その過程で指摘することも多く、自分で作成する際にもどのように記載すればよりわかりやすい仕様書となるのか？を日々試行錯誤しております。
「要件定義書の書き方をまとめたい！」という思いもあり、今回要件定義書の書き方をまとめてみることにしました！
まだ一部分ですが、要件定義書を作成する参考になれば嬉しいです。
要件定義書とは、サイトをどのような仕様にするかまとめたドキュメントのこと
要件定義書についてざっくり説明すると、WEBのシステム開発をする上で、サイトを作る（プログラミングする）前に、まずどのような仕様にするかをドキュメントにまとめます。このドキュメントのことを要件定義書と呼びます。
家電の取扱説明書には、ボタンを押すとどのような挙動となるかが記載されていますが、そのようなイメージに近いです。
今回のテーマは、「裏で設定や状態が変わった時の考慮」について
画面遷移が連続する機能では、裏で状態が変わった時の考慮が必要です。
例えば、宿を予約するシステムにて、予約をするフローを例に挙げると、
宿を選択する画面ではプランの掲載や満席チェックを実施していますが、その後の確認画面では特にチェック処理をしていなかったため、予約完了画面で予約できない状態となり、エラー画面が表示されてしまいます。
画面遷移のたびに随時チェックをしない仕様であったため、ユーザーは煩わしい画面遷移をしないと予約できないことに気付けません。
なのでこのような状態にならないように、裏で設定や状態が変わった時のことを考慮し、チェック処理を検討する必要があります。
満席などのチェック処理は、入力画面だけでなく、確認画面、完了画面でもチェック処理が必要
上記の回避するために、満席などのチェック処理は入力画面だけでなく、確認画面、完了画面でも画面遷移のたびにチェックする必要があります。
裏で設定や状態が変わった時のことを考慮し、入口の画面でチェックするだけでなく、画面遷移途中の画面（確認画面、完了画面など）でも必要に応じてチェック処理が必要かの検討が必要となります。
発生しうるパターンを整理し、参照する側の機能にて、どのタイミングのチェックすべきかを検討
上記では、宿のプランが満席になり予約ができない状態を例に挙げましたが、
他には、
・予約受付期限を過ぎた
・予約キャンセル期間を過ぎた
・宿のオーナーが該当プランの掲載を停止した
などがあります。
発生しうるパターンを整理し、参照する側の機能ではどのタイミングでチェックすべきかを検討する必要があります。
まとめる際には、入力、確認、完了など連続した画面遷移に注意し、画面遷移順に並べていきます。
入力画面で表示していた際のバージョンを保持して、確認、完了を遷移させるパターンもある
おわりに
以上で終わりとなります。
要件定義書には、仕様を漏れなく記載し、わかりやすく、認識誤りがないようにまとめていく必要がありますので、なかなか大変な作業です。
ですが、気を付けるポイントを意識し、どのような目的のドキュメントなのかを考えながら、日々作成に取り組むと徐々に良いドキュメントになってくるかと思います。
最後まで読んで頂き、ありがとうございました！
前回までの記事
おまけ
デザインに関しては素人なのですが、最近canvaでサイトのデザインを実験的に作ってみてます！
もしよければ以下の記事も読んで頂けると嬉しいです！