画面一覧より先に利用の流れを書く
誰が、どの情報を入力し、何を受け取り、次にどう行動するかを順に記載します。各工程に必要な画面、データ、外部連携を対応させます。価値が確かめられるなら、管理側の一部を手作業にする選択肢も検討できます。
完了条件を操作で説明する
「検索できる」ではなく、対象データ、検索条件、結果がない場合、権限がない場合の挙動を書きます。開発側と発注側が同じ手順で確認できる条件にすると、完成後の解釈の違いを減らせます。
保留と不足を区別する
将来実装する機能には保留の理由を残します。一方、バックアップ、障害連絡、アクセス制御など、初回公開から必要な事項は独立して確認します。後回しにした管理作業には担当者と対応時間を割り当て、誰かがやる前提にしないでください。
合意後の変更方法
新しい要望が出たら、同じ予算内で入れ替えるのか、追加費用が必要かを判断します。変更理由、影響する納期、承認者を残し、会話だけで範囲が広がらない運用にします。
参考資料と編集について
- ユーザのための要件定義ガイド 第2版（IPA 独立行政法人 情報処理推進機構） ↗
- 要件定義とは？ 今さら聞けないDX関連用語をわかりやすく解説（DX SQUARE／IPA） ↗
- システム構築の上流工程強化（非機能要求グレード）紹介ページ（IPA 独立行政法人 情報処理推進機構） ↗
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日