第02章 - 收集需求 - 《深入浅出面向对象分析与设计》读书笔记

快速实现一个狗门系统

这是一个关于狗门新项目。用户想要一个能用遥控器控制的狗门：按一下开门，再按一下关门。

Paste_Image.png

程序员很快实现了代码，有两个类：狗门类和遥控器类。

最后创建一个测试类模拟运行一下，一切正常。

Paste_Image.png

想当然的需求分析

程序到目前为止表面上看起来不错，但是在实际运行中很快就出现了问题。

用户按下按钮开门以后，往往会忘记再次按下按钮关门，这时候，猫啊、兔子啊都进到屋里来了。程序员有点想当然了，他以为用户每次都会记得关门。

想当然的小猿

这就引出了一个问题：怎么才能知道系统到底应该具有什么功能？

与用户交谈，大概能知道系统应该具有哪些功能

交谈

将了解到的相关功能写成列表单，特别是用户希望门被打开以后，经过一段时间能自动关闭。

需求列表

注意：需求列表也是工作成果的一部分

什么是需求分析：分析出为了满足用户的要求，系统需要做的哪些事情

什么是用例

之前得到的需求列表全面吗？谁也不敢确定。更好的方式是设计一个场景，用系统的功能来描述这个场景，这样才能发现功能是否满足要求。

下面就是一个用例

用例

用例中的场景应该考虑全面，有些意外情况或者可选情况都应该考虑进来。比如：狗门打开，狗狗出去以后没有及时回来，狗门自动关闭了，狗狗回来需要再次开门。

Paste_Image.png

什么是用例：一个用例描述了系统为了完成特定的目标，可以做什么（即具有什么功能）。因此，用例可以捕获需求。

用例的三个要素：

• 用例的价值
• 外部启动者
• 起点和终点

用例的三要素

关于用例的其他要点：

• 每个用例都对应一个明确的目标，且只有一个。
• 多个目标有多个用例
• 也可以用用例图来表示场景

用例检查需求

用例可以检查需求，甚至发现新的需求

检查需求

检查用例中的每一步，看看是否全部都可以用需求列表中的某个功能解决。

注意：某些步骤和系统功能没有关系，只是场景的需要，可以忽略

对照检查

经过对照检查，发现需求列表中的功能可以满足用例场景，下面就可以修改代码了。

相比原来的系统，增加了自动关门的功能

自动关门

每次修改系统后，都应该进行测试。下面的测试表明，狗门打开后，狗狗出去办完事、返回，一段时间后狗门自动关闭

测试

测试替换路径

上面的测试仅仅测试了用例中的主要路径。可选路径也需要测试。

狗狗出门后没有及时回来，狗门关闭，狗狗被关在门外。用户手动开门，狗狗返回，一段时间后，狗门关闭。

测试替换路径

实战：用例分析需求

又来了三个客户，各自有不同的需求（也就是说各自的系统有不同的功能）

不同的需求

给这三种需求设计三个不同的用例（每个有不同的目标）

使用密码锁开门的用例

用爪子自己开门的用例

将狗狗所在外面的用例

分析这三个用例的三要素

用例一

用例二

用例三

用这三个用例检查各自的需求列表

下面这个需求列表明显有错误，他不能满足用例中关闭窗户的功能

Paste_Image.png

下面这个功能列表也有明显的问题，他没有用例中要求的自动关门的功能

Paste_Image.png