用例文档是一种需求文档还是详细设计文档？(附例)，谢谢!
举个例子先：
用例“工艺变更”
1．工艺管理员选择需要变更的工艺流程
1.a 系统显示已审核工艺流程列表
2．工艺管理员要求变更工艺流程
2.a 系统审核查看零件工艺流程的状态。
2.b.系统显示用户选择需要更改的类型：零件工艺顺序、零件工艺文件资料、加工其他辅助信息。
3．工艺管理员选择更改工艺顺序
3.a系统显示工艺流程更改界面
4．工艺管理员调整工艺流程的顺序
4.a系统创建新的工艺流程顺序
4.b系统自动生成新的零件工艺流程版本号
1 2 3 4 表示用户操作，a,b,c表示该操作引起的系统响应。
我觉得这样一个用例变成了详细设计了，和用例文档是一种需求文档的说法不相一致。
并且，我有个奇怪的认识，
OO可能就是这种，从下而上的分析方法，然后在这个基础上建立类之间的内聚，实现组建的可扩展
大家指点以下我， 谢谢！ :)
问题点数：60、回复次数：49Top
1 楼Fusuli（傻强）回复于 2005-08-09 18:18:58 得分 0
用例是描述需求的，不是描述系统的！
也就是说用例要让最终用户能够看懂并且认可，而详细设计最终要让开发人员看懂并且认可Top
2 楼singlepine（小山）回复于 2005-08-09 22:13:43 得分 0
用例是业务需求，是程序开发的一个依据，它主要描述业务的流程，正常走下去和不正常走下，会有那些动作，需要程序员在开发过程中考虑到。
还有一种详细设计文档则细化到了代码怎么实现，比如
---------------------------------
if 审核通过 then
跳到a页面
else
跳到b页面
end if
--------------------------
相关的表等也会列出来，甚至还会把sql语句写出来(或一些主要的关联关系)。Top
3 楼kingofhawks（蓝鹰）回复于 2005-08-10 08:46:22 得分 0
回复人： Fusuli(傻强) ( )
用例是描述需求的，不是描述系统的！
也就是说用例要让最终用户能够看懂并且认可，而详细设计最终要让开发人员看懂并且认可
Top
4 楼stillfire（恒）回复于 2005-08-10 08:46:43 得分 0
那么，我上面做的是否正确，
就拿我的例子来说，
这里的用户操作 自然是需要用户确认的，是需求，而系统操作 描述系统行为 要细化到什么程度呢？象上面我做的，
2．工艺管理员要求变更工艺流程
2.a 系统审核查看零件工艺流程的状态。
2.b.系统显示用户选择需要更改的类型：零件工艺顺序、零件工艺文件资料、加工其他辅助信息。
这里就存在一个逻辑
if (工艺流程.get状态==通过)
允许变更
else
不允许
用例文档时候需要详细到这一层次，或者更细一些？Top
5 楼aboush（无人居）回复于 2005-08-10 11:27:06 得分 0
我认为楼主的问题在于用例不是水平状的,而是层次状的.
不同目的的用例描述的层次是不同的.
楼主写的用例是系统用例.描述的是用户与系统的交互.这个层次上的用例,主要关注系统的行为对用户的价值是什么.
但是需要强调的是没有一个用例(除了最上层的用例)是单独存在的,用例都有其上下文.
那么楼主的"工艺变更"的上下文是什么呢?楼主可以问自己什么情况下会变更工艺呢?
楼主的回答就可能是在工艺变更这个用例的上层用例了.
再回到这个用例,我的几点意见:
1. 既然是用户和系统的交互,那么要看系统行为是不是对用户有价值.比如:显示一个更改界面能对用户有什么实际价值嘛?但显示已审核工艺流程是有价值的.
2. 零件工艺顺序、零件工艺文件资料、加工其他辅助信息这种详细信息就最好不要放在用例里面,连接到外部文档比较好.
3. 象楼主的用例一个系统可能会写上几百个了,考虑是不是真的需要写.就象创建客户这样的用例.没有人会无缘无故创建的客户的.Top
6 楼stillfire（恒）回复于 2005-08-10 14:57:35 得分 0
to : aboush(无人居)
谢谢您宝贵的意见，：）
你的意思是 用例应该是水平的，而不应该是层次状的？
那么，用例 include 和 extend 是不是应该算成一种层次关系呢？
“什么情况下会变更工艺” 这里面的 "工艺变更"是在用户提出工艺变更请求的时候发生的，而究竟什么时候才提出这样一个请求，这个是我们系统不能触及到的，比如（生产事故出现过多，工艺损坏），我觉得可以把它理解为最上层的 用例。Top
7 楼Fusuli（傻强）回复于 2005-08-10 15:02:43 得分 0
楼主你说了半天其实就是用例粒度的一个问题,建议先看看相关书籍,论坛里也有这样的帖子:
http://community.csdn.net/Expert/TopicView.asp?id=4160648Top
8 楼aboush（无人居）回复于 2005-08-15 11:30:16 得分 0
楼主说的和我想的相反.
1.用例就是层次状的,不是水平状的.
2.有些问题,你不去理解是没有办法找到合适的解决方案的.比如你说的"这个是我们系统不能触及到的".这是现在很多需求人员的借口.你需要分析,采集这些情况,理解这些行为的动机,你才能清楚的描述问题域,只有搞清楚问题域所在,才能有合理的解决方案.
3.再次强调用例的层次的问题.不同的层次上的用例关注的问题点是不同的.但同一层次上的用例应该保持关注水平统一.有关用例的粒度问题,我也关注很久,感觉没有统一的规则,不同的情况粒度是不同的,即用例层次细化不同.但有一点可以参考一下:用例的目的是什么?如果你能一直牢记这点,相信你的用例粒度不会偏差太远.
比如:你的用例是给用户确认问题域的,那如果你的用例里面有系统这样的层次会使用户感到迷惑,你如果深入到子系统就更偏离你需要用户确认问题所在的本质目的了.
你的用例是给用户体验系统和自己交互的(包括给开发人员作为系统需求).那么你应该以用户目标级别的用例为主,子系统为辅助了.
随便说了点,大家多多发言...Top
9 楼tdaly（溜达溜达）回复于 2005-08-15 16:55:20 得分 0
用例是描述需求的，不是描述系统的！
也就是说用例要让最终用户能够看懂并且认可，而详细设计最终要让开发人员看懂并且认可
----------
简洁深刻。Top
10 楼Fusuli（傻强）回复于 2005-08-15 22:02:34 得分 0
简洁深刻
------------------
这是我追求的风格Top
11 楼cnyining（）回复于 2005-08-17 12:51:02 得分 0
用例用来描述需求、进行需求分析的，表示了输入输出，反映了用例相互关系，描述了场景等。Top
12 楼shunliu7521（吃老实饭,做老实人 ）回复于 2005-08-18 17:26:44 得分 0
呵呵,简洁深刻~Top
13 楼showerXP（小阿！）回复于 2005-08-19 18:04:06 得分 0
1．工艺管理员选择需要变更的工艺流程
1.a 系统显示已审核工艺流程列表
2．工艺管理员要求变更工艺流程
2.a 系统审核查看零件工艺流程的状态。
2.b.系统显示用户选择需要更改的类型：零件工艺顺序、零件工艺文件资料、加工其他辅助信息。
3．工艺管理员选择更改工艺顺序
3.a系统显示工艺流程更改界面
4．工艺管理员调整工艺流程的顺序
4.a系统创建新的工艺流程顺序
4.b系统自动生成新的零件工艺流程版本号
============================================
对于这样的用例，新接触项目的人是很难理解的。怎么强调“用例是描述需求的”都不为过。另外，不要把用例当成“大杂烩”，什么界面说明，业务规则全部反映在场景的步骤中。注意一定的通用化格式，你这种写法不知道从哪里看到的，还是自己想出来的。当然，如果你用这种格式一点障碍都没有，而且别人理解起来也一点问题都没有的话，就无可厚非。
多看看书吧！Top
14 楼showerXP（小阿！）回复于 2005-08-19 18:15:51 得分 0
用例“工艺变更”
1．工艺管理员选择需要变更的工艺流程
2、 系统显示已审核工艺流程列表供管理员选择
3、管理员选择其中一个变更工艺流程
4、系统审核工艺流程的状态，并提供零件工艺顺序、零件工艺文件资料、加工其他辅助信息
5、管理员选择更改工艺顺序，并能调整工艺流程顺序。
6、管理员确认无误后，系统产生新的工艺流程顺序和工艺流程版本
以上只是一个主成功场景，一般一个用例很可能包括很多不成功的失败场景。如果这样的话就用“2a,2b,2c,2d”等步骤来推动用例。Top
15 楼cdstarnet（星品网）回复于 2005-08-21 00:55:27 得分 0
星品网(http://www.cdstar.net)1000多款最新软件游戏和影视光盘促销,每张原装光盘4元,24H送货上门,进来看看!Top
16 楼xh308（xiaohu）回复于 2005-09-25 16:15:01 得分 0
简洁深刻，我喜欢。。。。Top
17 楼hahahahah（裆中央总竖鸡 - 以阿扁下野为荣，以小胡连任为耻！）回复于 2005-09-26 10:14:08 得分 0
楼主的例子，是一个sub-function级别的用例的序列图
离详细设计的肠子还远着呢Top
18 楼hahahahah（裆中央总竖鸡 - 以阿扁下野为荣，以小胡连任为耻！）回复于 2005-09-26 10:16:00 得分 0
建议楼主去认真看看相关书籍，深刻理解什么叫做需求，什么叫做分析，什么叫做概要设计，什么叫做详细设计Top
19 楼ghxwzh（ghxwzh）回复于 2005-09-26 10:26:51 得分 0
学习Top
20 楼goodliness（今宵多美好）回复于 2005-09-26 13:36:50 得分 0
上面有人说到用例是描叙需求的，是要让最终用户认同的需求描叙形式。
我不完全同意这种说法，用例不是用来描述需求的，用例是需求分析过程中用到的一种方法，它引导你以一种正确的方式去做需求分析，需求分析的过程中可以用到用例，但是也不一定就离不开来用例，看这个系统是否适合采用用例去分析需求，需求分析告一段落的时候，不管前面是否使用还是没有使用用例，我觉得在需求文档中最后都不要使用用例符号，这样反而会使得用户迷糊，用户需要的是你帮他解决实际问题，他可不觉得自己的意图，被你用图像化的形式转化了一下，然后再来学习阅读这些图标从而来明白自己原来的那些意思，是件理所当然的事情。Top
21 楼goodliness（今宵多美好）回复于 2005-09-26 13:40:27 得分 0
就我的经验，多数用户，在你写出了详细的需求说明书后，他也是不愿意去细看的，他们更喜欢看可以运行的系统。那么这样需求文档更重要的作用是和设计开发人员进行需求沟通的一种工具，而地接任者也更喜欢直白点的形式。Top
22 楼qiujsh（www.chinascsoft.com）回复于 2005-09-26 17:17:20 得分 0
最近也在学这个东西，看大家都在讨论这个问题，能不能问个无关的问题，为什么现在做东西要把简单的问题复杂化，做系统要做三层，还要用UML，本来一个月能做完的活，这么做得做半年了，另外用UML的好处在哪里，很多人说为设计方便，以后维护方便，不用UML也可以设计成那样，而且时间更短，随着需求的不断的变化，文档跟不上，最终做出来项目可能跟文档差异很大，那边前期设计的UML文档可能价值也不大了Top
23 楼Suddy（风）回复于 2005-09-26 23:10:10 得分 0
该文档没有使用过多的技术实现词汇, 是需求文档Top
24 楼ftai1971（）回复于 2005-09-29 17:01:59 得分 0
to qiujsh(www.chinascsoft.com)
这要看你是在做什么样的项目了, 如果项目小, 可以不用这种烦琐的方法, 但对于较大的项目, 建议还是要这样做的, 用例描述可以表现出你对客户需求理解的程度, 同样也反映出用户希望的功能究竟是什么. 这仅仅是域模型需求调查的初步, 在用例的基础上, 你将会提析出域模型中的概念类, 这对设计阶段中的设计类来说是重要的, 有助于你抽象出设计过程中类, 帮助你真正引入到面向对象的设计领域中来. GRASP模式的分析会有助于你提高类的抽象性与质量性.
目前我们公司开发的一个项目, 由于前期对此关注的不多, 现在功能虽然出来, 但可扩展性及重用性就很差. 现在还要从头来补, 对整个软件要进行大的重构. 化的时间, 人力, 物力更多!
Top
25 楼sp1234（asp.net不是一个语言，是一个操作系统）回复于 2005-10-02 15:41:18 得分 0
功能分解有明确的方法，各位可以参考传统软件工程中的具体说明。
所以，把用例说成是功能分解，这是因为不了解传统（至少30年前）软件工程早已经有比用例更有效说明系统控制流图、功能分解的方法。
用例有效地说明系统的功能需求，是满足决策型用户的需求的，而不是毫无主见的纯粹事务型用户的临时需求。如果用例仅仅满足后者，那么需求分析就失败了，随时会变来变去。Top
26 楼sp1234（asp.net不是一个语言，是一个操作系统）回复于 2005-10-02 15:47:13 得分 0
用例也可以用来作为测试用例，这时候尽可以随便你怎么细节化也行。但是，测试用例也必须根据具体开发实际随时修改。如果明确自己写的是测试用例，就不会提出搂主的问题了。
所以，结论是：楼主的用例对整个系统的建设没有该有的价值，属于大事反映不了小事斤斤计较那种不成熟设计。Top
27 楼BirdGu（鲲鹏）回复于 2005-10-03 10:08:24 得分 0
楼主的问题是对详细设计的理解错误。你写的用例离详细设计还差十万八千里呢。Top
28 楼go_fan（木野狐）回复于 2005-10-21 16:12:40 得分 0
我一直觉得“用例”是老外“白板文化”体现，有讨论，反馈，结队的氛围。用例，包括UML 都不应该过度设计，超前设计。RUP是“用例驱动，迭代开发”。它不应该重量级，而应该如XP的轻量级。试问：用例能成为法定的“需求规格说明书”的一部分吗？UML 应该粗粒度宏观分析，不求甚解。如果要功能分解，则仿照结构化数据流图做子图。但迭代开发允许不断修改需求，这需要你架构设计上有前瞻性。必要时还可能“重构”。当然OO分析比过去的功能模块分析天生要更灵活一些。Top
29 楼showerXP（小阿！）回复于 2005-10-21 21:57:34 得分 0
同意楼上的所说。这就和黑猫、白猫道理一样。
又如：
试问：用例能成为法定的“需求规格说明书”的一部分吗？
同样可以再问：用例“不”能成为法定的“需求规格说明书”的一部分吗？
其实，什么过度设计、超前设计、进度慢等等问题不是用例本身的问题，而是人的问题。只不过用例有充当以上问题诱因的嫌疑。Top
30 楼hmf3000（邱正男）回复于 2005-10-22 11:22:00 得分 0
用例应该是用来描述系统功能的，所以属于需求文档！！！Top
31 楼showerXP（小阿！）回复于 2005-10-22 22:45:27 得分 0
可能是我的思维有些跳跃得出了“什么过度设计、超前设计、进度慢等等问题不是用例本身的问题”这么一句话。
用例是用来描述功能性需求。
需求分析是设计的前的质量。很多人不断的做需求分析以期得到一个好的设计。而事实却往往不如愿。所以将原因转嫁到对项目而言经常是一纸空文的“用例”身上。Top
32 楼go_fan（木野狐）回复于 2005-10-24 10:04:15 得分 0
说极端一点，需求分析和设计之间的鸿沟并没有在用户、系分人员、开发人员真正融合。因为从问题域到计算机空间并不能完全匹配，等价印射。不同层次、业务类型的人员以自己的视角切入，带着自己的需求想法去审视理解一个系统，实际上是“盲人摸象”的状态。也许只有GOD能够从全局看到系统的全貌，同时又能如庖丁解牛，深刻洞察其七筋八脉。而且这其间的每一环犹如链条一样，缺一不可，不能“短板”，否则系统将从其最薄弱的环节崩溃。从“神六”上天可见大系统的复杂性。因此UML和用例对软件工程来说依旧是“没有银弹”。
所以微软并没有过分依赖UML，它用的是MSF. RUP是ROSE（被IBM收购）宣传的。我们不能迷信。还是邓老那句话：不管黑猫白猫，抓得到耗子的就是好猫。形式为手段服务，殊途同归。不要犯买椟还珠的错误。
扯远了些，有感而发。还是多谈技术，少谈主义：）
注：微软解决方案框架MSF(MicrosoftSolutionFramework)是微软公司，以及微软的产品开发者、IT组织、咨询专家、客户和全球范围合作伙伴的软件开发的经验的总结。MSF的3个基础模型：风险管理模型、小组模型及过程模型。MSF的4种软件开发范型；企业体系结构原理、应用开发原理、构件设计原理及基础设施部署原理。Top
33 楼yqydaful（无边落木）回复于 2005-11-03 10:06:57 得分 0
go_fan(木野狐)说的好Top
34 楼wangyangcheng（矛盾）回复于 2005-11-13 00:57:18 得分 0
Learning...Top
35 楼ZeusStar（修身齐家治国平天下）回复于 2005-11-14 13:27:06 得分 0
阅。Top
36 楼jordanxubin（许斌）回复于 2005-11-16 19:35:08 得分 0
用例描述的是需求这点是肯定的，不过描述需求有很多种，比如数据流图，不过它们之间是有区别的，数据流图其实就是功能图。
而所谓用例，就是一种用户正确对系统的一次有意义的使用，而不是系统的业务流程（这就是功能），用例是分用户的，描述的是每种用户怎样来使用系统。
楼主举的例子，我觉的就只有一个用例在里面就是给管理员使用的工艺变更，因为其它的每个小项都是为了工艺变更而存在，如果单独存在对管理员是每有任何意义的。Top
37 楼zhangmike（zhangmike）回复于 2005-11-16 19:39:29 得分 0
用例分析属于需求。
楼主的例子是典型的需求。
Top
38 楼zhangmike（zhangmike）回复于 2005-11-16 19:40:51 得分 0
在OO中，详细设计中典型应当有类，类的方法名称，参数和返回类型。
楼主所提供的例子显然没有以上特征。
Top
39 楼rainlight（蓝色的海）回复于 2005-12-08 17:37:24 得分 0
用例着重在需求上面Top
40 楼heqinchen（风之语）回复于 2005-12-13 23:04:46 得分 0
唉,都是高人啊!!Learning................Top
41 楼lizi02（冬虫夏草）回复于 2006-03-15 12:44:26 得分 0
唉..
学习...Top
42 楼sucan（凤梧）回复于 2006-05-30 12:49:39 得分 0
学习...
Top
43 楼yuyifriends（追风少年）回复于 2006-05-30 19:26:16 得分 0
今天刚作完以用例为中心的需求分析报告，算来是第三种方式写需求报告了，觉得以用例为中心的需求分析报告是最好用的。
按照《3P》的思想，源代码就是设计，这样是否可以推出根本就没必要把需求和系统设计区分很清楚？系统设计的过程某种程度上就是需求细化的过程。
个人的体会，用例最大的作用在于分清用户要干的每件事情，然后是细化到测试人员需要的层次－－－开发人员喜欢看的很少，也需要给他们留出足够的供他们发挥的空间。Top
44 楼nirvana_li（东成西就,芝兰境界）回复于 2006-06-18 20:55:13 得分 0
用例文档是需求文档，而且主要还是功能性需求文档。用例描述，用例图，补充规约，术语表……都是用来进行需求工程的手段，主要是为满足涉众的利益，产生有价值的结果。
而且OO思想和用例并没有一定的关系，采用用例的方式只是一种需求手段。和XP里面的Story一样，都是需求手段。
它绝对不同于详细设计。详细设计的时候面向的是系统，而不是涉众。详细设计考虑的除了功能性需求之外，还更多的会考虑非功能性需求。即，RUP中的FURPS＋模型。Top
45 楼zhangcf76（依贝贝）回复于 2006-06-22 15:38:41 得分 0
我不太赞成用例文档是需求文档。简单的从“阅读对象”的角度来谈：
1、软件工程的第一个里程碑是“软件项目规划得到认可”，它产生的文档是《需求规格说明书》。而《需求规格说明书》的阅读对象是用户，用户是看不懂用例图的， 用户能看懂的是业务流程图，能看懂系统要显示哪些表单等等，而用例图是给我们软件人员看的。
2、软件工程的第二个里程碑是“完成产品设计”，它产生的文档包括《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》。由于《需求规格说明书》是用自然语言描述的，所以对于系统设计师一方面要精通业务，至少理解用户的业务，另一方面还要精通如何将业务模型转化成设计模型。这时对于我国一般的软件企业，都会有一个中间文档，我把它称作《详细的需求规格说明书》，它是面向软件人员的一种需求规格说明书，在这里会用到用例图。
可能会有朋友说，我们公司没有什么《详细的需求规格说明书》啊，但是请想想，我们通常写的《需求规格说明书》是不是都带有很浓厚的“设计”思想？是不是恨不得在做需求的时候就把设计怎么实现都写出来了？用户是往往看不懂的。——为什么会这样？因为我们把给用户看的《需求规格说明书》，写成了面向软件人员的《详细的需求规格说明书》了。
3、在概要设计时要用到用例图，因为概要设计是个承前启后的过程，它要兼顾需求，又要兼顾详细设计。它的阅读对象是软件人员。Top
46 楼nirvana_li（东成西就,芝兰境界）回复于 2006-06-22 17:14:07 得分 0
楼上混淆一个概念《需求规格说明书》和 《 用例文档》 是不同的。
《需求规格说明书》是关于需求的概况，而
《用例文档》 是需求的具体细节及过程。Top
47 楼zhangcf76（依贝贝）回复于 2006-06-23 09:02:53 得分 0
singlepine(小山)所说的“用例是业务需求，是程序开发的一个依据，它主要描述业务的流程”，感觉此言不妥，
业务的流程是跨包描述的，用例图是对包内部的描述。Top
48 楼raze911（）回复于 2006-06-25 19:29:50 得分 0
我个人的理解:
用例文档是用户可以看懂的
用例文档直接描述了用户与系统的交互过程
比如ATM机例
用例文档会展示以下事件流：
用户->选择查询帐户余额->系统读取余额->系统显示余额
至于用什么样的技术手段来读取余额及显示余额,就不用在用例中描述了
而如果需要在当余额为透支状态时显示警告信息,则可以在用例文档中写入"非正常事件流"
所以,用例文档在某个程度上可以做为客户级的评测文档(比较粗糙级别的评测文档),来视查客户所要求具备的系统功能是否具备,及所实现的用户交互过程是否符合用例描述
用例描述通常应该由需求分析员与客户共同讨论而得,这样客户在软件设计过程的一开始,就可以了解未来与软件的交互过程,客户有可能会提出比较详细的自己设想的交互过程,而系统分析员根据客户的描述结合自己的经验提出改进建议并把最终讨论结果以标准文档模式记录下来
之后,在用例文档(或用例图)的基础上由系统分析员分析出业务实体类,之后进行类的抽象,画类关系图
另外说一点,我觉得系统分析员的概念是否应该分两个层次,一个层次是需求分析级系统分析员,就是分析客户需求,分析到业务实体类及类关系图这一层的；另一个层次则是在需求系统分析员所作工作的基础上考虑整个软件架构的稳定性\可扩展性\软件执行的性能等方面的软件实现级系统分析员Top
49 楼cms2140（敏盛）回复于 2006-06-26 10:20:46 得分 0
学习中^^^^Top
