需求总是在发生变化
之前的狗门运行的很不错，但是用户很快有了新的想法：它们嫌手动开门太麻烦了，希望能通过识别狗叫声自动开门。
Paste_Image.png
虽然这样的用户很烦人，但是用户永远是对的。
Paste_Image.png
场景中会有多条路径，但是目标只有一个
现在将声音识别器参与到系统中的场景，修改原先的用例。考虑到用声音识别器开门是一种独立的路径，可以这一步分单独分列出来。如下图：
Paste_Image.png
可以将更常用的路径放到主要路径中，声音识别器明显更常用，再次修改
Paste_Image.png
场景
每一条路径都是一个场景。一个用例可以有多条路径，即多个场景，但是所有路径的最终目标都是一样的。
替换路径不能缺少
替换路径虽然不常用，但是必不可少，否则用例就是不完整的，导致需求分析也不完整。
用修改后的用例检查需求列表
用修改后的用例检查需求列表，发现缺少声音识别的功能，因此添加这些功能
Paste_Image.png
为新的功能编写代码
新的需求分析出来以后，可以编写代码。主要增加了一个狗叫识别类
测试新功能，发现问题
测试新功能代码，发现似乎有些问题。通过狗叫开门以后，狗门无法自动关闭。
Paste_Image.png
经过分析发现了问题的原因：之前自动关门的相关代码，放置在了按钮开门之后；而声音识别开门后面没有相关的代码
按钮开门后有自动关门的代码
Paste_Image.png
修正错误，但不要重复
为了修正这个错误，有个程序员认为，可以在声音识别开门后面加上同样的自动关门代码，但是这样就造成了重复代码
Paste_Image.png
将自动关门的相关代码从遥控器类中，移动到狗门类中是更好的方法，不会造成重复
Paste_Image.png
最后再次测试，一切正常了
Paste_Image.png
总结：
- 用户的需求总是在发生变化，因此系统也常常会被修改
- 修改从更新用例开始
- 一个用例从起点到终点可以有多条路径，每条路径都是一个场景
- 替换路径是一条单独路径，虽然不常用但是不能缺少
- 修改代码是应该消除重复
