目標

ユーザー要求について共通理解を得るための唯一の文書を作成する。 その結果、ユーザー要求をハンドリング出来そうかどうか考えてみる。

検証内容

読書感想文：「ソフトウェア要求」6, 7, 8, 9 章で学習した内容をもとに、下記の図を作成して、ステークホルダーの発見からユーザー要求を引き出し、機能要求を発見するところまで行った。
作成の検証には前回に引き続き、個人開発しているlydie-serverの要求をもとに行った。

• コンテキスト図：外部エンティティの発見
• プロセスフロー図：ユーザーの業務に対してどの部分がシステムのユースケースになるかを発見する
• ユースケース図：機能要求の発見

できるだけ GitHub のマークダウン記法の範囲で作図をしたかったので、上記の図ごとの目的を達成できるように参考にした(1)(2)から個人的な解釈で作成した（本来は型通りに記載すべきだが、それは今後の改善点とする）。

結果

下記の図を作成することができた。

• コンテキスト図
• プロセスフロー図
• ユースケース図

考察

上記の結果今のところ自分が得られた実感は下記のとおりである。

• ステークホルダーの発見と、発見したステークホルダーごとの機能要求の発見
• ユーザーの行動からシステムがユーザーの期待値に沿えているかの実感（業務フローの課題点を解決できているか？を検証できる）
• システムを利用する際のフローを考えることで、システムの機能要求を発見

自分が目指したい目的（ビジネス要求）がユーザーの期待値（ユーザー要求）に応えられるかを簡単な図によって検証することができたという実感が湧いた。これはプロトタイプを作成するよりクイック＆ダーティーに仮説を検証する良い方法だと思う（もちろん要求がある程度固まった場合はプロトタイプで検証するのも良いとは思う）。
「この機能要求はなぜ達成する必要があるのか？ほんとにユーザーのためになるのか？」という自身の疑問を解決するためには、この手法はかなり有効であると感じている。特にユーザーの意見を鵜呑みにするのではなく、意見と行動によって裏に隠された本当の要求を見つけるために自身で妥当性を検証できることに価値を感じている。

参考文献

(1) カール ウィーガーズ；ジョイ ビーティ. ソフトウェア要求　第 3 版 (Japanese Edition), 日経 BP 社. Kindle Edition.
(2) RDRA https://www.rdra.jp/