第3章要件変更
この章で学ぶこと
要件は常に変化する。設計やアプリケーションがどんなに素晴らしくても、やがてアプリケーションは成長し変更される。この章では、要件変更に対応するための方法を学ぶ。
今回の例では、リモコンを使用して犬用ドアを開閉するようにしていたシステムを、犬の鳴き声に反応して自動でドアが開閉するように要件が変更される。
ソフトウェア分析設計において唯一不変であること = 変更
友好的な顧客が、「正しく動作するアプリケーションを修正する」といったような、狂ったような新しい要件を出すこともある。しかし、良いユースケースがあれば、新しい要件に対応するための変更を迅速に行うことができる。
システムに新しい要件または違った動作が必要になるとき、最初にユースケースを更新する。
| メインパス |
|---|
| 1. Fidoが外に出たいと吠える |
| 2. ToddまたはGinaがFidoの鳴き声を聞く 2.1 鳴き声認識装置が鳴き声を検知する |
| 3. ToddまたはGinaがリモコンのボタンを押す 3.1 鳴き声認識装置がドアを開くための要求を送信する |
| 4. 犬用ドアが開く |
| 5. Fidoが外に出る |
| 6. Fidoが用を済ます 6.1 ドアが自動的に閉まる 6.2 Fidoが中に入りたいと吠える 6.3 ToddまたはGinaがふたたびFidoの鳴き 6.3.1 鳴き声認識装置が再び鳴き声を検知する 6.4 ToddまたはGinaがリモコンのボタンを押す 6.4.1 鳴き声認識装置がドアを開くための要求を送信する 6.5 犬用ドアが再び開く |
| 7. Fidoが家の中に戻る |
| 8. ドアが自動的に閉まる |
ユースケースがややこしくなってきた。
必要なのはわかりやすいユースケース
ユースケースがわかりにくければ書き直す。重要なのはチーム、顧客に説明して理解できること。
| メインパス | 代替パス |
|---|---|
| 1. Fidoが外に出たいと吠える | |
| 2. 鳴き声認識装置が鳴き声を検知する | 2.1 ToddまたはGinaがFidoの鳴き声を聞く |
| 3. 鳴き声認識装置がドアを開くための要求を送信する | 3.1 ToddまたはGinaがリモコンのボタンを押す |
| 4. 犬用ドアが開く | |
| 5. Fidoが外に出る | |
| 6. Fidoが用を済ます 6.1 ドアが自動的に閉まる 6.2 Fidoが中に入りたいと吠える 6.3 鳴き声認識装置が再び鳴き声を検知する 6.4 鳴き声認識装置がドアを開くための要求を送信する 6.5 犬用ドアが再び開く |
6.3.1 ToddまたはGinaがふたたびFidoの鳴き声を聞く 6.4.1 ToddまたはGinaがリモコンのボタンを押す |
| 7. Fidoが家の中に戻る | |
| 8. ドアが自動的に閉まる |
代替パスとは・・・ ユースケースにおけるオプションまたは代替の手段を提供する、1つまたは複数の追加ステップ。
ユースケースにおいて、最初から最後までステップが揃っているパスのことをシナリオと呼ぶ。今回はメインパスがシナリオ。 ほとんどのユースケースには複数のシナリオが存在するが、その目標はどれも同じ。
ユースケースが変化した場合は、要件を再度見直す。
要件の変化によって、今まで存在にすら気づかなかった、システム上の問題が判明することがある。変更は避けられないことであり、変更に取り組むたびにシステムは改善される。
要件一覧
- 犬用ドアの開口部は少なくとも30センチの高さが必要である。
- リモコンのボタンを押すと、ドアが閉じていれば開き、開いていれば閉じる。
- 開いたドアが閉じられなかった場合、自動的に閉まる。
- 鳴き声認識装置は、犬が吠えるのを検知できる。
- 鳴き声認識装置は、犬の鳴き声を検知したときに、ドアを開けることができる。
コードの更新
物事はできるだけシンプルに保ってください。意味なく複雑にする必要はありません。
- 重複は避ける。
コードの重複は、ほとんどどんな場合でも避けるべきである。
保守する場合は、悪夢であり、通常はシステム設計における問題の現れである。
