系统用例和业务用例的区别

    楼主，请教一个问题：
    我现在在做一个项目，把所有的涉及到的业务都细分成添加、删除、浏览等等类似的一个个小的用例，这应该都是业务用例了，那请问我的系统用例是哪些呢？应该怎么写？或者说有必要写吗？（你可以拿一个电子商务的系统作例子指导一下，多谢了！）

 

      你列举出的那些用例实际上都是系统用例了，你还怎么再细分呢？业务用例是指的业务目标，例如说维护人员档案，这是一个完整的业务目标，也是一个业务用例。至于维护办法，有手工的，有自动的，有的只能加不能删，有的只能修改，有的只能看....这些，是实现业务目标的方法。在这些方法中，打算纳入软件开发范围的，才叫做系统用例。

 

 

楼主，多谢你的指教
那我是不是可以这样理解呢，如果把业务用例进行功能上的细分的话，分成若干个小的用例，那么这些小的用例是不是就是系统用例？
就象维护人员档案，如果细分成添加档案，修改档案，删除档案，查看档案等等。。。
如果你的答案是肯定的话，那我是不是可以继续这样理解：一般情况下，业务用例实际上是在一个比较高的层面上来看业务逻辑，更接近于用户的直接需求，而系统用例则是业务逻辑的详细的划分，更接近与程序的设计了？
多谢你的赐教！！！！！

 

 

不大对喔。系统用例和业务用例的区别并非是细分。
请注意理解：业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业务目标组成。比如一个档案管理员，他的业务目标就是维护档案。比如论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的全部。业务用例体现了需求。
而需求的实现有多种方式。如何实现它，是由系统用例来体现的，它们并不是一个简单的细分关系，虽然看上去象。就说维护档案吧，这样一个业务目标，会有多种不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案....对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪些部分是要纳入系统建设范围的。比如维护档案业务用例中，假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就增加档案，删除档案，而没有修改档案。
业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性需求由这些系统用例构成。
所以业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。