《软件方法》-系统用例

真正的软件需求，从“系统用例”模块才成型，并独立讨论。

它来源于业务需要，从“优化后的业务流程”推导而出

但是“软件需求”，依然在关注“用户要解决什么问题”

它不是交互，不是设计，不描述“问题”最终的解决方案。

这里要补充根据系统责任边界来确定系统用例的例子。

我们用word文档来写作

我们用word文档来做标书

但我们不能把写作，或做标书

当成是word文档应该提供的服务或责任

真正有责任做标书的，或写作的，应该是那个责任人本身

而word，只是提供一个便捷的文字编辑器

进行写作文档的编辑

进行标书的编辑

所以，我们不能这样来画word的使用过程：

写作者要自己写作，而不是请求word文档写作

写作者可以请求word文档编辑文字

这个部分给我了很大的启示

就是在我们问这个事情做的对不对时候

我们可能是找不到答案的

我们可能要换个问题来问

例如问是否有必要做这个事情（责任边界）

事情都没有必要去做的话

问这个事情做的对不对

本身就没有意义

回归系统的责任边界

即系统提供的，涉众愿意接受的服务

会是我们筛选系统用例的一个最重要的标准。

参考书籍《软件方法（上）》，作者“潘加宇”