要求分析がうまくいかない原因は、技術ではなく人と人の間にあります。
| 原因 | 中身 |
|---|---|
| ユーザは要求を言えない | 日々の仕事が「当たり前」になっていて、言語化されていない。 聞かれてはじめて気づくことが多い |
| ユーザは要求を知らない | 技術で何ができるかを知らないので、想像の枠が現状の延長になる |
| ことばが食い違う | 同じ用語を別の意味で使っている（第4回の用語定義） |
| 要求は変わる | 開発中に業務も市場も変わる。凍結しても現実は止まらない |
| 要求は矛盾する | 部署ごとに望むものが違う。全部を満たす解は存在しないことがある |
獲得とは、問題に関連するすべての情報を収集することです。
| 方法 | 向くところ | 注意 |
|---|---|---|
| 面談（インタビュー） | 背景や意図を深く聞ける | 聞き手の思い込みが入りやすい |
| アンケート | 多人数から広く集められる | 想定外のことは出てこない |
| 現場の観察 | 言語化されていない作業が見える | 手間がかかる |
| 既存文書・帳票の分析 | 実際に使われている項目が分かる | 形骸化した項目も混ざる |
| 試作品を触ってもらう | 「思っていたのと違う」が出る | 作る手間（第3回プロトタイプ） |
観察が効く理由。 ユーザが「言えない」要求は、聞いても出てきません。 しかし実際の作業を見れば分かることが多い。 「なぜこの付箋が貼ってあるのか」「なぜこの帳票を二度書きしているのか」── そこに、システムが解くべき本当の問題が隠れています。
表現とは、得られた情報を論理的な要求モデルに変換し、 仕様として正確に記述することです。
自然言語だけで書くと、どうしても曖昧さが残ります。 だから図や表を使ってモデル化します。
| 表し方 | 表せるもの |
|---|---|
| ユースケース図 | 誰が、システムに何をさせるか（第10回） |
| データフロー図 | データがどこからどこへ流れるか |
| 状態遷移図 | どんな状態があり、何で移るか |
| 画面遷移図・画面案 | 利用者から見た振る舞い |
| 用語集（データ辞書） | ことばの意味 |
曖昧な書き方の例。
これらはすべて、後になって「言った・言わない」の争いになります。 検証できない書き方は、要求として成立していないと考えてください。
検証とは、要求モデルや仕様に間違いがないことを確かめることです。
| 性質 | 問い |
|---|---|
| 完全性 | 必要なことがすべて書かれているか |
| 無矛盾性 | 互いに矛盾する要求はないか |
| 明確性 | 読む人によって解釈が変わらないか |
| 検証可能性 | 満たしたかどうかを後で確かめられるか |
| 実現可能性 | 技術・コスト・期間の中で作れるか |
| 追跡可能性 | どの要求がどの設計・どのテストに対応するか辿れるか |
追跡可能性が効く場面。 第8回のテストで、テスト網羅行列という表が出てきます。 「要求」と「プログラムの部分」の対応を記録しておく表です。 これがあると、システムを修正したときに どこを再テストすべきかがすぐ分かります。 要求分析の段階で対応を残しておくことが、後の工程を助けます。
誤りを見つけるのが遅れるほど、修正の費用は大きくなります。
| 見つけた工程 | 直す範囲 |
|---|---|
| 要求分析中 | 文書を直すだけ |
| 設計中 | 要求＋設計を直す |
| 実装中 | 要求＋設計＋コードを直す |
| テスト中 | 要求＋設計＋コード＋テストをやり直す |
| 運用開始後 | 上記すべて＋業務への影響、信用の低下 |
だからこそ、要求分析には時間をかける価値があるのです。 急いで先へ進むことが、結果的にいちばん遅い道になります。