1,265
社区成员
发帖
与我相关
我的任务
分享use case应该详细到什么程度？
首先说明，关于这些我懂得不是太多
use case diagram是不需要很详细
但是
老板让我写什么use case的description
说实在的我到现在还没有什么概念，
use case需要写得很详细吗？
最大程度因该详细到什么程度？
如果是最详细的use case文档，
编码人员有能变成只负责填写代码，
不用考虑任何复杂业务逻辑的角色吗？
希望有经验的人给我点提示，
分数自然不在话下，谢谢！
use case diagram是不需要很详细
但是
老板让我写什么use case的description
说实在的我到现在还没有什么概念，
use case需要写得很详细吗？
最大程度因该详细到什么程度？
如果是最详细的use case文档，
编码人员有能变成只负责填写代码，
不用考虑任何复杂业务逻辑的角色吗？
希望有经验的人给我点提示，
分数自然不在话下，谢谢！
...全文
请发表友善的回复…
发表回复
yangcl 2003-08-05
- 打赏
- 举报
多谢ozzzzzz(希望敏捷)的回复
看来我对软件设计的理解还远不够
要学的东西还很多
看来我对软件设计的理解还远不够
要学的东西还很多
yunhi 2003-08-05
- 打赏
- 举报
ozzzzzz(希望敏捷) 的解释经典，透彻。
hurricane 2003-08-04
- 打赏
- 举报
Use Case 主要是用来描叙需求的， 大概就是针对不同的角色，有不同的行为或功能
它的作用是为了使用户或程序员更好的理解业务逻辑
至于用例的大小么，既不能太大，也不能太小，这就是用例的粒度大小的问题
通常编码人员是不会直接从use case直接写代码的，那通常是详细设计之后的事情
它的作用是为了使用户或程序员更好的理解业务逻辑
至于用例的大小么，既不能太大，也不能太小，这就是用例的粒度大小的问题
通常编码人员是不会直接从use case直接写代码的，那通常是详细设计之后的事情
ozzzzzz 2003-08-04
- 打赏
- 举报
use case是一种uml吗 答案是--不是 但是use case可以用uml符号来说明 当然也可以不用 use case是一种格式化的文档 它是是由用户和系统在一次对话中执行的一个特殊事务序列
当然我观察这里大多数人都在说use case的时候 其实他们是在说use case diagrams
use case需要写的很详细吗 其实这个问题如果这样问use case 需要一开始就写的很详细吗 还有所有的use case都需要在开始的时候就写的很详细吗 我认为这会由于你是不是支持迭代而有所不同 而统一的答案是没有的
那么能详细到什么程度呢 实际上对use case描述的详细程度一直是一个没有统一答案的问题 有各种各异的说法 当然可能在瑞理那里你会得到的答案是统一的 但是你记住use case不是瑞理私有的一种技术 所以你应该可以建立起符合自己组织实际情况的一套标准 而你这里说的详细标准 我看是指的说明的详细程度 而不是对use case粒度划分的程度 这不是大问题 其实我看只要你可以把你的业务流程表叔清除 而没有角色和动作的遗漏就可以了 当然不要忘记前置和后置条件
use case实际上是一种需求的分析工具 而且它之停留在系统的外部 而不应该试图去用它来说明系统内部的运行情况 系统内部的运行情况是你的设计工作所要解决的问题 所以你不管对use case书写多么详细 也不可能代替你的设计 不可能会发生coder看着use case直接向里面填写代码的事情发生 但是我不知道你指的复杂的逻辑角色是什么 如果你指的是系统运行时候参与的角色 那么我认为你必须在需求中解决这个问题 也就是你必须在use case中把它们表达清除 而具体如何通过对它们的计算得到最后的结果 则不是use case所包括的必然部分 当然你给出解决方法(可能是客户现在的解决方法 也或许是你从什么地方找到的方法)会有好处
还有我不认为你可能把use case书写到一个对业务完全不懂的coder看过你的use case就能了解业务了 这是不太可能的 当然我不排除有这样的例子 但是如果你试图这样做你就要准备把你的use case书写成一部业务手册 其实use case还是要和客户的现场答疑 顾问的咨询 业务资料的研读等多种方法结合才可能使coder对业务有一个大概的了解 当然即使是这样你依然部可能要求他们吃完领域专家
最后说说用例的粒度问题 这是一个老话题 我在这个地方就回答过多次 我现在依然认为use case的粒度划分没有一个绝对的标准 你只是要做到适合自己使用就可以了 如果你认为增加记录可以是一个use case 那么就是一个use case好啦 这是你的选择 你只是需求对你划分粒度所带来的后果做成评估
当然我观察这里大多数人都在说use case的时候 其实他们是在说use case diagrams
use case需要写的很详细吗 其实这个问题如果这样问use case 需要一开始就写的很详细吗 还有所有的use case都需要在开始的时候就写的很详细吗 我认为这会由于你是不是支持迭代而有所不同 而统一的答案是没有的
那么能详细到什么程度呢 实际上对use case描述的详细程度一直是一个没有统一答案的问题 有各种各异的说法 当然可能在瑞理那里你会得到的答案是统一的 但是你记住use case不是瑞理私有的一种技术 所以你应该可以建立起符合自己组织实际情况的一套标准 而你这里说的详细标准 我看是指的说明的详细程度 而不是对use case粒度划分的程度 这不是大问题 其实我看只要你可以把你的业务流程表叔清除 而没有角色和动作的遗漏就可以了 当然不要忘记前置和后置条件
use case实际上是一种需求的分析工具 而且它之停留在系统的外部 而不应该试图去用它来说明系统内部的运行情况 系统内部的运行情况是你的设计工作所要解决的问题 所以你不管对use case书写多么详细 也不可能代替你的设计 不可能会发生coder看着use case直接向里面填写代码的事情发生 但是我不知道你指的复杂的逻辑角色是什么 如果你指的是系统运行时候参与的角色 那么我认为你必须在需求中解决这个问题 也就是你必须在use case中把它们表达清除 而具体如何通过对它们的计算得到最后的结果 则不是use case所包括的必然部分 当然你给出解决方法(可能是客户现在的解决方法 也或许是你从什么地方找到的方法)会有好处
还有我不认为你可能把use case书写到一个对业务完全不懂的coder看过你的use case就能了解业务了 这是不太可能的 当然我不排除有这样的例子 但是如果你试图这样做你就要准备把你的use case书写成一部业务手册 其实use case还是要和客户的现场答疑 顾问的咨询 业务资料的研读等多种方法结合才可能使coder对业务有一个大概的了解 当然即使是这样你依然部可能要求他们吃完领域专家
最后说说用例的粒度问题 这是一个老话题 我在这个地方就回答过多次 我现在依然认为use case的粒度划分没有一个绝对的标准 你只是要做到适合自己使用就可以了 如果你认为增加记录可以是一个use case 那么就是一个use case好啦 这是你的选择 你只是需求对你划分粒度所带来的后果做成评估
XACZ 2003-08-04
- 打赏
- 举报
你们老板根本就不知道什么是UML,UML提供了很多工具来从不同侧面来描述一个系统,use case 大量用来描述系统和外部的交互,而不是把什么都用USE CASE来做.如果那样,还要时序图,状态机等等干什么呢?总的来说use case是从高层来描述系统的,你甚至可以用一个USE CASE来描述你的系统,但大多数情况下是使用多个小的USE CASE来构成用例模型.
你的问题是USE CASE的粒度划分问题,： 如zhaoxichao(小西)说的定要对Actor是有意义的功能,其他增加记录，修改记录，删除记录可作为扩展来描述.
你的问题是USE CASE的粒度划分问题,： 如zhaoxichao(小西)说的定要对Actor是有意义的功能,其他增加记录，修改记录，删除记录可作为扩展来描述.
yangcl 2003-08-04
- 打赏
- 举报
增加记录，修改记录，删除记录不能作为单独的use case吗？
我听老板的意思好象连编程涉及到的流程都要写上
大家觉得有必要吗？
我听老板的意思好象连编程涉及到的流程都要写上
大家觉得有必要吗？
zhaoxichao 2003-08-04
- 打赏
- 举报
我觉得usecase应该越细越好，直到系统功能不能再细分
但是一定要对Actor是有意义的功能，比如说增加记录，修改记录，删除记录这些都不能做为单独的usecase
但是一定要对Actor是有意义的功能，比如说增加记录，修改记录，删除记录这些都不能做为单独的usecase
yangcl 2003-08-04
- 打赏
- 举报
对呀，我老板也是这么说的，
不过如果真是这样的话，现实中能有几个公司有能力做到这点呢？
还有
大家平时的use case是做到什么程度的呢？
不过如果真是这样的话，现实中能有几个公司有能力做到这点呢？
还有
大家平时的use case是做到什么程度的呢？
tongerlhy 2003-08-04
- 打赏
- 举报
我个人意见use case应当细到相当的程度，起码应当细到让一个对业务逻辑不了解的人看过之后能够了解整个业务过程，只有达到这种程度的设计，具体的编码人员才能按照你的设计思想去填写代码。就像盖楼一样，建筑工人是不用（也不太可能）去考虑图纸是如果画成的。
