##要件定義・調整
開発案件について、どういった実装を行いますかという
ユーザ↔開発間の、認識合わせ、お約束、取り決め、これって言ったよな、言質とるドキュメント...です。
ここで下手な定義したり、ここ決め忘れた、とかすると
「すみません、ここやっぱ無理で。。」とか
「すみません、ここって何がいいですか。。？」とか
まぁそう。みんな大嫌いな手戻りになるわけだ。
ということで、要件定義・調整をする際に抑えておきたい観点や注意点をまとめてみよう、という記事。
##調整時の注意点
調整時、やり取りした履歴はすべてドキュメントにしておかなくてはいけません。
スプレ上でQA表にて運用するもよし、会議にて議事録を作成、メールなどで確認を取ったうえで要件書に使うもよし。
また、開発→ユーザに質問する際には基本的に、選択肢を用意することが重要
例.
〇「文言はAAAAでよいでしょうか？」
×「文言は何にすればよいでしょうか？」
仮にAAAAでない場合、どちらも選択肢がないのは変わらないが、AAAAっぽい何かが来やすい。
AAAAでいい？って聞かれた場合に、もし何でもよければAAAAになるわけで
回答までのスピードがこっちのが早く、デメリットがない、完全上位互換な質問なので使わない手はない。
・バリデーション
・業務上の仕様で決まる値範囲
などのように、さすがにこちらで選択肢を用意できない質問の場合は仕方ない。
##要件書の観点・注意点
要件書作成時の注意点は以下。
| 観点 | 注意点 |
|---|---|
| 業務での実装目的 | 基本的に絶対あるので、開発側も一応把握しておこう |
| 鳥観図 | 改修が必要な部分に色がついているといい。改修なしだが試験はする部分は違う色とか。 |
| 他シス影響についてわかること | IF修正はないが試験はするなどでも記載しておこう |
| 開発スケジュールについて記載 | 大まかでよいので書く。未定の場合は予定ですって書いとけ |
| 業務要件が修正されるかどうか | ユーザ側で運用方法を変える必要があるなら書いておく。使うのはユーザだからね |
| 画面表示項目のカラム名 | 必ずユーザから来た文字列をコピペ。手打ちして間違えたら失業すると思え |
| 画面表示メッセージ文言 | 必ずユーザから来た文字列をコピペ。手打ちして間違えたら失業すると思え |
| 画面追加項目値(編集可)の値範囲やバリデーション | 編集可能な追加項目は絶対に必要。最初に確認 |
| ロジック改修のフロー図とか | あったら見やすいしわかりやすい。まぁ時間ないなら設計の時でいい |
| テーブルカラム追加 | イメージ図とかcsvとかはっつけとけ。とりあえず提示する！ |
| 影響範囲がすべて記載されている | まず影響範囲の調査漏れがないことが前提 |
| 付随して改修する箇所を全部提示 | あとから、勝手な仕様変更とか言われたら責任とれないのでね |
| 要件書を見てすべての必要改修がわかること | 別に改修予定の成果物名一覧とか書いちゃってもいいと思うぞ。要件書は神なんだ |
| ユーザと調整したやり取りの記録 | スプレや議事メモなどがあれば添付なりパスを記載しておきたい。 |
また、これらの情報をしっかり次の工程である、設計書に記載しきるところまで確認したい。
##影響範囲に漏れがあったら怖いので...
そもそも案件初期調査の時点で影響範囲の調査や、実現性などは確かめている前提。
追加予定のテーブル名でソースGrepなど、当たり前の調査ができていることは前提としています。。