自分的な要件定義の解釈は
- 何をやりたいのかを明確にする
- システムとして実現するために必要な項目の言語化
なんだけど、そのための流れとしてざっくり5このフェーズに分けるといいかなと思った
問題理解
要は「あなたは何に困っているのか？」を明確にしたい
有名な話で馬を早くしたいっていうのは「目的地に着くのが遅くて困ってる」が本質みたいなやつ
顧客は自分の理解の範疇で問題解決をしようとするから馬しか知らなければ馬を早くしたいってなるけど、車だったりほかの移動手段でも問題は解決できるよねというやつ
前提条件の共有も必須。目的地に早く着きたいけど生物との触れ合いの時間はより重要に考えている。とか、馬を大量に保有しているから馬を使うことは前提にある。とか、車を解決手段として用いられないケースもあるため。
KPI定義
システム開発はその問題を実際にどれぐらい改善できたらいいのか？みたいなのは立てておいたほうが良い
「目的地に着くのが遅くて困ってる」であれば「ぶっちゃけどれぐらい早くなったらいいの？」を定義しておく
具体性は数値で担保するのが基本なので、10%早く到着したいとかそういう感じ。もっというと計測方法も定めておくと後々楽です
ステークホルダーの特定
BtoBだと、誰かの発言で急にひっくり返った。みたいなことがありがちなので、部署だったり人だったりの単位で影響力と関心度の二軸でマッピングしておくといいとされている
要は「意思決定者って誰なの？」を明確にしておくのが重要ということ。
部署の力関係とか、人間関係とか面倒くさいけど組織としては重要だし、その辺適当にやると長い目で見たときに痛い目を見る（数敗）
非機能要件の決定
非機能要件っていうのは「作るシステムについて、どの程度の質を最低限として作成するか」ってこと
非機能要件を決める際はどうしたいですかとかではなく、「このシステムどうなると最悪ですか？」みたいな聞き方が良いとされているらしい
非機能要件の決定は要するに、正常な状態と異常な状態の境界値を決めるということなので。
目的地に早く着くのを目的としたとして、それでもなんらかの特例で遅くなる可能性がある（例えばよりよい馬を用意するで解決しようとして、よりよい馬の体調不良で現在の馬より遅くなるなど）。そういった悪くなるケースであっても、最低限現在の平均到達時刻n分より10%以上悪くなるのはダメ。といった時の平均到達時間+10%の時刻が非機能要件としての境界値になる。
KPIもちょっと似たところあるけど、これは改善目標なのでマストではないといえばマストではない（達成できなかったら何のために作ったんやでフィードバックを求められたり、これはこれで問題がいろいろ発生するだろうけど）
要件のレビュー
最後に要件に問題ないかを検証する
- 全員の解釈にずれがないか
- 誰かが困る抜けや矛盾がないか
- どうなったら完成とするか
- 明らかに非現実的ではないか
など。ぶっちゃけレビューテクはよくわからない部分が自分の中で多い
5w1h的な分析とか、境界値はあるかとか、KPIはあるかとか、第三者が理解できるような内容になっているかとか（設計担当が理解できるか）が重要そうかなーと思う
---
機能要件
機能要件は「こういう機能を作ろう！」というよりここまでのステップを通じておのずと決まってくるみたいな考え方をするのがいいらしい
消去法的な求め方が理想って話なんだろうけど、どこまで削り込んでもある程度の選択余地は発生するのでは？と個人的には思っているので、ここまでの5ステップで最良の解決策の中から選択する
みたいになるのかなぁと思う。ある種非機能要件やKPIは選択肢の幅を狭めるし、そこらへんが緩ければ実装側でやりやすかったりやりたい技術を使うとかができるんじゃないかな
---
Software Requirements Essentials: Core Practices for Successful Business Analysis
って本が結構いいらしいけど翻訳ないのでわからん
基本はそんなに外してないと思います（思いたい）
