真正的软件需求，从“系统用例”模块才成型，并独立讨论。
它来源于业务需要，从“优化后的业务流程”推导而出
但是“软件需求”，依然在关注“用户要解决什么问题”
它不是交互，不是设计，不描述“问题”最终的解决方案。
这里要补充根据系统责任边界来确定系统用例的例子。
我们用word文档来写作
我们用word文档来做标书
但我们不能把写作，或做标书
当成是word文档应该提供的服务或责任
真正有责任做标书的，或写作的，应该是那个责任人本身
而word，只是提供一个便捷的文字编辑器
进行写作文档的编辑
进行标书的编辑
所以，我们不能这样来画word的使用过程：
写作者要自己写作，而不是请求word文档写作
写作者可以请求word文档编辑文字
这个部分给我了很大的启示
就是在我们问这个事情做的对不对时候
我们可能是找不到答案的
我们可能要换个问题来问
例如问是否有必要做这个事情（责任边界）
事情都没有必要去做的话
问这个事情做的对不对
本身就没有意义
回归系统的责任边界
即系统提供的，涉众愿意接受的服务
会是我们筛选系统用例的一个最重要的标准。
参考书籍《软件方法（上）》，作者“潘加宇”
网友评论